Kubernetes Resource Limits

Resource limits are constraints placed on CPU and memory usage for containers or Pods.

To avoid a single pod consuming too much cluster or node resources and degrading other workloads.

CPU is the compute processing capacity available to a container or Pod.

Memory is the RAM available to a container or Pod.

A request is the minimum amount of CPU or memory reserved for a container.

A limit is the maximum amount of CPU or memory a container can use.

Request is guaranteed allocation; limit is the maximum cap.

The scheduler uses requests to decide which node can run the Pod.

Limits prevent runaway processes from exhausting node resources.

The `resources` block contains `requests` and `limits` for CPU and memory.

CPU request is the amount of CPU the scheduler tries to reserve for the Pod.

CPU limit is the upper bound on CPU the container can consume.

Memory request is the amount of memory guaranteed to the Pod by the scheduler.

Memory limit is the maximum memory the container can use before it is killed or throttled.

Usually the container is killed by the kernel OOM killer or the runtime enforces the limit.

The container may be throttled or slowed, but it is not usually killed immediately.

QoS (Quality of Service) classifies Pods based on request and limit values to determine eviction priority.

• Guaranteed
• Burstable
• BestEffort

Guaranteed QoS means requests and limits are equal for all containers.

Burstable QoS means requests and limits are set, but not equal.

BestEffort means no requests or limits are set.

They affect eviction priority and cluster behavior during resource pressure.

Node pressure means the node is short on compute, memory, or disk and Kubernetes starts evicting workloads.

Because without limits, one workload can starve others or trigger node instability.

CPU throttling slows a process when it exceeds the assigned CPU quota.

OOM kill means the kernel kills a process because it exceeded memory limits or system memory pressure.

Because memory limit too low causes crashes; too high can starve other pods.

It is the relationship between reserved and allowed resources, affecting burst capacity.

The scheduler decides which node can run a Pod based on resource requests and the cluster state.

It is the CPU and memory available for scheduling after system overhead and reservation.

Because the Pod can only schedule if the node has enough resource requests for the workload.

A pod can stay pending if no node has enough available resources matching its requests.

A Pending pod is waiting to be scheduled or bound to a node.

500m means 0.5 CPU (half a CPU core).

512Mi means 512 mebibytes of memory.

They are units for memory and CPU, where m means millicpu and Ki/Mi/Gi are binary memory units.

Because CPU is often fractional and expressed as thousandths of a core.

Common memory units include bytes, Ki, Mi, Gi, and similar binary units.

Because without requests, the scheduler may place workloads unpredictably and overload nodes.

Because it enforces a ceiling and reduces the chance of noisy neighbor behavior.

A noisy neighbor is a workload using excessive resources and impacting other workloads on the same node.

It is when the node is running out of CPU, memory, or disk and Kubernetes starts corrective actions.

Eviction is the process Kubernetes uses to terminate pods when the node can no longer support them.

Evictions can disrupt workloads if their resource requests and limits are poorly configured.

A ResourceQuota limits the total amount of resources a namespace can consume.

It prevents a single namespace from consuming too much cluster capacity.

A LimitRange defines default or maximum resource values for pods in a namespace.

To enforce a baseline and default resources for workloads in a namespace.

Kubernetes can apply defaults to pods that omit resource values based on the LimitRange.

A Deployment’s pod template can include resource requests and limits for all pod replicas.

Autoscaling decisions may depend on observed pod resource utilization and requests.

HPA (Horizontal Pod Autoscaler) scales pods based on metrics such as CPU utilization.

Because HPA uses resource utilization to decide when to scale, and bad limits can distort the metrics.

It is the average CPU percentage used by the pod relative to its request or limit.

Because the same percentage may correspond to different load depending on the pod’s request size.

It is the actual memory measured by the pod or node.

It happens when the process attempts to use more memory than allowed and is killed.

It means no explicit requests or limits are set for the container.

Because the pod may be scheduled without guarantees and may starve or be starved by others.

Because unrealistic limits create throttling, crashes, or overprovisioning.

A memory leak is a bug causing a program to consume memory continuously without releasing it.

They cap damage and can trigger restarts when a workload becomes unhealthy.

A CPU hog is a process or workload consuming excessive CPU time.

They prevent a single workload from monopolizing all compute on a node.

It is when the cluster experiences shortage relative to requests and usage.

It is the decision of which node should run a pod based on resources, labels, and constraints.

