Uber Containers & Kubernetes interview questions

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Evaluate identity, traffic policy and telemetry against measured proxy overhead and operating responsibilities, then test the authorization boundary.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

Everyone can recite the three. Explain what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

Compare the configured Service datapaths and their lookup and update mechanisms. The iptables datapath degrades with service count, and eBPF replaces a linear scan with a map lookup.

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, which can produce unstable feedback depending on their policies and workload.

Init containers are the easy half. The hard half is why plain sidecars race your app at both ends of the pod's life, and what restartPolicy Always changes about that.

The loop is easy; the statistics are not. This question finds engineers who can size a traffic slice against sample noise and name the false rollback that kills trust in automation.

Repeated full-resource polling can make an operator an expensive API client. This question separates people who run controllers at ten-thousand-object scale from those who copied a tutorial: watch semantics, cache behaviour, and which LISTs touch etcd.

Anti-affinity is binary and falls over at scale; topologySpreadConstraints give you numeric skew control across labeled domains. The subtle parts are eligibility filtering before the skew math, and the fact that Kubernetes never rebalances anything for you.

Two cleanup mechanisms hide behind one taint: image garbage collection removes unreferenced images by LRU at threshold crossings, while eviction kills pods. Candidates who conflate them fail this question quietly.

The classic five-second stall is rarely CoreDNS being slow; it is UDP, conntrack races and ndots expansion. The diagnosis ladder and the NodeLocal DNSCache fix separate operators from readers of architecture blogs.

Three API servers behind one health-checked endpoint, etcd on its own quorum, leader election everywhere else. The scored part is naming what degrades quietly before anything alerts.

A ladder from health-checked global DNS through endpoint mirroring to mesh east-west gateways. The deciding axis is trust boundary and failure isolation, not any mesh's feature matrix.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

An end-of-maintenance date changes the risk even while traffic stays healthy. The work is proving routing and security parity before moving a production hostname.

Clusters multiply for good reasons: regions, isolation, tenancy, blast radius. The problem is not creating them, it is that cluster seven diverges from cluster three and nobody knows until an upgrade behaves differently.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.