Aller au contenu
Conteneurs & Orchestration medium

Maîtriser kubectl : cheat sheet interactif

28 min de lecture

logo kubernetes

kubectl est l'outil CLI qui parle directement à l'API Server Kubernetes. Chaque commande suit le même schéma : verbe (get, apply, delete) → type (pod, deployment, service) → nomoptions (-n, -o, -l). Que ce soit pour inspecter un cluster, déployer une application ou diagnostiquer un incident, kubectl est votre point d'entrée unique.

  • Inspecter un cluster (get, describe, logs, top, events)
  • Créer et modifier des ressources (apply, create, patch, edit)
  • Déployer et rollback (rollout, scale, set image, autoscale)
  • Déboguer des Pods (exec, debug, port-forward, logs --previous)
  • Maintenir des nœuds (cordon, drain, taint, uncordon)
  • Automatiser dans un pipeline CI/CD (diff, wait, dry-run)

kubectl est la CLI officielle de Kubernetes, mais d'autres outils le complètent :

OutilSpécialitéQuand l'utiliser
kubectlCLI officielle KubernetesToutes les opérations cluster
k9sTUI interactifNavigation et debug en temps réel
helmGestionnaire de paquetsInstaller des applications packagées
kustomizeOverlays YAMLPersonnaliser sans templates
sternMulti-pod log tailingSuivre les logs de plusieurs Pods
kubectx/kubensChangement de contexte rapideNaviguer entre clusters/namespaces

Combinaisons fréquentes :

Fenêtre de terminal
# kubectl + jq : extraire des données structurées
kubectl get pods -o json | jq '.items[].metadata.name'
# kubectl + stern : logs multi-pods en couleur
stern -n production "web-.*"
# kubectl + kustomize : appliquer des overlays
kubectl apply -k overlays/production/

🧠 Modèle mental — Comment fonctionne kubectl

kubectl = Verbe → Type de ressource → Nom → Options

Modèle mental kubectl : Verbe (get, apply, delete) → Type (pod, deploy, svc) → Nom (my-app) → Options (-n, -o, -l)

Points clés

  • kubectl envoie des requêtes à l'API Server Kubernetes
  • Chaque commande suit le pattern : verbe + type de ressource + nom
  • Le contexte (~/.kube/config) définit QUEL cluster tu vises
  • Les options -n (namespace) et -o (output) sont partout
  • --dry-run=client -o yaml génère un manifeste sans rien créer
  • apply est déclaratif (idempotent), create est impératif (erreur si existe)

Règles d'or

1
Toujours vérifier le contexte avant d'agir kubectl config current-context — une commande sur le mauvais cluster peut être catastrophique.
2
Prévisualiser avant d'appliquer en prod kubectl diff -f manifest.yaml montre ce qui va changer, sans rien toucher.
3
Utiliser apply plutôt que create pour la reproductibilité apply est idempotent : relancer la même commande ne casse rien.

Vocabulaire essentiel

get
Lister les ressources (pods, svc, deploy...)
describe
Détails complets + événements d'une ressource
apply -f
Créer ou mettre à jour depuis un fichier YAML
delete
Supprimer une ressource
-n namespace
Cibler un namespace spécifique
-o yaml/json/wide
Changer le format de sortie
📚 Pour aller plus loin — 17 options avancées
explain
Documentation intégrée d'un champ YAML
api-resources
Lister tous les types de ressources disponibles
patch
Modifier un champ sans remplacer toute la ressource
rollout
Gérer les mises à jour progressives (status, undo, restart, history)
drain
Évacuer un nœud avant maintenance
taint/toleration
Contrôler quels Pods vont sur quels nœuds
port-forward
Tunnel local vers un Pod/Service
--dry-run=client
Simuler sans envoyer à l'API Server
jsonpath
Extraire un champ spécifique de la sortie
wait --for=condition
Attendre qu'une ressource atteigne un état
diff -f
Comparer un manifeste avec l'état du cluster
debug
Conteneur éphémère pour déboguer un Pod distroless
auth can-i
Vérifier les droits RBAC d'un utilisateur
--server-side
Apply côté serveur (résout les conflits de champs)
custom-columns
Colonnes personnalisées pour la sortie de get
rollout restart
Redémarrer les Pods d'un Deployment sans downtime
config get-contexts
Lister tous les contextes kubeconfig disponibles

