Resource Requests & Limits

Introduction

Resource Requests & Limits is a practical Kubernetes capability, not just a definition to memorize. This lesson explains the problem it solves, why teams use it in production, how it behaves under failure, and how to practice it hands-on.

Purpose of this lesson

By the end, you should be able to decide when Resource Requests & Limits belongs in a design, implement it with a clear manifest or command flow, and troubleshoot the most common failure modes using Kubernetes status, events, logs, metrics, and ownership relationships.

Understanding the topic

Requests drive scheduling; limits cap runtime usage. CPU is throttled at the limit; memory beyond the limit causes OOMKilled.

Use requests to reserve scheduling capacity and use limits carefully to control runaway resource usage. Requests affect placement and autoscaling math; limits affect runtime behavior.

• Read every object through metadata, spec, and status: who owns it, what should happen, and what the cluster reports actually happened.
• Connect YAML to the responsible component: scheduler, kubelet, controller manager, cloud controller, CSI driver, CNI, CoreDNS, admission webhook, or application runtime.
• Use it only when it improves a real operating concern such as availability, rollout safety, service discovery, isolation, security, cost, or developer workflow.

Visual explanation

Use this mental model when explaining the lesson during design reviews or incidents:

Human / CI / GitOps
  |
  v
kube-apiserver stores desired state
  |
  +-> controller reconciles objects
  +-> scheduler places pods
  +-> kubelet runs containers
  |
  v
events, status, logs, metrics reveal reality

Step-by-step explanation

1. Identify the workload or platform problem first: availability, traffic routing, storage, configuration, identity, policy, scaling, observability, or troubleshooting.
2. Write the smallest useful desired state for Resource Requests & Limits; include labels, namespace, ownership, resource settings, and health checks where relevant.
3. Apply or render the change in a safe environment, then read status and events before assuming the manifest worked.
4. Break one realistic dependency such as a selector, image tag, probe, permission, quota, or endpoint and practice the recovery path.
5. Promote through Git or your release process with a rollback plan, alert coverage, and a short runbook.

Informative example

Requests and limits: After applying it, verify both desired and observed state. A production-ready workflow should include kubectl diff, apply, describe, get events, and a rollout or health check when the object supports it.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

Real-world use

A Java API with low memory requests is packed too densely, then gets OOMKilled during traffic spikes. Right-sizing requests and JVM settings stabilizes the service.

Best practices

• Keep manifests reviewed in Git and treat manual cluster changes as temporary break-glass actions.
• Use standard labels such as app.kubernetes.io/name, part-of, and managed-by so selectors, dashboards, alerts, and cost reports line up.
• Attach ownership, environment, and runbook metadata before resources reach production.

Common mistakes

• Confusing resource exists with resource is healthy. Always inspect status, events, and downstream dependencies.
• Changing selectors, labels, or names casually; these are contracts between controllers, Services, policies, dashboards, and GitOps tools.
• Debugging from memory instead of reading the object: kubectl describe, events, endpoints, and controller logs usually tell the story.

Debugging tips

• CPU throttling appears as latency without pod restarts; inspect container CPU throttled metrics.
• Memory over the limit becomes OOMKilled with exit code 137.
• HPA CPU utilization is calculated against requests, so bad requests create bad scaling.

Optimization strategies

• For latency-sensitive services, many teams set CPU requests and avoid strict CPU limits to reduce throttling.
• Set memory limits with headroom and align language runtime settings such as JVM max heap.
• Use VPA recommendations or historical p95 usage to right-size requests.

Advanced interview questions

Hands-on exercise

Create the resource in a disposable namespace, inspect its live status with kubectl describe, intentionally break one important field, and document the exact event or status condition that reveals the mistake.

# Suggested lab loop for Resource Requests & Limits
kubectl create namespace resource-requests-limits-lab
kubectl -n resource-requests-limits-lab apply -f lesson.yaml
kubectl -n resource-requests-limits-lab get all
kubectl -n resource-requests-limits-lab describe all
kubectl -n resource-requests-limits-lab get events --sort-by=.lastTimestamp

Summary

Resource Requests & Limits becomes valuable when you connect the API object or command to real operational behavior. Practice the happy path, then deliberately break it so troubleshooting becomes evidence-driven rather than guesswork.