Surveillance et alertes du cycle de vie des pods Kubernetes : guide pratique de mise en œuvre

Introduction

La surveillance du cycle de vie des pods Kubernetes avec des exemples pratiques aide les opérateurs à passer d’un problème observé à un résultat vérifié. Le cycle de vie d’un pod est la séquence d’états par lesquels un pod passe de la création à la terminaison : Pending, Running, Succeeded, Failed et CrashLoopBackOff. Surveiller ces états et alerter sur les transitions inattendues est essentiel pour la fiabilité des services.

Cet article fournit un guide pratique, axé sur les commandes, destiné aux développeurs, consultants DevOps et équipes techniques de startups. Il explique comment :

Inspecter les états du cycle de vie des pods et les événements avec kubectl
Collecter les métriques des pods avec kube-state-metrics et les interroger dans Prometheus
Construire des alertes qui se déclenchent lorsque des pods échouent, plantent ou restent en attente
Diagnostiquer les modes de défaillance courants et récupérer en toute sécurité
Créer une liste de contrôle opérationnelle réutilisable pour la réponse aux incidents

Chaque commande inclut la sortie attendue et un signal à vérifier. L’objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des variables plutôt que des secrets, vérifier le résultat et documenter la récupération.

Inventaire des versions et de l’environnement

Avant de surveiller les cycles de vie des pods, faites l’inventaire de votre environnement. Indiquez le composant concerné, la plage de versions prise en charge, les prérequis et les commandes en lecture seule qui vérifient l’état actuel.

Exemple d’inventaire de base :

Cluster Kubernetes : v1.28
Client kubectl : v1.28 (correspond à la version mineure du serveur)
kube-state-metrics : v2.10
Prometheus : v2.50
Alertmanager : v0.26
Namespace de surveillance : monitoring

Commencez par une observation en lecture seule. Capturez les pods actuels dans tous les namespaces :

kubectl get pods -A -o wide

La sortie attendue montre le nom du pod, le namespace, le statut, les redémarrages, l’âge, l’IP et le nœud.

Pour inspecter les événements de planification et de cycle de vie d’un pod spécifique, utilisez :

kubectl describe pod <nom-du-pod> -n <namespace>

La section Events en bas révèle des avertissements comme FailedScheduling, Failed to pull image ou Back-off restarting failed container. C’est le premier endroit à regarder en cas d’échec.

Compatibilité des versions : kube-state-metrics v2.x nécessite Kubernetes v1.24 ou ultérieur. Prometheus v2.50 prend en charge toutes les versions actuelles de Kubernetes. Faites toujours correspondre kubectl à la version mineure de votre cluster pour éviter les incompatibilités d’API.

Règle du rayon d’impact : Avant d’appliquer toute modification, enregistrez le nombre actuel de pods et les redémarrages. Utilisez kubectl get pods -A --no-headers | wc -l et kubectl get pods -A -o jsonpath='{.items[].status.containerStatuses[].restartCount}'. Conservez ces valeurs pour les comparer après les modifications.

Chemin de configuration sûr

La surveillance des cycles de vie des pods nécessite souvent le déploiement ou la configuration de kube-state-metrics, Prometheus et des règles d’alerte. Suivez un chemin de configuration sûr : appliquez un manifeste, inspectez les ressources générées et vérifiez avant de passer en production.

Étape 1 : Déployer kube-state-metrics

Utilisez le manifeste officiel, épinglé à une version :

kubectl apply -f https://github.com/kubernetes/kube-state-metrics/releases/download/v2.10.0/standard.yaml

La sortie attendue confirme le déploiement, le compte de service et le ClusterRole.

Vérifiez que les pods sont en cours d’exécution :

kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics

Attendu : un pod avec le statut Running et zéro redémarrage.

Étape 2 : Exposer les métriques

Créez un ServiceMonitor si vous utilisez Prometheus Operator, ou ajoutez une configuration de scrape à votre ConfigMap Prometheus.

Exemple de snippet ServiceMonitor :

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-state-metrics
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-state-metrics
  endpoints:
  - port: http-metrics
    interval: 30s

Appliquez et vérifiez que Prometheus découvre la cible :

kubectl apply -f servicemonitor.yaml
kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090

Ouvrez http://localhost:9090/targets dans un navigateur et confirmez que la cible kube-state-metrics est opérationnelle.

Étape 3 : Configurer les règles d’alerte

Créez une PrometheusRule pour les échecs de pods. Exemple de règle pour CrashLoopBackOff :

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pod-lifecycle-alerts
  namespace: monitoring
