Kubernetes Resource Interview Questions: CPU Throttling, OOM Kills, and QoS

A Pod is Running, its latency doubled, and the node still reports free memory. Is Kubernetes failing to allocate resources? An interviewer may be testing whether you can separate scheduling requests, runtime limits, container OOM kills, and node-pressure eviction. They produce different symptoms and require different fixes. The useful answer begins with the actual container status, events, and CPU or memory measurements, then works backward to the configured contract.

Kubernetes documentation is the source for platform behavior here. The numbers and incident timeline below are original practice scenarios, not candidate reports from a specific employer. For a related debugging prompt, see Troubleshoot CPU, latency, and DNS issues.

The resource model to explain before changing YAML

For each container, a request is the amount the scheduler uses when deciding whether a Pod fits on a node. A CPU limit constrains how much CPU time that container can consume over its enforcement interval; a busy process is throttled rather than killed merely for exceeding the CPU limit. A memory limit is enforced reactively: when use exceeds the limit, the kernel's out-of-memory machinery can terminate the container. None of those values is a performance guarantee by itself. A request can help place a Pod, yet an overloaded node can still experience contention; an unlimited container can still be evicted under node pressure.

The official resource management guide distinguishes these mechanisms. If a limit is specified without a request, the API may copy the limit into the request when no admission-time default has provided a request. Do not assume an omitted request is necessarily zero on the persisted Pod; inspect the actual admitted spec. LimitRanges or policy webhooks can also change the effective configuration.

Quality of Service (QoS) is a Pod classification derived from its containers' CPU and memory requests and limits. It influences which Pods are considered for node-pressure eviction; it does not override a container's own memory limit. The three classes are Guaranteed, Burstable, and BestEffort. For Guaranteed, every container needs CPU and memory requests and limits, with each request equal to its corresponding limit. BestEffort has no CPU or memory requests or limits on any container. Other eligible configurations are Burstable. See Kubernetes Pod QoS classes for the formal conditions.

Interview question 1: High latency, low CPU usage, and no restarts—what do you check?

Ask for the CPU request and limit, per-container CPU usage, and a throttling counter or rate such as cgroup CPU throttled periods and time, interpreted over the same time window as latency. A container with a low CPU limit can wait for another quota period even while the node has idle CPU. A low average CPU graph is therefore compatible with short bursts that hit the quota. Confirm whether latency aligns with those bursts; do not diagnose throttling from the existence of a limit alone.

Compare request and limit to workload shape. A CPU-bound worker may need sustained compute; a request-based scheduler decision and a small limit can leave it placed but repeatedly throttled. A request that is too low can also lead to more Pods being packed onto a node than their actual peak demand warrants. Those are distinct failure paths. Inspect node utilization and neighboring workloads before raising every limit. Removing an overly tight CPU limit may be reasonable for a latency-sensitive service if cluster policy and capacity allow it, but then size requests from measured demand and keep a guard against runaway workload behavior elsewhere.

The interviewer may show kubectl top pod with low CPU. Explain its limitation: sampled usage is not a complete record of burst demand or quota stalls. Use an aligned rate of throttling metrics, application request latency, and per-container CPU usage. Then propose a controlled configuration change and compare p95/p99 latency plus node saturation after rollout. Avoid promising a precise performance gain without a load test.

Interview question 2: The Pod restarts with OOMKilled. Is node memory exhausted?

Not necessarily. OOMKilled in the terminated container state is evidence that the container was killed after exceeding an enforced memory boundary, commonly its cgroup memory limit. A node can have available memory at the same time. Confirm kubectl describe pod, lastState.terminated.reason, exit code, restart count, and the container's effective memory limit. Look at memory working set and allocation behavior near the restart, but allow for sampling gaps: a brief peak can happen between dashboard points.

Then separate the application cause from the resource setting. Did a release increase heap size, a queue accumulate messages, a cache grow without bounds, or traffic shift? Is the limit lower than a legitimate peak? Increasing the limit without inspecting growth can defer the next failure and reduce node headroom. Conversely, changing application code when the limit is obviously below a documented startup peak misses the immediate configuration problem. A strong answer proposes both a short-term safe capacity adjustment and an investigation of the allocation profile.

For JVMs and other managed runtimes, distinguish the language heap from total process memory: native allocations, stacks, and runtime overhead can make resident use exceed the heap target. Do not assert that a heap setting exactly equals cgroup use. In a multi-container Pod, identify which container was killed; a sidecar's OOM can create Pod-level symptoms that resemble main-process failure.

A four-signal diagnostic exercise

An API Pod has a 200m CPU request, a 500m CPU limit, a 256Mi memory request, and a 512Mi memory limit. Its main container shows elevated p99 latency and rising CPU throttled time during a burst. It later restarts with OOMKilled; another replica on the same node is evicted with a node-pressure event. These observations describe three mechanisms, even if they happen in one incident.

Observation	Mechanism to test	First evidence and decision
Pending Pod, Insufficient cpu event	Request will not fit allocatable node capacity	Inspect admitted request, node allocatable, and placement constraints
Running Pod, throttled CPU periods, higher latency	CPU limit constrains bursts	Correlate throttle rate with latency; test limit/request change under load
Restart with lastState.reason: OOMKilled	Container memory boundary crossed	Inspect limit and allocation peak; fix growth or resize safely
Pod replaced after Evicted event	Kubelet node-pressure decision	Inspect node conditions, eviction signal, QoS, request and node usage

