Resource requests and limits

Kubernetes · lesson 11 of 32 · 4 min read

Set CPU and memory so the scheduler can place your pods and the kernel does not kill them mid-request.

Open this lesson in the learning hub

Key points

  • requests are what the scheduler reserves on a node. limits are the ceiling the kernel enforces at runtime.
  • Exceed the CPU limit and the container is throttled, so it just gets slow. Exceed memory and it is OOMKilled.
  • No requests means BestEffort QoS, which is first in line for eviction when a node fills up. Always set requests.
  • Memory request equal to memory limit gives Guaranteed QoS, the safest setting for JVM services.
  • 1 CPU is one core, 500m is half. Memory uses Mi and Gi, not MB.
  • Add -XX:MaxRAMPercentage=75. The JVM reads the cgroup limit but only claims 25% of it by default.

Example

containers:
  - name: app
    image: ghcr.io/acme/web:1.4.2
    env:
      - name: JAVA_TOOL_OPTIONS
        value: "-XX:MaxRAMPercentage=75 -XX:+UseG1GC"
    resources:
      requests:
        cpu: "250m"        # scheduler reserves a quarter core
        memory: "512Mi"
      limits:
        cpu: "1"           # throttled above this
        memory: "512Mi"    # OOMKilled above this

Requests decide where you land. Limits decide how you fail.

Liveness, readiness and startup probes Horizontal Pod Autoscaling

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Kubernetes course, and every lesson in it is listed on the Kubernetes contents page.