Kubernetes

Kubernetes is a declarative container orchestration platform. A cluster splits into control plane nodes (decision-making: API Server, etcd, Scheduler, Controller Manager) and worker nodes (execution:

This chapter goes deeper into each of the six components. Interviewers frequently ask you to walk through what happens when you run kubectl apply -- this chapter gives you precision on each of the six

A Pod is the smallest deployable unit in Kubernetes -- not a container. A Pod wraps one or more containers that share the same network namespace (same IP, same localhost) and can share storage volumes

A Deployment is the standard way to run stateless applications. A Deployment manages ReplicaSets; a ReplicaSet manages Pods. This two-layer design enables rolling updates: when the Pod template change

StatefulSet exists for workloads where Deployment's 'all replicas are interchangeable' assumption is false: databases, message brokers needing stable identity (predictable name, dedicated storage, fix

Job runs Pods to completion (a fixed number of successful completions) and stops -- the opposite of always-on services. CronJob is a Job template plus a schedule: it creates a new Job object at each s

Pod IPs are inherently unstable -- Pods are created and destroyed constantly. A Service is a stable virtual IP and DNS name that load-balances traffic across a dynamically-changing set of backing Pods

Ingress solves HTTP/HTTPS routing: one entry point routing to many backend Services by hostname and URL path, with centralized TLS termination. NetworkPolicy adds explicit allow rules; once any policy

A container's own filesystem is ephemeral. Kubernetes Volumes solve this at increasing levels of durability: emptyDir (Pod-lifetime), PersistentVolume/PVC (cluster-scoped, outlives Pods), and StorageC

Three independent, complementary autoscaling mechanisms. HPA changes replica count based on metrics. VPA changes per-Pod CPU/memory allocation. Cluster Autoscaler changes node count. They operate at P

Real clusters use four mechanisms to influence Pod placement: Node Affinity, Pod Affinity/Anti-Affinity, Taints and Tolerations, and Topology Spread Constraints. Each solves a distinct placement probl

Kubernetes security operates at complementary layers: RBAC governs API access. Service Accounts are the identity a Pod uses when calling the API Server. Security Context controls OS/kernel-level conta

Kubernetes observability is built from three tools: Prometheus collects metrics via pull-based scraping. Grafana reads from Prometheus to build dashboards. AlertManager receives alerts from Prometheus

Two complementary tools manage manifest complexity. Helm 3 uses templating plus chart packaging plus release lifecycle management. Kustomize uses structured overlay files that transform base manifests

Kubernetes native rolling update is one of several strategies. Blue-Green runs two full production environments simultaneously and switches traffic atomically. Canary routes a small percentage to the

Continuous Integration/Delivery automates the path from code commit to running production service. GitOps extends this with a core principle: Git is the single source of truth for desired cluster stat

A service mesh moves cross-cutting networking concerns (mTLS, retries, circuit breaking, traffic shifting, observability) out of application code and into an infrastructure layer. Istio is the most wi

Running Spring Boot in Kubernetes well requires integrating with five areas: health probes (Spring Actuator /health/liveness and /health/readiness mapping exactly to Kubernetes probe types), configura

Production Kubernetes requires deliberate design across four areas: High Availability (spreading control plane and workloads across failure domains), Disaster Recovery (etcd backup, cluster restore, a

Hardcoding a database URL or an API key into a container image means rebuilding the image just to change an environment's config. This chapter is Kubernetes' answer: three distinct mechanisms for injecting configuration and identity information into a running Pod without ever baking it into the image.

Requests and limits look like two simple numbers in a Pod spec, but they drive scheduling decisions, eviction priority, and two of the most common production incidents in Kubernetes: OOMKilled containers and invisible CPU throttling. This chapter is what those numbers actually do.

A single control-plane node is a single point of failure for the entire cluster. This chapter is how Kubernetes runs the control plane itself across multiple nodes without multiple copies of the Scheduler or Controller Manager stepping on each other.