kubectl transforme chaque commande en requête REST vers l'API Server. Le fichier ~/.kube/config (kubeconfig) définit quel cluster, quel utilisateur et quel namespace sont ciblés.

Fenêtre de terminal
kubectl [VERBE] [TYPE] [NOM] [OPTIONS]
ÉtapeQuestionExemplesObligatoire ?
VerbeQuelle action ?get, apply, delete, describeOui
TypeSur quel type de ressource ?pod, deployment, service, nodeOui (sauf commandes globales)
NomQuelle ressource précise ?my-app, web-7d4f8b6c9Non (toutes si omis)
OptionsQuels paramètres ?-n staging, -o yaml, -l app=webNon

Verbe — L'action à effectuer. get pour lister, describe pour les détails, apply pour créer/mettre à jour, delete pour supprimer.

Type — Le type de ressource Kubernetes. On peut utiliser les formes courtes : po (pods), svc (services), deploy (deployments), ns (namespaces).

Nom — Cible une ressource précise. Sans nom, la commande s'applique à toutes les ressources du type.

Options — Modifient le comportement : -n (namespace), -o (format), -l (sélecteur de labels), --watch (suivre en temps réel).

CatégorieVerbesUsage
Lectureget, describe, logs, top, explainInspecter le cluster
Écritureapply, create, delete, edit, patch, replaceModifier les ressources
Déploiementrollout, scale, set, autoscaleGérer les mises à jour
Debugexec, debug, port-forward, cp, attachDiagnostiquer
Nœudscordon, uncordon, drain, taintMaintenance
CI/CDdiff, wait, --dry-run=clientAutomatisation
OptionUsageExemple
-n namespaceCibler un namespacekubectl get pods -n production
-ATous les namespaceskubectl get pods -A
-o yaml/json/wideChanger le format de sortiekubectl get svc web -o yaml
-o jsonpath='{...}'Extraire un champkubectl get pod x -o jsonpath='{.status.podIP}'
-l key=valueFiltrer par labelskubectl get pods -l app=nginx
--dry-run=clientSimuler sans créerkubectl create deploy x --image=y --dry-run=client -o yaml
-w / --watchSuivre en temps réelkubectl get pods -w
--field-selectorFiltrer sur un champ objet--field-selector=status.phase=Running
Fenêtre de terminal
# 1. Vérifier le contexte
kubectl config current-context
# 2. Prévisualiser les changements
kubectl diff -f deployment.yaml
# 3. Appliquer
kubectl apply -f deployment.yaml
# 4. Suivre le déploiement
kubectl rollout status deployment/web
# 5. Vérifier
kubectl get pods -l app=web -o wide
ErreurCauseSolution
Connection refused localhost:8080Kubeconfig absent ou cluster non démarréVérifier $KUBECONFIG et le cluster
"get all" ne montre pas les Secretsall est un alias limitéLister les types spécifiques
create échoue "already exists"create est impératifUtiliser apply (idempotent)
Résultats videsMauvais namespaceAjouter -n NS ou chercher avec -A

Maintenant que vous comprenez la logique de kubectl, voici les patterns prêts à l'emploi pour les opérations les plus fréquentes. Chacun associe une formule générique et un exemple concret à adapter.

Obtenir une vue d'ensemble d'un namespace — remplace le réflexe trompeur de get all.

Fenêtre de terminal
# Formule
kubectl get deploy,rs,po,svc,ing,cm,secret -n <namespace> [-o wide]
# Exemple
kubectl get deploy,rs,po,svc,ing,cm,secret -n production

get all ne montre pas tout (ni ConfigMaps, ni Secrets, ni Ingress, ni PVC). Listez toujours les types explicitement.

Comprendre pourquoi une ressource est en erreur, événements inclus.

