Study guide
3.6 Resource Requests, Limits & Namespace ResourceQuotas
Certified Kubernetes Administrator CKA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CKA Exam Environment & Cluster Architecture
1.1 CKA Exam Mechanics, Scoring & Remote Terminal Environment 1.2 Kubernetes Control Plane & Worker Node Components 1.3 etcd Architecture, Clustering & Raft Consensus 1.4 Initializing Clusters with Kubeadm 1.5 Highly Available (HA) Control Plane Topologies 1.6 Cluster Lifecycle & Step-by-Step Upgrades 1.7 etcd Snapshot Backup and Restore Procedures
2 Chapter 2: Cluster Extensions, Packaging & RBAC
2.1 Kubernetes TLS Certificates & PKI Infrastructure 2.2 Managing Kubeconfig Files, Users, & Contexts 2.3 Installing Cluster Components with Helm & Kustomize 2.4 Role-Based Access Control (RBAC): Roles & RoleBindings 2.5 ClusterRoles & ClusterRoleBindings 2.6 Custom Resource Definitions (CRDs) & Operators 2.7 Pod Security Standards (PSS) & Admission Controllers
3 Chapter 3: Workloads, Lifecycle & Pod Scheduling
3.1 Pod Lifecycle, Multi-Container Patterns & Init Containers 3.2 Deployments: Rolling Updates, Rollouts & Rollbacks 3.3 DaemonSets & StatefulSets Architecture 3.4 Batch Workloads: Jobs & CronJobs 3.5 Managing ConfigMaps & Sensitive Data with Secrets 3.6 Resource Requests, Limits & Namespace ResourceQuotas 3.7 NodeSelectors, Node Affinity & Anti-Affinity 3.8 Node Taints & Pod Tolerations 3.9 Autoscaling: Horizontal Pod Autoscaler (HPA) & Custom Metrics
4 Chapter 4: Services, Networking & Ingress Architecture
4.1 Kubernetes IP-per-Pod Model & CNI Plugins (Flannel, Calico, Cilium) 4.2 Services Deep Dive: ClusterIP, NodePort, LoadBalancer & EndpointSlices 4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF 4.4 CoreDNS Configuration, Resolution & Custom Forwarding 4.5 NetworkPolicies: Ingress, Egress & Default-Deny Isolation 4.6 Ingress Architecture, Controllers & Path-Based Routing 4.7 Gateway API: GatewayClass, Gateway, HTTPRoute & Traffic Splitting 4.8 External Traffic Ingress: NodePort, Cloud LoadBalancers & MetalLB
5 Chapter 5: Storage Architecture & Persistent Volumes
5.1 Ephemeral Volumes, EmptyDir, HostPath & Config Volumes 5.2 PersistentVolumes (PV) & PersistentVolumeClaims (PVC) Lifecycle 5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes 5.4 Storage Access Modes, Reclaim Policies & Volume Expansion 5.5 Container Storage Interface (CSI) Architecture & Drivers 5.6 StatefulSet VolumeClaimTemplates & Persistent Storage Workflows
6 Chapter 6: Advanced Troubleshooting, Monitoring & Maintenance
6.1 Systematic Kubernetes Troubleshooting Methodology 6.2 Node Failure, Kubelet Diagnostics & Systemd Services 6.3 Control Plane Failures, Static Pods & Component Logs 6.4 etcd Troubleshooting, Quorum Loss & Database Defragmentation 6.5 Pod Startup Failures, CrashLoopBackOff & OOMKilled Diagnostics 6.6 Workload Scheduling Failures & Resource Constraint Resolution 6.7 Container & Node Logging Architecture, Journalctl & Fluentd 6.8 Metrics Server, Resource Utilization & Kubectl Top 6.9 Service, Endpoint & Ingress Connectivity Troubleshooting 6.10 Storage Failures: PVC Pending, Mount Failures & Multi-Attach Errors 6.11 NetworkPolicy Isolation & CoreDNS Resolution Diagnostics
3.6 Resource Requests, Limits & Namespace ResourceQuotas
Key Takeaways Explain This Topic AI
Resource Requests represent guaranteed compute capacity used by kube-scheduler for Pod placement; Limits represent hard ceilings enforced by Linux cgroups at runtime.
CPU is a compressible resource subject to CFS bandwidth throttling when limits are exceeded; Memory is incompressible and triggers OOM Killer (exit code 137) upon breach.
Kubernetes assigns Guaranteed, Burstable, or BestEffort QoS from requests and limits; node-pressure eviction ranks Pods by usage above requests, Pod Priority, and relative excess usage rather than a fixed QoS ladder.
LimitRanges define default, minimum, and maximum resource allocations per container/pod within a namespace, automatically injecting defaults if requests are omitted.
ResourceQuotas enforce aggregate namespace-wide caps on compute resources (CPU/memory), storage requests, and object counts (Pods, Services, Secrets).
Last updated: August 2026
Resource Requests, Limits & Namespace ResourceQuotas
In multi-tenant Kubernetes clusters, uncontrolled workloads can monopolize CPU and memory, causing noisy neighbor problems, performance degradation, and node starvation. Kubernetes provides a robust, multi-tiered resource governance model: Requests and Limits at the container level, Quality of Service (QoS) classes at the Pod level, and LimitRanges and ResourceQuotas at the namespace level.
1. Requests vs Limits: Scheduling and Runtime Enforcement
Understanding the precise mechanical distinction between resource requests and resource limits is fundamental to Kubernetes operations and CKA exam success. +-----------------------------------------------------------------------------------------+
- | REQUESTS VS LIMITS MECHANICS |
- | |
- | +---------------------------------------+ +-------------------------------------+ |
- | | RESOURCE REQUESTS | | RESOURCE LIMITS | |
- | | - Used by: kube-scheduler | | - Enforced by: Linux cgroups | |
- | | - Role: Guaranteed minimum allocation| | - Role: Hard maximum threshold | |
- | | - Node selection: Capacity >= Sum(Req| | - Exceeding CPU: Throttling (CFS) | |
- | +---------------------------------------+ | - Exceeding Memory: OOMKilled (137)| |
- | +-------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- CPU Resources (Compressible)
Units : Measured in millicores ( m ) or whole cores ( 1000m = 1 vCPU / Core / Hyperthread ). A request of 250m represents 25% of a CPU core.
Behavior Under Contention : CPU is a compressible resource. If a container attempts to consume more CPU than its allocated limit, the Linux kernel Completely Fair Scheduler (CFS) throttles the container by restricting its CPU execution time slices (using cpu.cfs_quota_us and cpu.cfs_period_us in cgroups v1, or cpu.max in cgroups v2). The container experiences latency and reduced processing throughput, but the process is never killed .
Memory Resources (Incompressible)
Units : Measured in bytes or power-of-two mebibytes/gibibytes ( Mi , Gi ) or decimal megabytes/gigabytes ( M , G ). 1Mi = 1,048,576 bytes , whereas 1M = 1,000,000 bytes .
Behavior Under Contention : Memory is an incompressible resource. If a container consumes all its allocated memory and attempts to allocate more beyond its limits.memory , the Linux kernel triggers the Out Of Memory (OOM) Killer . The kernel immediately sends a SIGKILL (Signal 9) to the container process, terminating it with Exit Code 137 ( 128 + 9 ). kubectl describe pod will display Reason: OOMKilled .
Ephemeral Storage Requests and Limits
Kubernetes also supports tracking local node storage (including container writable layers, container logs in /var/log/pods , and emptyDir volumes):
requests.ephemeral-storage : Informs the scheduler of minimum disk capacity needed on the node.
limits.ephemeral-storage : Hard cap. If an emptyDir volume or container writable layer exceeds this limit, the kubelet evicts the Pod from the node. apiVersion: v1
kind: Pod
metadata:
- name: backend-processor
- namespace: production
spec:
containers:
- name: app
- image: redis:7.0-alpine
resources:
requests:
- cpu: "250m"
- memory: "512Mi"
- ephemeral-storage: "1Gi"
limits:
- cpu: "1000m"
- memory: "1Gi"
- ephemeral-storage: "2Gi"
- 2. Quality of Service (QoS) Classification
The kube-scheduler and kubelet automatically assign every Pod to one of three Quality of Service (QoS) classes based entirely on how requests and limits are configured across all containers in the Pod: +-----------------------------------------------------------------------------------------+
- | QOS DETERMINATION MATRIX |
- | |
- | 1. GUARANTEED (Highest Priority | oom_score_adj: -997) |
- | - Every container in Pod has CPU & Memory Requests AND Limits defined. |
- | - CPU Request == CPU Limit AND Memory Request == Memory Limit for all containers. |
- | |
- | 2. BURSTABLE (Moderate Priority | oom_score_adj: 100 - 999) |
- | - At least one container has a CPU or Memory Request. |
- | - Does not meet the strict equality criteria of Guaranteed. |
- | |
- | 3. BESTEFFORT (Lowest Priority | oom_score_adj: 1000) |
- | - No Requests and no Limits set for ANY container in the Pod. |
- +-----------------------------------------------------------------------------------------+
QoS Class Qualification Requirement Typical memory OOM adjustment
Guaranteed Every container specifies CPU and memory requests and limits, with each request equal to its limit. Strong protection (commonly -997 )
Burstable At least one container has a request or limit, but the Pod does not qualify as Guaranteed. Calculated from requested memory
BestEffort No container has CPU or memory requests or limits. Least protection (commonly 1000 )
The OOM adjustment affects the Linux kernel OOM killer. Kubelet node-pressure eviction is a separate ranking process. For a resource such as memory, kubelet first separates Pods whose current usage exceeds their requests from those that do not. Within the relevant group it considers Pod Priority, then how far usage exceeds the request. A BestEffort Pod has a zero request and commonly ranks as exceeding it, but a fixed “BestEffort, then Burstable, then Guaranteed” ordering is not guaranteed. A high-priority BestEffort Pod can outlive a lower-priority Burstable Pod that is also over request.
Pods whose usage is below requests are not immune if kubelet cannot reclaim enough resource. Static Pods and system-critical workloads also have priority considerations. Diagnose actual decisions through node events and kubelet logs rather than inferring solely from the displayed QoS class.
- 3. LimitRanges---
- 3. LimitRanges: Namespace Defaulting and Boundaries
A LimitRange is a namespaced resource that automatically injects default requests/limits into incoming Pods and enforces boundary constraints (min/max size). apiVersion: v1
kind: LimitRange
metadata:
- name: core-resource-limits
- namespace: staging
spec:
limits:
- type: Container
- default: # Default LIMIT if omitted by user
- cpu: "500m"
- memory: "512Mi"
- defaultRequest: # Default REQUEST if omitted by user
- cpu: "100m"
- memory: "256Mi"
- max: # Maximum allowed request/limit per container
- cpu: "2000m"
- memory: "2Gi"
- min: # Minimum allowed request/limit per container
- cpu: "50m"
- memory: "64Mi"
maxLimitRequestRatio:
- cpu: "4" # Limit cannot exceed 4x the Request
- type: Pod
max:
- cpu: "4000m"
- memory: "4Gi"
Note
If a developer applies a Pod manifest with no resources block in a namespace with an active LimitRange, the Admission Controller automatically mutates the Pod manifest, populating it with the defaultRequest and default limit values.
4. ResourceQuotas: Namespace Capacity Caps
A ResourceQuota restricts total aggregate resource consumption across an entire namespace, preventing any single team or project from consuming all cluster compute, storage, or object counts. apiVersion: v1
kind: ResourceQuota
metadata:
- name: team-compute-quota
- namespace: staging
spec:
hard:
- requests.cpu: "4" # Max total CPU requests across all Pods in namespace
- requests.memory: "8Gi" # Max total Memory requests across all Pods
- limits.cpu: "8" # Max total CPU limits
- limits.memory: "16Gi" # Max total Memory limits
- pods: "10" # Max number of Pods allowed in namespace
- services: "5" # Max number of Services
- services.loadbalancers: "1" # Max cloud load balancers
- persistentvolumeclaims: "4" # Max PVC count
- requests.storage: "100Gi" # Max total persistent storage allocation
- The ResourceQuota Golden Rule
If a ResourceQuota restricts compute resources ( requests.cpu or requests.memory ), every single Pod submitted to that namespace MUST explicitly specify resource requests (either in its YAML manifest or automatically through an active LimitRange). If requests are omitted and no LimitRange exists, the API server rejects the Pod creation with a 403 Forbidden error ( exceeded quota: ... is missing request for cpu ).
Quota Scopes and PriorityClasses
ResourceQuotas can be restricted to specific Pod subsets using spec.scopes :
Terminating : Applies only to Pods with spec.activeDeadlineSeconds >= 0 .
NotTerminating : Applies only to long-running Pods ( activeDeadlineSeconds unset).
BestEffort : Applies only to Pods with BestEffort QoS.
NotBestEffort : Applies to Guaranteed and Burstable Pods.
scopeSelector : Matches Pods based on PriorityClass names.
5. CKA Exam CLI Commands & Troubleshooting Workflows # Inspect ResourceQuota status and current utilization in a namespace
- kubectl get resourcequota -n staging
- kubectl describe resourcequota team-compute-quota -n staging
- # Inspect LimitRange rules in a namespace
- kubectl describe limitrange core-resource-limits -n staging
- # Check live compute utilization of nodes and pods
- kubectl top nodes
- kubectl top pods -n staging --containers
- # Troubleshoot Pod rejection due to quota breach
- kubectl get events -n staging --field-selector reason=FailedCreate --sort-by=.metadata.creationTimestamp