Kubernetes : guide pratique pour surveiller et alerter sur les requêtes et limites de ressources

Introduction

Les requêtes et limites de ressources Kubernetes sont fondamentales pour la stabilité du cluster, l'ordonnancement et la maîtrise des coûts. Les requêtes garantissent une quantité minimale de CPU et de mémoire pour un conteneur, tandis que les limites plafonnent son utilisation maximale. Des requêtes et limites mal configurées entraînent des évictions de pods, une pression sur les nœuds, des performances imprévisibles et une capacité gaspillée. Surveiller ces paramètres et alerter en cas d'écart est essentiel pour toute équipe exécutant des charges de travail en production.

Ce guide propose une approche pratique, axée sur les opérations, pour la surveillance et l'alerte sur les requêtes et limites de ressources Kubernetes. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui ont besoin de mesures concrètes, pas seulement de théorie. Nous couvrons l'inventaire des versions et de l'environnement, les chemins de configuration sûrs, la vérification et le diagnostic, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, les sorties attendues, les signaux de défaillance et les décisions de récupération.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les procédures de récupération avant qu'un incident ne vous force la main.

Inventaire des versions et de l'environnement

Avant de surveiller ou d'alerter sur les requêtes et limites de ressources, établissez un inventaire clair de votre environnement. Cela inclut la version de Kubernetes, la topologie de déploiement et les composants que vous inspectez. Connaître votre version est essentiel car les API et les noms de métriques peuvent différer entre les versions.

Identifier la version et la topologie de Kubernetes

Exécutez les commandes en lecture seule suivantes pour capturer l'état actuel :

kubectl version --short
kubectl get nodes -o wide
kubectl get pods -A -o wide

Sortie attendue pour kubectl version --short (exemple) :

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.6

La version du serveur est celle qui compte pour la compatibilité. La sortie de kubectl get nodes montre les noms des nœuds, leur statut, leurs rôles, leur âge, leur version et leur capacité en ressources. Par exemple :

NAME           STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
node-1         Ready    control-plane   21d   v1.27.6   10.0.0.11     <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.6.28
node-2         Ready    <none>          21d   v1.27.6   10.0.0.12     <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.6.28

Enregistrez ces sorties dans un fichier texte ou un runbook. Cela établit une base de référence et aide à détecter les changements après des modifications de configuration.

Vérifier les requêtes et limites de ressources existantes

Pour voir les requêtes et limites actuelles de tous les pods dans un namespace, utilisez :

kubectl get pods -n your-namespace -o custom-columns=NAME:.metadata.name,REQUESTS_CPU:.spec.containers[*].resources.requests.cpu,LIMITS_CPU:.spec.containers[*].resources.limits.cpu,REQUESTS_MEM:.spec.containers[*].resources.requests.memory,LIMITS_MEM:.spec.containers[*].resources.limits.memory

Exemple de sortie :

NAME          REQUESTS_CPU   LIMITS_CPU   REQUESTS_MEM   LIMITS_MEM
web-app       100m           200m         128Mi          256Mi
db            500m           1            512Mi          1Gi

Si un conteneur n'a pas de requêtes ou de limites, c'est un signal d'intervention.

Prérequis pour la surveillance

Assurez-vous de disposer des outils et autorisations suivants :

