Requests, limits and PodDisruptionBudget: how to read a Kubernetes manifest without fooling yourself

Almost every upgrade incident and a good part of Kubernetes cost waste go through a few manifest fields: requests, limits, readinessProbe, replicas and the PodDisruptionBudget. They look simple, which is why the mistakes stay.

Requests: the field that sets cost

The request is what the scheduler reserves for the pod on a node. The node is billed whole, so cluster cost follows requests, not usage. A pod that asks for 2 CPUs and uses 200m takes the same room as one that uses all 2.

That has three effects:

• Inflated requests create nodes that look full and are idle, and no autoscaler fixes that on its own.
• Missing requests leave the pod without a reservation. It lands in the BestEffort or Burstable QoS class and is among the first removed when a node runs out of memory.
• Autoscalers, consolidation and Savings Plans planning depend on correct requests.

To set values, start from observed usage, for example the 95th percentile plus headroom, not a guess. rightsizing-check compares requests with usage (files or Prometheus) and tells you what to set.

Limits: CPU and memory behave differently

• Memory. Go past the limit and the container is killed by OOM. With no limit, a leak can eat the whole node. That is why you want a memory limit, close to the request.
• CPU. Go past the limit and the container is throttled, not killed. Tight CPU limits can raise latency without showing up as errors. Many teams use a CPU request with no CPU limit, and that is a valid choice, as long as it is a choice.

When requests equal limits on every container, the pod is Guaranteed, the most protected class. It is a good default for critical workloads, at the cost of less node utilization.

readinessProbe: what decides who gets traffic

Without a readinessProbe, the pod counts as ready as soon as the container starts. During a deploy or a consolidation, the Service may send traffic to a pod that is still starting. The probe also matters for the PDB, because it counts ready pods.

PodDisruptionBudget: what it protects and what it does not

A PDB limits how many pods of a service can be unavailable at once during voluntary disruptions: node drains, upgrades and consolidation by Karpenter or Cluster Autoscaler.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: checkout

The most common mistakes:

• A selector that does not match. If matchLabels does not correspond to the pod labels, the PDB protects nothing and no error appears. Check with kubectl get pdb and see whether ALLOWED DISRUPTIONS makes sense.
• `minAvailable` equal to the replica count (or maxUnavailable: 0). No pod can be removed, and node upgrades get stuck. Always leave some slack.
• A single replica with `minAvailable: 1`. Same problem: the pod can never leave.
• Thinking the PDB covers node failure. It does not. On Spot, for example, the two-minute notice limits what a drain can do, which is why replicas and spreading matter more than the PDB.

How to check all of this at once

The manifest checker reads your YAML in the browser, sending nothing, and flags missing requests, no memory limit, no readiness probe, the latest tag, a single replica, and no PDB or spreading, matching the PDB selector against the pod labels. For the cluster itself, spot-readiness applies similar rules and builds a plan of what can move to Spot.

A short plan

1. Run the checker on the manifests of your most critical service.
2. Fix requests and memory first: they have the biggest effect on cost and stability.
3. Add readiness and, on services with 2 or more replicas, a PDB and topologySpreadConstraints.
4. Test a node drain in staging and see whether the PDB lets through what it should.

To understand the financial effect of fixing requests, use the savings calculator. If you want a review of your cluster, the efficiency assessment is the place to start.