A node selector constrains which nodes a pod may be scheduled onto.

Because workloads may need to be placed onto nodes with the right capacity or hardware.

Taints and tolerations allow pods to schedule onto specific nodes or avoid others.

Because they influence where workloads run and how resources are shared.

It limits how many pods can be disrupted during voluntary or involuntary disruptions.

Because if a node is overloaded, more pods may be evicted and disruption increases.

A threshold is a limit or alerting point that flags unusual resource consumption.

Use requests for scheduling and guarantees, and limits for safe caps based on real workload needs.

It often includes heap and runtime overhead plus some buffer for GC and OS memory.

Java uses heap, object overhead, native memory, and GC behavior that affect actual memory consumption.

Some workloads benefit from bursting or using idle CPU when available.

A CPU burst is temporary additional CPU usage above the requested amount, if allowed by the node.

Because limits cap the maximum average throughput a process can use.

A pod can be restarted when the container exceeds its memory limit and is terminated.

Kubernetes uses Linux cgroups to enforce memory limits.

They are the underlying mechanism used by Kubernetes to enforce limits.

It restricts memory usage to the configured limit and may kill the process when exceeded.

Because a cluster can look healthy until one node saturates and causes evictions.

It is when a node does not have enough resources left to satisfy workloads.

A resource leak is an application bug that gradually consumes resources.

They can mask failures by causing restarts rather than correcting the root cause.

It happens when the numbers do not reflect actual runtime behavior, causing poor scheduling or failures.

A workload with misconfigured or greedy limits can starve others on the same node.

Capacity planning estimates how much CPU and memory the cluster must provide for current and future workloads.

A reservation is a guarantee that some resources are left for system daemons or critical workloads.

Because system services also need CPU and memory, and they should not be starved.

These system-level resources are important for node health and should not be fully consumed by user workloads.

Overcommit happens when total requested resources exceed total cluster capacity.

It can lead to node pressure and pod eviction under load.

Poor pod sizing causes poor utilization, unexpected throttling, or crash loops.

It is the typical amount of CPU and memory a workload uses in production.

It means tuning requests and limits based on real load and throughput observations.

Autoscaling responds to traffic dynamics; tuning sets a baseline for pod sizing and resource allocation.

• no requests
• no limits
• requests too low
• limits too low
• limits too high
• ignoring node capacity

The scheduler uses requests to find a suitable node and reserve space.

The runtime uses limits to enforce maximum cgroup usage.

Because the runtime and scheduler use them differently: one is soft reserved capacity, the other is enforcement.

Because the scheduler can only place pods on nodes with enough available requests.

When you want predictable behavior and consistent capacity planning.

To allow burst capacity without starving the node.

It allows short spikes above the request when there is available node capacity.

It is the point at which the runtime limits or throttles CPU usage.

Because it can cause OOM kills and disruption when multiple pods compete for memory.

Because the cluster may reserve memory that is not actually needed, reducing scheduling density.

It is local ephemeral storage, not CPU or memory, but may still affect disk usage.

The kubelet, kernel, and control plane components also consume CPU and memory.

The actual memory left for application workloads after system reservations.

It occurs when memory or disk is under heavy strain and Kubernetes starts eviction or scheduling restrictions.

A PriorityClass gives a pod higher or lower scheduling and eviction priority.

Because under pressure, Kubernetes may evict lower-priority pods first.

They help control the total resources users or namespaces can consume.

A quota object defines total requests and limits for a namespace.

Because LimitRange sets defaults and bounds, while quota limits total usage.

It is the namespace-level total for CPU, memory, and storage.

The cluster autoscaler adds or removes nodes based on pending pods and cluster load.

Because I/O and CPU pressure dictate whether more nodes are needed.

A node pool is a group of nodes with similar size or characteristics, often for scheduling CPU/memory workloads.

Because different apps have different CPU, memory, and capacity needs.

Request is the reserved baseline; usage is actual observed allocation.

Because pods can exceed requests or limits without the platform realizing it.

It shows pod resource usage over time and helps tune requests and limits.

A saturation event happens when the node or pod is at or near its CPU capacity.

It is when memory usage is close to limit or near the node’s total capacity.

They are the basis for scheduling and future node scaling.

Because sidecars may not need a strict cap or may be designed to burst.

A sidecar is a helper container in the same pod that shares resources with the main app.

Because sidecars compete for the same pod-level resource pool.

