Configure Pod admission and scheduling (limits, node affinity, etc.)
5 minutes
5 Questions
In the context of the CKA exam, configuring pod admission and scheduling is essential for ensuring application stability and efficient cluster resource utilization.
First, **Resource Requests and Limits** manage compute allocation. A 'Request' is the minimum amount of CPU and Memory guaranteed to …In the context of the CKA exam, configuring pod admission and scheduling is essential for ensuring application stability and efficient cluster resource utilization.
First, **Resource Requests and Limits** manage compute allocation. A 'Request' is the minimum amount of CPU and Memory guaranteed to a container, used by the scheduler to filter suitable nodes. A 'Limit' is the hard ceiling; exceeding memory limits results in OOMKills, while CPU overage leads to throttling. Failing to set these can lead to 'Noisy Neighbor' issues.
For controlling placement, **Node Affinity** allows you to constrain pods to nodes with specific labels. It supports flexible operators (In, NotIn, Exists) and two modes: 'hard' (`requiredDuringScheduling...`), which mandates conditions, and 'soft' (`preferred...`), which prioritizes nodes but allows scheduling elsewhere if conditions aren't met.
**Taints and Tolerations** work inversely. Taints are applied to nodes to repel pods, while Tolerations are applied to pods to allow them onto tainted nodes. This pattern is critical for dedicating nodes to specific workloads (e.g., GPU instances) or preventing scheduling during maintenance.
**Pod Affinity/Anti-Affinity** rules schedule pods based on the labels of *other pods* running on the node. Use affinity to co-locate chatty services for performance, and anti-affinity to spread replicas across different nodes or zones for high availability.
Finally, **LimitRanges** and **ResourceQuotas** are admission controls applied at the namespace level. LimitRanges define default request/limit values for pods that don't specify them, while ResourceQuotas cap the total aggregate resource consumption of a namespace, preventing tenant resource exhaustion.
Configure Pod Admission and Scheduling (Limits, Node Affinity, etc.)
Why is this Important? Kubernetes clusters have finite resources. Without controlling Pod admission and scheduling, a single application could consume all available CPU and Memory, starving critical system components and causing cluster instability. Furthermore, high-priority workloads often require specific hardware (like GPUs) or security isolation. Mastering this concept allows you to optimize resource usage, ensure fairness, and guarantee that workloads run exactly where they are intended.
What is it? This topic covers the mechanisms Kubernetes uses to accept pods into the cluster and assign them to nodes. It is primarily categorized into two areas: 1. Resource Management: Defining requests (minimum resources guaranteed) and limits (maximum resources allowed) for CPU and Memory. 2. Scheduling Constraints: Directing Pods to specific Nodes using Node Selectors, Node Affinity, and Taints/Tolerations.
How it Works
1. Resource Requests & Limits: Defined within the containers spec. The Scheduler uses Requests to calculate if a Node has enough capacity to fit the Pod. The Container Runtime uses Limits to enforce boundaries. If a container exceeds its Memory limit, it is OOMKilled (restarted). If it exceeds CPU limits, it is throttled.
2. Node Affinity: This is a flexible way to constrain pods to nodes based on labels. It operates in two modes: - requiredDuringSchedulingIgnoredDuringExecution: A hard rule. If no node matches the criteria, the Pod stays Pending. - preferredDuringSchedulingIgnoredDuringExecution: A soft rule. The scheduler attempts to satisfy the rule but will schedule the pod elsewhere if no match is found.
3. Taints and Tolerations: Taints are applied to Nodes to repel pods. Tolerations are applied to Pods to allow them to schedule on tainted nodes. This is often used to dedicate nodes to specific user groups or to keep standard workloads off the Control Plane.
How to Answer Questions in the Exam When faced with a scheduling question, follow this workflow: 1. Assess the Constraint: Does the question demand the pod must run on a specific node (Affinity/Selector) or that it must not exceed specific usage (Limits)? 2. Inspect the Cluster: Always run kubectl get nodes --show-labels to identify existing labels. Use kubectl describe node [node-name] to check for existing Taints. 3. Generate YAML: Use imperative commands to generate a skeleton: kubectl run my-pod --image=nginx --restart=Never --dry-run=client -o yaml > pod.yaml. 4. Edit Spec: Open the generated file and manually add the affinity or resources blocks. Rely on kubectl explain pod.spec.affinity if you forget the syntax.
Exam Tips: Answering Questions on Configure Pod admission and scheduling - Syntax Precision: Node Affinity syntax is deeply nested and sensitive to indentation. Memorize the hierarchy: affinity -> nodeAffinity -> requiredDuring... -> nodeSelectorTerms -> matchExpressions. - CPU Units: Remember that 1000m (mollicores) equals 1 vCPU. If the exam asks for 0.5 CPU, you can write 500m. - Taint Key/Values: When adding a toleration, ensure the key, value, and effect (e.g., NoSchedule) match the Node's taint exactly. - OOMKilled Scenarios: If a debugging question involves a pod that keeps crashing with OOMKilled, the solution is almost always to increase the Memory Limit in the pod configuration.