• Cluster Kubernetes version 1.19 ou ultérieure (pour des API de métriques stables).
• kubectl configuré avec les autorisations RBAC appropriées pour lister les pods, les nœuds et les métriques.
• Metrics Server installé (si vous prévoyez d'utiliser kubectl top).
• Prometheus (ou un autre système de surveillance) pour les métriques à long terme et les alertes.

Pour vérifier si Metrics Server est en cours d'exécution :

kubectl get deployment metrics-server -n kube-system

Sortie attendue s'il est installé :

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           10d

S'il n'est pas installé, vous pouvez l'installer via les manifestes officiels, mais sachez qu'il peut ne pas convenir à la production sans personnalisation.

Chemin de configuration sûr

Modifier les requêtes et limites de ressources peut perturber les charges de travail en cours d'exécution. Suivez un chemin de configuration sûr qui sépare l'observation de l'intervention et valide les modifications de manière contrôlée.

Observer avant de modifier

Avant de modifier tout manifeste, inspectez le déploiement actuel et la spécification de ses pods.

Exemple : vérifiez le déploiement web-app :

kubectl get deployment web-app -n prod -o yaml

Cherchez la section resources sous chaque conteneur. Si elle est absente, notez-le. Décrivez ensuite les pods en cours d'exécution pour voir l'utilisation actuelle des ressources (si metrics-server est disponible) :

kubectl top pod -n prod -l app=web-app

Exemple de sortie :

NAME                      CPU(cores)   MEMORY(bytes)
web-app-7c9f5b6d-abcde   45m          89Mi
web-app-7c9f5b6d-fghij   32m          78Mi

Cela montre l'utilisation réelle, qui devrait éclairer vos requêtes et limites. Une pratique courante consiste à définir les requêtes égales à l'utilisation moyenne plus une marge (par exemple 20 à 30 %), et les limites en fonction de l'utilisation maximale.

Changement le plus petit justifié

Faites un changement à la fois. Par exemple, ajoutez une limite de mémoire à un conteneur qui n'en a pas. Utilisez kubectl set resources ou modifiez le déploiement :

kubectl set resources deployment web-app -n prod --limits=memory=256Mi --requests=memory=128Mi

Cela ajoute à la fois les requêtes et les limites pour la mémoire. Avant d'appliquer, enregistrez le manifeste actuel :

kubectl get deployment web-app -n prod -o yaml > web-app-backup.yaml

Appliquez le changement, puis vérifiez le déploiement :

kubectl rollout status deployment/web-app -n prod

Sortie attendue :

deployment "web-app" successfully rolled out

Si le déploiement échoue, revenez en arrière en utilisant la sauvegarde :

kubectl apply -f web-app-backup.yaml

Tester dans un environnement de préproduction

Pour des changements importants, testez dans un namespace ou un cluster de préproduction. Utilisez une copie du déploiement de production avec des ressources modifiées. Simulez ensuite la charge et observez les performances.

Exemple : créez un namespace de préproduction staging et appliquez un manifeste de test :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-test
  namespace: staging
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app
        image: nginx:1.25
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "200m"

Après l'application, surveillez avec kubectl top pod et vérifiez les étranglements ou les arrêts OOM.

Vérification et diagnostic

La vérification garantit que les requêtes et limites de ressources sont correctement appliquées et que les charges de travail sont saines. Le diagnostic aide à identifier les problèmes lorsqu'ils ne le sont pas.

Vérifier l'ordonnancement des pods et l'allocation des ressources

Après la mise à jour des ressources, vérifiez que les pods sont planifiés et en cours d'exécution :

kubectl get pods -n prod -l app=web-app -o wide

Exemple de sortie :

NAME                      READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
web-app-7d4f8c9b5-9x2kj   1/1     Running   0          2m    10.244.1.5   node-2   <none>           <none>

Si un pod est en attente, décrivez-le pour voir les événements :

kubectl describe pod <pod-name> -n prod

Recherchez des événements comme :

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  30s   default-scheduler  0/2 nodes are available: 2 Insufficient memory.

Cela indique que vos requêtes sont trop élevées pour les nœuds disponibles. Ajustez en conséquence.

Diagnostiquer les arrêts de conteneurs

Si un conteneur s'arrête en raison d'un OOM (dépassement de mémoire), vérifiez le statut du pod et ses journaux :

kubectl get pods -n prod
kubectl logs <pod-name> -n prod --previous

Extrait de journal d'un arrêt OOM :

container <names> consumed 268435456 bytes of memory, which exceeds the limit of 134217728 bytes

Cela vous indique que la limite de mémoire est trop basse. Augmentez-la après analyse.

Utiliser les métriques pour un diagnostic approfondi

Prometheus est la norme pour collecter les métriques Kubernetes. Les métriques clés liées aux requêtes et limites de ressources comprennent :

• kube_pod_container_resource_requests (avec des étiquettes pour resource et container)
• kube_pod_container_resource_limits
• container_memory_working_set_bytes (de cAdvisor)
• container_cpu_usage_seconds_total
• container_memory_usage_bytes

Exemple de requête PromQL pour trouver les pods sans requêtes mémoire :

sum by (namespace, pod) (kube_pod_container_resource_requests{resource="memory"} == 0)

Cela renvoie une liste de pods sans requêtes mémoire. Vous pouvez de même trouver les pods proches de leurs limites :

sum by (namespace, pod) (container_memory_working_set_bytes) / sum by (namespace, pod) (kube_pod_container_resource_limits{resource="memory"}) > 0.9

Cela montre les pods utilisant plus de 90 % de leur limite mémoire.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à préparer des procédures de récupération automatiques ou manuelles.

Éviction de pods due à la pression sur les nœuds

Lorsqu'un nœud manque de mémoire, le kubelet évince les pods, en commençant par ceux qui dépassent leurs requêtes. Si un pod est évincé, son statut est Failed ou Evicted. Vérifiez avec :

kubectl get pods -n prod --field-selector=status.phase=Failed

Exemple de sortie :

NAME                      READY   STATUS    RESTARTS   AGE
web-app-7d4f8c9b5-9x2kj   0/1     Evicted    0          5m

Pour récupérer, vous pouvez supprimer manuellement le pod évincé (il sera recréé par le contrôleur), mais plus important encore, ajustez les requêtes pour mieux refléter l'utilisation réelle ou ajoutez de la capacité au nœud.

Arrêt OOM d'un conteneur

Comme mentionné, si un conteneur dépasse sa limite de mémoire, il est arrêté par OOM. Le pod redémarre (si la politique de redémarrage le permet). Des arrêts OOM répétés peuvent conduire à un CrashLoopBackOff. Surveillez avec :

kubectl get pods -n prod -l app=web-app

Si RESTARTS est élevé, enquêtez. Récupération : augmentez la limite de mémoire, optimisez l'application, ou les deux.

Épuisement des ressources des nœuds

Les nœuds peuvent devenir insensibles si les processus système manquent de ressources. Surveillez les conditions des nœuds :

kubectl describe node node-2 | grep -A5 Conditions

Recherchez les conditions MemoryPressure ou DiskPressure à True. Si c'est le cas, cordonnez le nœud, drainez-le et enquêtez.

kubectl cordon node-2
kubectl drain node-2 --ignore-daemonsets --delete-emptydir-data

Après résolution, décordonez :

kubectl uncordon node-2

Vérification de la récupération

Après toute action de récupération, vérifiez que le système revient à un état sain. Par exemple, après avoir augmenté une limite de mémoire, surveillez que les redémarrages du pod tombent à zéro et y restent pendant au moins 10 minutes.

Liste de contrôle opérationnelle

Utilisez cette liste pour assurer une surveillance et des alertes continues sur les requêtes et limites de ressources.

Liste de contrôle de la configuration de la surveillance

• [ ] Metrics Server installé et en cours d'exécution dans le namespace kube-system.
• [ ] Prometheus déployé avec une configuration de collecte pour les nœuds Kubernetes, les pods et kube-state-metrics.
• [ ] kube-state-metrics installé pour exposer les métriques kube_pod_container_resource_requests et kube_pod_container_resource_limits.
• [ ] Tableau de bord Grafana (ou équivalent) créé avec des panneaux pour :
• Utilisation CPU des pods par rapport aux requêtes et limites.
• Utilisation mémoire des pods par rapport aux requêtes et limites.
• Pods sans requêtes ni limites (comptage par namespace).
• Nœuds sous pression mémoire ou CPU.
• [ ] Règles d'alerte configurées pour :
• Utilisation mémoire des pods > 90 % de la limite pendant 5 minutes.
• Étranglement CPU des pods > 25 % pendant 10 minutes.
• Pod sans requêtes ni limites.
• Condition de pression mémoire sur les nœuds vraie.

Exemples de règles d'alerte

Voici des exemples de règles d'alerte Prometheus (dans alerting_rules.yml) :

groups:
- name: resource-requests-limits
  rules:
  - alert: PodMemoryNearLimit
    expr: |
      sum by (namespace, pod) (container_memory_working_set_bytes) /
      sum by (namespace, pod) (kube_pod_container_resource_limits{resource="memory"}) > 0.9
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is using more than 90% of its memory limit"

  - alert: PodCPUThrottlingHigh
    expr: |
      sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) /
      sum by (namespace, pod) (rate(container_cpu_usage_seconds_total[5m])) > 0.25
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is being CPU throttled significantly"

  - alert: PodMissingRequestsOrLimits
    expr: |
      (sum by (namespace, pod) (kube_pod_container_resource_requests) == 0) or
      (sum by (namespace, pod) (kube_pod_container_resource_limits) == 0)
    for: 15m
    labels:
      severity: info
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} has containers without requests or limits"