The values and sequence are illustrative inference, not a claim that one counter proves one root cause. In production, correlate timestamps and container identity. A terminated container can have an OOM reason while a separate Pod is evicted by the kubelet. Treating both as “memory errors” hides which control actually acted.

Interview question 3: How do requests affect scheduling and utilization?

The scheduler compares requests, not observed usage, against node allocatable resources. A Pod may stay Pending even when kubectl top nodes reports low current consumption because the node's remaining request capacity is insufficient. Conversely, low requests can permit aggressive packing, leading to contention under simultaneous load. Requests are a planning signal and, for CPU, influence relative share under contention; they are not a promise that the application will use only that amount.

In a worked explanation, write down each node's allocatable CPU and memory, subtract the requests of already scheduled Pods, and check whether the incoming Pod fits both resources. Then inspect affinity, taints, topology, and volume constraints if the arithmetic says it should fit. Saying “the cluster has spare CPU” is incomplete if the one eligible node does not. If a namespace has a LimitRange or ResourceQuota, inspect those admission controls separately from scheduler placement.

There is also a scale-out consequence. If Horizontal Pod Autoscaler behavior depends on CPU utilization relative to requests, changing CPU requests can change the utilization denominator and scaling decisions. You need not solve HPA in a resource-limit interview, but you should mention it when proposing a large request change in a live system. Validate with actual workload metrics rather than tuning one Pod in isolation.

Interview question 4: Does Guaranteed QoS prevent an OOM kill?

No. Guaranteed QoS does not grant unlimited memory. A container in a Guaranteed Pod can exceed its configured memory limit and be OOM-killed. QoS is relevant to kubelet eviction ordering under node-resource pressure. It is also not an application-level uptime guarantee: liveness errors, node failures, and bad code remain possible.

An interviewer may ask why a Pod is Burstable even though the main container has matched CPU and memory request/limit values. Check every container, including sidecars and init-container implications, against the QoS definition. A sidecar missing a CPU limit can prevent Guaranteed classification. Inspect the persisted Pod status field qosClass rather than guessing from one container's YAML. For an exact class calculation, use the official rules and any admission defaults that changed the submitted spec.

Do not set all requests equal to inflated limits solely to earn Guaranteed QoS. That can block scheduling and waste capacity. Choose resource values from a service-level performance requirement and observed working set, then assess the operational eviction risk. If a critical service needs priority under node pressure, QoS is only one part of the broader scheduling and priority design.

Interview question 5: How would you fix this safely during an incident?

Begin with classification. Record the affected namespace, Pod UID, container name, node, current resource spec, and recent restart or eviction events. Check whether user impact is latency, failed requests, or missing replicas. Separate a container restart from an evicted Pod and from a Pending replacement. Time-align application latency, throttle metrics, memory peaks, and node pressure signals. This reduces the risk of “fixing” CPU when the immediate outage is actually an OOM loop.

If a CPU quota is clearly binding, test a measured limit increase or removal within available capacity and policy; keep an eye on neighboring Pods and node saturation. If memory use crosses its limit, restore the service with a limit that covers a known good peak only if the node can safely host it, while investigating leaks or unbounded work. If the node is under pressure, address overcommit, requests, placement, or capacity; blindly increasing a Pod's limit can worsen the node problem. Roll out one change at a time when possible and compare before/after outcomes.

Communicate uncertainty honestly: a sampled metric may miss a spike, OOMKilled identifies a termination mechanism but not the allocation cause, and low node CPU does not refute container throttling. A concise interview response that names the next discriminating observation is stronger than a list of generic kubectl commands.

Practice a complete explanation

Try saying: “Requests govern scheduler fit; CPU limits can throttle a Running container; memory limits can lead to OOM kill; QoS influences node-pressure eviction. I would identify the specific container and event, then align quota, memory, and node metrics with the latency window. I would only change a request or limit after checking scheduling capacity and the expected traffic peak.” This is a reusable reasoning pattern, but the answer should still point to the actual evidence in the prompt.

Practice question	What to rehearse
Troubleshoot CPU, latency, and DNS issues	Separate CPU quota symptoms from network latency.
Debug Kubernetes crashes and review Python ingestion script	Tie restart reason and application behavior to a concrete fix.
Diagnose overloaded Kubernetes cluster	Distinguish requested capacity from current utilization.
Explain Kubernetes autoscaling and traffic routing	Describe how requests affect scaling calculations.
Describe how you use Kubernetes	Give an evidence-led incident example.

Use Troubleshoot CPU, latency, and DNS issues as the next timed prompt: list the evidence that would make you prefer CPU throttling over OOM, eviction, or DNS before choosing a remedy.

Sources and further reading

• Kubernetes: Resource Management for Pods and Containers — requests, limits, and runtime behavior.
• Kubernetes: Pod Quality of Service Classes — class criteria and eviction relevance.
• Kubernetes: Node-pressure Eviction — eviction signals and ordering.
• Kubernetes: Resource Metrics Pipeline — what metrics-server provides and does not provide.