Surveillance et alertes des déploiements Kubernetes : guide pratique d'exploitation

Introduction

La surveillance et les alertes des Deployments Kubernetes sont essentielles pour maintenir la santé des applications, mais de nombreuses équipes se contentent de vérifier que les Pods tournent. Un Deployment peut sembler sain alors qu'il déploie du code défectueux, épuise le CPU ou échoue silencieusement ses sondes de readiness. Ce guide vous propose une approche pratique, axée sur les commandes, pour surveiller les Deployments, configurer des alertes pertinentes et récupérer rapidement en cas de problème.

Nous allons suivre un exemple réaliste : le Deployment web exécutant l'image nginx:1.25, mis à l'échelle sur trois réplicas. Vous apprendrez à inspecter son état actuel, à effectuer des changements en toute sécurité, à vérifier les rollouts, à diagnostiquer les échecs et à construire une pile de surveillance avec kubectl, metrics-server et Prometheus. Chaque commande inclut la sortie attendue et la marche à suivre si le résultat diffère.

À la fin, vous disposerez d'une liste de contrôle opérationnelle adaptable à votre propre cluster, ainsi que des pièges courants et des schémas de reprise qui font gagner des heures lors d'un incident.

1. Inventaire des versions et de l'environnement

Avant de pouvoir surveiller un Deployment, vous devez savoir ce qui tourne et si vos outils le prennent en charge. Cette étape consiste uniquement en une observation en lecture seule. Aucun changement pour l'instant.

Vérifiez la version de votre cluster

kubectl version --short

Sortie attendue :

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

Pourquoi c'est important : les fonctionnalités des Deployments comme maxSurge et maxUnavailable varient selon les versions. Si votre client est plus ancien que le serveur, certains indicateurs peuvent être indisponibles. Pour ce guide, nous supposons Kubernetes 1.25 ou ultérieur.

Vérifiez l'API des métriques

La surveillance des Deployments nécessite des métriques. Vérifiez si metrics-server est installé :

kubectl get apiservices | grep metrics

Sortie attendue :

v1beta1.metrics.k8s.io                 kube-system/metrics-server   True        24h

Si le statut n'est pas True, installez metrics-server avant de continuer. Sans lui, kubectl top retournera error: Metrics API not available.

Inspectez le Deployment

Listez vos Deployments dans le namespace cible :

kubectl get deployments -n production

Sortie attendue :

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    3/3     3            3           5d

Examinez maintenant la spécification complète :

kubectl get deployment web -n production -o yaml

Champs clés à noter :

• spec.replicas (nombre désiré actuel)
• spec.strategy.type (RollingUpdate ou Recreate)
• spec.template.spec.containers[].image (image et tag)
• spec.template.spec.containers[].resources (limites et requêtes)
• spec.template.spec.containers[].readinessProbe et livenessProbe

Créez un fichier d'inventaire local avec des horodatages. Exemple :

# Inventaire du Deployment 2025-04-12 10:00 UTC
Deployment : web
Namespace : production
Réplicas : 3
Stratégie : RollingUpdate (maxSurge 25%, maxUnavailable 25%)
Image : nginx:1.25
Requête/limite CPU : 100m / 500m
Requête/limite mémoire : 128Mi / 256Mi
Sonde de readiness : HTTP GET / sur le port 80, initialDelay 5s, period 10s
Sonde de liveness : HTTP GET /healthz sur le port 80, initialDelay 15s, period 20s

Notez l'horodatage. Cet inventaire devient votre référence pour comparer après tout changement.

2. Chemin de configuration sécurisé

Maintenant que vous connaissez l'état actuel, vous pouvez effectuer un changement ciblé en toute sécurité. Le principe : changez une chose à la fois, avec un plan de retour en arrière.

Avant de changer : capturez un point de retour en arrière

Enregistrez le manifeste actuel du Deployment :

kubectl get deployment web -n production -o yaml > web-deployment-backup.yaml

