Diagnostiquer avec kubectl get, describe, logs et top

Quatre commandes suffisent pour diagnostiquer 90 % des problèmes Kubernetes : kubectl get repère les ressources en erreur, kubectl describe explique pourquoi, kubectl logs montre ce que l'application a écrit, et kubectl top détecte les goulets de ressources. Ce guide vous apprend à les combiner efficacement.

Ce que vous allez apprendre

À la fin de ce guide, vous saurez :

• Lister et filtrer des ressources avec kubectl get (labels, colonnes personnalisées, formats de sortie)
• Inspecter l'état complet d'un pod avec kubectl describe et interpréter chaque section de sa sortie
• Extraire les logs d'un conteneur (en temps réel, multi-conteneurs, après un crash)
• Surveiller CPU et mémoire avec kubectl top et repérer les fuites de ressources
• Diagnostiquer les 6 incidents les plus courants grâce aux runbooks en fin de guide

Pipeline de diagnostic rapide

Retenez cette séquence pour tout incident :

get → describe → logs → top

1. kubectl get pods → repérer le pod en erreur (status ≠ Running)
2. kubectl describe pod <nom> → lire les Events pour comprendre la cause
3. kubectl logs <nom> → voir les erreurs applicatives
4. kubectl top pod <nom> → vérifier les ressources consommées

kubectl get, Lister les ressources

kubectl get est votre point d'entrée. Il affiche l'état de n'importe quelle ressource Kubernetes : pods, services, deployments, nodes, etc.

Syntaxe de base

Le type de ressource s'écrit indifféremment au singulier, au pluriel ou avec son abréviation (po, svc, deploy). Sans -n, la commande ne regarde que le namespace courant du contexte actif, ce qui explique la plupart des « mon pod a disparu ».

kubectl get <ressource> [nom] [-n namespace] [options]

Exemples courants :

# Tous les pods du namespace courant
kubectl get pods

# Tous les pods de tous les namespaces
kubectl get pods -A

# Un pod précis
kubectl get pod mon-pod

# Plusieurs types de ressources en une commande
kubectl get pods,services,deployments

Filtrer avec les labels

Les labels permettent de cibler précisément les ressources qui vous intéressent :

# Pods avec un label précis
kubectl get pods -l app=nginx

# Combiner plusieurs labels (ET logique)
kubectl get pods -l app=nginx,env=production

# Exclure un label
kubectl get pods -l 'app!=nginx'

# Label présent (quelle que soit la valeur)
kubectl get pods -l 'app'

Labels et sélecteurs

Les labels sont le mécanisme fondamental de sélection dans Kubernetes. Services, Deployments et NetworkPolicies les utilisent tous. Maîtriser -l ici vous servira partout. Consultez le guide dédié pour aller plus loin : kubectl label et annotate.

Formats de sortie

Par défaut, kubectl get affiche un tableau lisible. Vous pouvez changer le format selon vos besoins :

Option	Usage	Exemple
-o wide	Colonnes supplémentaires (IP, node)	kubectl get pods -o wide
-o yaml	Manifeste YAML complet	kubectl get pod mon-pod -o yaml
-o json	Format JSON (pour scripts)	kubectl get pods -o json
-o name	Noms uniquement	kubectl get pods -o name
-o jsonpath	Extraction ciblée	kubectl get pod mon-pod -o jsonpath='{.status.phase}'
-o custom-columns	Tableau personnalisé	Voir ci-dessous

Glissez pour voir

Colonnes personnalisées

Chaque colonne s'écrit EN-TÊTE:chemin, où le chemin est une expression JSONPath sans accolades. Un champ absent de la ressource n'échoue pas : il s'affiche <none>, comme l'IP du pod encore en Pending ci-dessous.

kubectl get pods -o custom-columns=\
NOM:.metadata.name,\
STATUS:.status.phase,\
IP:.status.podIP,\
NODE:.spec.nodeName

Résultat :

NOM              STATUS    IP           NODE
nginx-abc123     Running   10.244.1.5   worker-1
redis-def456     Pending   <none>       <none>

JSONPath, Extraire une valeur précise

JSONPath interroge le même objet que -o json, mais ne renvoie que la valeur demandée, sans retour à la ligne final : dans un terminal, l'invite se colle donc à la sortie. C'est le format à privilégier dès que la valeur alimente une variable de script.

