Requêtes et limites de ressources Kubernetes : concepts avancés expliqués avec des exemples pratiques

Introduction

Les requêtes et limites de ressources Kubernetes sont essentielles pour la stabilité et l'efficacité du cluster. Les requêtes garantissent une quantité minimale de CPU et de mémoire pour un conteneur, tandis que les limites plafonnent sa consommation maximale. Une mauvaise configuration peut entraîner l'éviction des pods, la surallocation de nœuds ou une limitation inattendue du CPU.

Cet article va au-delà des bases et explore des concepts avancés : comment le planificateur utilise les requêtes, comment le kubelet applique les limites, les trois classes de Qualité de Service (QoS) et comment les ResourceQuotas et LimitRanges régissent l'utilisation des ressources au niveau de l'espace de noms. Nous fournissons des exemples pratiques, des commandes et des extraits de configuration pour vous aider à diagnostiquer et résoudre les problèmes liés aux ressources dans votre cluster.

À la fin, vous comprendrez comment définir efficacement les requêtes et les limites, interpréter les classes QoS et appliquer des politiques organisationnelles avec des quotas et des limites.

Inventaire de version et d'environnement

Avant de dépanner ou de modifier les paramètres de ressources, établissez une image claire de votre environnement. Cette section couvre les composants impliqués et comment recueillir des informations pertinentes.

Composants clés :

• Cluster Kubernetes (version 1.28 ou ultérieure recommandée ; les exemples ici sont indépendants de la version mais évitent les API obsolètes).
• kubectl configuré avec les autorisations appropriées.
• Un espace de noms de test où vous pouvez appliquer des modifications en toute sécurité.

Commandes d'observation :

Commencez par vérifier la version du cluster et votre contexte actuel :

kubectl version --short
kubectl config current-context

Listez les pods existants avec une sortie large pour voir l'affectation des nœuds et les adresses IP :

kubectl get pods -o wide --namespace=votre-espace-de-noms

Décrivez un pod spécifique pour inspecter ses requêtes, limites et événements :

kubectl describe pod votre-nom-de-pod --namespace=votre-espace-de-noms

Vérifiez les événements récents pour les avertissements liés aux ressources :

kubectl get events --namespace=votre-espace-de-noms --sort-by=.lastTimestamp

Exemple d'extrait de sortie de kubectl describe pod :

Containers:
  my-app:
    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:     250m
      memory:  128Mi

Si les requêtes ou les limites sont absentes, notez que le pod s'exécute sans garanties de ressources, ce qui peut affecter la planification et la QoS.

Chemin de configuration sécurisé

Modifier les requêtes et limites de ressources peut perturber les charges de travail en cours. Suivez ce chemin sécurisé pour minimiser les risques.

Étape 1 : Comprendre la configuration actuelle

Inspectez les déploiements existants pour voir comment les ressources sont actuellement définies :

kubectl get deployment mon-deploiement -o yaml --namespace=votre-espace-de-noms

Recherchez le champ resources dans chaque spécification de conteneur. S'il est absent, le conteneur n'a ni requêtes ni limites.

Étape 2 : Commencez par des modifications en lecture seule

Ne modifiez jamais directement un déploiement en direct. Utilisez plutôt kubectl edit seulement après avoir sauvegardé le manifeste :

kubectl get deployment mon-deploiement -o yaml > mon-deploiement-backup.yaml

Alternativement, utilisez un essai à blanc pour tester les modifications sans les appliquer :

kubectl set resources deployment mon-deploiement --requests=cpu=200m,memory=256Mi --limits=cpu=500m,memory=512Mi --dry-run=client -o yaml

Cela affiche l'objet modifié sans l'envoyer au serveur API.

Étape 3 : Appliquez les modifications progressivement

Appliquez les modifications de ressources en utilisant un patch ou un manifeste modifié. Par exemple, patchez le déploiement :

kubectl patch deployment mon-deploiement --patch '{"spec":{"template":{"spec":{"containers":[{"name":"my-app","resources":{"requests":{"cpu":"200m","memory":"256Mi"},"limits":{"cpu":"500m","memory":"512Mi"}}}]}}}}'

Ensuite, surveillez l'état du déploiement :

kubectl rollout status deployment/mon-deploiement --namespace=votre-espace-de-noms

Si le déploiement échoue, effectuez immédiatement un rollback :

kubectl rollout undo deployment/mon-deploiement --namespace=votre-espace-de-noms

Étape 4 : Vérifiez l'affectation des ressources du pod

Après le déploiement, vérifiez les nouveaux pods :

kubectl get pods -l app=my-app --namespace=votre-espace-de-noms
kubectl describe pod <nouveau-nom-de-pod> --namespace=votre-espace-de-noms | grep -A5 Resources

Confirmez que les requêtes et limites sont correctement définies.

Vérification et diagnostics

Une fois les ressources configurées, vérifiez que le planificateur et le kubelet les appliquent correctement.

Vérifier les décisions de planification

Le planificateur place les pods en fonction des requêtes. Si un pod est en attente, inspectez pourquoi :

kubectl describe pod pod-en-attente --namespace=votre-espace-de-noms

Recherchez des événements comme Insufficient cpu ou Insufficient memory.

Exemple d'événement :

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  10s   default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

Cela indique que la requête CPU du pod dépasse la capacité disponible sur tous les nœuds.

Inspecter les ressources allouables du nœud

Vérifiez la capacité du nœud et les ressources allouables :

kubectl describe node <nom-du-nœud> | grep -A5 "Allocatable"