Si quelque chose tourne mal, restaurez avec :

kubectl apply -f web-deployment-backup.yaml

Exemple de changement : mettre à jour l'image du conteneur

Supposons que vous deviez passer à nginx:1.26. Utilisez la commande impérative pour un changement unique :

kubectl set image deployment/web nginx=nginx:1.26 -n production

Sortie attendue :

deployment.apps/web image updated

Vous pouvez aussi modifier directement le manifeste :

kubectl edit deployment web -n production

Changez uniquement le tag de l'image, enregistrez et quittez. Le contrôleur de Deployment démarrera une mise à jour progressive.

Vérifiez le rollout avant de supposer le succès

kubectl rollout status deployment/web -n production

Sortie attendue pendant le déploiement :

Waiting for deployment "web" rollout to finish: 1 out of 3 new replicas have been updated...

En cas de succès :

deployment "web" successfully rolled out

Si le rollout se bloque, inspectez immédiatement les nouveaux Pods. N'appliquez pas un autre changement tant que vous n'avez pas compris pourquoi (voir Modes de défaillance).

Gardez les tests locaux petits

Avant d'exposer le Deployment via un LoadBalancer ou un Ingress, vérifiez-le localement :

kubectl port-forward deployment/web 8080:80 -n production

Ouvrez ensuite http://localhost:8080 dans un navigateur ou utilisez curl.

Résultat attendu : HTTP 200 et la page d'accueil nginx. Si vous obtenez une connexion refusée, le Pod n'écoute peut-être pas sur le port 80, ou le sélecteur du Service est incorrect.

3. Vérification et diagnostics

Après un changement, vous devez confirmer que le Deployment est sain sous plusieurs angles : Pods, ReplicaSets, utilisation des ressources et événements.

Vérifiez le statut et la répartition des Pods

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

Sortie attendue :

NAME                   READY   STATUS    RESTARTS   AGE   IP           NODE
web-7d9f8c5b6-abcde   1/1     Running   0          2m    10.0.1.12    node-1
web-7d9f8c5b6-fghij   1/1     Running   0          2m    10.0.2.34    node-2
web-7d9f8c5b6-klmno   1/1     Running   0          2m    10.0.3.56    node-3

Vérifiez que les Pods sont répartis sur les nœuds si vous avez des règles d'anti-affinité. Si tous les Pods sont sur un seul nœud, une panne de nœud supprimera tous les réplicas.

Décrivez un Pod pour les événements et les sondes

Choisissez un Pod :

kubectl describe pod web-7d9f8c5b6-abcde -n production

Recherchez :

• La section Events: pour les erreurs de tirage d'image, les échecs de sonde ou les problèmes d'ordonnancement
• Les Conditions: pour le statut Ready
• Les résultats des sondes de readiness et de liveness dans Containers:

Exemple d'événement indiquant un échec de sonde de readiness :

Warning  Unhealthy  45s (x3 over 75s)  kubelet  Readiness probe failed: HTTP probe failed with statuscode: 503

Cela signifie que l'application à l'intérieur du conteneur n'est pas prête à servir le trafic, même si le conteneur tourne.

Vérifiez les journaux

Pour un Pod en cours d'exécution :

kubectl logs web-7d9f8c5b6-abcde -n production

Pour un conteneur planté ou redémarré, examinez l'instance précédente :

kubectl logs web-7d9f8c5b6-abcde -n production --previous

Vérifiez l'utilisation actuelle des ressources

kubectl top pods -n production -l app=web

Sortie attendue (exemple) :

NAME                   CPU(cores)   MEMORY(bytes)
web-7d9f8c5b6-abcde   45m          120Mi
web-7d9f8c5b6-fghij   52m          118Mi
web-7d9f8c5b6-klmno   48m          122Mi

Comparez avec les requêtes/limites. Si l'utilisation du CPU est proche de la limite, le Pod peut être limité, provoquant de la latence. Si l'utilisation mémoire est proche de la limite, le Pod risque d'être tué par OOM bientôt.

