Requests et Limits Kubernetes : Évitez les pièges !

Vos Pods Kubernetes se font tuer avec un mystérieux message OOMKilled ? Ou ils semblent tourner au ralenti malgré un serveur bien dimensionné ? Le problème vient probablement d’une mauvaise configuration des requests et limits — les paramètres qui définissent combien de CPU et de mémoire chaque Pod peut utiliser.

Ce guide vous explique comment configurer ces paramètres pour éviter les ralentissements, les crashs et la surconsommation de ressources.

Prérequis : concepts Kubernetes de base et un cluster fonctionnel.

Ce que vous allez apprendre

Comprendre la différence entre requests (ressources garanties) et limits (plafonds)
Identifier les symptômes d’une mauvaise configuration (OOMKilled, throttling)
Choisir la bonne classe de QoS selon le type d’application
Configurer les ressources pour des workloads critiques, élastiques et non critiques
Diagnostiquer les problèmes avec kubectl et Prometheus

Comprendre les requests et limits

Les requests et limits sont les deux paramètres qui contrôlent la consommation de ressources d’un conteneur.

Requests : le minimum garanti

Les requests définissent la quantité minimale de ressources (CPU/mémoire) dont un conteneur a besoin pour fonctionner. Kubernetes réserve ces ressources sur le nœud où le Pod est déployé.

Exemple : si un Pod demande 500m CPU (soit 50% d’un CPU), Kubernetes s’assure qu’un nœud ayant au moins cette capacité disponible l’accueille.

Analogie : c’est la taille minimale garantie de votre chambre d’hôtel. Vous avez réservé une chambre standard — peu importe l’affluence, vous êtes sûr d’avoir cet espace minimal.

Limits : la barrière à ne pas franchir

Les limits définissent la quantité maximale de ressources qu’un conteneur peut consommer. Si un Pod dépasse cette limite, Kubernetes applique des restrictions :

CPU : throttling (ralentissement forcé)
Mémoire : OOMKilled (le Pod est tué immédiatement)

Exemple : si un Pod a une limit de 1 CPU, il ne pourra jamais dépasser cette valeur, même en cas de forte demande.

Analogie : l’hôtel ne vous laissera jamais dormir dans la suite présidentielle si vous avez réservé une chambre standard.

Vérifier les ressources d’un Pod

kubectl describe pod mon-pod | grep -A 10 "Limits:"

Sortie attendue :

    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:     250m
      memory:  128Mi

Visualisation requests vs limits

Schéma requests vs limits Kubernetes

Le request (vert) est l’espace garanti par le scheduler. La zone burst (jaune) est disponible si le nœud a de la capacité. La limit (rouge) est le plafond absolu — au-delà, c’est le throttling CPU ou l’OOMKilled mémoire.

Les problèmes d’une mauvaise configuration

Si vous définissez mal requests et limits, vous risquez trois types de problèmes.

Throttling CPU : quand Kubernetes vous freine

Le throttling CPU se produit lorsque votre conteneur atteint sa limit CPU. Kubernetes utilise le planificateur CFS (Completely Fair Scheduler) de Linux pour le ralentir.

Symptômes :

L’application devient lente et peu réactive
Des timeouts apparaissent sur les requêtes
Une baisse de performance inattendue en période de charge

Comment détecter le throttling :

kubectl top pod

Si un Pod affiche 100% d’utilisation CPU, il est probablement en throttling.

Avec Prometheus :

rate(container_cpu_cfs_throttled_seconds_total[5m])

Une valeur élevée signifie que Kubernetes empêche votre conteneur d’utiliser plus de CPU.

Solutions :

Évitez de définir une limit CPU si ce n’est pas nécessaire
Augmentez la limit CPU si votre application a besoin de plus de puissance
Utilisez le Horizontal Pod Autoscaler (HPA) pour ajouter des Pods au lieu de restreindre un seul

OOMKilled : quand votre Pod explose

Contrairement au CPU, la mémoire ne peut pas être limitée dynamiquement. Si un Pod dépasse sa limit mémoire, Kubernetes le tue immédiatement avec le message OOMKilled (Out Of Memory Killed).

Symptômes :

Redémarrages en boucle (CrashLoopBackOff)
Pertes de données si l’application ne gère pas bien les interruptions
Instabilité du service si plusieurs Pods critiques sont affectés

Comment détecter un OOMKilled :

kubectl get pod mon-pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'

Si la réponse est OOMKilled, le Pod a dépassé sa limite mémoire.

Solutions :

Augmentez la limite mémoire
Surveillez la consommation mémoire pour détecter des fuites éventuelles
Utilisez Prometheus pour monitorer container_memory_working_set_bytes

Éviction : quand Kubernetes fait le ménage

Si un nœud manque de ressources, Kubernetes doit faire de la place pour les Pods les plus importants. Il utilise un mécanisme d’éviction pour supprimer les Pods non prioritaires.

L’ordre d’éviction dépend de la classe de QoS (Quality of Service) de chaque Pod.

Les trois classes de QoS

Kubernetes attribue automatiquement une classe de QoS à chaque Pod en fonction de sa configuration de ressources.

Classe	Condition	Priorité à l’éviction
Guaranteed	requests = limits (CPU et mémoire)	Derniers évincés
Burstable	requests < limits	Évincés après BestEffort
BestEffort	Aucun requests ni limits	Premiers évincés

Priorité d'éviction selon la QoS Kubernetes

En cas de pression mémoire sur un nœud, Kubernetes évince d’abord les Pods BestEffort, puis les Burstable, et en dernier recours les Guaranteed.

Vérifier la QoS d’un Pod :

kubectl get pod mon-pod -o jsonpath='{.status.qosClass}'

Configurer les ressources selon le workload

Identifier le type de workload

Type de workload	QoS recommandée	Pourquoi
Base de données, API critique	Guaranteed	Protégé contre l’éviction
Serveur web avec pics de charge	Burstable	Doit pouvoir monter en charge
Job batch temporaire	Burstable	A besoin de plus de ressources si disponible
Tâches non critiques	BestEffort	Peut être arrêté en cas de besoin

Configurer selon la QoS choisie

Workloads critiques (Guaranteed)

Pour les applications critiques (bases de données, APIs essentielles), configurez requests = limits :

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

Workloads élastiques (Burstable)

Pour les applications qui supportent les variations de charge :

resources:
  requests:
    cpu: "250m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

Cette configuration garantit 250m CPU et 128Mi en permanence, mais autorise jusqu’à 500m CPU et 256Mi en cas de pic.

Workloads non critiques (BestEffort)

Pour les tâches qui peuvent être interrompues sans conséquence :

resources: {}

Tableau récapitulatif

Type d’application	QoS	Requests CPU	Limits CPU	Requests Mémoire	Limits Mémoire
Base de données, API critique	Guaranteed	2 CPU	2 CPU	4Gi	4Gi
Serveur web	Burstable	250m	500m	128Mi	256Mi
Batch job	Burstable	500m	1000m	512Mi	1024Mi
Pods de test	BestEffort	-	-	-	-

Dépannage

Symptôme	Cause probable	Solution
Pod OOMKilled	Limit mémoire trop basse	Augmenter limits.memory
Application lente	Throttling CPU	Augmenter limits.cpu ou supprimer la limit
Pod Pending	Requests > ressources disponibles	Réduire requests ou ajouter des nœuds
Éviction fréquente	QoS BestEffort	Ajouter des requests pour passer en Burstable

À retenir

Requests = ressources garanties, utilisées par le scheduler pour placer le Pod
Limits = plafond maximal, déclenche throttling (CPU) ou OOMKill (mémoire)
QoS Guaranteed (requests = limits) : pour les workloads critiques
QoS Burstable (requests < limits) : pour les workloads avec pics de charge
QoS BestEffort (aucune config) : premiers évincés, à éviter en production
Le throttling CPU ralentit l’application ; l’OOMKilled la tue
Utilisez kubectl top pod et kubectl describe pod pour diagnostiquer

Contrôle des connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

90% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Prochaines étapes

Les Pods Kubernetes Comprendre l'unité d'exécution de base

Les Deployments Gérer le cycle de vie de vos applications

Probes Kubernetes Liveness, Readiness et Startup Probes

Autoscaling avec HPA Scaler automatiquement vos Pods