Quelle est la différence entre les requests et les limits CPU/mémoire, et comment affectent-elles le scheduling, l'éviction et la QoS ?

Question

IT Interview Practice · Accepted Answer

Les **requests** sont ce qu'un conteneur a *garanti* (utilisé pour le scheduling) ; les **limits** sont le *plafond* qu'il ne peut pas dépasser (imposé à l'exécution). Ensemble, elles déterminent où les Pods sont placés, comment ils sont throttlés ou tués sous pression, et quelle classe de **Quality of Service (QoS)** un Pod obtient.

## Requests vs limits

```text
REQUEST → la quantité RÉSERVÉE pour le conteneur. Le SCHEDULER utilise la somme des
          requests pour décider si un node a de la place. C'est votre plancher garanti.
LIMIT   → le MAX que le conteneur peut utiliser. Imposé à l'exécution :
          CPU au-dessus de la limit    → THROTTLÉ (ralenti, pas tué)
          mémoire au-dessus de la limit → OOM-KILLED (conteneur terminé, puis redémarré)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 d'un cœur, garanti
          memory: "256Mi"
        limits:
          cpu: "500m"        # peut monter jusqu'à 0,5 cœur, puis throttlé
          memory: "512Mi"    # dépasser ceci → OOMKilled
```

## Comment le scheduling utilise les requests

```text
Un node a 4 CPU / 8Gi allouables.
Le scheduler somme les REQUESTS des Pods déjà placés ; un nouveau Pod ne tient que si ses
requests tiennent encore dans ce qui reste. (Les limits ne sont PAS utilisées pour le placement.)
→ Requests trop basses → node surchargé, les Pods se battent pour les ressources.
→ Requests trop hautes → capacité gaspillée, Pods bloqués en Pending (rien ne tient).
```

## Classes de QoS (décident l'ordre d'éviction sous pression mémoire)

```text
Guaranteed  → requests == limits pour LES DEUX cpu & mémoire (chaque conteneur)
              → évincé en dernier (priorité la plus haute)
Burstable   → a des requests mais elles sont < limits (ou partiellement définies)
              → évincé après BestEffort
BestEffort  → aucune request ni limit du tout
              → PREMIER à être évincé quand le node manque de mémoire
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # usage réel CPU/mémoire
kubectl describe node <node>               # ressources allouées vs capacité
```

## Conseils pratiques

```text
✓ Mettez toujours memory requests = limits pour un comportement prévisible et OOM-safe sur les apps critiques
✓ Réglez les CPU requests sur le besoin en régime établi ; les CPU limits sont souvent omises pour permettre le bursting
✓ Dimensionnez à partir de l'usage réel (kubectl top / metrics) — pas au jugé
✓ Utilisez LimitRange / ResourceQuota pour imposer des valeurs par défaut saines par namespace
```

## Pourquoi c'est important

Les requests et les limits sont la façon dont Kubernetes partage les ressources finies des nodes de manière équitable et prévisible, donc comprendre la distinction et ses conséquences est une connaissance essentielle de performance et de fiabilité. L'idée centrale est qu'elles servent des buts différents : les **requests** sont une réservation garantie que le **scheduler** utilise pour placer les Pods (en sommant les requests pour décider si un node a de la place, en ignorant les limits), tandis que les **limits** sont un plafond à l'exécution imposé différemment selon la ressource — dépasser une limit **CPU** vous fait **throttler** (ralentir), mais dépasser une limit **mémoire** fait **OOM-killer** le conteneur qui est ensuite redémarré. Mal régler les requests a des coûts réels des deux côtés : trop basses et les nodes deviennent surchargés, les Pods s'affamant mutuellement ; trop hautes et la capacité est gaspillée tandis que les Pods restent en Pending faute de place. Les trois **classes de QoS** — Guaranteed (requests égales aux limits), Burstable (requests sous les limits) et BestEffort (rien de défini) — déterminent l'ordre d'éviction sous pression mémoire, BestEffort tué en premier et Guaranteed en dernier, ce qui est exactement ce que vous devez comprendre pour protéger les workloads critiques. Connaître les conseils pratiques (mettre memory requests égales aux limits pour les apps critiques, dimensionner à partir de l'usage réel via `kubectl top`, imposer des valeurs par défaut avec LimitRange/ResourceQuota) transforme cela de la théorie en une planification de capacité solide. Parce que la mauvaise configuration des ressources est l'une des causes les plus fréquentes d'instabilité, de dépenses gaspillées et de Pods en Pending dans de vrais clusters, maîtriser les requests, les limits et la QoS est fondamental pour faire tourner des workloads Kubernetes efficaces et stables.

Requests vs limits

Comment le scheduling utilise les requests

Classes de QoS (décident l'ordre d'éviction sous pression mémoire)

Conseils pratiques

Pourquoi c'est important

Questions connexes