Requests et limits Kubernetes : arrêter de deviner

Comment définir des requests et limits CPU/mémoire qui tiennent la route, pourquoi le surdimensionnement coûte cher, et une méthode simple pour calibrer.

Si tu mets des requests et limits au pif sur tes pods, tu paies trop cher ou tu te fais OOM kill en production. Voici une méthode pour sortir du pifomètre.

Le rôle de chaque valeur

  • requests : ce que le scheduler réserve. C’est la base du bin packing sur tes nœuds.
  • limits : le plafond. Dépasser la limite mémoire = le pod est tué.
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    memory: "512Mi"

Note : je ne mets pas de limite CPU ici. La limite CPU provoque du throttling qui dégrade la latence sans bénéfice réel sur un cluster bien dimensionné.

La méthode en 3 étapes

  1. Mesure d’abord. Laisse tourner une à deux semaines avec des requests larges et observe la consommation réelle (Prometheus, kubectl top, ou un VPA en mode recommendation).
  2. Cale les requests sur le p95 de la consommation observée, pas sur le pic.
  3. Cale la limite mémoire avec ~30 % de marge au-dessus du p99.

Le piège du surdimensionnement

Des requests trop hautes « gaspillent » de la capacité réservée mais inutilisée : tes nœuds se remplissent côté réservation alors que le CPU réel est à 15 %. Résultat, tu paies des nœuds en plus pour rien.

Régler les requests, c’est du FinOps déguisé en config YAML.

Dans un prochain article, on verra comment automatiser tout ça avec le Vertical Pod Autoscaler.