Fenêtre de terminal
# Formule
kubectl describe <type> <nom> -n <namespace>
# Exemple
kubectl describe pod my-app-7d4f8b6c9-x2k4m -n staging
  • describe affiche les détails complets et la section Events, essentielle au diagnostic.

Suivre les logs d'un Pod ou d'un ensemble de Pods.

Fenêtre de terminal
# Formule
kubectl logs [-f] [-c <conteneur>] [--previous] <pod> -n <ns>
# Exemple
kubectl logs -f -l app=nginx -n production --all-containers
  • -f : suivre en temps réel ; --previous : logs du conteneur précédent (après un crash) ; -l : tous les Pods correspondant au label.

Créer un squelette YAML sans toucher au cluster.

Fenêtre de terminal
# Formule
kubectl create <type> <nom> [options] --dry-run=client -o yaml
# Exemple
kubectl create deployment nginx --image=nginx:1.26 --replicas=3 --dry-run=client -o yaml > deploy.yaml
  • --dry-run=client : simule côté client, sans appel à l'API.

Créer ou mettre à jour une ressource de façon idempotente.

Fenêtre de terminal
# Formule
kubectl apply -f <fichier.yaml> -n <namespace>
# Exemple
kubectl apply -f deployment.yaml -n production
  • -f : fichier ou dossier YAML ; -R : récursif ; --prune : supprime les ressources non déclarées.

Récupérer une valeur précise pour du scripting.

Fenêtre de terminal
# Formule
kubectl get <type> <nom> -o jsonpath='{.spec.field}'
# Exemple
kubectl get pod nginx -o jsonpath='{.status.podIP}'
  • jsonpath cible un champ dans la structure de l'objet.

Voir ce qui va changer avant d'appliquer.

Fenêtre de terminal
# Formule
kubectl diff -f <fichier.yaml>
# Exemple
kubectl diff -f deployment.yaml

En production, ne jamais appliquer sans avoir vérifié le diff au préalable.

Revenir à la version précédente après un déploiement raté.

Fenêtre de terminal
# Formule
kubectl rollout undo deployment/<nom> [--to-revision=N]
# Exemple
kubectl rollout undo deployment/web --to-revision=2
  • --to-revision : numéro de révision cible (par défaut, la révision N-1).

Inspecter un conteneur en cours d'exécution.

Fenêtre de terminal
# Formule
kubectl exec -it <pod> -n <ns> [-c <conteneur>] -- <commande>
# Exemple
kubectl exec -it web-7d4f8b6c9-x2k4m -n production -- /bin/sh

Pour les Pods distroless (sans shell), utilisez plutôt kubectl debug.

Préparer un nœud pour une maintenance (upgrade, reboot).

Fenêtre de terminal
# Formule
kubectl cordon <noeud> && kubectl drain <noeud> --ignore-daemonsets --delete-emptydir-data
# Exemple
kubectl cordon worker-01 && kubectl drain worker-01 --ignore-daemonsets --delete-emptydir-data

--delete-emptydir-data est destructif : il supprime les volumes emptyDir. Vérifiez qu'aucun Pod n'y stocke de données critiques avant de drainer.

Accéder à un service sans Ingress ni LoadBalancer.

Fenêtre de terminal
# Formule
kubectl port-forward <type>/<nom> <local>:<distant> -n <ns>
# Exemple
kubectl port-forward svc/grafana 3000:3000 -n monitoring
  • local:distant : port local mappé sur le port du conteneur ou du service.

Bloquer un pipeline jusqu'à ce qu'une ressource soit prête.

Fenêtre de terminal
# Formule
kubectl wait --for=condition=<cond> <type>/<nom> --timeout=<durée>
# Exemple
kubectl wait --for=condition=Available deployment/web --timeout=120s
  • condition : Ready, Available, Complete… ; --timeout : durée maximale.

Éviter d'exécuter une commande sur le mauvais cluster.

Fenêtre de terminal
# Formule
kubectl config current-context && kubectl config use-context <ctx>
# Exemple
kubectl config current-context && kubectl config use-context staging-cluster

Pour cibler ponctuellement un contexte sans changer le contexte global : kubectl --context=staging-cluster get pods.

