Kubernetes : requests, limits et QoS classes

Un cluster Kubernetes sans requests et limits est un cluster qui finira par avoir des nœuds surchargés, des pods évincés et des OOMKills en production. Comprendre le système de resources est fondamental pour opérer Kubernetes.

Requests vs Limits : la distinction essentielle

Requests — ce que le pod est garanti d’avoir. Le scheduler utilise les requests pour décider sur quel nœud placer le pod. Un pod ne sera jamais schedulé sur un nœud qui n’a pas assez de resources disponibles pour ses requests.

Limits — le maximum que le pod peut utiliser. Si un pod dépasse sa limit CPU, il est throttlé (ralenti). S’il dépasse sa limit mémoire, il est tué (OOMKill).

spec:
  containers:
    - name: api
      image: myapp:1.0
      resources:
        requests:
          memory: "256Mi"    # garanti — utilisé par le scheduler
          cpu: "250m"        # 0.25 vCPU garanti
        limits:
          memory: "512Mi"    # max — OOMKill si dépassé
          cpu: "500m"        # max — throttling si dépassé

Les trois classes QoS

Kubernetes attribue automatiquement une QoS class à chaque pod selon ses requests/limits, ce qui détermine sa priorité lors des evictions (quand un nœud manque de ressources).

Guaranteed — requests == limits pour tous les conteneurs. Ces pods sont les derniers à être évincés.

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"   # identique aux requests
    cpu: "250m"       # identique aux requests

Burstable — requests < limits. Évincés après les BestEffort.

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"

BestEffort — aucun request ni limit défini. Premiers à être évincés.

LimitRange : valeurs par défaut au niveau namespace

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: production
spec:
  limits:
    - type: Container
      default:           # limits par défaut si non spécifiées
        memory: "256Mi"
        cpu: "500m"
      defaultRequest:    # requests par défaut si non spécifiées
        memory: "128Mi"
        cpu: "100m"
      max:               # jamais plus que ces valeurs
        memory: "2Gi"
        cpu: "2"
      min:               # jamais moins
        memory: "64Mi"
        cpu: "50m"

ResourceQuota : limiter la consommation d’un namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "20"        # total des requests CPU dans le namespace
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "50"                # max 50 pods dans le namespace
    services: "20"

Vertical Pod Autoscaler : dimensionner automatiquement

VPA analyse la consommation réelle et suggère (ou applique) les bonnes requests/limits.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: "Off"   # "Off" = recommandations seulement, pas d'application auto

# Voir les recommandations VPA
kubectl describe vpa myapp-vpa

# Output exemple :
# Recommended:
#   Container: api
#     Lower Bound:  100m CPU, 128Mi memory
#     Target:       250m CPU, 256Mi memory
#     Upper Bound:  500m CPU, 512Mi memory

Notre formation Kubernetes couvre la gestion des ressources avec des ateliers sur des clusters de production.