The sum of all containers’ requests and limits in a pod.

Because pod scheduling and resource enforcement happen at the pod/container aggregate level.

It may be lower than the main app, but the total still matters.

Because they share the pod’s total and can affect each other.

It can cause the app to be throttled or killed even though the node has enough overall capacity.

It can starve other pods or reduce cluster density, leading to poor scheduling.

Because real workloads differ by runtime, concurrency, and traffic patterns.

A container can restart after OOM, which can cause a crash loop if limits are set too low.

Because memory and CPU constraints remain aligned with actual workload behavior.

Headroom is the extra memory left after requests and limits to absorb bursts and system activity.

It helps avoid unnecessary evictions and OOM kills.

The extra CPU capacity in the node that allows bursts without system starvation.

Because operating system daemons and Kubernetes components also need resources.

Kubernetes uses scoring to pick the best node based on many factors, including resource fit.

CPU and memory are the standard ones, but custom resources can also be used in some clusters.

GPUs can be requested and limited as custom resources in some clusters.

It caps how much accelerator capacity a pod can use and is often modeled separately from CPU and memory.

They keep some CPU and memory available for system-critical tasks.

Because the node still needs to run kubelet, container runtime, and OS tasks.

It is the policy and sizing model for each production service based on expected traffic and workload characteristics.

Because it informs safe requests and limits, which impact scheduling and reliability.

It is the process of understanding total available CPU and memory and how much is consumed by workloads.

It is the process of measuring a workload under realistic conditions to determine good limits.

It measures whether a new workload version fits its resource budget before full rollout.

It is the visibility into actual CPU, memory, and process behavior of workloads.

An alert signals abnormal usage above expected thresholds.

A trend shows whether a workload grows over time and may require tuning or scaling.

Because workloads evolve and traffic changes over time.

It receives no scheduling guarantee and can be noisy or starved on a node.

It reduces scheduling efficiency and can create unanticipated contention.

Garbage collection may generate temporary CPU and memory use that is not always visible in baseline app metrics.

Under resource pressure, pods with lower QoS or lower priority are more likely to be evicted.

It is when the cluster experiences insufficient CPU or memory relative to current demand.

Because it affects eviction order and resilience under stress.

It is the idea that workloads use only the resources they are allowed to use based on limits and requests.

A pod starved of CPU or memory can behave erratically or fail under load.

Memory pressure increases the risk of OOM kills and performance degradation.

CPU pressure makes the process slow or queued behind resource limits.

Because one can cause slowness while the other can cause failures or restarts.

It determines which pods are sacrificed first during node pressure events.

Because it ensures workloads land on suitable nodes and avoids chaotic contention.

It improves reliability, predictability, and cluster health.

It is the initial request and limit values set based on profiling and expected load.

It ensures users or namespaces do not overwhelm the shared cluster resources.

It is the total requests across all pods in a namespace or cluster.

It is the actual usage relative to request or limit values.

Because good resource limits are derived from actual workload behavior, not guesses.

They are different Linux cgroup versions used by the runtime to enforce resource limits.

Because some tools and kernels behave differently depending on the cgroup version.

It is the tracking of CPU and memory consumed by containers and processes.

Because it provides the raw input for scheduling, alerting, autoscaling, and tuning.

They show current resource usage of nodes or pods for operational observability.

It helps estimate whether requests and limits are realistic and whether workloads are saturating the cluster.

The OOM killer may kill the highest-memory container or process when memory is exhausted.

Because it can restart a pod abruptly and cause service disruption.

Pods may temporarily use more memory than their request if there is free node memory.

Because the node can allow short spikes if capacity remains available.

It happens when a pod cannot be scheduled because no node has enough requested resources.

Because mis-sized CPU requests can cause under-scheduling or overutilization.

An app with many parallel workers or requests that may use bursts of CPU and memory.

Because they can be starved or killed if limits are too low and not aligned with traffic spikes.

It depends on low response time and stable resource availability.

Because if they do not have enough resources, they may queue or throttle and increase latency.

It often requires more predictability and less aggressive overcommit.

Because apps can degrade under load and appear “slow” even though they are still running.

Autoscaling decides scale-out based on load, while limits decide how much each pod can consume before throttling or OOM.

Resource limits are about safety, scheduling correctness, and cluster health; requests reserve capacity, limits cap usage, and both must be based on real workload behavior to keep the cluster stable and the app reliable.