Appliquer des manifestes en résolvant les conflits de champs côté serveur.

Fenêtre de terminal
# Formule
kubectl apply -f <fichier> --server-side --force-conflicts
# Exemple
kubectl apply -f k8s/ --server-side --force-conflicts
  • --server-side : le serveur gère les field managers ; --force-conflicts : prend possession des champs en conflit.

Savoir ce qu'un utilisateur ou un ServiceAccount peut faire.

Fenêtre de terminal
# Formule
kubectl auth can-i <verbe> <type> -n <namespace>
# Exemple
kubectl auth can-i create deployments -n production

Pour tout voir d'un coup : kubectl auth can-i --list -n production.

Voir ce qui s'est passé récemment dans un namespace.

Fenêtre de terminal
# Formule
kubectl get events -n <ns> --sort-by=.metadata.creationTimestamp
# Exemple
kubectl get events -n production --sort-by=.metadata.creationTimestamp | tail -20
  • --field-selector reason=Failed filtre directement sur les erreurs.

Relancer tous les Pods sans changer le manifeste (rotation de secrets, refresh).

Fenêtre de terminal
# Formule
kubectl rollout restart deployment/<nom> -n <ns>
# Exemple
kubectl rollout restart deployment/web -n production && kubectl rollout status deployment/web -n production --timeout=120s

Préférez cela à la suppression des Pods un par un, qui peut provoquer du downtime.

Extraire exactement les colonnes dont vous avez besoin.

Fenêtre de terminal
# Formule
kubectl get <type> -o custom-columns=COL1:.path,COL2:.path
# Exemple
kubectl get pod -o custom-columns=NAME:.metadata.name,IP:.status.podIP,NODE:.spec.nodeName
  • custom-columns : liste de paires COLONNE:jsonpath séparées par des virgules.

Ces erreurs reviennent constamment avec kubectl. Plusieurs peuvent provoquer un incident de production : les connaître est indispensable.

Vous lancez kubectl delete deployment web en pensant être sur le cluster de dev.

Symptôme : la ressource est supprimée en production.

Cause : le contexte courant pointe sur le cluster de production.

Fenêtre de terminal
kubectl config current-context && kubectl delete deployment web
Fenêtre de terminal
kubectl get all

Symptôme : ConfigMaps, Secrets, Ingress, PVC… n'apparaissent pas — vous croyez le namespace vide.

Cause : all est un alias limité (pods, services, deployments, replicasets, jobs).

Fenêtre de terminal
kubectl get deploy,rs,po,svc,ing,cm,secret -n NS
Fenêtre de terminal
kubectl create -f deploy.yaml

Symptôme : Error: already exists quand le script est relancé.

Cause : create est impératif — il refuse de recréer une ressource existante.

Fenêtre de terminal
kubectl apply -f deploy.yaml
Fenêtre de terminal
kubectl get pods

Symptôme : aucun résultat, ou les résultats du mauvais namespace.

Cause : sans -n, kubectl utilise le namespace default.

Fenêtre de terminal
kubectl get pods -n production
Fenêtre de terminal
kubectl drain node1 --delete-local-data

Symptôme : avertissement --delete-local-data is deprecated.

Cause : l'option a été renommée dans les versions récentes.

Fenêtre de terminal
kubectl drain node1 --ignore-daemonsets --delete-emptydir-data
Fenêtre de terminal
kubectl exec -it pod-name /bin/sh

Symptôme : erreur ou comportement inattendu.

Cause : sans --, kubectl peut interpréter les arguments de la commande comme ses propres options.

Fenêtre de terminal
kubectl exec -it pod-name -- /bin/sh
Fenêtre de terminal
kubectl get pods -l app=web, env=prod

Symptôme : erreur de parsing ou résultats incorrects.

Cause : les sélecteurs n'acceptent pas d'espace autour de la virgule.

Fenêtre de terminal
kubectl get pods -l app=web,env=prod
Fenêtre de terminal
kubectl delete pod stuck-pod --force --grace-period=0