# IP d'un pod
kubectl get pod mon-pod -o jsonpath='{.status.podIP}'

# Image utilisée par le premier conteneur
kubectl get pod mon-pod -o jsonpath='{.spec.containers[0].image}'

# Toutes les images de tous les pods
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

Surveiller les changements en temps réel

L'option --watch (-w) garde la commande ouverte et ajoute une ligne à chaque changement d'état, au lieu de rafraîchir le tableau. Vous conservez donc l'historique des transitions à l'écran, et vous coupez avec Ctrl+C.

kubectl get pods -w

C'est particulièrement utile après un déploiement ou pendant un incident pour voir les transitions d'état (Pending → ContainerCreating → Running ou → Error).

Résumé kubectl get

Ces sept variantes couvrent l'essentiel des situations. Gardez-les à portée : dans un incident, choisir la bonne option d'affichage en premier évite trois commandes inutiles ensuite.

Besoin	Commande
Vue rapide	kubectl get pods
Tous les namespaces	kubectl get pods -A
Avec IP et node	kubectl get pods -o wide
Filtrer par label	kubectl get pods -l app=nginx
Format script	kubectl get pods -o json
Valeur précise	kubectl get pod X -o jsonpath='{.status.phase}'
Temps réel	kubectl get pods -w

Glissez pour voir

kubectl describe, Inspecter une ressource

Quand kubectl get montre un pod en erreur, kubectl describe vous dit pourquoi. Il affiche la configuration complète et les événements récents.

Syntaxe

Contrairement à get, describe accepte un nom partiel : s'il ne trouve pas de correspondance exacte, il décrit toutes les ressources dont le nom commence par la chaîne fournie. Pratique avec les pods générés par un Deployment, dont le suffixe est aléatoire.

kubectl describe <ressource> <nom> [-n namespace]

# Décrire un pod
kubectl describe pod mon-pod

# Décrire un node
kubectl describe node worker-1

# Décrire un service
kubectl describe service mon-service

Lire la sortie de describe pod

La sortie est longue. Voici comment la lire efficacement, section par section :

kubectl describe pod mon-pod (sortie annotée)

Name:         mon-pod                          ← Identité
Namespace:    default
Node:         worker-1/192.168.1.10            ← Sur quel node il tourne
Status:       Running                          ← État global
IP:           10.244.1.5                        ← IP du pod

Containers:                                    ← Configuration des conteneurs
  nginx:
    Image:         nginx:1.25                   ← Image utilisée
    Port:          80/TCP
    State:         Running                      ← État du conteneur
      Started:     Mon, 01 Jan 2026 10:00:00
    Ready:         True
    Restart Count: 0                            ← 0 = stable, >0 = problème potentiel
    Limits:                                     ← Ressources maximales autorisées
      cpu:     500m
      memory:  128Mi
    Requests:                                   ← Ressources demandées au scheduler
      cpu:     250m
      memory:  64Mi

Conditions:                                    ← Check-list de santé
  Type              Status
  Initialized       True                        ← Init containers OK
  Ready             True                        ← Prêt à recevoir du trafic
  ContainersReady   True                        ← Tous les conteneurs sont prêts
  PodScheduled      True                        ← Planifié sur un node

Events:                                        ← SECTION LA PLUS IMPORTANTE
  Type     Reason     Age    Message
  ----     ------     ---    -------
  Normal   Scheduled  2m     Successfully assigned default/mon-pod to worker-1
  Normal   Pulled     2m     Container image "nginx:1.25" already present
  Normal   Created    2m     Created container nginx
  Normal   Started    2m     Started container nginx

La section Events est la clé

Allez toujours directement à la section Events en bas de la sortie. C'est là que Kubernetes vous dit ce qui s'est passé. Les événements Warning signalent un problème. Exemples courants :

• FailedScheduling → pas assez de ressources sur les nodes
• Failed + ErrImagePull → image introuvable ou accès refusé
• BackOff → le conteneur crash en boucle
• FailedMount → volume ou secret manquant

describe sur d'autres ressources

describe fonctionne sur toutes les ressources Kubernetes. En particulier :