spec:
  groups:
  - name: pod-lifecycle
    rules:
    - alert: PodCrashLooping
      expr: |
        increase(kube_pod_container_status_restarts_total[10m]) > 5
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Le pod {{ $labels.namespace }}/{{ $labels.pod }} est en boucle de crash"
        description: "Le conteneur {{ $labels.container }} a redémarré {{ $value }} fois au cours des 10 dernières minutes."

Appliquez et vérifiez que la règle apparaît dans Prometheus :

kubectl apply -f prometheusrule.yaml
kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090
# Accédez à http://localhost:9090/rules pour voir la règle.

Chemin de retour en arrière : Conservez le manifeste précédent dans le contrôle de version. Si la nouvelle règle provoque des faux positifs, supprimez-la avec kubectl delete prometheusrule pod-lifecycle-alerts -n monitoring et restaurez le fichier précédent.

Vérification et diagnostics

Une fois la surveillance configurée, vérifiez son fonctionnement en simulant des défaillances et en observant les métriques et les alertes.

Vérifier manuellement le statut des pods

Utilisez kubectl get pods pour voir les états du cycle de vie. Pour observer les transitions d’état en temps réel :

kubectl get pods -n default --watch

Cela diffuse les changements jusqu’à ce que vous appuyiez sur Ctrl+C.

Inspecter les journaux et l’historique

Pour un conteneur qui redémarre, affichez les journaux actuels et précédents :

kubectl logs <nom-du-pod> -n <namespace> --previous

L’option --previous affiche les journaux du dernier conteneur terminé, qui contiennent souvent l’erreur à l’origine du crash.

Vérifiez l’état d’un déploiement :

kubectl rollout status deployment/<nom-du-déploiement> -n <namespace>

Sortie attendue : deployment "<nom>" successfully rolled out. Si le déploiement est bloqué, la commande se termine avec une erreur et vous devez inspecter les événements.

Interroger les métriques Prometheus

kube-state-metrics expose les métriques du cycle de vie des pods. Requêtes courantes :

Total des pods par phase :

  sum by (phase) (kube_pod_status_phase)

Pods en état Pending depuis plus de 5 minutes :

  sum(kube_pod_status_phase{phase="Pending"}) by (namespace, pod)

Redémarrages de pods au cours de la dernière heure :

  increase(kube_pod_container_status_restarts_total[1h])

Pods non prêts :

  kube_pod_status_ready{condition="false"}

Exécutez ces requêtes dans l’interface Prometheus (http://localhost:9090/graph après le port-forward) et vérifiez que les valeurs correspondent à kubectl get pods.

Déclencher une alerte de test

Déployez un pod qui se termine immédiatement pour observer un CrashLoopBackOff :

apiVersion: v1
kind: Pod
metadata:
  name: crash-loop-test
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "exit 1"]

Après quelques minutes, l’alerte PodCrashLooping devrait se déclencher. Vérifiez avec :

kubectl get pods crash-loop-test
# La sortie montre RESTARTS en augmentation et STATUS CrashLoopBackOff