Symptôme : le Pod disparaît de l'API, mais le conteneur tourne peut-être encore sur le nœud.

Cause : --force supprime l'objet API immédiatement, sans attendre l'arrêt réel du conteneur. Réservez-le aux nœuds définitivement morts ; sinon, diagnostiquez d'abord.

Fenêtre de terminal
kubectl delete pod -l app=web

Symptôme : downtime potentiel si tous les Pods sont supprimés en même temps.

Cause : delete supprime instantanément, sans rolling update.

Fenêtre de terminal
kubectl rollout restart deployment/web -n production
Fenêtre de terminal
kubectl apply -f deploy.yaml --server-side

Symptôme : Apply failed: conflict with "kubectl-client-side-apply"….

Cause : un autre outil (Helm, Argo, kubectl client-side) possède certains champs.

Fenêtre de terminal
kubectl apply -f deploy.yaml --server-side --force-conflicts

Vous recevez Forbidden sans savoir quel droit manque.

Symptôme : Error from server (Forbidden): pods is forbidden.

Cause : le ServiceAccount n'a pas le Role ou ClusterRole nécessaire.

Fenêtre de terminal
kubectl auth can-i --list -n production
Fenêtre de terminal
kubectl logs pod/web-xxx

Symptôme : défilement interminable de logs anciens, terminal bloqué.

Cause : par défaut, logs affiche tout l'historique disponible.

Fenêtre de terminal
kubectl logs pod/web-xxx --since=10m --tail=200

Ce lab vous fait manipuler kubectl sur une application de test déployée dans un namespace dédié. Comptez 20 minutes. Il suppose un cluster Kubernetes accessible (kind, minikube, k3s, k3d…).

Le script suivant déploie une application web, une application qui crashe (pour le debug) et un ConfigMap :

Fenêtre de terminal
# Créer le namespace de lab
kubectl create namespace kubectl-lab
# Déployer une application de test
kubectl -n kubectl-lab create deployment web --image=nginx:1.25 --replicas=2
kubectl -n kubectl-lab expose deployment web --port=80 --target-port=80
# Déployer une app qui crashe (pour le debug)
kubectl -n kubectl-lab run crashloop --image=busybox -- /bin/sh -c "exit 1"
# Ajouter des labels
kubectl -n kubectl-lab label deployment web env=staging tier=frontend
# Créer un ConfigMap
kubectl -n kubectl-lab create configmap app-config --from-literal=ENV=staging --from-literal=LOG_LEVEL=info
kubectl -n kubectl-lab get all

Pour tout nettoyer à la fin : kubectl delete namespace kubectl-lab.

  1. Lister les Pods du namespacekubectl get pods -n kubectl-lab. Vous voyez 2 pods web-xxx et 1 pod crashloop en CrashLoopBackOff.

  2. Inspecter le Pod en erreurkubectl describe pod crashloop -n kubectl-lab. La section Events montre Back-off restarting failed container. Pour les logs : kubectl logs crashloop -n kubectl-lab --previous.

  3. Sortie en format largekubectl get pods -n kubectl-lab -o wide. -o wide ajoute les colonnes IP et NODE.

  4. Générer un manifeste YAMLkubectl create deployment redis --image=redis:7 --dry-run=client -o yaml. Le manifeste s'affiche sans rien créer dans le cluster.

  5. Scaler le déploiementkubectl scale deployment web --replicas=4 -n kubectl-lab. Vérifiez avec kubectl get pods -n kubectl-lab -l app=web.

  6. Mettre à jour l'imagekubectl set image deployment/web nginx=nginx:1.26 -n kubectl-lab. Suivez le rollout : kubectl rollout status deployment/web -n kubectl-lab.

  7. Port-forward vers le servicekubectl port-forward svc/web 8080:80 -n kubectl-lab. Un tunnel local est ouvert sur 127.0.0.1:8080.

  8. Exécuter une commande dans un Podkubectl exec -it deployment/web -n kubectl-lab -- /bin/sh. Vous obtenez un shell interactif dans le conteneur nginx.

Ces exercices vont de l'inspection de base au pipeline CI/CD complet. Lisez l'énoncé, cherchez la commande, puis dépliez la solution.