Ressource	Ce que describe révèle
node	Capacité, allocations, conditions (MemoryPressure, DiskPressure), pods hébergés
service	Endpoints (pods ciblés), sélecteur de labels, ports
deployment	Stratégie de rollout, replicas, conditions, événements de scaling
pvc	StorageClass, taille, status (Bound/Pending), volume associé

Glissez pour voir

# Un node manque de ressources ?
kubectl describe node worker-1 | grep -A5 "Allocated resources"

# Un service ne route pas le trafic ?
kubectl describe service mon-service | grep -A5 "Endpoints"

kubectl logs, Lire les journaux

Une fois le pod identifié et son état compris, kubectl logs vous montre ce que l'application a écrit sur stdout et stderr. Tout ce que le processus écrit ailleurs, dans un fichier à l'intérieur du conteneur par exemple, reste invisible : c'est la première chose à vérifier quand la commande ne renvoie rien. Le kubelet ne conserve que l'instance courante du conteneur et la précédente ; au-delà de deux redémarrages, les traces les plus anciennes sont définitivement perdues.

Syntaxe et options essentielles

Toutes les options ci-dessous se cumulent, et les trois premières sont celles que vous taperez au quotidien.

kubectl logs <pod> [-n namespace] [options]

Option	Effet	Exemple
-f	Flux continu (comme tail -f)	kubectl logs -f mon-pod
--tail=N	N dernières lignes	kubectl logs --tail=50 mon-pod
--since=T	Logs depuis une durée	kubectl logs --since=5m mon-pod
--timestamps	Ajouter l'horodatage	kubectl logs --timestamps mon-pod
-c conteneur	Conteneur spécifique (multi-conteneur)	kubectl logs mon-pod -c sidecar
-p	Conteneur précédent (après crash)	kubectl logs -p mon-pod
--all-containers	Tous les conteneurs du pod	kubectl logs --all-containers mon-pod

Glissez pour voir

6 recettes de logs pour le diagnostic

Les options du tableau précédent se combinent, et c'est là qu'elles deviennent utiles. Voici les six associations qui reviennent le plus souvent en incident, de la plus courante à la plus spécifique.

1. Dernières erreurs d'un pod

Sans --tail, kubectl logs déverse l'intégralité du journal disponible : borner la sortie avant de filtrer évite d'attendre plusieurs milliers de lignes.

kubectl logs --tail=100 mon-pod | grep -i "error\|fatal\|panic\|exception"

2. Logs depuis le dernier redémarrage

--since raisonne en durée relative (10m, 2h) et --timestamps préfixe chaque ligne de l'heure vue par le nœud, indispensable pour recouper avec les Events de describe.

kubectl logs --since=10m mon-pod --timestamps

3. Logs du conteneur qui a crashé

L'option -p renvoie une erreur si le conteneur n'a jamais redémarré, faute d'instance terminée à relire : dans ce cas, le problème est ailleurs que dans un crash.

kubectl logs -p mon-pod

Logs après un crash

Quand un pod est en CrashLoopBackOff, le conteneur redémarre en boucle. Utilisez -p (previous) pour voir les logs de l'exécution précédente, celle qui a crashé. Sans -p, vous voyez les logs de l'instance actuelle qui n'a peut-être pas encore produit d'erreur.

4. Logs d'un conteneur spécifique (sidecar/init)

Dès qu'un pod héberge plusieurs conteneurs, kubectl logs refuse de choisir et réclame -c. Les conteneurs d'initialisation ne figurent pas dans .spec.containers : ils se lisent via .spec.initContainers.

# Lister les conteneurs d'un pod
kubectl get pod mon-pod -o jsonpath='{.spec.containers[*].name}'

# Voir les logs du sidecar
kubectl logs mon-pod -c istio-proxy

5. Logs de tous les pods d'un Deployment

Avec un sélecteur de labels, kubectl logs agrège les journaux de tous les pods correspondants ; le --tail devient alors obligatoire en pratique, car la valeur par défaut retombe à quelques lignes par pod.

kubectl logs -l app=nginx --all-containers --tail=50

6. Flux temps réel multi-pods

Pour suivre les logs de plusieurs pods simultanément, stern est l'outil idéal :

