Kubernetes interview questions built from real upgrades

Kubernetes trivia is easy to memorise. Upgrades are not, and most production pain arrives during one. These seven questions come from the changes that shipped between 2025 and 2026, so a candidate who has actually operated clusters recently will recognise every one.

1. A node drain has been stuck for forty minutes. Why?

Listen for PodDisruptionBudgets. A budget that cannot be satisfied blocks voluntary evictions, and a drain is a voluntary disruption [1][2]. The senior answer checks the budget against the replica count before touching anything; the weak answer deletes the budget or force-deletes the pods.

2. New nodes join after an upgrade to 1.35 but never become Ready.

From 1.35, failCgroupV1 defaults to true, so the kubelet does not start on a cgroup v1 node [3]. Strong candidates know the temporary override exists and that it buys time, not a fix [3].

3. What does in-place Pod resize change, and where does it fall short?

It made CPU and memory mutable in a running Pod and became stable in 1.35 [4]. The senior answer adds the catch: Java and Python runtimes cannot resize memory without a restart [4], so raising a JVM's limit in place does not raise its heap.

4. How would you migrate off Ingress NGINX?

Ingress NGINX was retired in March 2026 with no further security fixes [5]. A strong answer starts with an inventory of behaviour, not manifests — Ingress NGINX regex matching is prefix-based and case-insensitive, which a faithful-looking Gateway API translation can break [6].

5. What happens to an OOM kill on cgroup v2 nodes?

On cgroup v2 the kubelet sets memory.oom.group by default, so an OOM kills every process in the container together rather than leaving it half-working [3]. It is a good test of whether a candidate has read beyond the headline changes.

6. A stateful workload loses quorum during a rolling node upgrade.

Ask how they would set the PodDisruptionBudget for a three-member quorum system. The strong answer ties the budget to the quorum size, so an upgrade can never take down more members than the system can lose.

7. Walk me through the last cluster upgrade you led.

Listen for versions, sequencing, the thing that went wrong, and how they would plan it differently. 'It went fine' from a candidate claiming upgrade experience is a warning sign.