Ensuite, dans la page Alertes de Prometheus (http://localhost:9090/alerts), vous devriez voir l’alerte à l’état Pending ou Firing.

Nettoyez le pod de test pour éviter le bruit :

kubectl delete pod crash-loop-test

Modes de défaillance et récupération

Les pods peuvent échouer pour de nombreuses raisons. Reconnaître les schémas accélère la récupération. Le tableau ci-dessous répertorie les modes de défaillance courants, leurs symptômes typiques, les commandes de diagnostic et les actions de récupération.

Mode de défaillance	Symptôme	Commande de diagnostic	Action de récupération
Erreur de tirage d’image	Statut `ErrImagePull` ou `ImagePullBackOff`	`kubectl describe pod <nom>` montre `Failed to pull image`	Corrigez le nom/la balise de l’image ou le secret d’extraction, puis supprimez le pod pour le recréer
CrashLoopBackOff	Le conteneur démarre puis se termine, les redémarrages augmentent	`kubectl logs <nom> --previous`	Examinez l’erreur dans les journaux, corrigez la configuration ou le code de l’application, revenez en arrière sur le déploiement
Pending (non planifiable)	Pod bloqué en Pending	`kubectl describe pod <nom>` montre `FailedScheduling` en raison de ressources insuffisantes ou d’un sélecteur de nœud	Mettez à l’échelle les nœuds, ajustez les demandes de ressources ou corrigez l’affinité de nœud
OOMKilled	Conteneur terminé avec la raison OOMKilled	`kubectl describe pod <nom>` montre `OOMKilled` dans le dernier état	Augmentez la limite de mémoire ou réduisez l’utilisation de la mémoire de l’application, puis redémarrez le pod
Échec de la sonde de vivacité	Le pod redémarre à plusieurs reprises mais les journaux du conteneur ne montrent aucune erreur d’application	`kubectl describe pod <nom>` montre `Liveness probe failed`	Ajustez le timing de la sonde ou corrigez le point de terminaison de santé de l’application
Échec de la sonde de préparation	Pod Running mais pas Ready, le service ne route pas le trafic	`kubectl get pods` montre `0/1 Running`, `kubectl describe pod` montre `Readiness probe failed`	Corrigez le point de terminaison de préparation ou retardez la sonde, assurez-vous que les dépendances sont prêtes
Défaillance du nœud	Les pods sur un nœud passent à Terminating ou Unknown	`kubectl get nodes` montre NotReady	Drainez ou isolez le nœud, les pods se replanifient automatiquement s’ils font partie d’un contrôleur

Procédure de récupération pour CrashLoopBackOff :

Obtenez les détails du pod : kubectl describe pod <nom-du-pod> -n <namespace>
Vérifiez la raison de la dernière terminaison : cherchez Error ou OOMKilled
Affichez les journaux précédents : kubectl logs <nom-du-pod> -n <namespace> --previous
Si cela est dû à un déploiement récent, revenez en arrière : kubectl rollout undo deployment/<nom-du-déploiement>
Si c’est un problème de ressources, modifiez les limites de ressources et appliquez : kubectl apply -f updated-deployment.yaml
Vérifiez que le pod est Running et que les redémarrages n’augmentent pas : kubectl get pods -n <namespace> --watch

Mesures préventives :

Définissez des limites de mémoire et de CPU pour tous les conteneurs afin d’éviter les OOMKills
Configurez des sondes de vivacité et de préparation adaptées au temps de démarrage de votre application
Utilisez spec.template.metadata.labels et des budgets de perturbation de pods pour une éviction gracieuse
Surveillez kube_pod_status_phase et kube_pod_container_status_restarts_total avec des tableaux de bord

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle lors de la réponse aux incidents ou de la maintenance de routine pour vérifier systématiquement la santé du cycle de vie des pods.

Avant l’incident (routine) :

[ ] Versions du cluster et de la pile de surveillance enregistrées (par exemple, K8s v1.28, kube-state-metrics v2.10)
[ ] Pods kube-state-metrics sains : kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics
[ ] Cibles Prometheus opérationnelles : port-forward et vérification de /targets
[ ] Règles d’alerte chargées : vérification de /rules
[ ] Nombre de pods de référence et métriques de redémarrage stockés

Pendant l’incident :

[ ] Identifier le namespace et le pod affectés : kubectl get pods -A --field-selector=status.phase=Failed ou =Pending
[ ] Vérifier les événements du pod : kubectl describe pod <nom> -n <ns> | tail -20
[ ] Vérifier les journaux du conteneur : kubectl logs <nom> -n <ns> --previous
[ ] Vérifier l’utilisation des ressources : kubectl top pod <nom> -n <ns> (nécessite metrics-server)
[ ] Interroger la métrique Prometheus pertinente (par exemple, increase(kube_pod_container_status_restarts_total[10m]))
[ ] Déterminer si un changement récent a causé l’échec (déploiement, ConfigMap, Secret)
[ ] Si oui, revenir en arrière : kubectl rollout undo deployment/<nom> -n <ns>
[ ] Si non, procéder à la récupération spécifique du tableau des modes de défaillance
[ ] Vérifier la récupération : kubectl get pods -n <ns> --watch jusqu’à stabilisation

Après l’incident :

[ ] Documenter la cause racine et la chronologie
[ ] Ajuster les alertes si elles ont été manquées ou déclenchées à tort
[ ] Mettre à jour les procédures avec de nouvelles étapes de diagnostic
[ ] Revoir les limites de ressources et les sondes
[ ] Supprimer tous les pods de test utilisés

Exemple d’entrée de procédure pour OOMKilled :

Symptôme : le pod redémarre avec OOMKilled dans kubectl describe pod.
Confirmer : kubectl get pod <nom> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}' renvoie OOMKilled.
Vérifier les limites actuelles : kubectl get pod <nom> -o jsonpath='{.spec.containers[0].resources}'
Augmenter la limite de mémoire de 25 % dans le manifeste de déploiement, appliquer.
Surveiller la stabilité des redémarrages : kubectl get pods --watch.

Conclusion

La surveillance et les alertes du cycle de vie des pods Kubernetes ne sont efficaces que si chaque recommandation est limitée à une version, observable et réversible. Copier une commande sans vérifier les prérequis et la sortie attendue n’est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque dans cet article : déployez kube-state-metrics, créez une règle d’alerte simple ou simulez un pod de test CrashLoopBackOff. Enregistrez l’état actuel, exécutez la vérification documentée et comparez le résultat avec le signal attendu. Passez en revue les dépendances telles que Pod, Node et Event.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu’un incident ne force la décision.