# Installer stern
brew install stern   # macOS
# ou
go install github.com/stern/stern@latest

# Suivre tous les pods nginx
stern nginx

# Avec filtre sur le contenu
stern nginx --include "error"

Interpréter les logs courants

Quelques messages reviennent inlassablement, quelle que soit la technologie de l'application. Les reconnaître fait gagner l'essentiel du temps de diagnostic, car chacun désigne une couche précise à inspecter : le service cible, les droits, la mémoire, le DNS ou le réseau.

Message dans les logs	Signification probable	Action
connection refused	Service cible inactif ou mauvais port	Vérifier le service cible avec describe svc
permission denied	RBAC ou filesystem	Vérifier le ServiceAccount et les montages
OOMKilled	Dépassement de limite mémoire	Augmenter resources.limits.memory
no such host	DNS ne résout pas	Vérifier le nom de service et CoreDNS
dial tcp: i/o timeout	Réseau bloqué	Vérifier NetworkPolicies et connectivité
certificate signed by unknown authority	TLS mal configuré	Vérifier les secrets TLS et la CA

Glissez pour voir

kubectl top, Surveiller les ressources

kubectl top affiche la consommation CPU et mémoire observée des nodes et des pods. Ces chiffres ne viennent pas de l'API Kubernetes classique mais de l'API de métriques, alimentée par un composant à installer séparément. Ce sont des mesures instantanées, échantillonnées à intervalle régulier : elles ne remplacent pas un historique Prometheus, mais elles suffisent à trancher entre « l'application consomme trop » et « le nœud est saturé ».

Prérequis : metrics-server

kubectl top nécessite que metrics-server soit installé dans le cluster. Sans lui, la commande retourne une erreur Metrics API not available.

Pour vérifier si metrics-server est présent :

kubectl get deployment metrics-server -n kube-system

Pour l'installer si manquant :

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Surveiller les nodes

Les pourcentages sont calculés par rapport à la capacité allouable du nœud, pas à sa capacité physique : le système d'exploitation et le kubelet sont déjà déduits.

kubectl top nodes

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
worker-1   350m         17%    2048Mi           52%
worker-2   820m         41%    3200Mi           82%
control    150m         7%     1024Mi           26%

Surveillez les nodes avec un usage CPU > 80 % ou mémoire > 85 %, ils sont proches de la saturation et peuvent causer des évictions de pods.

Surveiller les pods

Sans --containers, la ligne affichée est la somme de tous les conteneurs du pod, sidecars compris : un pod injecté par un maillage de services paraît donc plus gourmand que l'application seule.

# Tous les pods du namespace
kubectl top pods

# Un pod précis
kubectl top pod mon-pod

# Tous les namespaces, triés par CPU
kubectl top pods -A --sort-by=cpu

# Avec détail par conteneur
kubectl top pod mon-pod --containers

NAME              CPU(cores)   MEMORY(bytes)
nginx-abc123      5m           32Mi
redis-def456      120m         256Mi
api-server-xyz    450m         512Mi

Détecter une fuite mémoire

Pour repérer un conteneur dont la consommation mémoire croît sans cesse :

# Surveiller toutes les 10 secondes
watch -n 10 kubectl top pod mon-pod --containers

Si la colonne MEMORY augmente régulièrement sans retomber, c'est probablement une fuite mémoire. Comparez avec la limite définie :

kubectl get pod mon-pod -o jsonpath='{.spec.containers[0].resources.limits.memory}'

Quand la consommation atteint la limite, Kubernetes tue le conteneur avec le status OOMKilled.

Combiner les commandes, Workflow de diagnostic

Prises isolément, ces quatre commandes donnent des vues partielles ; enchaînées dans cet ordre, elles répondent successivement aux questions quoi, pourquoi, avec quel message et à quel coût. Suivez la séquence sans la raccourcir : sauter describe pour foncer sur les logs est l'erreur la plus fréquente, car un pod bloqué en Pending n'a tout simplement aucun log à produire.

1. Repérer le pod en erreur

   kubectl get pods -A | grep -v Running | grep -v Completed

   Cette commande affiche uniquement les pods dont l'état n'est pas normal.

2. Comprendre la cause

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

   Scrollez directement jusqu'à la section Events. Cherchez les lignes Warning.

