Kubernetes
Layer 5 · Post 2 of 12
← Previous: Containers → Next: Service Discovery
Layer 5 — Modern infrastructure · Post 52 of 88
Kubernetes schedules containers across machines, restarts what dies, and gives you a control plane for deploying and scaling services.
What you'll learn
What a Pod, a Deployment, and a Service each actually do
How the control plane notices a dead replica and replaces it
Why Kubernetes is an API you declare desired state to — not a host you SSH
The idea in one minute
Kubernetes (k8s) is a cluster OS for containers. You say "I want 3 copies of payments:1.4.2 behind a stable name." The control plane places them on nodes, watches them, and reconciles when reality drifts.
You: "3 replicas of payments" | v [ API server + scheduler ] | +--> Node A: pod +--> Node B: pod +--> Node C: pod
You do not pick a machine by hand. You declare desired state. Kubernetes loops until actual state matches.
Why it matters
Containers solve packaging. They do not solve "the box died at 3am" or "I need a DNS name that survives pod IPs changing every deploy."
Kubernetes is the default interview answer when you have many services, rolling deploys, and unattended restarts. Saying "we'll run it on Kubernetes" is not a design; naming Pods, Deployments, and Services is.
How it works
Three objects cover most whiteboard designs.
Pod
A Pod is the smallest deployable unit: one or more containers that share a network namespace and volumes. Your app is usually one container per Pod; a helper (log shipper, mesh proxy) can sit beside it. Pods are mortal — their IPs die with them. You almost never create a lone Pod in production and hope.
Deployment
A Deployment says: keep N replicas of this Pod template. It owns a ReplicaSet. If a node vanishes, a replica count drops, and a new Pod is scheduled elsewhere. A new image tag triggers a rolling update: new Pods come up, old ones drain, you can roll back to the previous ReplicaSet.
Service
A Service is a stable virtual IP and DNS name (payments.default.svc) plus a selector. It load-balances to whatever Pods currently match. ClusterIP is internal. LoadBalancer / Ingress is how the internet reaches you. Next post is discovery in more depth.
Control plane vs nodes
The API server is the front door. etcd stores cluster state. The scheduler binds Pods to nodes. kubelet on each node starts containers and reports health. kube-proxy (or equivalent) programs Service networking.
Health checks matter: liveness restarts a stuck process; readiness removes a Pod from the Service until it can take traffic.
A simple example
You deploy payments with replicas: 3, a readiness probe on /health, and a Service. One node fails. Kubernetes schedules a replacement. The Service drops the dead endpoint. Users see a blip, not a war room, if the remaining two can take the load.
You ship 1.4.3. New Pods come up; when they pass readiness, old 1.4.2 Pods terminate. If 1.4.3 crash-loops, you roll back. That story is what interviewers want — not CKA trivia.
Common mistakes
Putting state in the Pod's disk. Deploys and reschedules wipe it. Use a database, object storage, or a PersistentVolume with a real story.
No resource requests/limits. The scheduler packs blind; one noisy neighbor OOMs the node. Request what you need; limit what you can afford.
Skipping probes. A process that is "running" but deadlocked still gets traffic. Readiness is not optional for rolling deploys.
Treating Kubernetes as the product. YAML is not a substitute for backpressure, timeouts, and idempotency.
How this shows up in real systems
EKS, GKE, AKS: managed control planes so you do not babysit etcd.
Helm / Kustomize / GitOps (Argo CD, Flux): desired state in git, applied continuously.
Jobs / CronJobs, HPA, Ingress: batch, scale, and HTTP entry.
You can run containers without Kubernetes (ECS, Cloud Run, Nomad). Pick k8s when declare-and-reconcile matches the problem.
Recap
A Pod is a running unit; a Deployment keeps N of them; a Service is the stable name in front.
Kubernetes reconciles desired state: dead replicas get replaced, rolling deploys are the default path.
You talk to an API, not to boxes. Health probes and resource requests are part of the design.
Pods come and go. Next: how callers find whatever is alive right now.
Layer 5 · Post 2 of 12
← Previous: Containers → Next: Service Discovery
Comments