How would you design Kubernetes Pod-level resource requests?

Problem and context

Kubernetes Pod-level resources let a Pod declare CPU, memory, or hugepages requests and limits in addition to container-level values. The Pod-level values take precedence when both are present, and they influence scheduling, QoS, and OOM scoring. The PodLevelResources feature gate and cluster version must be verified before rollout.

Assume the proxy and workers share a bursty workload, but the proxy has a latency SLO and the workers can use spare capacity. The goal is to express that relationship without making the scheduler or kubelet enforce a budget the team did not intend.

What interviewers evaluate

Interviewers look for a clear resource ownership model, correct precedence rules, and awareness that Pod-level requests change scheduling and QoS. Strong answers discuss aggregate versus per-container guarantees, limits, autoscaling, observability, and migration tests.

An ordinary answer copies the sum of container requests into spec.resources. A strong answer explains whether the Pod budget is a shared pool, which container needs a floor, and how to prevent one worker from consuming proxy latency headroom.

Questions to clarify first

• Is the Pod-level request a shared budget or a hard minimum for each container?
• Which Kubernetes versions, feature gates, resource managers, and operating systems are in scope?
• Does the proxy need a guaranteed CPU floor or memory limit independent of workers?
• How do HPA, VPA, and eviction policies observe the new scope?
• What happens when both Pod-level and container-level requests are specified during migration?

If containers have independent scaling or failure domains, separate Pods may be safer. If they truly share a lifecycle and burst budget, Pod-level resources can express that relationship more directly.

A 30-second answer

“I would first verify feature-gate and version support, then model the Pod as a shared budget with an explicit proxy floor. Pod-level requests take precedence, so I would avoid accidental mixed settings, test QoS and OOM behavior, and check autoscaler inputs. I would canary the manifest, compare latency, throttling, eviction, and cost with the old policy, and keep a rollback to container-level requests.”

Step-by-step design

1. Map resource roles. Measure proxy latency sensitivity, worker burstiness, steady-state usage, and memory growth. Decide whether the containers share a budget or need isolated guarantees.
2. Verify capability. Confirm Kubernetes server version, PodLevelResources gate on control plane and nodes, supported resource types, and Linux-only limitations where applicable.
3. Set the Pod budget. Choose requests for scheduling and limits for the aggregate ceiling. Ensure the budget leaves room for the proxy’s latency floor and worker bursts.
4. Avoid ambiguous precedence. During migration, document that Pod-level values override container-level values. Remove stale container values or keep them only when the policy intentionally needs both scopes.
5. Check QoS and eviction. Recalculate QoS class and OOM behavior, then test node pressure, throttling, and worker contention. A healthy aggregate can still hide proxy starvation.
6. Roll out and observe. Canary one workload and track p95 latency, CPU throttling, memory pressure, OOM kills, evictions, restarts, and cost. Expand only when guardrails hold.

Alternatives include separate Deployments, container-specific requests only, or a sidecar with explicit limits. Pod-level resources are most useful when lifecycle and burst capacity are intentionally shared.

Example answer

“The proxy needs a latency floor, while workers can borrow spare CPU. I would set a Pod request that reflects the normal aggregate and a limit for the burst ceiling, then validate that the proxy is not starved under worker load. During migration I would remove conflicting container requests or document their purpose because Pod-level values win. I would canary on two nodes, watch p95 latency, throttling, OOM, eviction, and autoscaler behavior, and roll back to the previous container policy if the proxy SLO regresses.”

Common mistakes

• Error: Assuming Pod requests are automatically per-container guarantees → Why it fails: the budget may be shared → Fix: define floors and isolation explicitly.
• Error: Leaving conflicting container values undocumented → Why it fails: Pod-level precedence surprises operators → Fix: document and test effective resources.
• Error: Checking only CPU utilization → Why it fails: memory pressure and OOM behavior can change → Fix: observe CPU, memory, QoS, eviction, and latency together.
• Error: Enabling the feature on one control-plane component → Why it fails: all required nodes and components must support it → Fix: verify cluster-wide capability before rollout.

Follow-up questions and responses

What if the proxy is starved even though the Pod is under its limit?

Treat it as a contention failure. Add a proxy floor, separate the workloads, or use container-level isolation; aggregate headroom alone does not guarantee latency.

How do Pod-level requests affect QoS?

They take precedence when both scopes are present and influence the Pod’s QoS and OOM calculations. Recompute the class during migration and test node pressure.

Can Windows Pods use Pod-level resources?

Check the version-specific limitations. The documented Kubernetes 1.35 behavior does not support Pod-level resources for Windows Pods, so keep a container-level policy there.

When would you split the Pod instead?

Split when containers scale, fail, or have SLOs independently. Keep one Pod when shared lifecycle and burst budget are intentional and observable.