Vérifiez l'historique des ReplicaSets

kubectl get replicasets -n production -l app=web

Sortie attendue :

NAME              DESIRED   CURRENT   READY   AGE
web-7d9f8c5b6     3         3         3       2m
web-6c8b7d9f4e     0         0         0       5d

L'ancien ReplicaSet avec 0 réplique est conservé pour le retour en arrière. Vous pouvez y revenir avec kubectl rollout undo deployment/web.

4. Modes de défaillance et reprise

Les Deployments échouent de manière prévisible. Voici les modes de défaillance les plus courants, comment les diagnostiquer et comment récupérer.

4.1 CrashLoopBackOff

Symptôme : le statut du Pod affiche CrashLoopBackOff.

Diagnostic :

kubectl get pods -n production -l app=web
kubectl logs <pod-name> -n production --previous
kubectl describe pod <pod-name> -n production

Les journaux montrent généralement l'erreur de l'application (par exemple, configuration manquante, mauvaise URL de base de données). La sortie de describe affichera le code de sortie et les événements.

Reprise : corrigez la cause sous-jacente (configuration, image, commande). Si cela a été causé par un changement récent, revenez en arrière :

kubectl rollout undo deployment/web -n production

4.2 ImagePullBackOff

Symptôme : le statut du Pod affiche ImagePullBackOff ou ErrImagePull.

Diagnostic :

kubectl describe pod <pod-name> -n production | grep -A5 Events

Recherchez des messages comme Failed to pull image "nginx:1.26": rpc error: code = NotFound ou unauthorized: authentication required.

Reprise : corrigez le tag de l'image, ou configurez les secrets de tirage d'image si vous utilisez un registre privé :

kubectl create secret docker-registry regcred \
  --docker-server=myregistry.example.com \
  --docker-username=myuser \
  --docker-password=mypassword \
  [email protected] \
  -n production

Ensuite, ajoutez imagePullSecrets à la spécification du Deployment.

4.3 Rollout bloqué

Symptôme : kubectl rollout status se bloque et les nouveaux Pods ne deviennent pas prêts.

Diagnostic :

kubectl get pods -n production -l app=web

Si les nouveaux Pods sont en état Pending, vérifiez les événements d'ordonnancement :

kubectl describe pod <new-pod-name> -n production

Raisons courantes : CPU/mémoire insuffisants sur les nœuds, sélecteurs de nœuds qui ne correspondent à aucun nœud, ou demandes de volume persistant non liées.

Reprise : ajustez les requêtes de ressources, ou réduisez le Deployment pour tenir dans la capacité disponible, ou retirez/ajustez les sélecteurs de nœuds. Si c'est la sonde de readiness qui échoue, le Pod tournera mais ne deviendra pas Ready ; vérifiez la sonde et les journaux de l'application.

4.4 Le Deployment ne se met pas à jour (pas de nouveau ReplicaSet)

Symptôme : après avoir modifié la spécification, aucun nouveau Pod n'est créé.

Diagnostic :

kubectl get deployment web -n production -o yaml

Vérifiez si le changement a réellement été appliqué. Parfois, kubectl apply échoue silencieusement ou vous avez modifié le mauvais objet.

Vérifiez également si le Deployment est en pause :

