Kubernetes
Kubernetes does not "run your containers" the way docker run does. You hand it a declared desired state — three replicas of this image, reachable on this port — and a set of controllers work in a loop to make the cluster match that description, forever. A node dies, a pod crashes, you scale up: the reconciliation loop closes the gap without you touching anything. Internalising that one idea — declare the destination, let controllers drive — is what separates an engineer who operates a cluster from one who fights it.
This topic walks the whole stack in the order interviews probe it. We start with the core objects and the control loop, climb through the workload controllers that own your pods, then cover how pods get placed, connected, given storage, and locked down — and finish with the failure-signature toolkit you reach for when it all breaks at 3 a.m.
Topic map
- Core objects and the control loop — the Pod as the ephemeral scheduling unit,
Deployment → ReplicaSet → Pod, declarative reconciliation, theServiceVIP, and the control-plane components. - Workloads —
DeploymentvsStatefulSetvsDaemonSetvsJob/CronJob, rolling updates and rollback, probes, requests vs limits, and QoS. - Scheduling and resources — filter/score placement, taints that repel vs affinity that attracts, topology spread, priority/preemption, and disruption budgets.
- Networking — a routable IP per pod,
Servicetypes,kube-proxy, Ingress, CNI, CoreDNS, andNetworkPolicy. - Storage — the
PV/PVC/StorageClasstriangle, access modes enforced per node, reclaim policies, andStatefulSetvolumes. - Security — RBAC least privilege, ServiceAccount tokens, Pod Security Standards,
SecurityContext, and why Secrets are not encryption. - Troubleshooting — the failure-signature toolkit:
CrashLoopBackOff,ImagePullBackOff,Pending,OOMKilled, Ingress 503, and stuck rollouts.
Common traps
| Mistake | Consequence |
|---|---|
| Thinking a Pod self-heals | Nothing recreates a bare pod; only a controller does — deleting one that has no owner is permanent |
| Expecting a Pod to keep its IP | The address is ephemeral; the stable endpoint lives on the Service, not the pod |
Calling Ingress a load balancer for pods | Ingress is L7 HTTP routing that needs a controller; L4 balancing across pods is the Service |
Treating a Secret as encrypted | It is only base64-encoded and readable by anyone with get, unless etcd encryption is on |
| Confusing a memory limit with a CPU limit | Over a memory limit the container is OOMKilled; over a CPU limit it is throttled, never killed |
| Reading a taint as an attractor | A taint repels and a toleration only permits; to attract a pod you need nodeAffinity |
Interview relevance
Kubernetes is where a DevOps interview stops testing recall and starts testing your model of a distributed control system. The candidate who says "I declare desired state and controllers reconcile it" answers ten follow-ups at once; the one who lists commands stalls on the first "why".
Typical checks:
- Why a Pod is the scheduling unit and what recreates it when it dies.
- Where the stable address comes from and how a
Servicefinds its pods. - What a rolling update actually does and how to roll it back.
- How to read
Pending,CrashLoopBackOff, andOOMKilledfromkubectl describe/logs.
Common wrong answer: "Kubernetes restarts my pod when it fails." A bare pod is never restarted onto another node — a controller (Deployment, StatefulSet, DaemonSet) observes the shortfall and creates a replacement. The distinction is the whole point of the object model.