Exercice 1 — Lister les Pods en erreur. Affichez tous les Pods du cluster qui ne sont pas en état Running ou Succeeded.

Indice : --field-selector sur status.phase.

Voir la solution
Fenêtre de terminal
kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded

--field-selector filtre côté serveur ; -A cherche dans tous les namespaces.

Exercice 2 — Trouver l'IP d'un Pod. Récupérez uniquement l'adresse IP du Pod nginx dans le namespace default.

Indice : -o jsonpath avec .status.podIP.

Voir la solution
Fenêtre de terminal
kubectl get pod nginx -o jsonpath='{.status.podIP}'

jsonpath extrait un champ précis de la structure JSON de l'objet.

Exercice 3 — Générer un manifeste Service. Générez un manifeste YAML pour exposer le deployment api sur le port 8080, sans le créer.

Indice : --dry-run=client -o yaml.

Voir la solution
Fenêtre de terminal
kubectl expose deployment api --port=8080 --dry-run=client -o yaml

--dry-run=client simule, -o yaml formate. Redirigez vers un fichier avec > svc.yaml.

Exercice 4 — Vérifier le contexte et changer de namespace. Affichez le contexte courant, puis changez le namespace par défaut vers staging.

Indice : config current-context puis config set-context.

Voir la solution
Fenêtre de terminal
kubectl config current-context && kubectl config set-context --current --namespace=staging

current-context montre le cluster actif ; set-context --current modifie le namespace par défaut sans changer de cluster.

Exercice 5 — Diff avant apply. Comparez un fichier deploy.yaml modifié avec l'état actuel du cluster.

Indice : kubectl diff.

Voir la solution
Fenêtre de terminal
kubectl diff -f deploy.yaml

diff compare le manifeste local avec l'état du cluster. Code de sortie 0 = pas de différence, 1 = changements.

Exercice 6 — Rollback d'un déploiement. Revenez à la révision 3 du deployment web et vérifiez que le rollback est terminé.

Indice : rollout undo puis rollout status.

Voir la solution
Fenêtre de terminal
kubectl rollout undo deployment/web --to-revision=3 && kubectl rollout status deployment/web

--to-revision=N cible une version précise. Sans cette option, on revient à la révision N-1.

Exercice 7 — Vérifier les droits RBAC. Vérifiez si vous pouvez créer des Deployments dans production, puis listez tous vos droits dans ce namespace.

Indice : auth can-i et --list.

Voir la solution
Fenêtre de terminal
kubectl auth can-i create deployments -n production && kubectl auth can-i --list -n production

auth can-i vérifie un droit précis ; --list donne la vue complète.

Exercice 8 — Rollout restart et suivi. Redémarrez le Deployment api dans staging et attendez la fin du rolling restart.

Indice : rollout restart puis rollout status.

Voir la solution
Fenêtre de terminal
kubectl rollout restart deployment/api -n staging && kubectl rollout status deployment/api -n staging --timeout=120s

rollout restart relance les Pods progressivement ; rollout status bloque jusqu'à la fin.

Exercice 9 — Custom-columns pour un rapport. Affichez les Pods du namespace prod avec 3 colonnes : NOM, IP, NŒUD.

Indice : -o custom-columns avec .metadata.name, .status.podIP, .spec.nodeName.

Voir la solution
Fenêtre de terminal
kubectl get pods -n prod -o custom-columns=NOM:.metadata.name,IP:.status.podIP,NOEUD:.spec.nodeName

custom-columns définit exactement les colonnes voulues à partir de chemins JSONPath.

Exercice 10 — Debug d'un Pod distroless. Attachez un conteneur éphémère busybox à un Pod api qui n'a pas de shell.

Indice : kubectl debug avec --image.

Voir la solution
Fenêtre de terminal
kubectl debug -it api --image=busybox --target=api -- /bin/sh

debug crée un conteneur éphémère dans le Pod ; --target partage le namespace PID.

Exercice 11 — Drain d'un nœud pour maintenance. Préparez le nœud worker-02 pour un reboot : empêchez le scheduling et évacuez les Pods.

