📍 Article principal : CKA depuis l’Afrique de l’Ouest. Ce tutoriel structure une méthode systématique de troubleshooting Kubernetes — domaine qui pèse 30 % du score CKA, donc le plus important à maîtriser.
Le troubleshooting est l’épreuve qui distingue les candidats CKA confirmés des autres. Sans méthode, face à un pod en CrashLoopBackOff ou un cluster qui ne répond plus, le candidat panique et perd des minutes précieuses. Avec une méthode systématique, chaque type de panne se diagnostique en quelques minutes par élimination des hypothèses. Ce tutoriel propose une démarche en quatre niveaux — pod, service, control plane, node — avec les commandes clés pour chaque, et termine par des scénarios concrets type examen.
Prérequis
- Cluster kubeadm fonctionnel (voir tutoriel kubeadm)
- RBAC et NetworkPolicy maîtrisés (voir tutoriel RBAC)
- Niveau : avancé
- Temps estimé : 4 à 5 heures
Niveau 1 — Troubleshooting des pods
Quand un pod ne se comporte pas comme attendu, suivre une séquence systématique. Premier : kubectl get pods -n <namespace> pour voir le statut global. Si Pending, le pod attend ses ressources — investiguer les events. Si CrashLoopBackOff, le conteneur crash en boucle — examiner les logs. Si ImagePullBackOff, l’image n’est pas accessible — vérifier le nom et l’auth du registry.
Commandes essentielles. kubectl describe pod <name> -n <ns> affiche les events détaillés et la configuration complète — premier réflexe systématique. kubectl logs <pod> -n <ns> récupère les logs du conteneur courant, kubectl logs <pod> -n <ns> --previous les logs du conteneur précédent (utile en CrashLoopBackOff). kubectl logs <pod> -c <container> spécifie un conteneur dans un pod multi-conteneurs.
Pour les pods qui démarrent mais ne fonctionnent pas, exécuter une commande dedans : kubectl exec -it <pod> -n <ns> -- sh. Tester la connectivité, vérifier la résolution DNS, examiner la config injectée par ConfigMap ou Secret. Cette pratique de debug interactive est testée à l’examen — savoir naviguer rapidement dans un pod défaillant est crucial.
Niveau 2 — Troubleshooting des services et networking
Quand un Service ne répond pas, trois causes possibles. Premier : pas d’endpoint associé. Vérifier kubectl get endpoints <svc> -n <ns> — si la liste est vide, le selector ne matche aucun pod. Comparer les labels du service et des pods cibles. Deuxième : NetworkPolicy bloque le trafic. Lister les NetworkPolicy du namespace, identifier celles qui s’appliquent aux pods cibles, vérifier que le pod source est autorisé. Troisième : kube-proxy ou CoreDNS en panne — vérifier leurs pods dans kube-system.
Outil indispensable pour le debug réseau : déployer un pod nicolaka/netshoot dans le namespace concerné. Ce pod inclut tous les outils nécessaires (curl, dig, nslookup, traceroute, tcpdump). Tester depuis ce pod la connectivité aux services concernés. Si curl fonctionne par IP mais pas par nom, c’est un problème DNS (CoreDNS). Si curl ne fonctionne pas par IP non plus, c’est un problème routage ou NetworkPolicy.
Niveau 3 — Troubleshooting du control plane
Quand kubectl ne répond plus ou réponse intermittente, le control plane est probablement en cause. Sur un cluster kubeadm, les composants control plane tournent comme pods statiques sur le nœud master. Localiser leurs manifests dans /etc/kubernetes/manifests/ — kube-apiserver.yaml, kube-controller-manager.yaml, kube-scheduler.yaml, etcd.yaml. Vérifier le statut de containerd avec crictl ps sur le node, identifier les conteneurs en panne.
Les pods statiques redémarrent automatiquement si on modifie leur manifest. Pour les redémarrer manuellement, déplacer le manifest hors du dossier puis le remettre. Pour debugger l’API server lui-même, examiner les logs avec journalctl -u kubelet -n 100 ou crictl logs <container-id>. Souvent les erreurs API viennent d’un certificat expiré, d’un fichier kubeconfig corrompu, ou d’etcd indisponible.
Pour les problèmes etcd, l’outil etcdctl permet le diagnostic. Vérifier la santé : etcdctl endpoint health. Lister les membres : etcdctl member list. En cas d’incohérence, restaurer un snapshot précédent — opération testée à l’examen via le scénario etcd backup et restore.
Niveau 4 — Troubleshooting des nodes
Quand un node passe en NotReady, plusieurs causes. Premier : kubelet en panne. Vérifier systemctl status kubelet sur le node. Si le service est down, le redémarrer et examiner les logs journalctl -u kubelet -f. Deuxième : containerd en panne — même approche avec le service containerd. Troisième : certificat kubelet expiré — souvent lié à un manque de rotation automatique. Régénérer avec kubeadm.
Quatrième : ressources épuisées sur le node. df -h pour le disque, free -h pour la mémoire, top pour le CPU. Si la pression mémoire est élevée, kubelet peut évincer des pods et basculer en NotReady. Cinquième : réseau en panne. Tester la connectivité du node vers le control plane via curl ou ping. Si la résolution DNS échoue, vérifier /etc/resolv.conf et la connectivité internet.
Méthode systématique pour l’examen
Face à n’importe quelle question troubleshooting CKA, appliquer cette séquence en moins de 60 secondes. Étape 1, lire la question deux fois pour identifier le symptôme exact et le résultat attendu. Étape 2, vérifier le contexte — quel cluster, quel namespace. Étape 3, commande de diagnostic appropriée selon le niveau (pod, service, node, control plane). Étape 4, identifier la cause via les events, logs ou état. Étape 5, appliquer le correctif le plus simple. Étape 6, valider que le symptôme a disparu.
Erreur classique à l’examen : vouloir comprendre profondément la cause au lieu d’appliquer le correctif rapide. La CKA évalue l’efficacité opérationnelle, pas l’expertise théorique. Un certificat expiré ? Régénérer immédiatement. Un service sans endpoint ? Corriger les labels du pod. Cette pragmatique économise des minutes précieuses qui peuvent faire la différence entre la réussite et l’échec.
Scénarios concrets type examen
Scénario 1 : un pod nginx ne démarre pas dans le namespace finance. Diagnostic : kubectl describe pod nginx -n finance montre un event « FailedScheduling » car aucun node ne dispose des ressources requises. Correctif : réduire les requests CPU et mémoire du pod, ou ajouter un node au cluster. Scénario 2 : un Service web ne route pas vers les pods. Diagnostic : endpoints vides, le selector du service ne matche aucun pod. Correctif : corriger les labels.
Scénario 3 : kubectl ne répond plus. Diagnostic : SSH sur le master, crictl ps montre que kube-apiserver est down. Correctif : examiner le manifest, corriger l’erreur de syntaxe YAML, attendre le redémarrage automatique. Scénario 4 : un node passe en NotReady après une mise à jour kernel. Diagnostic : kubelet utilise un cgroup driver différent du kernel. Correctif : aligner le driver dans /var/lib/kubelet/config.yaml et redémarrer kubelet.
Pratiquer ces scénarios sur le cluster d’entraînement Hetzner construit l’intuition diagnostic indispensable à l’examen. Mémoriser les commandes clés est insuffisant — il faut développer le réflexe d’application correct dans le contexte réel.
Outils CLI avancés et alias productifs
Pour accélérer le diagnostic, plusieurs outils CLI complètent kubectl. k9s propose une interface terminal interactive qui affiche en temps réel les pods, services, deployments. La navigation est rapide et permet de descendre dans les ressources sans taper de longues commandes. stern agrège les logs de plusieurs pods en suivant un pattern — pratique pour observer un déploiement avec plusieurs replicas. kubectx et kubens simplifient le changement de cluster et de namespace. Ces outils ne sont pas disponibles à l’examen mais leur usage en pratique forme l’intuition.
Configurer aussi des alias bash productifs. alias k=kubectl, alias kgp="kubectl get pods", alias kgs="kubectl get svc", alias kdp="kubectl describe pod", alias kex="kubectl exec -it". Ces raccourcis économisent des centaines de frappes par session de pratique et construisent les réflexes nécessaires. À l’examen, configurer immédiatement alias k=kubectl et l’autocomplétion en début d’épreuve.
Logs centralisés pour le post-mortem
En production réelle (au-delà de l’examen), centraliser les logs Kubernetes facilite le diagnostic post-incident. La stack Loki + Grafana est le choix moderne : Loki ingère les logs envoyés par Promtail ou Fluent Bit déployé en DaemonSet, Grafana permet la recherche full-text dans tous les logs du cluster. Pour un cluster de 50 pods, la stack tient en 2 Go de RAM additionnels avec rétention de 30 jours.
Cette compétence d’observabilité distingue les ingénieurs CKA-certifiés capables d’opérer un cluster en production de ceux qui ont uniquement préparé l’examen. Pour les freelances ouest-africains, ajouter cette stack à la prestation initiale différencie commercialement face aux concurrents qui livrent uniquement le cluster sans observabilité — premium tarifaire de 30 à 50 %.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Diagnostic trop long | Volonté de comprendre profondément | Appliquer le correctif le plus simple, comprendre après |
| Oubli de namespace | Commandes sans -n | Toujours préciser -n explicite ou alias avec namespace par défaut |
| Logs –previous oublié | Réflexe absent en CrashLoopBackOff | Sur tout pod en restart, tester systématiquement –previous |
| SSH oublié sur le node | Tout depuis kubectl seulement | Pour les pannes node, journalctl et crictl sont indispensables |
Adaptation au contexte ouest-africain
Pour les apprenants ouest-africains qui passent l’examen depuis Dakar ou Abidjan, la latence vers les VPS Hetzner pendant le diagnostic peut ralentir certaines opérations. Préparer mentalement les enchaînements de commandes pour minimiser les allers-retours sur la documentation. Mémoriser au moins 30 commandes essentielles à utiliser sans regarder la doc — investissement initial qui se paie largement le jour J. La méthode systématique compense largement les éventuelles latences réseau locales.
Patterns de pannes courants en production
Au-delà des scénarios d’examen, plusieurs patterns reviennent en production réelle. Le pod qui consomme 100 % du CPU : limites de ressources non définies, application bugguée. Solution : ajouter resources.limits, redémarrer. Le node qui passe régulièrement en NotReady : pression mémoire ou disque, kubelet eviction. Solution : agrandir les ressources ou ajouter un node. Le déploiement bloqué en RollingUpdate : readinessProbe trop stricte, nouveaux pods jamais ready. Solution : assouplir la probe ou rollback.
Documenter ces patterns au fil de l’expérience professionnelle construit une bibliothèque personnelle de référence inestimable. Pour les ingénieurs débutants, plusieurs livres techniques décrivent ces cas — Kubernetes Patterns de Bilgin Ibryam et Roland Huss, Kubernetes Operators de Jason Dobies. Investir dans cette littérature accélère drastiquement la montée en compétence opérationnelle après la certification.
Diagnostic des CrashLoopBackOff complexes
Le CrashLoopBackOff est l’état le plus fréquent à diagnostiquer. Causes principales par fréquence : configuration erronée (variable d’environnement manquante, ConfigMap non monté), permissions insuffisantes (ServiceAccount sans droits, FileSystemPermission), dépendance externe indisponible (base de données, Redis, API), bug applicatif (panic au démarrage). Pour chaque cause, la commande logs –previous révèle l’erreur originale avant que kubelet ne tue le conteneur.
Cas piège : un pod en CrashLoopBackOff dont les logs sont vides. Le conteneur crash trop vite avant d’écrire des logs. Solution : ajouter une commande sleep dans le YAML pour retarder la commande principale, exec dans le conteneur démarré, examiner manuellement le filesystem et tester la commande. Cette technique sauve les diagnostics impossibles autrement et révèle les bugs les plus subtils. Pratiquer sur le cluster d’entraînement permet de mémoriser ce réflexe.
Diagnostic des problèmes de stockage
Pour les pods qui utilisent des PersistentVolume, plusieurs points de défaillance. Premier : PVC en Pending — aucun PV ne matche, ou StorageClass introuvable. Deuxième : PV bloqué en Released — l’ancien PVC supprimé n’a pas libéré le PV correctement. Troisième : ReadWriteMany impossible sur certains backends (NFS uniquement). Quatrième : AccessModes mal alignés entre PV et PVC.
Commandes diagnostic. kubectl get pv,pvc -A donne la vue d’ensemble. kubectl describe pvc <name> -n <ns> montre les events de provisioning. Pour les StorageClass dynamiques, vérifier que le provisioner CSI est sain : pods CSI dans kube-system en état Running. Sur un cluster Hetzner, le provisioner Hetzner Cloud Volumes peut être en panne — solution : redéployer le DaemonSet ou créer manuellement les Volumes via la console Hetzner.
Maîtriser ces patterns de diagnostic transforme l’opérateur Kubernetes d’un poste réactif en moteur proactif d’amélioration continue de la plateforme, capable d’anticiper les pannes avant qu’elles ne deviennent critiques pour le business.
Cette posture proactive constitue le marqueur des ingénieurs DevOps les plus valorisés sur le marché ouest-africain et international.
Compétences observabilité au-delà de la CKA
Le troubleshooting devient encore plus efficace avec une bonne stack d’observabilité. Métriques via Prometheus + Grafana pour les tendances, logs centralisés via Loki pour la recherche post-incident, traces distribuées via Tempo ou Jaeger pour les architectures microservices. Cette stack auto-hébergée tient en quelques gigaoctets de RAM additionnels et donne aux équipes DevOps une visibilité continue qui réduit drastiquement le temps moyen de résolution des incidents.
Pour les apprenants ouest-africains qui veulent monter au-delà de la CKA pure, investir une semaine après la certification dans le déploiement d’une stack observabilité complète sur le cluster d’entraînement. Cette compétence supplémentaire fait gagner 30 à 50 % de TJM freelance face à un pur certifié CKA — argument commercial décisif lors des entretiens et des négociations.
Pour aller plus loin
🔝 Retour à l’article principal : CKA depuis l’Afrique de l’Ouest. Tutoriels précédents : cluster kubeadm, RBAC et NetworkPolicy.
Documentation officielle troubleshooting : kubernetes.io/docs/tasks/debug, image debug netshoot : github.com/nicolaka/netshoot. Le troubleshooting est la compétence Kubernetes la plus durable — les versions de l’orchestrateur évoluent, les outils changent, mais la méthode systématique de diagnostic reste la même. Investir dans cette discipline construit une expertise transférable qui résiste à l’obsolescence technologique.