## 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 : ```bash 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 : ```bash kubectl describe pod -n ``` 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 : ```bash 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 : ```bash 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 : ```yaml 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 : ```bash 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 : ```yaml 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 : ```bash 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 : ```bash 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 : ```bash kubectl logs -n --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 : ```bash kubectl rollout status deployment/ -n ``` Sortie attendue : `deployment "" 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 : ```promql sum by (phase) (kube_pod_status_phase) ``` - Pods en état Pending depuis plus de 5 minutes : ```promql sum(kube_pod_status_phase{phase="Pending"}) by (namespace, pod) ``` - Redémarrages de pods au cours de la dernière heure : ```promql increase(kube_pod_container_status_restarts_total[1h]) ``` - Pods non prêts : ```promql 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 : ```yaml 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 : ```bash 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 : ```bash 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 ` 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 --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 ` 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 ` 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 ` 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 :** 1. Obtenez les détails du pod : `kubectl describe pod -n ` 2. Vérifiez la raison de la dernière terminaison : cherchez `Error` ou `OOMKilled` 3. Affichez les journaux précédents : `kubectl logs -n --previous` 4. Si cela est dû à un déploiement récent, revenez en arrière : `kubectl rollout undo deployment/` 5. Si c’est un problème de ressources, modifiez les limites de ressources et appliquez : `kubectl apply -f updated-deployment.yaml` 6. Vérifiez que le pod est Running et que les redémarrages n’augmentent pas : `kubectl get pods -n --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 -n | tail -20` - [ ] Vérifier les journaux du conteneur : `kubectl logs -n --previous` - [ ] Vérifier l’utilisation des ressources : `kubectl top pod -n ` (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/ -n ` - [ ] 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 --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 :** 1. Symptôme : le pod redémarre avec `OOMKilled` dans `kubectl describe pod`. 2. Confirmer : `kubectl get pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'` renvoie `OOMKilled`. 3. Vérifier les limites actuelles : `kubectl get pod -o jsonpath='{.spec.containers[0].resources}'` 4. Augmenter la limite de mémoire de 25 % dans le manifeste de déploiement, appliquer. 5. 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.