Cette section aborde les techniques et commandes courantes pour diagnostiquer et résoudre les problèmes dans un cluster Kubernetes.
Les problèmes au niveau du cluster peuvent se manifester de diverses manières : nœuds non prêts, API Server inaccessible, pods non schedulés, etc.
1. Vérifier l'accessibilité de l'API Server et la configuration kubeconfig:
La première étape est souvent de vérifier si kubectl peut communiquer avec l'API Server. Une erreur courante est :
kubectl get nodes
The connection to the server <host>:<port> was refused - did you specify the right host or port?
Causes possibles :
kube-apiserver) n'est pas en cours d'exécution sur le(s) nœud(s) master.kubeconfig (souvent ~/.kube/config) pointe vers une mauvaise adresse ou un mauvais port, ou les certificats/tokens sont invalides.Actions : Vérifiez la configuration
kubeconfig. Si vous êtes sur un nœud master, vérifiez le statut du servicekube-apiserver(s'il est géré par systemd) ou le Pod statiquekube-apiserverdans/etc/kubernetes/manifestset ses logs (docker logs <container_id>oucrictl logs <container_id>si vous utilisez containerd/CRI-O, ou viakubectl logs -n kube-system kube-apiserver-<nodename>si le pod miroir existe et quekubectlfonctionne partiellement).
2. Vérifier l'état des Nœuds :
kubectl get nodes -o wide
Regardez la colonne STATUS. Un nœud doit être Ready pour accepter des Pods. S'il est NotReady ou Unknown:
NotReady : Le nœud est joignable mais le Kubelet rencontre un problème (CRI down, CNI non prêt, manque de ressources, etc.).Unknown : Le control plane n'arrive pas à joindre le Kubelet de ce nœud (probablement un problème réseau ou le Kubelet est arrêté).3. Décrire le Nœud problématique :
kubectl describe node <nom-du-noeud-problematique>
Analysez attentivement les sections :
Conditions : Donne l'état détaillé (Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable). Regardez les messages associés à chaque condition False ou Unknown.Events : Liste les événements récents liés au nœud, qui peuvent indiquer la cause du problème (ex: erreurs de CNI, problèmes de ressources).System Info : Vérifiez si les versions (Kubelet, OS, CRI) sont cohérentes.Allocatable / Capacity : Pour détecter d'éventuels problèmes de ressources.4. Vérifier les Services Critiques sur le Nœud :
Connectez-vous au nœud concerné (via SSH par exemple) et vérifiez le statut des services essentiels :
# Vérifier le Kubelet
systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager # Voir les 50 derniers logs
# Vérifier le Container Runtime Interface (CRI)
systemctl status docker # Si Docker est utilisé
systemctl status containerd # Si containerd est utilisé
journalctl -u docker -n 50 --no-pager
journalctl -u containerd -n 50 --no-pager
Redémarrez les services si nécessaire (systemctl restart <service>).
5. Vérifier les Pods du Control Plane (kube-system) :
Les composants du control plane (API Server, Scheduler, Controller Manager, etcd, CoreDNS, CNI, Kube-proxy) tournent souvent comme des Pods (statiques ou non) dans le namespace kube-system. Des problèmes avec ces Pods peuvent paralyser le cluster.
# Lister les pods dans kube-system
kubectl get pods -n kube-system -o wide
# Regarder les pods non 'Running' ou avec des 'RESTARTS' élevés
# Décrire un pod problématique
kubectl describe pod <nom-pod-problematique> -n kube-system
# Consulter les logs d'un pod problématique
kubectl logs <nom-pod-problematique> -n kube-system
# Si le pod a redémarré, voir les logs précédents
kubectl logs <nom-pod-problematique> -n kube-system -p
Faites particulièrement attention à etcd (si visible), kube-apiserver, kube-scheduler, kube-controller-manager, coredns, et les pods de votre plugin CNI (ex: calico-node, flannel).
6. Consulter les Logs des Composants :
Si les composants tournent comme des services systemd (moins courant avec kubeadm), leurs logs sont dans journalctl (voir étape 4).
S'ils tournent comme des Pods statiques, leurs logs peuvent être dans /var/log/pods sur le nœud master, ou accessibles via docker logs/crictl logs du container correspondant sur le nœud master. Les logs de l'API Server, du Scheduler et du Controller Manager sont souvent très verbeux mais peuvent contenir des indices cruciaux.
# Exemple pour voir les logs de l'api-server (si pod statique)
kubectl logs -n kube-system kube-apiserver-<nom-noeud-master>
Lorsqu'une application déployée via un Pod, Deployment, StatefulSet, etc. ne fonctionne pas comme prévu.
1. Vérifier l'état du Pod :
kubectl get pods -n <namespace> -o wide
Regardez la colonne STATUS. Statuts courants indiquant un problème :
Pending : Le Pod n'a pas encore été schedulé sur un nœud ou est en train de télécharger une image. Causes : ressources insuffisantes, taints non tolérés, affinité/anti-affinité non satisfaite, PVC non lié (Pending).CrashLoopBackOff : Le container démarre, crashe immédiatement, et Kubernetes essaie de le redémarrer en boucle avec un délai croissant. C'est un problème applicatif ou de configuration dans le container.ImagePullBackOff / ErrImagePull : Kubernetes n'arrive pas à télécharger l'image Docker spécifiée. Causes : nom d'image incorrect, tag inexistant, problème de registre (privé sans credentials, etc.), problème réseau sur le nœud.CreateContainerConfigError : Problème lors de la création de la configuration du container. Souvent lié à un Secret ou une ConfigMap manquant(e) référencé(e) dans la spec du Pod (ex: envFrom, volumeMount).RunContainerError : Erreur lors du démarrage du container lui-même (après la création de la config).Terminating : Le Pod est en cours d'arrêt mais est bloqué (ex: finalizer, problème de stockage).Failed : Le Pod (souvent un Job ou avec restartPolicy: Never/OnFailure) s'est terminé avec un code d'erreur non nul.2. Décrire le Pod :
C'est souvent l'étape la plus informative.
kubectl describe pod <nom-du-pod> -n <namespace>
Analysez :
Status : Confirme le statut vu dans get pods.Reason / Message : Peuvent donner une indication plus précise (ex: pour Pending, ça peut indiquer Unschedulable).Containers > State / Last State : Indique l'état actuel et précédent du/des container(s). Pour CrashLoopBackOff, Last State montrera souvent Terminated avec un Reason: Error et un Exit Code non nul.Events : La section la plus importante ! Elle liste chronologiquement les événements liés au cycle de vie du Pod : scheduling, pull d'image, création/démarrage de container, échecs de sondes (liveness/readiness), etc. Les messages d'erreur ici sont cruciaux.3. Consulter les Logs du Container :
Indispensable pour les problèmes applicatifs (CrashLoopBackOff, comportement inattendu).
# Voir les logs actuels du container par défaut
kubectl logs <nom-du-pod> -n <namespace>
# Si plusieurs containers, spécifier le container
kubectl logs <nom-du-pod> -c <nom-du-container> -n <namespace>
# Suivre les logs en temps réel
kubectl logs -f <nom-du-pod> -c <nom-du-container> -n <namespace>
# Voir les logs du container précédent (après un crash/redémarrage)
kubectl logs -p <nom-du-pod> -c <nom-du-container> -n <namespace>
# Voir les N dernières lignes
kubectl logs --tail=50 <nom-du-pod> -c <nom-du-container> -n <namespace>
4. Exécuter une commande dans le Container (exec) :
Si le Pod est Running mais ne fonctionne pas correctement, on peut obtenir un shell ou exécuter des commandes de diagnostic à l'intérieur.
# Obtenir un shell interactif dans le container (si l'image contient sh/bash)
kubectl exec -it <nom-du-pod> -c <nom-du-container> -n <namespace> -- /bin/sh # ou /bin/bash
# Exécuter une commande spécifique
kubectl exec <nom-du-pod> -c <nom-du-container> -n <namespace> -- ps aux
kubectl exec <nom-du-pod> -c <nom-du-container> -n <namespace> -- curl localhost:<port-app>
Attention :
kubectl execnécessite que le container soit en cours d'exécution. Ça ne fonctionne pas pour les PodsPending,CrashLoopBackOff(sauf très brièvement), ouFailed.
5. Vérifier les Probes (Liveness/Readiness/Startup) :
Des probes mal configurées peuvent causer des redémarrages inutiles (Liveness) ou empêcher un Pod de recevoir du trafic (Readiness). Vérifiez les Events dans kubectl describe pod pour des messages comme Liveness probe failed ou Readiness probe failed. Testez la commande/URL de la probe manuellement depuis le Pod (kubectl exec) ou depuis un autre Pod si possible.
Les problèmes réseau peuvent être complexes. Voici quelques pistes :
1. Vérifier le DNS :
# Depuis un pod de test (ex: busybox)
nslookup <nom-service>.<namespace>.svc.cluster.local
nslookup <nom-service> # Devrait fonctionner si dans le même namespace
nslookup www.google.com
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system <pod-coredns-xxxx>
/etc/resolv.conf à l'intérieur d'un Pod (kubectl exec <pod> -- cat /etc/resolv.conf). Il doit pointer vers l'IP du Service kube-dns.2. Vérifier les Services et Endpoints :
kubectl get svc <nom-service> -n <namespace>)kubectl get endpoints <nom-service> -n <namespace>
# Ou pour les versions récentes, utiliser EndpointSlice
kubectl get endpointslice -l kubernetes.io/service-name=<nom-service> -n <namespace>
ENDPOINTS est vide ou <none>, vérifiez le selector du Service et les labels des Pods cibles. Vérifiez aussi que les Pods cibles sont Running et Ready (la readiness probe réussit).targetPort du Service correspond-il au port où l'application écoute dans les Pods ?3. Vérifier kube-proxy :
Ce composant tourne sur chaque nœud et configure les règles (iptables/IPVS) pour router le trafic des Services vers les Pods. Vérifiez qu'il tourne (souvent un DaemonSet dans kube-system). Consultez ses logs.
4. Vérifier les Network Policies :
kubectl get networkpolicy -n <namespace>
kubectl describe networkpolicy <nom-policy> -n <namespace>
5. Utiliser des Outils de Diagnostic Réseau :
Lancer un Pod avec des outils réseau comme netshoot pour tester la connectivité depuis l'intérieur du cluster.
apiVersion: v1
kind: Pod
metadata:
name: netshoot-debug
namespace: default
spec:
containers:
- name: netshoot
image: nicolaka/netshoot # Contient curl, ping, dig, netstat, etc.
command: ["sleep", "infinity"]
Appliquer, puis utiliser kubectl exec :
kubectl exec -it netshoot-debug -- bash
# Depuis ce shell :
# ping <ip-autre-pod>
# curl <nom-service>:<port>
# dig <nom-service>.<namespace>.svc.cluster.local @<ip-coredns>
Pending (Unschedulable) :
kubectl describe pod <pod-pending> montrera souvent des messages indiquant un manque de CPU, de mémoire, ou des conflits de taints/tolerations/affinity.kubectl top node.requests du Pod et les ressources allocatable des nœuds.OOMKilled (Out Of Memory Killed) :
limit de mémoire.kubectl describe pod <pod> montrera Terminated avec Reason: OOMKilled dans Last State.limit de mémoire ou optimisez la consommation mémoire de l'application.limit (s'il en a une) ou sature ses requests si le nœud est chargé.kubectl top pod <pod> --containers.requests/limits ou optimisez l'application.Pour maximiser l'efficacité lors du dépannage, suivez cette approche systématique :
Questions initiales :
Collecter les informations de base :
# État global du cluster
kubectl get nodes
kubectl get pods -A | grep -v Running
# Identifier la portée
kubectl get pods -n <namespace>
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
Suivre la pile technique de bas en haut :
Couche 1 : Infrastructure → Nœuds, ressources physiques
Couche 2 : Control Plane → API Server, etcd, Scheduler, Controller Manager
Couche 3 : Worker Components → Kubelet, Container Runtime, CNI, kube-proxy
Couche 4 : Application → Pods, Containers, configuration
# 1. GET - Vue d'ensemble
kubectl get <resource> -n <namespace>
# 2. DESCRIBE - Détails et events
kubectl describe <resource> <name> -n <namespace>
# 3. LOGS - Si Running
kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
# 4. EVENTS - Contexte temporel
kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20
Pod ne démarre pas (Pending/ImagePullBackOff/CrashLoopBackOff) :
kubectl describe pod → Vérifier Events et Conditionskubectl logs si le container a démarréService inaccessible :
kubectl get endpoints <service>nslookup <service> depuis un PodCluster dysfonctionnel :
Le Control Plane est le cerveau du cluster. Un dysfonctionnement ici affecte tout le cluster.
Symptômes :
kubectl renvoie "connection refused" ou timeoutDiagnostic :
# Vérifier si le Pod/Service API Server est en cours d'exécution
kubectl get pods -n kube-system | grep apiserver
# Sur le nœud master, vérifier le Pod statique
sudo crictl ps | grep kube-apiserver
sudo crictl logs <container-id>
# Vérifier les logs
sudo journalctl -u kube-apiserver -n 100 --no-pager
# Vérifier le manifeste du Pod statique
sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml
# Tester l'accès direct
curl -k https://localhost:6443/healthz
curl -k https://localhost:6443/livez
curl -k https://localhost:6443/readyz
Problèmes courants :
Certificats expirés ou invalides :
# Vérifier expiration des certificats
sudo kubeadm certs check-expiration
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
etcd inaccessible :
Problème de réseau/port :
Ressources insuffisantes :
Symptômes :
PendingDiagnostic :
# Vérifier le Scheduler
kubectl get pods -n kube-system | grep scheduler
kubectl logs -n kube-system kube-scheduler-<master-node>
# Vérifier les events
kubectl get events -A | grep scheduler
# Sur le nœud master
sudo crictl ps | grep kube-scheduler
sudo crictl logs <container-id>
Problèmes courants :
Scheduler non démarré :
Problème de RBAC :
Ressources insuffisantes sur tous les nœuds :
kubectl top nodesSymptômes :
Diagnostic :
# Vérifier le Controller Manager
kubectl get pods -n kube-system | grep controller-manager
kubectl logs -n kube-system kube-controller-manager-<master-node>
# Sur le nœud master
sudo crictl ps | grep kube-controller-manager
sudo crictl logs <container-id> | tail -100
# Vérifier les événements liés aux controllers
kubectl get events -A | grep controller
Problèmes courants :
Leader election failed :
Problème de synchronisation :
Controller spécifique en échec :
ETCD est la base de données distribuée qui stocke tout l'état du cluster. C'est un composant critique.
# Si etcd tourne comme un Pod
kubectl get pods -n kube-system | grep etcd
kubectl logs -n kube-system etcd-<master-node>
# Sur le nœud master, avec etcdctl
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
# Vérifier les membres du cluster etcd
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
member list
# Vérifier l'utilisation d'espace
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint status --write-out=table
1. Corruption de données
Symptômes : API Server ne démarre pas, erreurs "mvcc: database space exceeded"
Solution :
# Compacter et défragmenter
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
compact <revision>
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
defrag
2. Perte de quorum (cluster multi-master)
Symptômes : Cluster non fonctionnel, etcd ne peut pas élire de leader
Actions :
3. Backup et restauration
Créer un backup :
ETCDCTL_API=3 sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db
# Vérifier le backup
ETCDCTL_API=3 sudo etcdctl snapshot status /backup/etcd-snapshot-*.db --write-out=table
Restaurer depuis un backup :
# Arrêter l'API Server et etcd
sudo systemctl stop kube-apiserver etcd
# Restaurer
ETCDCTL_API=3 sudo etcdctl snapshot restore /backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-restore
# Mettre à jour le manifeste etcd pour pointer vers /var/lib/etcd-restore
sudo vi /etc/kubernetes/manifests/etcd.yaml
# Redémarrer
sudo systemctl start etcd kube-apiserver
Les certificats expirent par défaut après 1 an dans kubeadm. Des certificats expirés cassent complètement le cluster.
# Avec kubeadm
sudo kubeadm certs check-expiration
# Manuellement pour chaque certificat
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A 2 Validity
sudo openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -noout -dates
sudo openssl x509 -in /etc/kubernetes/pki/front-proxy-client.crt -noout -dates
Résultat typique :
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY
apiserver Jan 24, 2026 10:00 UTC 364d ca
apiserver-kubelet-client Jan 24, 2026 10:00 UTC 364d ca
...
Méthode automatique (kubeadm) :
# Renouveler tous les certificats
sudo kubeadm certs renew all
# Renouveler un certificat spécifique
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew apiserver-kubelet-client
# Vérifier après renouvellement
sudo kubeadm certs check-expiration
# Redémarrer les composants du control plane
sudo systemctl restart kubelet
Important : Après renouvellement, mettre à jour le fichier kubeconfig admin :
sudo cp /etc/kubernetes/admin.conf ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config
Le CNI gère le réseau entre les Pods. Un problème CNI impacte toute la communication.
# Identifier le plugin CNI
kubectl get pods -n kube-system | grep -E 'calico|flannel|weave|cilium|canal'
# Vérifier les logs du CNI (exemple avec Calico)
kubectl logs -n kube-system <calico-node-pod> -c calico-node
# Vérifier la configuration CNI sur un nœud
ls -la /etc/cni/net.d/
cat /etc/cni/net.d/10-calico.conflist
Running mais ne peuvent pas communiquer entre euxNotReady avec condition NetworkUnavailable1. Vérifier que le plugin CNI est déployé :
kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get daemonset -n kube-system
Tous les nœuds doivent avoir un Pod CNI en Running.
2. Vérifier les logs du CNI :
kubectl logs -n kube-system <cni-pod> --all-containers=true
3. Vérifier les interfaces réseau sur un nœud :
# Sur un worker node
ip addr show
ip route show
# Vérifier les bridges (dépend du CNI)
brctl show # Pour Flannel
ip link show type vxlan # Pour VXLAN overlays
4. Tester la connectivité Pod-to-Pod :
# Créer deux Pods de test sur des nœuds différents
kubectl run test-1 --image=nicolaka/netshoot --command -- sleep infinity
kubectl run test-2 --image=nicolaka/netshoot --command -- sleep infinity
# Obtenir les IPs
kubectl get pods -o wide
# Tester ping entre les Pods
kubectl exec test-1 -- ping <IP-test-2>
5. Problèmes courants CNI :
Permet d'injecter un container de debug dans un Pod running sans modifier la spec originale. Utile quand l'image du Pod ne contient pas d'outils de debug.
# Ajouter un container éphémère avec des outils
kubectl debug <pod-name> -it --image=nicolaka/netshoot --target=<container-name>
# Le container éphémère partage le namespace réseau et process du container cible
# Permet d'inspecter avec netstat, tcpdump, strace, etc.
Exemple :
kubectl debug nginx-pod -it --image=nicolaka/netshoot --target=nginx
# Depuis le shell éphémère :
netstat -tlnp
ps aux
curl localhost:80
Debug un nœud en créant un Pod privilégié sur ce nœud avec accès au filesystem de l'hôte.
# Créer une session de debug sur un nœud
kubectl debug node/<node-name> -it --image=ubuntu
# Le filesystem du nœud est monté dans /host
# Exemple :
chroot /host
systemctl status kubelet
journalctl -u kubelet -n 50
Très utile pour :
# Copier un fichier depuis un Pod vers local
kubectl cp <namespace>/<pod>:/path/to/file ./local-file
# Copier depuis local vers un Pod
kubectl cp ./local-file <namespace>/<pod>:/path/to/file
# Utile pour récupérer :
# - Logs applicatifs internes
# - Dumps mémoire
# - Fichiers de configuration générés
Sur un nœud, crictl permet d'interagir directement avec le Container Runtime (containerd/CRI-O).
# Lister tous les containers (même ceux arrêtés)
sudo crictl ps -a
# Voir les logs d'un container
sudo crictl logs <container-id>
# Inspecter un container
sudo crictl inspect <container-id>
# Voir les images
sudo crictl images
# Executer une commande dans un container
sudo crictl exec -it <container-id> /bin/sh
Utile quand kubectl ne fonctionne pas (problème API Server) mais les containers tournent encore.
Les upgrades mal effectuées peuvent casser un cluster.
1. Incompatibilité de versions
Symptômes : Composants ne démarrent pas après upgrade
Solution :
2. Pods du control plane en CrashLoopBackOff
Diagnostic :
kubectl logs -n kube-system kube-apiserver-<master> --previous
kubectl logs -n kube-system kube-controller-manager-<master> --previous
kubectl logs -n kube-system kube-scheduler-<master> --previous
Actions :
/etc/kubernetes/manifests/3. kubeadm upgrade échoue
# Vérifier l'état avant upgrade
sudo kubeadm upgrade plan
# Logs détaillés pendant l'upgrade
sudo kubeadm upgrade apply v1.28.0 --v=5
# Si échec, vérifier :
# - Tous les nœuds sont Ready
# - Pas de Pods en état anormal dans kube-system
# - Backups etcd récents disponibles
4. Rollback si nécessaire
Si l'upgrade échoue catastrophiquement :
# Restaurer etcd depuis backup
ETCDCTL_API=3 sudo etcdctl snapshot restore /backup/etcd-snapshot-before-upgrade.db
# Downgrade des packages (si possible)
sudo apt-mark unhold kubelet kubeadm kubectl
sudo apt install kubelet=1.29.0-00 kubeadm=1.29.0-00 kubectl=1.29.0-00
sudo apt-mark hold kubelet kubeadm kubectl
# Redémarrer
sudo systemctl restart kubelet
1. Ressources des nœuds
# Utilisation globale
kubectl top nodes
# Détail par Pod
kubectl top pods -A --sort-by=cpu
kubectl top pods -A --sort-by=memory
# Sur un nœud (via SSH)
top
htop
vmstat 1
iostat -x 1
2. Slow API responses
Symptômes : kubectl commands prennent longtemps
Causes possibles :
Diagnostic :
# Métriques API Server (si metrics-server ou prometheus installé)
kubectl get --raw /metrics | grep apiserver_request_duration_seconds
# Vérifier la charge etcd
ETCDCTL_API=3 sudo etcdctl endpoint status --write-out=table
3. Pods lents au démarrage
Causes :
# Voir le temps de chaque phase
kubectl describe pod <pod> | grep -A 10 "Events:"
# Vérifier temps d'image pull
# Vérifier temps d'init containers
# Vérifier readiness probe
# Diagnostic rapide
kubectl get pods -A
kubectl get nodes -o wide
kubectl get events -A --sort-by='.lastTimestamp' | tail -20
# Inspection détaillée
kubectl describe <resource> <name> -n <namespace>
kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
# Debug avancé
kubectl debug <pod> -it --image=nicolaka/netshoot
kubectl debug node/<node> -it --image=ubuntu
kubectl exec -it <pod> -- /bin/sh
# Composants du control plane
kubectl logs -n kube-system kube-apiserver-<master>
kubectl logs -n kube-system kube-scheduler-<master>
kubectl logs -n kube-system kube-controller-manager-<master>
kubectl logs -n kube-system etcd-<master>
# Certificats
sudo kubeadm certs check-expiration
sudo kubeadm certs renew all
# ETCD
ETCDCTL_API=3 sudo etcdctl endpoint health --cluster
ETCDCTL_API=3 sudo etcdctl snapshot save /backup/etcd-snapshot.db
# Nodes
systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager
sudo crictl ps
sudo crictl logs <container-id>
Pour troubleshooter efficacement à l'examen (30% du score CKA) :
Ce guide couvre les scénarios de dépannage les plus courants pour la CKA. La clé est d'utiliser kubectl describe et kubectl logs de manière méthodique pour isoler la cause première du problème, et de connaître les techniques avancées pour les problèmes complexes du control plane, etcd, certificats et CNI.