Indice : cordon puis drain avec les options DaemonSets et emptyDir.

Voir la solution
Fenêtre de terminal
kubectl cordon worker-02 && kubectl drain worker-02 --ignore-daemonsets --delete-emptydir-data --timeout=120s

cordon empêche les nouveaux Pods ; drain évacue les existants ; --timeout évite de bloquer indéfiniment.

Exercice 12 — Pipeline CI/CD complet. Écrivez une séquence qui compare le manifeste, l'applique, puis attend que le deployment soit prêt.

Indice : diff, apply, puis wait --for=condition.

Voir la solution
Fenêtre de terminal
kubectl diff -f deploy.yaml && kubectl apply -f deploy.yaml && kubectl wait --for=condition=Available deployment/web --timeout=120s

diff vérifie, apply applique, wait bloque jusqu'à ce que le deployment soit disponible.

Quand une commande kubectl échoue, ces méthodes de diagnostic et ces erreurs fréquentes couvrent la grande majorité des cas.

Fenêtre de terminal
# Vérifier le contexte et le namespace actifs
kubectl config current-context
# Événements récents triés par date
kubectl get events --sort-by=.metadata.creationTimestamp -n <namespace> | tail -20
# Repérer les Pods qui ne tournent pas
kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded
# Logs du conteneur précédent (après un crash)
kubectl logs <pod> --previous -c <conteneur>
# Consommation CPU/mémoire
kubectl top pods -n <namespace> --sort-by=memory && kubectl top nodes
# Vérifier les droits RBAC
kubectl auth can-i --list -n <namespace>
ErreurCause probableSolution
The connection to the server localhost:8080 was refusedKubeconfig absent, cluster non démarré, ou KUBECONFIG incorrectConfigurer KUBECONFIG ou démarrer le cluster, vérifier avec kubectl cluster-info
Error from server (Forbidden)Droits RBAC manquants, mauvais namespace, ou token expiréVérifier avec kubectl auth can-i --list, demander les droits à l'admin
Error from server (NotFound)Ressource inexistante ou mauvais namespaceChercher avec -A, ou préciser le bon -n <namespace>
ErrImagePull / ImagePullBackOffImage inexistante, registry privé sans secret, ou réseauCorriger l'image/tag, ajouter imagePullSecrets, vérifier la connectivité
CrashLoopBackOffApplication qui crashe, liveness probe trop stricte, ou OOMKilledkubectl logs <pod> --previous, ajuster les probes ou les limites de ressources

À garder sous la main : la cheat sheet complète, regroupée par usage — contexte, syntaxe, commandes, filtres, déploiement, RBAC et debug.

