Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Kubernetes resource management is a foundational skill for any engineer managing production containerized workloads. In 2026, as organizations shift toward granular cost optimization and high-density cluster packing, understanding the interplay between resource requests and limits is critical. Requests define the guaranteed resources for scheduling, while limits define the hard ceiling for container consumption. This topic is frequently tested in interviews for SRE, DevOps, and Platform Engineering roles because it directly impacts cluster stability, cost, and reliability. Junior candidates are expected to understand the basic definitions and how to set them in manifests. Senior candidates must demonstrate deep knowledge of Quality of Service (QoS) classes, the mechanics of CPU CFS quotas causing throttling, and the kernel-level implications of OOMKilled events. Mastering this allows engineers to prevent 'noisy neighbor' issues and ensure consistent application performance under load.
Resource management is the primary lever for balancing cluster cost against service reliability. In production environments, misconfigured requests lead to cluster under-utilization (wasted spend) or over-subscription (resource contention). If requests are too low, the scheduler may pack too many pods onto a single node, leading to CPU starvation or memory pressure. If limits are too tight, applications experience artificial performance degradation via CPU throttling or unexpected termination via OOMKilled status. This topic is a high-signal interview area because it reveals whether a candidate understands the underlying Linux kernel mechanisms (cgroups) that Kubernetes leverages. A strong candidate can explain how the CFS (Completely Fair Scheduler) period and quota interact to cause latency spikes, whereas a weak candidate views limits as purely 'soft' suggestions. In 2026, with the rise of AI workloads requiring predictable GPU and memory throughput, the ability to tune these parameters is the difference between a stable inference service and one that suffers from intermittent, hard-to-debug failures.
Kubernetes manages resources by mapping container specifications to Linux cgroups (Control Groups) on the host node. When a pod is scheduled, the Kubelet creates a cgroup hierarchy for the container, setting values for cpu.shares (requests) and cpu.cfs_quota_us (limits). Memory is managed via memory.limit_in_bytes. The kernel enforces these limits in real-time. If a process attempts to exceed its memory limit, the OOM Killer terminates the process. For CPU, the CFS scheduler enforces the quota over a 100ms period.
[Pod Spec]
↓
[Kube-Scheduler]
↓
[Kubelet]
↓
[Cgroup Setup]
↓ ↓
[CPU Quota] [Mem Limit]
↓ ↓
[CFS Period] [OOM Killer]
↓ ↓
[Kernel Enforcement]Setting requests equal to limits for critical services to ensure stable resource allocation.
Trade-offs: Reduces bin-packing efficiency but eliminates performance jitter.
Setting requests lower than limits to allow pods to use spare node capacity.
Trade-offs: Increases node density but risks performance degradation during contention.
Allocating specific resources to sidecar containers to prevent them from starving the main app.
Trade-offs: Increases total pod resource footprint.
| Reliability | Use Guaranteed QoS for critical services to prevent eviction during node pressure. |
| Scalability | Implement HPA based on custom metrics like request-per-second to scale pods before limits are hit. |
| Performance | Monitor CFS throttled metrics; if high, increase CPU limits or decrease parallelism. |
| Cost | Use VPA in recommendation mode to identify over-provisioned pods and reduce requests. |
| Security | Limits prevent DoS attacks where a compromised container consumes all node resources. |
| Monitoring | Track 'container_memory_working_set_bytes' and 'container_cpu_cfs_throttled_seconds_total'. |
Requests are the resources guaranteed to a container, used by the scheduler to place pods on nodes. Limits are the maximum resources a container can consume, enforced by the kernel to prevent resource exhaustion. Requests are for placement; limits are for enforcement.
This usually happens due to node-level memory pressure. If the node runs out of memory, the kernel will evict pods to reclaim space, starting with those that have the lowest priority (BestEffort) or those exceeding their requests, even if they are below their limits.
CPU throttling occurs when a container hits its CPU limit and the CFS scheduler pauses its execution to keep it within the quota. You can detect it using Prometheus by monitoring the 'container_cpu_cfs_throttled_seconds_total' metric.
QoS classes (Guaranteed, Burstable, BestEffort) categorize pods based on their resource request/limit configuration. They determine the priority for eviction when a node experiences memory pressure. Guaranteed pods are the last to be evicted.
Yes, in production environments. Without limits, a single pod can consume all node resources, leading to 'noisy neighbor' issues or node failure. Limits provide the necessary isolation to ensure cluster stability.
Yes, over-subscription is common to increase cluster density. However, it requires careful monitoring of CPU throttling. If your services are latency-sensitive, you should avoid over-subscription or use Guaranteed QoS.
Memory is non-compressible; if a process exceeds its limit, the kernel terminates it (OOMKilled). CPU is compressible; if a process exceeds its limit, the kernel throttles its execution speed, but the process continues to run.
The working set is the amount of memory currently in use by the container that cannot be easily reclaimed by the kernel (e.g., active heap). Kubernetes uses this metric to decide if a container is exceeding its memory limit.
Yes, it puts the pod in the 'Guaranteed' QoS class, which prevents the pod from being throttled by the scheduler and makes it less likely to be evicted during node-level memory pressure.
The node is at high risk. Without limits, pods can consume all available memory and CPU, leading to node-wide instability. The scheduler will treat all pods as BestEffort, making them all equally likely to be evicted.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.