3. Lire les logs applicatifs

   # Si le pod tourne encore
   kubectl logs <nom-du-pod> --tail=100
   
   # Si le pod a crashé
   kubectl logs -p <nom-du-pod>

4. Vérifier les ressources

   kubectl top pod <nom-du-pod>
   kubectl top node

   Comparez la consommation avec les limits définies dans le manifeste.

5. Investiguer plus en profondeur si nécessaire

   Si le problème persiste, passez à l'investigation avancée avec kubectl exec et debug.

Runbooks de diagnostic

Ces runbooks couvrent les 6 incidents les plus fréquents en production. Pour chaque incident : symptôme, diagnostic pas à pas, et résolution.

Runbook 1, Pod bloqué en Pending

Symptôme : kubectl get pods affiche Status = Pending depuis plus de 30 secondes.

Causes fréquentes : ressources insuffisantes sur les nodes, affinité/anti-affinité non satisfaite, PVC non lié.

1. Lire les événements du pod

   kubectl describe pod <nom> -n <namespace> | grep -A20 "Events:"

   Cherchez FailedScheduling dans les événements.

2. Identifier la cause dans le message

   Message Events	Cause	Solution
   Insufficient cpu	Pas assez de CPU disponible	Ajoutez un node ou réduisez les requests
   Insufficient memory	Pas assez de mémoire disponible	Ajoutez un node ou réduisez les requests
   node(s) had taint	Taint sans toleration	Ajoutez la toleration au pod ou retirez le taint
   node(s) didn't match Pod's node affinity	Affinité non satisfaite	Vérifiez nodeSelector ou nodeAffinity
   persistentvolumeclaim not found	PVC inexistant	Créez le PVC ou corrigez le nom

   Glissez pour voir

3. Vérifier la capacité des nodes

   kubectl describe nodes | grep -A5 "Allocated resources"

   Comparez Requests et Limits avec la capacité totale.

4. Vérifier les PVC si applicable

   kubectl get pvc -n <namespace>

   Un PVC en Pending signifie qu'aucun PV ne correspond (taille, storageClass, mode d'accès).

5. Résoudre

   # Option A : libérer des ressources
   kubectl top pods -A --sort-by=cpu | head -10
   
   # Option B : vérifier les taints
   kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
   
   # Option C : forcer le scheduling (si drain actif)
   kubectl uncordon <node>

Runbook 2, CrashLoopBackOff

Symptôme : kubectl get pods affiche Status = CrashLoopBackOff, le RESTARTS augmente.

Causes fréquentes : erreur applicative au démarrage, variable d'environnement manquante, point de montage incorrect, commande de démarrage invalide.

1. Voir les logs de l'exécution qui a crashé

   kubectl logs -p <nom> -n <namespace>

   C'est la commande la plus importante. Elle montre les logs du conteneur avant qu'il ne soit tué.

2. Examiner la configuration du pod

   kubectl describe pod <nom> -n <namespace>

   Vérifiez dans la sortie :

   • Last State : Terminated avec le Reason (Error, OOMKilled)
   • Exit Code : 1 = erreur applicative, 137 = OOMKilled, 139 = segfault
   • Restart Count : combien de fois le conteneur a redémarré

3. Vérifier les variables d'environnement et volumes

   # Variables d'environnement injectées
   kubectl get pod <nom> -o jsonpath='{.spec.containers[0].env[*].name}'
   
   # ConfigMaps référencés
   kubectl get pod <nom> -o jsonpath='{.spec.containers[0].envFrom[*].configMapRef.name}'
   
   # Secrets référencés
   kubectl get pod <nom> -o jsonpath='{.spec.containers[0].envFrom[*].secretRef.name}'

   Si un ConfigMap ou Secret n'existe pas, le pod crashe au démarrage.

4. Tester l'image manuellement

   kubectl run debug-test --image=<image> --rm -it -- sh

   Si l'image ne démarre pas non plus en mode interactif, le problème est dans l'image elle-même.

