Kubernetes Resource Limits and Requests

Why Set Resource Limits?

Resource requests and limits ensure fair resource distribution and prevent a single Pod from consuming all CPU or memory on your Breeze. Without them, one misbehaving container can starve other workloads.

Requests vs Limits

• Requests — the minimum resources guaranteed to the container. The scheduler uses this to place Pods on nodes.
• Limits — the maximum resources a container can use. Exceeding the memory limit causes an OOMKill.

Set Resources in a Pod Spec

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: my-app:latest
          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"

Understanding CPU Units

• 1 = 1 full CPU core
• 500m = 0.5 CPU core (500 millicores)
• 100m = 0.1 CPU core

Check Current Resource Usage

kubectl top pods
kubectl top nodes
kubectl describe node your-node | grep -A 5 "Allocated resources"

Set Default Limits with LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: default
spec:
  limits:
    - default:
        memory: "256Mi"
        cpu: "250m"
      defaultRequest:
        memory: "128Mi"
        cpu: "100m"
      type: Container

Set Namespace Quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: default
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "20"

Best Practices

• Always set both requests and limits for production workloads
• Set requests based on actual usage from monitoring data
• Set limits 2x the request as a starting point
• Use LimitRange to enforce defaults on your Breeze cluster