kubectl get deployment web -n production -o jsonpath='{.spec.paused}'`

Si la sortie est true, reprenez :

kubectl rollout resume deployment/web -n production

4.5 Zéro réplique après une mise à l'échelle vers zéro

Symptôme : vous avez mis à l'échelle à zéro, mais maintenant le Deployment affiche 0/0 et vous ne pouvez pas accéder à l'application.

Diagnostic :

kubectl get deployment web -n production

Attendu : READY 0/0.

Reprise : remettez à l'échelle :

kubectl scale deployment web --replicas=3 -n production

Surveillez ensuite le statut du rollout.

5. Surveillance et alertes

Les vérifications manuelles ne suffisent pas. Vous avez besoin d'une surveillance continue et d'alertes qui se déclenchent avant que les utilisateurs ne s'en aperçoivent. Cette section vous propose une configuration minimale basée sur Prometheus avec des exemples d'alertes pour les Deployments.

5.1 Métriques à collecter

Prometheus avec kube-state-metrics expose des métriques au niveau du Deployment. Installez kube-state-metrics et configurez Prometheus pour le scraper. Métriques clés :

• kube_deployment_spec_replicas : nombre désiré de répliques
• kube_deployment_status_replicas_available : répliques actuellement disponibles
• kube_deployment_status_replicas_unavailable : répliques actuellement indisponibles
• kube_deployment_status_condition : conditions du Deployment (Available, Progressing, ReplicaFailure)
• kube_deployment_metadata_generation : génération de la spécification du Deployment
• kube_deployment_status_observed_generation : génération observée par le contrôleur

5.2 Exemples de règles d'alerte

Créez un fichier de règles d'alerte Prometheus deployment-alerts.yaml :

groups:
- name: deployment
  rules:
  - alert: DeploymentReplicasMismatch
    expr: |
      kube_deployment_spec_replicas{namespace="production"}
      !=
      kube_deployment_status_replicas_available{namespace="production"}
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Le Deployment {{ $labels.deployment }} a un nombre de répliques incohérent"
      description: "Répliques désirées : {{ $value }} disponibles, attendu {{ $labels.kube_deployment_spec_replicas }}. Vérifiez le statut du rollout."

  - alert: DeploymentNotProgressing
    expr: |
      kube_deployment_status_condition{namespace="production", condition="Progressing", status="false"} == 1
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Le Deployment {{ $labels.deployment }} ne progresse pas"
      description: "Le Deployment {{ $labels.deployment }} échoue à progresser depuis 10 minutes. Vérifiez les événements et les journaux des Pods."

  - alert: DeploymentReplicaFailure
    expr: |
      kube_deployment_status_condition{namespace="production", condition="ReplicaFailure", status="true"} == 1
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Le Deployment {{ $labels.deployment }} a une défaillance de réplique"
      description: "Le Deployment {{ $labels.deployment }} ne peut pas créer ou maintenir des répliques. Vérifiez les quotas de ressources, la capacité des nœuds et les erreurs de tirage d'image."

Appliquez à Prometheus et rechargez. Testez en mettant intentionnellement à l'échelle au-delà de la capacité ou en changeant l'image vers un tag invalide. Vous devriez voir l'alerte se déclencher dans la durée for.

5.3 Exemple de tableau de bord (Grafana)

Créez un tableau de bord Grafana simple avec ces panneaux :

1. Répliques du Deployment (Désirées vs Disponibles) : Requête kube_deployment_spec_replicas et kube_deployment_status_replicas_available pour le Deployment sélectionné, visualisées en deux séries.
2. Statut du rollout du Deployment : Utilisez kube_deployment_status_condition{condition="Progressing"} pour afficher 1 ou 0 dans un panneau de statistique avec seuils vert/rouge.
3. Redémarrages des Pods : Requête rate(kube_pod_container_status_restarts_total{namespace="production"}[5m]) et alertez si > 0,2.
4. Utilisation CPU et mémoire : Depuis metrics-server ou node exporter, affichez par Pod et la somme par Deployment avec lignes de limite.

5.4 Runbook de réponse aux incidents pour les alertes de Deployment

Lorsqu'une alerte de Deployment se déclenche, suivez cet ordre :

1. Accusez réception et notez l'heure, le nom de l'alerte et le Deployment affecté.
2. Vérifiez le statut du rollout : kubectl rollout status deployment/<name> -n <namespace>.
3. Vérifiez les Pods : kubectl get pods -n <namespace> -l app=<label> et recherchez CrashLoopBackOff, ImagePullBackOff, Pending.
4. Vérifiez les événements : kubectl describe deployment <name> -n <namespace> et lisez les 10 derniers événements.
5. Vérifiez les métriques : kubectl top pods et comparez avec les limites.
6. Si un changement récent est en cause, revenez en arrière : kubectl rollout undo deployment/<name> -n <namespace>.
7. Si c'est un problème de capacité, réduisez ou ajoutez des nœuds.
8. Après la récupération, documentez la cause racine et définissez un rappel pour revoir dans 24 heures.

Attribuez un propriétaire unique : l'ingénieur d'astreinte qui répond à l'appel est responsable de l'incident jusqu'à sa résolution et doit rédiger le post-mortem dans les 48 heures.

6. Pièges courants et comment les éviter

Voici les erreurs que les équipes commettent fréquemment lors de la surveillance des Deployments, avec des conseils de prévention et de récupération.

Piège 1 : Surveiller uniquement les Pods, pas les Deployments

Pourquoi cela arrive : les Pods sont l'unité visible ; les équipes supposent que si les Pods tournent, le Deployment est sain. Comment éviter : surveillez les conditions du Deployment (Available, Progressing, ReplicaFailure) et alertez sur celles-ci, pas seulement sur le statut des Pods. Un Deployment peut avoir des Pods en cours d'exécution mais échouer à progresser (par exemple, rollout bloqué, ancien ReplicaSet toujours en service). Reprise : utilisez l'alerte DeploymentNotProgressing ci-dessus et vérifiez immédiatement kubectl rollout status.

Piège 2 : Ignorer les échecs de sonde de readiness pendant le rollout

Pourquoi cela arrive : les équipes ne configurent souvent que des sondes de liveness, ou configurent les sondes de readiness trop souplement. Le contrôleur de Deployment considère alors les nouveaux Pods comme prêts même s'ils ne peuvent pas servir le trafic, entraînant des pannes partielles. Comment éviter : définissez des sondes de readiness appropriées et utilisez kubectl rollout status pour bloquer le CI/CD jusqu'à ce que le rollout réussisse. Utilisez minReadySeconds pour laisser le temps aux sondes de se stabiliser. Reprise : si un rollout est en cours et que les Pods ne sont pas prêts, examinez le point de terminaison de readiness. Revenez en arrière si nécessaire.

Piège 3 : Ne pas avoir de plan de retour en arrière

Pourquoi cela arrive : les équipes appliquent les changements directement et espèrent que tout se passera bien. Comment éviter : enregistrez toujours le manifeste précédent (kubectl get deployment <name> -o yaml > backup.yaml) avant de changer. Utilisez le contrôle de version pour les manifestes. Reprise : si le changement échoue, kubectl rollout undo deployment/<name> ou kubectl apply -f backup.yaml.

Piège 4 : Fatigue des alertes avec trop d'alertes bruyantes

Pourquoi cela arrive : les équipes créent des alertes pour chaque fluctuation mineure des métriques. Comment éviter : utilisez des clauses for (par exemple, 5 minutes) pour éviter les alertes transitoires. Définissez des seuils significatifs basés sur des références historiques. Routez les alertes vers les canaux appropriés (avertissement vs critique). Reprise : ajustez régulièrement les règles d'alerte ; chaque alerte doit avoir une action claire. Si aucune action n'est nécessaire, supprimez l'alerte.

Piège 5 : Surveiller sans metrics-server ni Prometheus

Pourquoi cela arrive : certains clusters n'ont pas metrics-server installé, ou les équipes se fient à kubectl top manuel. Comment éviter : assurez-vous que metrics-server est installé et fonctionnel. Pour la production, configurez Prometheus et kube-state-metrics pour des alertes historiques et basées sur les conditions. Reprise : si l'API des métriques est absente, installez metrics-server ; si les alertes sont absentes, installez kube-state-metrics et configurez les règles.

7. Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour chaque changement ou incident de Deployment. Attribuez un propriétaire responsable unique pour chaque étape majeure (exemple : Priya Shah, responsable de l'ingénierie).

Liste de contrôle avant changement

• [ ] Enregistrez la spécification actuelle du Deployment et l'horodatage (Propriétaire : Priya Shah)
• [ ] Enregistrez le manifeste de sauvegarde : kubectl get deployment <name> -n <ns> -o yaml > backup.yaml (Propriétaire : ingénieur d'astreinte)
• [ ] Vérifiez que metrics-server est disponible : kubectl get apiservices | grep metrics (Propriétaire : Priya Shah)
• [ ] Identifiez un changement unique et son effet attendu (Propriétaire : demandeur du changement)
• [ ] Définissez les critères de retour en arrière (par exemple, si le rollout n'est pas terminé en 10 minutes, revenez en arrière) (Propriétaire : Priya Shah)

Vérification après changement

• [ ] Exécutez kubectl rollout status deployment/<name> -n <ns> et confirmez le succès (Propriétaire : ingénieur d'astreinte)
• [ ] Vérifiez les Pods : kubectl get pods -n <ns> -l app=<label> tous Running et Ready (Propriétaire : ingénieur d'astreinte)
• [ ] Vérifiez les journaux pour les erreurs (Propriétaire : développeur)
• [ ] Vérifiez kubectl top pods pour l'utilisation des ressources dans les limites (Propriétaire : ingénieur d'astreinte)
• [ ] Vérifiez le trafic via port-forward local ou point de terminaison du Service (Propriétaire : ingénieur QA)
• [ ] Confirmez que les alertes ne se déclenchent pas (Propriétaire : administrateur de surveillance)

Liste de contrôle de reprise d'incident

• [ ] Accusez réception de l'alerte et notez l'heure (Propriétaire : ingénieur d'astreinte)
• [ ] Vérifiez le statut du rollout et les événements récents (Propriétaire : ingénieur d'astreinte)
• [ ] Déterminez si un changement récent a causé l'incident (Propriétaire : ingénieur d'astreinte)
• [ ] Revenez en arrière si nécessaire : kubectl rollout undo deployment/<name> -n <ns> (Propriétaire : ingénieur d'astreinte)
• [ ] Réduisez ou ajoutez de la capacité si lié aux ressources (Propriétaire : ingénieur d'astreinte)
• [ ] Documentez la cause racine et le post-mortem dans les 48 heures (Propriétaire : commandant d'incident)
• [ ] Planifiez la revue de l'incident et des seuils d'alerte lors de la prochaine réunion hebdomadaire des opérations (Propriétaire : Priya Shah)

Fréquence de revue : la liste de contrôle et les seuils d'alerte doivent être revus mensuellement, ou après tout incident majeur.

Conclusion

La surveillance des Deployments Kubernetes ne se résume pas à kubectl get pods. Elle exige une approche systématique : connaître votre version et votre environnement, modifier les configurations en toute sécurité, vérifier les rollouts avec les bonnes commandes, anticiper les défaillances courantes et mettre en place des alertes automatisées qui vous avertissent quand quelque chose ne va pas.

Les exemples pratiques de ce guide — manifestes de sauvegarde, vérifications du statut du rollout, règles d'alerte Prometheus et liste de contrôle détaillée — vous donnent une base solide. Commencez par implémenter les trois alertes de base (ReplicasMismatch, NotProgressing, ReplicaFailure) et la liste de contrôle opérationnelle. Testez vos alertes en cassant intentionnellement un Deployment dans un environnement de préproduction. Entraînez-vous ensuite aux retours en arrière. Lorsqu'un incident surviendra, vous aurez la mémoire musculaire pour répondre rapidement et en toute sécurité.

N'oubliez pas : l'objectif n'est pas seulement de détecter les problèmes, mais de rendre la récupération rapide et prévisible. Gardez votre surveillance axée sur des signaux actionnables, attribuez des responsabilités claires et revoyez régulièrement votre approche.