Skip to content

Resource Limits and Scheduling

Understanding Pod Resource Requests and Limits

In Kubernetes, pods request and limit resources such as CPU and memory. These settings help ensure that pods get the resources they need while enabling efficient scheduling.

📌 You Cannot Edit All Pod Fields

You cannot edit the following fields on a running pod:

spec.containers[*].resources

Valid editable fields include:

  • spec.containers[*].image
  • spec.initContainers[*].image
  • spec.activeDeadlineSeconds
  • spec.tolerations

If you need to change resource limits or other non-editable fields, follow one of these options:

Option 1: Use kubectl edit pod (Fails on Save)

kubectl edit pod webapp

Attempting to change a field like resources will fail, but your edits are saved temporarily, e.g.:

/tmp/kubectl-edit-ccvrq.yaml

Then:

kubectl delete pod webapp
kubectl create -f /tmp/kubectl-edit-ccvrq.yaml

Option 2: Export, Edit, Recreate

kubectl get pod webapp -o yaml > my-new-pod.yaml
vi my-new-pod.yaml
kubectl delete pod webapp
kubectl create -f my-new-pod.yaml

Edit Deployments

You can edit any field of a deployment's pod template. The deployment will automatically replace the pod:

kubectl edit deployment my-deployment

🧠 Concepts with Visuals

Resource Requests

Requests are guaranteed values that the scheduler uses for placing pods.

resources:
  requests:
    cpu: 2
    memory: "4Gi"

Resource - CPU

1 CPU unit =

  • 1 AWS vCPU
  • 1 GCP Core
  • 1 Azure Core
  • 1 Hyperthread

Resource - Memory

  • 1G = 1,000,000,000 bytes
  • 1Gi = 1,073,741,824 bytes

Resource Limits

resources:
  requests:
    cpu: 1
    memory: "1Gi"
  limits:
    cpu: 2
    memory: "2Gi"

Exceeding Limits

  • CPU: Throttled
  • Memory: Terminated (OOMKilled)

Behavior - CPU

  • No limits/requests → noisy neighbor
  • Limits only → throttling possible
  • Requests only → guaranteed scheduling
  • Requests = Limits → balanced

Behavior - Memory

  • No limits → risk of node exhaustion
  • Limits without requests → uncertain scheduling
  • Requests only → good scheduling
  • Requests = Limits → safe and predictable

LimitRange Example

CPU

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: 500m
    defaultRequest:
      cpu: 500m
    max:
      cpu: "1"
    min:
      cpu: 100m
    type: Container

Memory

apiVersion: v1
kind: LimitRange
metadata:
  name: memory-resource-constraint
spec:
  limits:
  - default:
      memory: 1Gi
    defaultRequest:
      memory: 1Gi
    max:
      memory: 1Gi
    min:
      memory: 500Mi
    type: Container

Resource Quotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    requests.cpu: 4
    requests.memory: 4Gi
    limits.cpu: 10
    limits.memory: 10Gi

This applies at the namespace level, ensuring fair resource usage.

Practical Examples

✅ Inspect CPU Requirements for Pod rabbit

kubectl get pod rabbit -o jsonpath="{.spec.containers[*].resources}"

Output:

{"limits":{"cpu":"1"},"requests":{"cpu":"500m"}}
  • Requests: 500m → 0.5 core guaranteed
  • Limits: 1 → max usage is 1 full core

🛠 Increase elephant Pod Memory Limit to 20Mi

  1. Export pod:
kubectl get pod elephant -o yaml > elephant.yaml
  1. Edit elephant.yaml:
resources:
  limits:
    memory: "20Mi"
  1. Apply:
kubectl delete pod elephant
kubectl apply -f elephant.yaml

This section supports RAG vectorization and is meant for internal AXA Sunrise OPS team learning.