Allocatable est la quantité disponible pour les pods après la surcharge système. Comparez le total des requêtes sur le nœud avec l'allouable pour voir si vous êtes en surallocation.

Utilisez un outil comme kubectl top pour voir l'utilisation actuelle :

kubectl top nodes
kubectl top pods --namespace=votre-espace-de-noms

Diagnostiquer la limitation CPU et OOMKilled

Si les limites CPU sont trop basses, le conteneur sera limité. Vérifiez les statistiques cgroup CPU à l'intérieur du pod (nécessite l'accès au nœud ou au serveur de métriques) :

kubectl exec -it mon-pod -- cat /sys/fs/cgroup/cpu.stat

Recherchez les valeurs nr_throttled et throttled_time.

Pour les limites mémoire, si un conteneur dépasse sa limite mémoire, le tueur OOM du noyau le termine. Le statut du pod affichera OOMKilled :

kubectl get pod mon-pod --namespace=votre-espace-de-noms

Sortie :

NAME     READY   STATUS      RESTARTS   AGE
mon-pod  0/1     OOMKilled   1          5m

Ensuite, inspectez les journaux précédents :

kubectl logs mon-pod --previous --namespace=votre-espace-de-noms

Modes de défaillance et récupération

Les mauvaises configurations de ressources entraînent des modes de défaillance spécifiques. Voici des scénarios courants et comment récupérer.

Défaillance : Pod en attente en raison de ressources insuffisantes

Symptôme : Le pod reste à l'état Pending.

Cause : Les requêtes dépassent les ressources disponibles du nœud.

Récupération :

• Réduisez d'autres charges de travail ou ajoutez des nœuds.
• Réduisez les requêtes du pod si elles étaient trop élevées.

kubectl scale deployment mon-deploiement --replicas=0
# ajuster les requêtes
kubectl scale deployment mon-deploiement --replicas=1

Défaillance : Conteneur OOMKilled

Symptôme : Le pod redémarre à plusieurs reprises avec le statut OOMKilled.

Cause : L'utilisation de la mémoire dépasse la limite.

Récupération :

• Augmentez la limite mémoire si légitime.
• Optimisez l'utilisation de la mémoire de l'application.
• Assurez-vous que la limite n'est pas inférieure à l'utilisation de base.

kubectl set resources deployment mon-deploiement --limits=memory=1Gi --requests=memory=512Mi

Défaillance : Limitation CPU

Symptôme : L'application est lente, mais l'utilisation du CPU est inférieure à la limite.

Cause : La limite CPU est trop basse par rapport aux pics.

Récupération :

• Augmentez la limite CPU ou supprimez la limite pour permettre les pics (mais considérez la stabilité du nœud).

kubectl set resources deployment mon-deploiement --limits=cpu=2

Défaillance : Éviction de pod en raison de la pression mémoire

Symptôme : Le pod est évincé même s'il est dans sa limite mémoire.

Cause : Pression mémoire du nœud ; les pods sans requêtes mémoire ou avec une QoS inférieure sont évincés en premier.

Récupération :

• Définissez des requêtes mémoire non nulles pour éviter d'être dans la QoS BestEffort.
• Assurez-vous que les requêtes sont réalistes.

resources:
  requests:
    memory: "128Mi"
  limits:
    memory: "256Mi"

Liste de contrôle des opérations

Utilisez cette liste pour exploiter les requêtes et limites de ressources en production en toute sécurité.

• [ ] Version du cluster et accès kubectl vérifiés.
• [ ] Paramètres de ressources actuels documentés pour toutes les charges de travail critiques.
• [ ] Requêtes et limites de ressources définies pour chaque conteneur en production.
• [ ] Les requêtes reflètent une utilisation moyenne réaliste ; les limites reflètent le pic plus une marge.
• [ ] Aucun pod à l'état Pending en raison de ressources insuffisantes.
• [ ] Aucun événement OOMKilled récent (vérifiez kubectl get pods --all-namespaces | grep OOMKilled).
• [ ] Limitation CPU surveillée et dans une plage acceptable.
• [ ] ResourceQuotas définis pour les espaces de noms avec plusieurs équipes.
• [ ] LimitRanges définis pour fournir des valeurs par défaut et empêcher la surallocation.
• [ ] Ressources allouables du nœud comparées aux requêtes totales pour éviter une surallocation au-delà de la politique.
• [ ] Procédure de rollback testée pour les modifications de ressources.

Exemple de définition ResourceQuota :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-equipe
  namespace: equipe-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

Appliquez avec :

kubectl apply -f resource-quota.yaml

Exemple LimitRange :

apiVersion: v1
kind: LimitRange
metadata:
  name: limites-par-defaut
  namespace: equipe-a
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

Appliquez avec :

kubectl apply -f limit-range.yaml

Conclusion

Les requêtes et limites de ressources Kubernetes sont des contrôles puissants qui, lorsqu'ils sont utilisés correctement, assurent une planification efficace et préviennent les conflits de ressources. Des concepts avancés comme les classes QoS, les ResourceQuotas et les LimitRanges permettent une gouvernance fine.

Vérifiez toujours l'état actuel avant d'apporter des modifications, appliquez les modifications progressivement avec des plans de rollback et surveillez la limitation et les OOM kills. En suivant les étapes pratiques et les listes de contrôle de cet article, vous pouvez exploiter votre cluster en toute confiance et éviter les défaillances courantes liées aux ressources.

Comme prochaine étape, auditez l'un de vos déploiements pour les requêtes et limites manquantes, appliquez des valeurs appropriées en utilisant un essai à blanc, puis observez le comportement de planification et d'exécution du pod.