Kubernetes Resource Configuration Guidelines

Kubernetes Resource Configuration Guidelines are the set of practices for declaring and tuning the compute resources — CPU, memory, and ephemeral storage — that Pods and their containers consume, so that the scheduler can place workloads correctly and the cluster remains stable under load. These guidelines cover how requests and limits should be chosen, how Quality of Service (QoS) classes emerge from those choices, how namespace-level quotas and defaults interact with individual workloads, and how autoscaling mechanisms depend on accurate resource data to function correctly.

Requests vs. Limits

Requests

A request is the amount of a resource the scheduler guarantees is available on a node before placing a Pod there. It is used purely for scheduling and bin-packing decisions — the sum of requests on a node cannot exceed that node's allocatable capacity.

Limits

A limit is the maximum amount of a resource a container is allowed to consume at runtime. CPU limits are enforced through throttling (the container is not killed, just slowed), while memory limits are enforced by the kernel OOM killer — exceeding a memory limit terminates the container.

Why Both Matter

Setting only limits without requests causes the scheduler to treat the Pod as if it needs a full node's worth of headroom in the worst case, or in older scheduling models leads to unpredictable placement. Setting only requests without limits allows a single container to consume unbounded resources on a node, starving neighboring workloads. Declaring both, sized appropriately, is the baseline expectation for any production workload.

Quality of Service Classes

Guaranteed

A Pod is assigned the Guaranteed QoS class when every container specifies both requests and limits, and the request equals the limit for both CPU and memory. These Pods are the last to be evicted under node resource pressure.

Burstable

A Pod is Burstable when at least one container has a request set, but requests and limits are not equal (or limits are unset). These Pods can consume more than their request when spare capacity exists, but are evicted before Guaranteed Pods under pressure.

BestEffort

A Pod with no requests or limits set on any container is BestEffort. These Pods are the first to be evicted when a node runs low on resources, and should be reserved for genuinely non-critical, disposable workloads.

Sizing Methodology

Baseline From Observation

Resource values should never be guessed from intuition. They should be derived from actual measured usage — CPU and memory metrics collected over a representative period covering peak load — using tools such as the Kubernetes Vertical Pod Autoscaler in recommendation mode, or historical metrics from a monitoring stack.

Headroom for Bursts

CPU requests are typically set near the steady-state average, with limits set high enough to absorb short bursts without throttling critical paths. Memory requests and limits are usually set closer together, since memory is not compressible the way CPU is — a container cannot be "throttled" out of an OOM condition.

Avoiding Over-Provisioning

Requests set far above actual usage waste cluster capacity and inflate infrastructure cost, since the scheduler reserves that capacity even if it is never used. Periodic review of actual versus requested usage is necessary to keep a cluster efficiently packed.

Namespace-Level Controls

ResourceQuota

A ResourceQuota object caps the total resource consumption (and object counts) within a namespace, preventing a single team or application from exhausting cluster-wide capacity.

LimitRange

A LimitRange object defines default requests and limits applied to containers that don't specify their own, as well as minimum and maximum bounds for any container in the namespace. This provides a safety net against Pods that omit resource declarations entirely.

Interaction With Autoscaling

Horizontal Pod Autoscaler (HPA)

The HPA scales the number of Pod replicas based on observed metrics (commonly CPU utilization as a percentage of the request). Because the HPA's target is expressed relative to the request value, an inaccurate request directly skews scaling behavior — an under-set request causes premature scale-out, while an over-set request delays scaling until it's too late.

Vertical Pod Autoscaler (VPA)

The VPA adjusts the resource requests and limits of a Pod's containers over time based on observed usage. Running VPA in Auto mode alongside HPA on the same metric can cause conflicting scaling decisions, so the two are typically paired carefully — VPA for memory, HPA for CPU-driven replica counts, is a common split.

Cluster Autoscaler

The Cluster Autoscaler adds or removes nodes based on whether pending Pods can be scheduled given current capacity. Accurate resource requests are what allow it to determine, correctly, whether a new node is actually required.

Example Configuration

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: codartium
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      type: Container
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: codartium
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

Practical Consequences

Well-configured resource requests and limits produce a cluster where the scheduler places workloads predictably, autoscalers respond to real signal rather than noise, and a single misbehaving Pod cannot destabilize its neighbors. Poorly configured resources are one of the most common root causes of node pressure incidents, cascading evictions, and unexplained latency spikes traced back to CPU throttling that was invisible without inspecting the resource configuration directly.