5. Résoudre selon l'exit code

   Exit Code	Signification	Action
   0	Succès (le process se termine normalement)	Vérifiez que la commande est un process long, pas un script one-shot
   1	Erreur applicative	Lisez les logs -p, corrigez le code ou la config
   126	Permission denied	Vérifiez les permissions de l'entrypoint
   127	Commande introuvable	Vérifiez command: dans le manifeste
   137	OOMKilled (SIGKILL)	Augmentez limits.memory
   139	Segfault (SIGSEGV)	Bug dans l'application, problème d'architecture (arm64/amd64)

   Glissez pour voir

Runbook 3, ImagePullBackOff / ErrImagePull

Symptôme : kubectl get pods affiche Status = ImagePullBackOff ou ErrImagePull.

Causes fréquentes : image inexistante, tag incorrect, registre privé sans credentials, limite de rate Docker Hub.

1. Identifier l'image en cause

   kubectl describe pod <nom> -n <namespace> | grep -i "image\|pull\|back"

2. Vérifier que l'image existe

   # Tester le pull depuis votre machine
   docker pull <image:tag>
   
   # Ou avec crane (sans Docker)
   crane manifest <image:tag>

3. Vérifier les credentials du registre

   # ImagePullSecrets configurés sur le pod ?
   kubectl get pod <nom> -o jsonpath='{.spec.imagePullSecrets[*].name}'
   
   # Le secret existe ?
   kubectl get secret <nom-secret> -n <namespace>
   
   # Contenu du secret (base64)
   kubectl get secret <nom-secret> -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d

4. Vérifier le ServiceAccount par défaut

   kubectl get serviceaccount default -n <namespace> -o yaml | grep -A5 imagePullSecrets

5. Résoudre

   # Créer un secret pour un registre privé
   kubectl create secret docker-registry regcred \
     --docker-server=registry.example.com \
     --docker-username=user \
     --docker-password=pass \
     -n <namespace>
   
   # Attacher au ServiceAccount par défaut
   kubectl patch serviceaccount default -n <namespace> \
     -p '{"imagePullSecrets": [{"name": "regcred"}]}'

Runbook 4, Service inaccessible (pas de réponse)

Symptôme : un curl ou une requête HTTP vers un Service Kubernetes ne répond pas ou retourne connection refused.

1. Vérifier que le Service a des endpoints

   kubectl get endpoints <service> -n <namespace>

   Si la colonne ENDPOINTS est vide (<none>), aucun pod ne correspond au sélecteur du Service.

2. Comparer le sélecteur du Service avec les labels des pods

   # Sélecteur du Service
   kubectl get svc <service> -n <namespace> -o jsonpath='{.spec.selector}'
   
   # Pods avec ces labels
   kubectl get pods -n <namespace> -l <key>=<value>

   Si aucun pod ne matche, il y a une incohérence entre les labels.

3. Vérifier que les pods ciblés sont Ready

   kubectl get pods -n <namespace> -l <key>=<value> -o wide

   Un pod qui n'est pas Ready est retiré des endpoints du Service.

4. Tester la connectivité depuis le cluster

   kubectl run test-net --image=busybox --rm -it -- wget -qO- http://<service>.<namespace>.svc.cluster.local:<port>

5. Vérifier les NetworkPolicies

   kubectl get networkpolicies -n <namespace>

   Une NetworkPolicy peut bloquer le trafic entrant vers les pods.

6. Résoudre

   • Labels incohérents → corriger les labels du Deployment ou le sélecteur du Service
   • Pod pas Ready → vérifier les readinessProbes (kubectl describe pod)
   • NetworkPolicy → ajuster les règles d'ingress

   Pour plus de détails sur les Services et le port-forward : kubectl expose, port-forward et proxy.

Runbook 5, OOMKilled (mémoire dépassée)

Symptôme : le pod redémarre avec Reason: OOMKilled (visible dans kubectl describe pod) ou Exit Code 137.

1. Confirmer l'OOMKilled

   kubectl describe pod <nom> -n <namespace> | grep -A3 "Last State"

   Vous devez voir Reason: OOMKilled.

2. Mesurer la consommation réelle

   kubectl top pod <nom> --containers

   Comparez avec la limite définie :

   kubectl get pod <nom> -o jsonpath='{range .spec.containers[*]}{.name}: {.resources.limits.memory}{"\n"}{end}'