Points saillants du runbook d'incident

Pour chaque alerte, documentez les étapes de runbook suivantes (exemple pour PodMemoryNearLimit) :

1. Identifier le pod affecté : kubectl get pods -n <namespace> -l app=<label>
2. Vérifier l'utilisation actuelle de la mémoire : kubectl top pod <pod-name> -n <namespace>
3. Examiner les journaux récents : kubectl logs <pod-name> -n <namespace> --tail=100
4. Vérifier si des arrêts OOM ont eu lieu : kubectl describe pod <pod-name> -n <namespace> | grep -i oom
5. Déterminer si la limite de mémoire est appropriée ; si ce n'est pas le cas, l'augmenter après approbation via la gestion des changements.
6. Surveiller pendant 30 minutes pour s'assurer qu'il n'y a plus d'alertes.

Cadence de révision régulière

• Hebdomadaire : examiner les tableaux de bord pour tout pod proche des limites ou sans requêtes.
• Mensuel : examiner les règles d'alerte pour ajuster les seuils en fonction des changements de charge de travail.
• Trimestriel : auditer tous les déploiements pour les paramètres de ressources ; utiliser un moteur de politique comme OPA Gatekeeper pour appliquer des valeurs par défaut.

Conclusion

Surveiller les requêtes et limites de ressources Kubernetes n'est pas une tâche ponctuelle mais une discipline continue. En établissant un inventaire conscient des versions, en effectuant des changements incrémentaux en toute sécurité, en vérifiant avec des diagnostics concrets, en se préparant aux modes de défaillance et en adhérant à une liste de contrôle opérationnelle, vous pouvez prévenir les incidents liés aux ressources et maintenir la santé du cluster.

Chaque recommandation de ce guide est conçue pour être limitée à la version, observable et réversible lorsque cela est possible. Ne copiez pas les commandes aveuglément ; comprenez les prérequis, les sorties attendues et les chemins de récupération.

Comme prochaine étape, choisissez une vérification à faible risque : enregistrez les paramètres de ressources actuels pour un seul déploiement, exécutez une commande d'inspection en lecture seule comme kubectl get deployment <name> -o yaml, comparez la sortie à votre base de référence et configurez une simple alerte Prometheus pour les requêtes manquantes. Ensuite, étendez-vous à une couverture de surveillance et d'alerte plus large.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force une décision. Avec ces pratiques, vous pouvez gérer en toute confiance les requêtes et limites de ressources Kubernetes en production.