SyntaxeSignificationExemple
config get-contextsLister tous les contexteskubectl config get-contexts
config use-context CTXChanger de cluster actifkubectl config use-context staging
config current-contextSavoir sur quel cluster on estkubectl config current-context
config set-context --current --namespace=NSNamespace par défautkubectl config set-context --current --namespace=prod
cluster-infoURL de l'API Server et serviceskubectl cluster-info
version --shortVersion client et serveurkubectl version --short
SyntaxeSignificationExemple
kubectl [verbe] [type] [nom] [options]Format généralkubectl get pods -n production
-n NSCibler un namespace-n kube-system
-A / --all-namespacesTous les namespaceskubectl get pods -A
-o yaml/json/wide/nameFormat de sortie-o wide
-o jsonpath='{...}'Extraire un champ-o jsonpath='{.status.podIP}'
-o custom-columns=COL:.pathColonnes personnalisées-o custom-columns=NAME:.metadata.name
--context CTXCibler un contexte sans changerkubectl --context=prod get pods
--kubeconfig FILEConfig alternativekubectl --kubeconfig=/tmp/admin.conf get nodes
SyntaxeSignificationExemple
get TYPE [-o wide]Lister les ressourceskubectl get deploy,svc,pods -n prod
describe TYPE NOMDétails complets et eventskubectl describe pod my-app -n prod
api-resourcesLister les types disponibleskubectl api-resources --verbs=list
explain TYPE.champ --recursiveDocumentation intégréekubectl explain deploy.spec --recursive
top pod -n NSCPU/mémoire des Podskubectl top pod -n prod --sort-by=memory
apply -f FICHIERCréer/maj déclaratif (idempotent)kubectl apply -f deploy.yaml
create TYPE NOMCréer impératifkubectl create ns staging
delete TYPE NOMSupprimer une ressourcekubectl delete pod my-pod
edit TYPE NOMÉditer dans $EDITORkubectl edit deploy web -n prod
patch TYPE NOM -p JSONModifier un champ ciblékubectl patch deploy web -p '{"spec":{"replicas":5}}'
SyntaxeSignificationExemple
logs POD -fSuivre en temps réelkubectl logs deploy/web -f -n prod
logs --since=DURÉEFiltrer par anciennetékubectl logs deploy/web --since=10m
logs --tail=NN dernières ligneskubectl logs pod/web-xxx --tail=200
logs --previousLogs du conteneur crashékubectl logs pod/web-xxx --previous
-l key=valueSélecteur de labels-l app=nginx,env=prod
--field-selector CHAMP=VALFiltre sur les champs de l'objet--field-selector=status.phase=Running
--sort-by=.CHEMINTrier la sortie--sort-by=.metadata.creationTimestamp
SyntaxeSignificationExemple
scale --replicas=NChanger le nombre de réplicaskubectl scale deploy web --replicas=5
set image DEPLOY CONT=IMGMettre à jour une imagekubectl set image deploy/web nginx=nginx:1.26
rollout restartRedémarrer sans changer le YAMLkubectl rollout restart deploy/web
rollout status [--timeout]Suivre un déploiementkubectl rollout status deploy/web --timeout=120s
rollout undo [--to-revision=N]Rollbackkubectl rollout undo deploy/web --to-revision=3
rollout historyHistorique des révisionskubectl rollout history deploy/web
autoscale --min --max --cpuCréer un HPAkubectl autoscale deploy web --min=2 --max=10 --cpu-percent=80
SyntaxeSignificationExemple
--dry-run=client -o yamlGénérer du YAML sans créerkubectl create deploy x --image=y --dry-run=client -o yaml
diff -f FICHIERComparer avec le clusterkubectl diff -f manifest.yaml
apply --server-side --force-conflictsApply server-side (production)kubectl apply -f k8s/ --server-side --force-conflicts
wait --for=condition=CONDAttendre un état (CI/CD)kubectl wait --for=condition=Ready pod/x --timeout=60s
auth can-i VERBE TYPE -n NSVérifier un droitkubectl auth can-i create pods -n production
auth can-i --list -n NSTous mes droits dans un namespacekubectl auth can-i --list -n production
exec -it POD -- CMDShell dans un conteneurkubectl exec -it pod/web -- /bin/sh
debug -it POD --image=IMGConteneur éphémère (distroless)kubectl debug -it pod/api --image=busybox --target=api
port-forward TYPE/NOM LOCAL:DISTTunnel localkubectl port-forward svc/web 8080:80 -n prod
cordon / drain NOEUDMaintenance d'un nœudkubectl drain worker-01 --ignore-daemonsets --delete-emptydir-data

Vous maîtrisez kubectl quand vous pouvez cocher chacun de ces points sans hésiter :

  • Je sais naviguer entre contextes et namespaces.
  • Je sais inspecter avec get, describe et logs.
  • Je sais extraire des données avec jsonpath et custom-columns.
  • Je sais générer des manifestes avec --dry-run=client.
  • Je sais utiliser diff avant apply.
  • Je sais gérer les rollouts (status, undo, restart, history).
  • Je sais déboguer avec exec et debug.
  • Je sais préparer un nœud pour maintenance.
  • Je sais automatiser avec wait et diff dans un pipeline.
  • Je sais diagnostiquer les erreurs courantes (ImagePull, CrashLoop, Forbidden).
  • Je sais vérifier les droits RBAC avec auth can-i.
  • Je sais utiliser les Events et top pour le debug day-2.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn