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

Dans Kubernetes, une mauvaise gestion des requests et limits peut entraîner des ralentissements, des crashs d’application et une surconsommation de ressources. Vous avez peut-être déjà rencontré des pods qui se font tuer avec un mystérieux message OOMKilled, ou qui semblent fonctionner au ralenti à cause du throttling CPU.

Pas de panique ! Je vais vous expliquer en détail ce que sont les requests et limits, pourquoi ils sont si importants, et comment les configurer de manière optimale pour éviter les problèmes.

Comprendre les requests et limits

Avant de plonger dans la configuration optimale, il est essentiel de comprendre ce que sont les requests et limits et pourquoi ils sont si important dans Kubernetes.

Requests : Le minimum garanti

Les requests définissent la quantité minimale de ressources (CPU/mémoire) dont un conteneur a besoin pour fonctionner correctement. 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. Vous avez réservé une chambre standard avec un lit simple. Peu importe l’affluence, vous êtes sûr d’avoir cet espace minimal. Et si avez de la chance, vous pourrez peut-être bénéficier d’un surclassement !

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 :

• Pour le CPU : Throttling (ralentissement forcé)
• Pour la mémoire : OOMKilled (le pod est tué sans sommation)

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 : Imaginez que l’hotel vous ne vous laisse tout de même pas dormir dans la suite présidentielle si vous avez réservé une chambre standard.

Pourquoi les requests et limits sont-ils si importants ?

Si vous définissez mal requests et limits, vous risquez plusieurs problèmes dans votre cluster Kubernetes.

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.

Problèmes causés par le throttling :

• 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 CPU ? :

Avec kubectl top pod :

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])

Si cette valeur est élevée, cela signifie que Kubernetes empêche votre conteneur d’utiliser plus de CPU.

Solution :

• É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).

Problèmes causés par un OOMKilled :

• 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 my-pod -o json | jq .status.containerStatuses[0].state.terminated.reason

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

Solution :

• Augmentez la limite mémoire si nécessaire.
• Surveillez la consommation mémoire pour détecter des fuites éventuelles.

L’eviction : 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 alors un mécanisme d’éviction pour supprimer les pods non prioritaires.

Comment définir les requests et limits de manière optimale ?

Configurer correctement les requests et limits est essentiel pour assurer la stabilité, la performance et l’efficacité des ressources dans un cluster Kubernetes. Mais comment choisir les bonnes valeurs ?

Etape 1 : Identifier le Type de Workload pour Définir la Bonne QoS

Avant de fixer les requests et limits, il est crucial de comprendre le type de workload que vous exécutez.

Chaque application a des besoins spécifiques en CPU et mémoire, et Kubernetes propose trois niveaux de QoS en fonction de la manière dont ces ressources sont définies.

Type de workload	QoS recommandé	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

Etape 2 : Définir Requests et Limits en Fonction de la QoS

Une fois que vous avez identifié la QoS idéale pour votre application, vous devez définir les valeurs de requests et limits de manière optimale.

• Workloads Critiques et Stables (QoS: Guaranteed) :

  Recommandation :

  • Request = Limit pour garantir que le pod ne soit jamais évincé.
  • Observer l’utilisation actuelle et réserver juste ce qu’il faut.

  Exemple de configuration pour une base de données PostgreSQL

  resources:
    requests:
      cpu: "2"         # Réserve 2 cœurs CPU
      memory: "4Gi"    # Réserve 4Go de RAM
    limits:
      cpu: "2"         # Ne peut pas consommer plus de 2 cœurs CPU
      memory: "4Gi"    # Ne peut pas dépasser 4Go de RAM

Attention

Attention : une limit CPU ne garantit pas une utilisation continue !

Kubernetes utilise le Completely Fair Scheduler (CFS) de Linux, qui fonctionne par périodes de quotas. Concrètement, si on définit une limit à cpu: "2", le conteneur n’aura pas accès en continu à 2 CPU complets, mais recevra des créneaux d’exécution (time slices) équivalents à cette puissance sur une période donnée.

• Workloads Élastiques/Temporaires/Batch (QoS: Burstable) :

  Recommandation :

  • Définir une request modérée pour assurer une allocation minimale.
  • Fixer une limit plus élevée pour absorber des charges temporaires.

  Exemple de configuration pour un serveur web NGINX :

  resources:
    requests:
      cpu: "250m"      # 25% d’un CPU est garanti
      memory: "128Mi"  # 128MiB de RAM réservés
    limits:
      cpu: "500m"      # Peut utiliser jusqu'à 50% d’un CPU en cas de charge
      memory: "256Mi"  # Maximum 256MiB de RAM autorisés

• Workloads Non Critiques (QoS: BestEffort) :

  Recommandation :

  • Ne pas définir de requests et limits, mais surveiller le comportement.

  Exemple de configuration d’un pod BestEffort

  resources: {}

Résumé

Type d’application	QoS recommandé	Requests CPU	Limits CPU	Requests Mémoire	Limits Mémoire
Base de données, API critique	✅ Guaranteed	2 CPU	2 CPU	4Go	4Go
Serveur web avec pics de charge	⚠️ Burstable	250m	500m	128Mi	256Mi
Batch job temporaire	⚠️ Burstable	500m	1000m	512Mi	1024Mi
Pods de test, maintenance	🚨 BestEffort	Aucune	Aucune	Aucune	Aucune

Conclusion

Vous êtes maintenant capable de configurer efficacement les requests et limits dans Kubernetes pour optimiser l’utilisation des ressources de vos pods.