3. Analyser l'historique de consommation

   Si vous avez Prometheus/Grafana, consultez la métrique container_memory_working_set_bytes. Sinon, surveillez avec watch :

   watch -n 5 kubectl top pod <nom> --containers

   Une croissance linéaire sans palier indique une fuite mémoire.

4. Résoudre

   Situation	Action
   Pic ponctuel au démarrage	Augmentez limits.memory de 20-30 %
   Croissance continue (fuite)	Corrigez l'application (profiling mémoire)
   Limite trop basse par rapport au besoin réel	Ajustez requests et limits

   Glissez pour voir

   # Modifier la limite mémoire (via le Deployment)
   kubectl set resources deployment <nom> \
     --limits=memory=512Mi \
     --requests=memory=256Mi

Runbook 6, Pod Evicted

Symptôme : kubectl get pods affiche Status = Evicted. Les pods évincés restent visibles mais ne tournent plus.

1. Identifier la raison de l'éviction

   kubectl describe pod <nom-evicted> -n <namespace> | grep -i "message\|reason\|status"

   Les raisons courantes : The node was low on resource: ephemeral-storage ou memory.

2. Vérifier la pression sur le node

   kubectl describe node <node> | grep -A5 "Conditions"

   Cherchez MemoryPressure, DiskPressure ou PIDPressure à True.

3. Identifier les consommateurs principaux

   # CPU et mémoire par pod sur ce node
   kubectl top pods -A --field-selector spec.nodeName=<node> --sort-by=memory
   
   # Espace disque éphémère (si applicable)
   kubectl get pods -A --field-selector spec.nodeName=<node> \
     -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'

4. Nettoyer les pods évincés

   Les pods évincés ne servent plus à rien, supprimez-les :

   kubectl get pods -A --field-selector status.phase=Failed | grep Evicted
   kubectl delete pods -A --field-selector status.phase=Failed

5. Prévenir les futures évictions

   • Ajoutez des requests et limits sur tous les pods
   • Configurez des PodDisruptionBudgets pour les workloads critiques
   • Surveillez l'espace disque avec kubectl top et des alertes Prometheus
   • Envisagez le drain contrôlé pour la maintenance

Tableau récapitulatif des erreurs

Ce tableau sert d'aiguillage : le statut affiché par kubectl get détermine la commande à lancer ensuite, et donc l'endroit où se trouve la réponse. Notez que quatre statuts sur huit se résolvent dans les Events de describe : quand vous hésitez, c'est là qu'il faut regarder en premier.

Status / Erreur	Commande de diagnostic	Cause la plus fréquente
Pending	kubectl describe pod → Events	Ressources insuffisantes ou taint
CrashLoopBackOff	kubectl logs -p	Erreur applicative au démarrage
ImagePullBackOff	kubectl describe pod → Events	Image inexistante ou credentials manquants
OOMKilled	kubectl describe pod → Last State	Limite mémoire trop basse
Evicted	kubectl describe pod + describe node	Node en pression (disque/mémoire)
CreateContainerError	kubectl describe pod → Events	ConfigMap/Secret manquant
RunContainerError	kubectl describe pod → Events	Commande de démarrage invalide
Service sans réponse	kubectl get endpoints	Pas de pods matchant le sélecteur

Glissez pour voir

À retenir

• kubectl get liste et filtre les ressources, commencez toujours par là pour repérer les anomalies.
• kubectl describe inspecte une ressource en détail, allez directement à la section Events.
• kubectl logs affiche les journaux applicatifs, utilisez -p pour voir les logs d'un conteneur crashé.
• kubectl top montre la consommation CPU/mémoire en temps réel, nécessite metrics-server.
• Le pipeline get → describe → logs → top couvre 90 % des diagnostics Kubernetes.
• Les 6 runbooks en fin de guide traitent les incidents les plus courants avec des commandes copier-coller.

Prochaines étapes

kubectl exec et debug Ouvrir un shell dans un conteneur ou un pod éphémère de debug.

Kubeconfig et contextes Importer un kubeconfig, basculer entre clusters et namespaces.

stern, logs multi-pods Suivre les logs de plusieurs pods simultanément avec filtres.

Cordon, drain et taints Gérer la maintenance des nodes et l'éviction contrôlée.

Cheat sheet kubectl Toutes les commandes kubectl essentielles sur une page.

×

📖 Voir la documentation →