Advanced Kubernetes Interview Questions

Analogy categoryAnalogies

What Senior Interviews Actually Probe

Advanced Kubernetes interviews rarely ask you to define a Pod; they probe how the control plane makes decisions under contention and failure. Expect questions about the scheduler's two-phase filtering-and-scoring process (predicates that eliminate infeasible nodes, then priority functions that rank the rest), how the kube-controller-manager's reconciliation loops converge desired state to actual state through repeated diffing rather than one-shot imperative commands, and how etcd's Raft consensus makes the control plane resilient to a minority of node failures but strictly requires a quorum majority to accept writes. Interviewers are testing whether you understand Kubernetes as a continuously reconciling distributed system, not a static configuration format — the strongest answers explain the 'why' behind a mechanism, like why etcd needs an odd number of members (3 or 5, not 4) to maximize fault tolerance per additional node.

🏏

Cricket analogy: It's like a national selection committee interview asking not 'what is a cover drive' but 'how do you build a batting order under pressure with two key players injured' — testing decision-making under real constraints, not textbook definitions.

Networking and Failure-Mode Depth

A staff-level Kubernetes interview often digs into the CNI layer: how kube-proxy implements Services via iptables or IPVS rules (and the performance tradeoffs between them at high Service counts), how a Service's Endpoints/EndpointSlices are kept in sync with matching pod readiness, and why a pod passing its liveness probe but failing readiness stays in the pod list yet gets removed from load-balancing entirely. Strong candidates can also reason about split-brain-adjacent failure modes — what happens during a network partition between a node and the control plane (the node is marked NotReady after the node-monitor-grace-period, but pods aren't evicted until pod-eviction-timeout elapses, deliberately trading faster failover against the risk of dual-writing if the partitioned pod is actually still running and reachable by clients on that side of the partition).

🏏

Cricket analogy: It's like understanding why a third umpire delays overturning a soft signal by several seconds rather than instantly — deliberately trading speed for certainty, similar to how Kubernetes waits out pod-eviction-timeout before acting on a suspected node failure.

A Representative Coding/Diagnostic Prompt

bash

# Interview-style prompt: "A Service has 3 backend pods but only 2 receive traffic. Diagnose."

# Step 1: confirm Service selector matches pod labels
kubectl get svc checkout-service -o jsonpath='{.spec.selector}'
kubectl get pods -l app=checkout --show-labels

# Step 2: check EndpointSlices for readiness state per pod
kubectl get endpointslices -l kubernetes.io/service-name=checkout-service -o yaml

# Step 3: inspect the excluded pod's readiness probe result
kubectl describe pod checkout-7f9d8c-zzzzz | grep -A5 Readiness

A very common interview trap: candidates conflate liveness and readiness probes. A failing liveness probe restarts the container; a failing readiness probe does NOT restart it — it only removes the pod from Service endpoints until it passes again. Confusing the two in an answer is an immediate signal of shallow hands-on experience.

Senior interviews probe control-plane reasoning (scheduling, reconciliation, consensus), not definitions.
The scheduler runs filtering (predicates) then scoring (priorities) across two distinct phases.
etcd requires an odd-numbered Raft quorum majority; 3 or 5 members maximize fault tolerance per node added.
Readiness probe failures remove a pod from Service endpoints without restarting the container.
Liveness probe failures restart the container; conflating this with readiness is a common red flag.
node-monitor-grace-period and pod-eviction-timeout deliberately delay failover to avoid false evictions.
Strong answers explain tradeoffs and 'why', not just mechanism names.