In the context of the CKA exam and Kubernetes Workloads, managing compute resources (CPU and Memory) is vital for efficient scheduling and cluster stability. These controls are defined within the container spec of a Pod manifest under the `resources` field.
**Resource Requests** specify the guaran…In the context of the CKA exam and Kubernetes Workloads, managing compute resources (CPU and Memory) is vital for efficient scheduling and cluster stability. These controls are defined within the container spec of a Pod manifest under the `resources` field.
**Resource Requests** specify the guaranteed minimum resources a container requires to start. The kube-scheduler uses this value purely for scheduling decisions; it filters out Nodes that do not have enough unallocated capacity to meet the request. If a container requests `500m` CPU and `256Mi` Memory, the scheduler ensures the chosen Node has that specific capacity available. If no Node meets the requirement, the Pod remains in a `Pending` state.
**Resource Limits** specify the hard maximum a container is allowed to consume. This setting prevents a single misbehaving Pod from monopolizing Node resources and starving other processes. The behavior when exceeding limits depends on the resource type:
1. **CPU:** Considered a compressible resource. If a container tries to exceed its CPU limit, the runtime throttles the CPU cycles, resulting in degraded performance, but the container remains running.
2. **Memory:** Considered incompressible. If a container tries to consume more RAM than its limit, the kernel invokes the OOM (Out Of Memory) Killer, terminating the container with an `OOMKilled` error.
Additionally, these settings determine the **Quality of Service (QoS)** class assigned to the Pod (Guaranteed, Burstable, or BestEffort), which dictates the order in which Pods are evicted when a Node is under resource pressure.
Understanding Kubernetes Resource Requests and Limits
Why is it Important? In a shared Kubernetes cluster, resources (CPU and Memory) are finite. Without proper management, a single malfunctioning application could consume all available resources on a Node, starving other critical applications and leading to cluster instability (the 'noisy neighbor' problem). Resource Requests and Limits are the primary mechanisms Kubernetes uses to control compute resource allocation, ensuring efficient scheduling and preventing application crashes due to resource starvation.
What is it? Resource configurations are applied at the container level within a Pod specification. They define two distinct concepts: 1. Requests: This is the minimum amount of resources a container is guaranteed to have. The Kubernetes Scheduler uses Requests to determine which Node has enough available capacity to host the Pod. 2. Limits: This is the hard maximum amount of resources a container is allowed to use. The container runtime (e.g., containerd) enforces this boundary.
How it Works Resources are defined in the Pod manifest under spec.containers[].resources. CPU: Measured in cores. 1 CPU core = 1000 millicores (1000m). CPU is a compressible resource. If a container hits its CPU Limit, the system throttles the container's CPU cycles, resulting in slower performance but not termination. Memory: Measured in bytes (typically Mi or Gi). Memory is an incompressible resource. If a container tries to consume more memory than its Limit, the Linux kernel invokes the Out Of Memory (OOM) Killer, terminating the process. The Pod status will show OOMKilled.
Quality of Service (QoS): Based on these settings, Kubernetes assigns a QoS class (Guaranteed, Burstable, or BestEffort), which determines eviction priority when a Node is under pressure.
How to Answer Questions in the CKA Exam You will likely face tasks requiring you to create a Pod with specific resource requirements or troubleshoot a Pod that is failing. 1. Creating Resources: Use imperative commands to generate the basic YAML structure to save time. kubectl run nginx --image=nginx --restart=Never --requests='cpu=100m,memory=128Mi' --limits='cpu=200m,memory=256Mi' --dry-run=client -o yaml > pod.yaml 2. Modifying Resources: If asked to update an existing Deployment, use kubectl edit deployment [name] and locate the resources block inside the container spec.
Exam Tips: Answering Questions on Resource requests and limits Tip 1: Scheduling vs. Running. Remember that Requests affect Scheduling (where the Pod goes), while Limits affect Runtime (if the Pod gets throttled or killed). If a Pod is stuck in Pending state, it usually means the Requests are too high for any Node to satisfy. Tip 2: Watch Your Units. Be precise. 1Gi is 1024Mi, while 1G is 1000M. The exam expects the exact notation requested. For CPU, 0.5 is the same as 500m. Tip 3: The OOMKilled Status. If a question involves a Pod that keeps restarting, run kubectl get pod. If you see 'OOMKilled', the answer almost always involves increasing the Memory Limit. Tip 4: Syntax Hierarchy. Ensure you place the resources key inside the specific container object, not at the Pod level.