Objectifs
- Collecter état, événements, logs et configuration avant de corriger.
- Diagnostiquer CrashLoopBackOff, ImagePullBackOff et Pending.
- Vérifier selectors, endpoints, probes et ressources.
- Distinguer symptôme et cause racine dans un environnement distribué.
Diagnostiquer méthodiquement Kubernetes
Un statut Kubernetes comme CrashLoopBackOff ou Pending décrit un symptôme et une stratégie d’attente, pas une cause unique. La cause se trouve souvent dans les événements, l’état précédent du container, la configuration ou une dépendance.
Commencez par identifier le bon cluster, namespace et objet. Collectez les preuves avant de supprimer un Pod ou de modifier le workload, car une recréation peut effacer l’état utile au diagnostic.
Les commandes d’observation essentielles
get fournit une vue d’ensemble, describe corrèle état et événements, et logs montre la sortie du processus. --previous récupère les logs de l’instance précédente d’un container redémarré.
kubectl get pods
kubectl get pods -o wide
kubectl describe pod <pod>kubectl logs <pod>
kubectl logs <pod> --previouskubectl get events --sort-by=.metadata.creationTimestampkubectl get deployments
kubectl get svc
kubectl get endpoints
kubectl top pods
kubectl top nodeskubectl top nécessite Metrics Server ou une autre implémentation compatible de la Metrics API. Son échec peut signaler l’absence de métriques plutôt qu’un problème du Pod observé.
Méthode de diagnostic en dix étapes
Suivez un ordre reproductible et conservez l’heure, le namespace et les sorties utiles pour pouvoir comparer avant et après la correction.
- 1. Identifier précisément la ressource, le namespace et le contexte.
- 2. Vérifier son état et les conditions affichées.
- 3. Utiliser describe sur l’objet concerné.
- 4. Lire les Events récents et leurs raisons.
- 5. Consulter les logs actuels puis précédents si le container redémarre.
- 6. Comparer labels et selectors.
- 7. Vérifier Service, EndpointSlices, ports et politiques réseau.
- 8. Vérifier ConfigMaps, Secrets et dépendances externes.
- 9. Vérifier requests, limits, probes et capacité des nœuds.
- 10. Confirmer la cause avec une preuve avant la correction.
CrashLoopBackOff et ImagePullBackOff
CrashLoopBackOff signifie que Kubernetes espace les tentatives après des crashs répétés. Cherchez une erreur applicative, une configuration ou un Secret manquant, une dépendance indisponible ou une probe incorrecte.
ErrImagePull et ImagePullBackOff orientent vers le nom ou tag de l’image, le registry, le réseau ou un imagePullSecret absent ou invalide.
kubectl describe pod <pod>
kubectl logs <pod>
kubectl logs <pod> --previouskubectl describe pod <pod>Pod Pending
Un Pod reste Pending si le scheduler ne trouve pas de placement ou si une dépendance de démarrage n’est pas prête. Les événements peuvent indiquer des ressources insuffisantes, taints sans toleration, contraintes de placement ou un PVC Pending.
kubectl describe pod <pod>
kubectl get nodesService inaccessible
Vérifiez le Service, ses backends et les labels des Pods. Le problème classique est un selector de Service différent des labels réellement présents, ou des Pods exclus parce qu’ils ne sont pas Ready.
kubectl get svc
kubectl get endpoints
kubectl get pods --show-labelsLe diagnostic moderne peut aussi consulter kubectl get endpointslices pour voir les backends et leurs conditions.
Readiness, liveness et ressources
Une liveness probe répond à la question : faut-il redémarrer ce container ? Une readiness probe indique s’il peut actuellement recevoir du trafic via les Services. Une readiness en échec ne redémarre pas le container.
Les requests guident le scheduling et la réservation de capacité. Les limits encadrent l’utilisation ; dépasser une limite mémoire peut conduire à OOMKilled, tandis qu’une limite CPU provoque généralement du throttling.
kubectl describe pod <pod>
kubectl top pod <pod>Bonnes pratiques DevOps / Production
Automatisez la collecte d’indices, structurez les logs et définissez des probes qui reflètent réellement l’état de l’application. Une probe trop agressive peut aggraver un incident en provoquant des redémarrages inutiles.
- Toujours noter contexte, namespace, nom et heure de l’incident.
- Consulter --previous avant que de nouveaux redémarrages remplacent les indices utiles.
- Comparer état désiré, état réel et événements avant toute suppression.
- Définir requests et limits à partir de mesures, puis surveiller les OOM et throttlings.
Erreur fréquente : supprimer le Pod avant de collecter les preuves
Mini résumé
- Un statut d’attente est un symptôme : describe, Events et logs révèlent la cause.
- --previous est essentiel pour les containers qui redémarrent.
- Selectors, readiness et endpoints expliquent de nombreux incidents Service.
- Requests, limits et probes doivent être vérifiés avec les métriques disponibles.
Outils associés
Analyser les logs Kubernetes
Collez un extrait anonymisé de kubectl logs dans Log Analyzer pour repérer erreurs et motifs fréquents localement.
Ouvrir l’outilVérifier ou générer un manifeste
Utilisez Kubernetes YAML Generator pour préparer un manifeste cohérent avant de le relire et de l’appliquer.
Ouvrir l’outilConstruire une commande kubectl
Utilisez kubectl Command Builder pour composer une commande de diagnostic adaptée à la ressource ciblée.
Ouvrir l’outilMini quiz
Trois questions pour vérifier les notions essentielles de la leçon.