Roadmap
Kubernetes orchestrates containers across machines: schedule, replicate, heal, roll out. You declare desired state (replicas: 3); controllers keep reality aligned. In interviews it answers "how do we run the app tier?" — pair with horizontal scaling and an API gateway/Ingress. Don't lead with K8s before you've justified stateless replicas.
Pod
Deployment
Service · Ingress
API + etcd
1 · Architecture
Control plane decides; workers run pods. Managed clouds (EKS/GKE/AKS) host the control plane — you still need to know what it does.
- API Server — only write path; AuthN/AuthZ, admission, Watch API.
- etcd — durable desired + observed state. Controllers never write it directly.
- Scheduler — binds unbound pods to nodes (filters + scores).
- Controller Manager — reconciliation loops (Deployment, ReplicaSet, Node, …).
- kubelet / kube-proxy / runtime — on each worker: run containers, publish Service routes.
kubectl apply path: validate → write etcd → controllers react → ReplicaSet creates Pods → scheduler binds → kubelet starts containers.
Vocabulary
- Pod — smallest unit (one+ containers). Ephemeral IP — never address pods directly.
- Label / selector — how Services and ReplicaSets find pods.
- Namespace — isolation boundary (team / env).
- Deployment — how you manage replicas and rollouts (not bare Pods).
2 · How replication works
Set replicas: 3. Controllers compare desired vs actual and fix drift. Not disk copying — N copies of a pod template kept alive by a loop.
- Deployment — user object: template, count, rollout strategy; owns ReplicaSets.
- ReplicaSet — ensures N matching pods exist (rarely edit directly).
- Pod — running instance with ownerRef for garbage collection.
When a replica dies
- Container restart — same Pod/IP; kubelet restarts per
restartPolicy. - Pod replacement — new Pod object (new name/IP); needs schedule + readiness before Service traffic.
- Probes — liveness = restart process; readiness = join/leave Endpoints; startup = slow boot grace. Don't liveness-check the DB.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels: { app: api }
template:
metadata:
labels: { app: api }
spec:
containers:
- name: api
image: myregistry/api:2.0.0
ports: [{ containerPort: 8080 }]
readinessProbe:
httpGet: { path: /ready, port: 8080 }
livenessProbe:
httpGet: { path: /health, port: 8080 }
resources:
requests: { cpu: "250m", memory: "256Mi" }
limits: { cpu: "500m", memory: "512Mi" }Rollouts
Image change → new ReplicaSet → rolling update (maxSurge / maxUnavailable). kubectl rollout undo reverts. Use a PodDisruptionBudget so node drains don't take too many replicas down.
3 · Networking & scaling
Pods get cluster IPs that change. A Service gives a stable DNS + virtual IP over ready pods (selected by labels). Ingress adds HTTP host/path routing (needs a controller).
- ClusterIP — internal only (default).
- LoadBalancer — cloud LB in front.
- NodePort — debug / simple expose.
- Misaligned labels — empty Endpoints = 502 with "healthy" pods.
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector: { app: api }
ports: [{ port: 80, targetPort: 8080 }]Autoscaling
HPA changes Deployment replica count from metrics. Cluster Autoscaler adds nodes when pods stay Pending. Mention both — HPA alone fails if the cluster is full.
State & other workloads
- StatefulSet — stable identity + PVC (brokers). Default APIs use Deployment.
- DaemonSet — one pod per node (agents).
- Job / CronJob — batch.
- Primary DBs → managed RDS/Cloud SQL, not DIY Postgres pods.
4 · Hands-on lab
Deploy → break a pod → watch heal → scale → rollout. Same story you'd tell verbally.
kind create cluster --name lattice-lab # or: minikube start
kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata: { name: demo-api }
spec:
replicas: 3
selector: { matchLabels: { app: demo-api } }
template:
metadata: { labels: { app: demo-api } }
spec:
containers:
- name: web
image: nginx:1.27
ports: [{ containerPort: 80 }]
---
apiVersion: v1
kind: Service
metadata: { name: demo-api }
spec:
selector: { app: demo-api }
ports: [{ port: 80 }]
EOF
POD=$(kubectl get pod -l app=demo-api -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod "$POD"
kubectl get pods -l app=demo-api -w # back to 3/3
kubectl scale deploy/demo-api --replicas=5
kubectl set image deploy/demo-api web=nginx:1.27-alpine
kubectl rollout undo deploy/demo-apikubectl cheatsheet
kubectl get deploy,rs,pods,svc -o wide
kubectl describe pod <name>
kubectl logs deploy/api -f --tail=100
kubectl get endpoints api
kubectl top pods
kubectl exec -it deploy/api -- /bin/shCost and performance levers
5 · In the interview
Propose K8s when
- Stateless services need horizontal scale + zero-downtime deploys.
- Independent release cycles, HPA, health checks.
- Team already on EKS/GKE/AKS.
Skip or defer when
- Single low-traffic monolith — VM/PaaS is enough.
- Primary database — use managed DB.
- Early MVP — ops cost delays product.
- Prompt doesn't need infra depth — "containers behind a load balancer" may suffice.
Pitfalls
- Scale pods without fixing DB connection pools.
- No resource requests/limits → noisy neighbor OOM.
- Liveness probing dependencies → restart storms.
- Ignore PDBs during drains.
Wrapping up
Roadmap recall: control plane writes desired state to etcd → Deployment/ReplicaSet keep N pods → Service/Ingress for reach → HPA (+ cluster autoscaler) for scale → propose only when the app tier needs it.
Related: Scalability, API Gateway, ZooKeeper / etcd patterns, Spark on K8s.