kubernetes

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.

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.

Three states, three completely different causes, and one command that tells you which you are looking at. The state name says whether the problem is the scheduler, the registry or your own process.

A namespace scopes names, permissions and quotas. It does not scope the kernel or the network by default, and the gap between what people assume it isolates and what it does is where the trouble starts.

Selectors match object labels; owner references record controller relationships. Keeping those mechanisms separate explains how a Service can select the wrong pods without owning them.

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.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

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.

Trace sandbox setup, address allocation and a cross-node packet, then distinguish pod reachability from Service translation.

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.

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.

Both solve the same surface problem and they disagree about how. Compare what each mechanism makes hard, and notices that the GitOps tool you use changes the calculus.

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.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Describing it as 'it keeps N pods alive' states the part it does not do, since it constrains voluntary eviction and not the machine that fails.

The two ideas that decide whether an operator is safe are level-triggered reconciliation and finalizer semantics. The partition question separates people who have written a controller from people who have installed one.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

Kubernetes does not see GPUs, it sees an extended resource that something has to advertise. When that advertisement is missing or wrong, the scheduler is behaving correctly and the node is lying.

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.

Ingress solved routing by convention and annotation, which meant every controller invented its own. Gateway API's real contribution is not features, it is splitting one object into three so that platform and application teams stop editing the same file.

Route attachment and cross-namespace backend access have different owners. Use route status to find the failing boundary before broadening any permission.

A common scenario question, and the one where a list of commands most often stands in for an argument about what each one eliminates. Empty logs is the clue, not the obstacle.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

The pods are Running, the dashboard is green, and users get errors. The gap between Running and receiving traffic is where this question lives, and it has a precise answer.

Tests whether you know that Kubernetes waits, and for how long. The default timings surprise most candidates, and they explain why a node failure hurts longer than people expect.

Intermittent DNS is the most-reported and least-understood Kubernetes failure. There are three well-known causes and each leaves a different fingerprint.

Low utilisation with terrible tail latency is not a contradiction. It is the CFS quota doing exactly what it was configured to do. Most candidates have never read nr_throttled.

One disk metric explaining a whole cluster's weirdness is the point of this question. Restarting etcd first turns a slow cluster into a down one, because a restarted member has to catch up before it can vote.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

The reflex is rollback and it is usually right. Shared state, changed credentials and unavailable old artifacts can make an undo incomplete or unsafe. Verify those dependencies before choosing the recovery.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and a controlled recovery that preserves cluster state.

The pods are Pending, the nodes are Ready, and the GPUs have vanished from allocatable. Something changed on the node under a fleet that nobody considered part of the deploy surface.

A drain that hangs without erroring is almost always eviction being refused, and the two refusals that look identical from the outside have opposite fixes.

The disk is not full, the keyspace quota is. Defragmenting without disarming the alarm leaves the cluster read-only, and disarming without compacting puts it back within minutes.

The volume is in one availability zone and the scheduler cannot move it. Spare capacity in the other two zones is not spare capacity for this pod, and no amount of scaling helps.

The pod's resolver is configured to try five search domains before the real one. An uncached external hostname can trigger several search-expanded queries before its absolute lookup, and the failures are what you are paying for.

Two controllers with different opinions and no shared hysteresis. Flat traffic with an oscillating node count means the loop is driven by something other than demand, and the candidates are few.

The heap is the part you configured and the smaller part of what the process uses. The kernel counts everything the cgroup touches, including the page cache the JVM never asked for.

Running pods already have their images, so a credential expiry is invisible until something needs to start. That gap is why this always surfaces during an unrelated incident, at the worst moment.

Workload authentication, traffic encryption and authorization need separate verification. Admission and RBAC constrain who can deploy a workload that bypasses those controls.

Four tools that solve the same sentence and differ on one question: where does the plaintext end up? In a regulated environment that question decides the answer.

Most clusters fail an RBAC review on the same handful of patterns. Naming them concretely, plus the namespace-first design that prevents them, is what separates operators from tutorial readers.

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

A shared cluster produces one bill and no answer. Attribution is a measurement problem first and a cultural one second, and the number that changes behaviour is not the one finance asked for.

Everyone quotes the discount. Fewer candidates can describe what happens when a notice arrives late or a worker disappears without completing shutdown and why some workloads shrug it off while others lose hours of compute.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

The question that separates people running GPU clusters from people running Kubernetes clusters that happen to have GPUs. The answer is that an integer count cannot express what a GPU workload needs.

Three sharing modes with three different isolation guarantees. MIG partitions the hardware, MPS shares the SMs, time-slicing just interleaves contexts, and picking wrong turns a latency SLO into a lottery.

The default scheduler places pods one at a time, which is exactly wrong for a job that needs all sixteen or none. Two half-placed jobs can hold each other's GPUs forever without either ever starting.

The driver, the container toolkit, the CUDA runtime inside the image and the framework build all have to agree. Upgrade the wrong one first and every pod on the node fails to start with an error that names none of them.

A mixed fleet is the normal state, not a transitional one, because capacity arrives when it arrives. The failure is a scheduler that treats two very different cards as the same countable unit.

GPU cost attribution needs allocation records as well as utilization. Separate exclusive reservations from borrowable quota, then reconcile team charges and idle capacity to the actual bill.