
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) → nom → options (-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.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- 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 dans l'écosystème Kubernetes
Section intitulée « kubectl dans l'écosystème Kubernetes »kubectl est la CLI officielle de Kubernetes, mais d'autres outils le complètent :
| Outil | Spécialité | Quand l'utiliser |
|---|---|---|
kubectl | CLI officielle Kubernetes | Toutes les opérations cluster |
k9s | TUI interactif | Navigation et debug en temps réel |
helm | Gestionnaire de paquets | Installer des applications packagées |
kustomize | Overlays YAML | Personnaliser sans templates |
stern | Multi-pod log tailing | Suivre les logs de plusieurs Pods |
kubectx/kubens | Changement de contexte rapide | Naviguer entre clusters/namespaces |
Combinaisons fréquentes :
# kubectl + jq : extraire des données structuréeskubectl get pods -o json | jq '.items[].metadata.name'
# kubectl + stern : logs multi-pods en couleurstern -n production "web-.*"
# kubectl + kustomize : appliquer des overlayskubectl apply -k overlays/production/Comprendre kubectl en 2 min
Section intitulée « Comprendre kubectl en 2 min »🧠 Modèle mental — Comment fonctionne kubectl
kubectl = Verbe → Type de ressource → Nom → Options
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
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.
Syntaxe minimale
Section intitulée « Syntaxe minimale »kubectl [VERBE] [TYPE] [NOM] [OPTIONS]Les 4 parties d'une commande kubectl
Section intitulée « Les 4 parties d'une commande kubectl »| Étape | Question | Exemples | Obligatoire ? |
|---|---|---|---|
| Verbe | Quelle action ? | get, apply, delete, describe | Oui |
| Type | Sur quel type de ressource ? | pod, deployment, service, node | Oui (sauf commandes globales) |
| Nom | Quelle ressource précise ? | my-app, web-7d4f8b6c9 | Non (toutes si omis) |
| Options | Quels paramètres ? | -n staging, -o yaml, -l app=web | Non |
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).
Les verbes essentiels
Section intitulée « Les verbes essentiels »| Catégorie | Verbes | Usage |
|---|---|---|
| Lecture | get, describe, logs, top, explain | Inspecter le cluster |
| Écriture | apply, create, delete, edit, patch, replace | Modifier les ressources |
| Déploiement | rollout, scale, set, autoscale | Gérer les mises à jour |
| Debug | exec, debug, port-forward, cp, attach | Diagnostiquer |
| Nœuds | cordon, uncordon, drain, taint | Maintenance |
| CI/CD | diff, wait, --dry-run=client | Automatisation |
Options incontournables
Section intitulée « Options incontournables »| Option | Usage | Exemple |
|---|---|---|
-n namespace | Cibler un namespace | kubectl get pods -n production |
-A | Tous les namespaces | kubectl get pods -A |
-o yaml/json/wide | Changer le format de sortie | kubectl get svc web -o yaml |
-o jsonpath='{...}' | Extraire un champ | kubectl get pod x -o jsonpath='{.status.podIP}' |
-l key=value | Filtrer par labels | kubectl get pods -l app=nginx |
--dry-run=client | Simuler sans créer | kubectl create deploy x --image=y --dry-run=client -o yaml |
-w / --watch | Suivre en temps réel | kubectl get pods -w |
--field-selector | Filtrer sur un champ objet | --field-selector=status.phase=Running |
Le workflow type en production
Section intitulée « Le workflow type en production »# 1. Vérifier le contextekubectl config current-context
# 2. Prévisualiser les changementskubectl diff -f deployment.yaml
# 3. Appliquerkubectl apply -f deployment.yaml
# 4. Suivre le déploiementkubectl rollout status deployment/web
# 5. Vérifierkubectl get pods -l app=web -o wideErreurs typiques (et solutions)
Section intitulée « Erreurs typiques (et solutions) »| Erreur | Cause | Solution |
|---|---|---|
| Connection refused localhost:8080 | Kubeconfig absent ou cluster non démarré | Vérifier $KUBECONFIG et le cluster |
| "get all" ne montre pas les Secrets | all est un alias limité | Lister les types spécifiques |
| create échoue "already exists" | create est impératif | Utiliser apply (idempotent) |
| Résultats vides | Mauvais namespace | Ajouter -n NS ou chercher avec -A |
Les modèles de commandes courants
Section intitulée « Les modèles de commandes courants »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.
Lister les ressources d'un namespace
Section intitulée « Lister les ressources d'un namespace »Obtenir une vue d'ensemble d'un namespace — remplace le réflexe trompeur de get all.
# Formulekubectl get deploy,rs,po,svc,ing,cm,secret -n <namespace> [-o wide]
# Exemplekubectl get deploy,rs,po,svc,ing,cm,secret -n productionget all ne montre pas tout (ni ConfigMaps, ni Secrets, ni Ingress, ni PVC). Listez toujours les types explicitement.
Diagnostiquer avec describe
Section intitulée « Diagnostiquer avec describe »Comprendre pourquoi une ressource est en erreur, événements inclus.
# Formulekubectl describe <type> <nom> -n <namespace>
# Exemplekubectl describe pod my-app-7d4f8b6c9-x2k4m -n stagingdescribeaffiche les détails complets et la section Events, essentielle au diagnostic.
Logs multi-conteneurs
Section intitulée « Logs multi-conteneurs »Suivre les logs d'un Pod ou d'un ensemble de Pods.
# Formulekubectl logs [-f] [-c <conteneur>] [--previous] <pod> -n <ns>
# Exemplekubectl 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.
Générer un manifeste YAML
Section intitulée « Générer un manifeste YAML »Créer un squelette YAML sans toucher au cluster.
# Formulekubectl create <type> <nom> [options] --dry-run=client -o yaml
# Exemplekubectl 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.
Appliquer un manifeste (déclaratif)
Section intitulée « Appliquer un manifeste (déclaratif) »Créer ou mettre à jour une ressource de façon idempotente.
# Formulekubectl apply -f <fichier.yaml> -n <namespace>
# Exemplekubectl apply -f deployment.yaml -n production-f: fichier ou dossier YAML ;-R: récursif ;--prune: supprime les ressources non déclarées.
Extraire un champ avec JSONPath
Section intitulée « Extraire un champ avec JSONPath »Récupérer une valeur précise pour du scripting.
# Formulekubectl get <type> <nom> -o jsonpath='{.spec.field}'
# Exemplekubectl get pod nginx -o jsonpath='{.status.podIP}'jsonpathcible un champ dans la structure de l'objet.
Diff avant apply
Section intitulée « Diff avant apply »Voir ce qui va changer avant d'appliquer.
# Formulekubectl diff -f <fichier.yaml>
# Exemplekubectl diff -f deployment.yamlEn production, ne jamais appliquer sans avoir vérifié le diff au préalable.
Rollback d'un déploiement
Section intitulée « Rollback d'un déploiement »Revenir à la version précédente après un déploiement raté.
# Formulekubectl rollout undo deployment/<nom> [--to-revision=N]
# Exemplekubectl rollout undo deployment/web --to-revision=2--to-revision: numéro de révision cible (par défaut, la révision N-1).
Shell dans un conteneur
Section intitulée « Shell dans un conteneur »Inspecter un conteneur en cours d'exécution.
# Formulekubectl exec -it <pod> -n <ns> [-c <conteneur>] -- <commande>
# Exemplekubectl exec -it web-7d4f8b6c9-x2k4m -n production -- /bin/shPour les Pods distroless (sans shell), utilisez plutôt kubectl debug.
Maintenance d'un nœud
Section intitulée « Maintenance d'un nœud »Préparer un nœud pour une maintenance (upgrade, reboot).
# Formulekubectl cordon <noeud> && kubectl drain <noeud> --ignore-daemonsets --delete-emptydir-data
# Exemplekubectl 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.
Tunnel local vers un Pod ou Service
Section intitulée « Tunnel local vers un Pod ou Service »Accéder à un service sans Ingress ni LoadBalancer.
# Formulekubectl port-forward <type>/<nom> <local>:<distant> -n <ns>
# Exemplekubectl port-forward svc/grafana 3000:3000 -n monitoringlocal:distant: port local mappé sur le port du conteneur ou du service.
Attendre une condition (CI/CD)
Section intitulée « Attendre une condition (CI/CD) »Bloquer un pipeline jusqu'à ce qu'une ressource soit prête.
# Formulekubectl wait --for=condition=<cond> <type>/<nom> --timeout=<durée>
# Exemplekubectl wait --for=condition=Available deployment/web --timeout=120scondition:Ready,Available,Complete… ;--timeout: durée maximale.
Vérifier et changer de contexte
Section intitulée « Vérifier et changer de contexte »Éviter d'exécuter une commande sur le mauvais cluster.
# Formulekubectl config current-context && kubectl config use-context <ctx>
# Exemplekubectl config current-context && kubectl config use-context staging-clusterPour cibler ponctuellement un contexte sans changer le contexte global : kubectl --context=staging-cluster get pods.
Apply server-side (production)
Section intitulée « Apply server-side (production) »Appliquer des manifestes en résolvant les conflits de champs côté serveur.
# Formulekubectl apply -f <fichier> --server-side --force-conflicts
# Exemplekubectl apply -f k8s/ --server-side --force-conflicts--server-side: le serveur gère les field managers ;--force-conflicts: prend possession des champs en conflit.
Vérifier les droits RBAC
Section intitulée « Vérifier les droits RBAC »Savoir ce qu'un utilisateur ou un ServiceAccount peut faire.
# Formulekubectl auth can-i <verbe> <type> -n <namespace>
# Exemplekubectl auth can-i create deployments -n productionPour tout voir d'un coup : kubectl auth can-i --list -n production.
Déboguer avec les Events
Section intitulée « Déboguer avec les Events »Voir ce qui s'est passé récemment dans un namespace.
# Formulekubectl get events -n <ns> --sort-by=.metadata.creationTimestamp
# Exemplekubectl get events -n production --sort-by=.metadata.creationTimestamp | tail -20--field-selector reason=Failedfiltre directement sur les erreurs.
Redémarrer un Deployment proprement
Section intitulée « Redémarrer un Deployment proprement »Relancer tous les Pods sans changer le manifeste (rotation de secrets, refresh).
# Formulekubectl rollout restart deployment/<nom> -n <ns>
# Exemplekubectl rollout restart deployment/web -n production && kubectl rollout status deployment/web -n production --timeout=120sPréférez cela à la suppression des Pods un par un, qui peut provoquer du downtime.
Sortie personnalisée avec custom-columns
Section intitulée « Sortie personnalisée avec custom-columns »Extraire exactement les colonnes dont vous avez besoin.
# Formulekubectl get <type> -o custom-columns=COL1:.path,COL2:.path
# Exemplekubectl get pod -o custom-columns=NAME:.metadata.name,IP:.status.podIP,NODE:.spec.nodeNamecustom-columns: liste de pairesCOLONNE:jsonpathséparées par des virgules.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Ces erreurs reviennent constamment avec kubectl. Plusieurs peuvent provoquer un incident de production : les connaître est indispensable.
Mauvais contexte actif
Section intitulée « Mauvais contexte actif »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.
kubectl config current-context && kubectl delete deployment webget all ne montre pas tout
Section intitulée « get all ne montre pas tout »kubectl get allSymptôme : ConfigMaps, Secrets, Ingress, PVC… n'apparaissent pas — vous croyez le namespace vide.
Cause : all est un alias limité (pods, services, deployments, replicasets, jobs).
kubectl get deploy,rs,po,svc,ing,cm,secret -n NScreate échoue si la ressource existe
Section intitulée « create échoue si la ressource existe »kubectl create -f deploy.yamlSymptôme : Error: already exists quand le script est relancé.
Cause : create est impératif — il refuse de recréer une ressource existante.
kubectl apply -f deploy.yamlOubli du namespace
Section intitulée « Oubli du namespace »kubectl get podsSymptôme : aucun résultat, ou les résultats du mauvais namespace.
Cause : sans -n, kubectl utilise le namespace default.
kubectl get pods -n production--delete-local-data est déprécié
Section intitulée « --delete-local-data est déprécié »kubectl drain node1 --delete-local-dataSymptôme : avertissement --delete-local-data is deprecated.
Cause : l'option a été renommée dans les versions récentes.
kubectl drain node1 --ignore-daemonsets --delete-emptydir-dataOubli du -- dans exec
Section intitulée « Oubli du -- dans exec »kubectl exec -it pod-name /bin/shSymptôme : erreur ou comportement inattendu.
Cause : sans --, kubectl peut interpréter les arguments de la commande comme ses propres options.
kubectl exec -it pod-name -- /bin/shSélecteur de labels mal formé
Section intitulée « Sélecteur de labels mal formé »kubectl get pods -l app=web, env=prodSymptôme : erreur de parsing ou résultats incorrects.
Cause : les sélecteurs n'acceptent pas d'espace autour de la virgule.
kubectl get pods -l app=web,env=proddelete --force sans comprendre
Section intitulée « delete --force sans comprendre »kubectl delete pod stuck-pod --force --grace-period=0Symptô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.
Supprimer les Pods au lieu de rollout restart
Section intitulée « Supprimer les Pods au lieu de rollout restart »kubectl delete pod -l app=webSymptôme : downtime potentiel si tous les Pods sont supprimés en même temps.
Cause : delete supprime instantanément, sans rolling update.
kubectl rollout restart deployment/web -n productionConflit de field managers en server-side apply
Section intitulée « Conflit de field managers en server-side apply »kubectl apply -f deploy.yaml --server-sideSymptôme : Apply failed: conflict with "kubectl-client-side-apply"….
Cause : un autre outil (Helm, Argo, kubectl client-side) possède certains champs.
kubectl apply -f deploy.yaml --server-side --force-conflictsErreur Forbidden sans diagnostic
Section intitulée « Erreur Forbidden sans diagnostic »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.
kubectl auth can-i --list -n productionLogs sans --since sur un Pod ancien
Section intitulée « Logs sans --since sur un Pod ancien »kubectl logs pod/web-xxxSymptôme : défilement interminable de logs anciens, terminal bloqué.
Cause : par défaut, logs affiche tout l'historique disponible.
kubectl logs pod/web-xxx --since=10m --tail=200Travaux pratiques
Section intitulée « Travaux pratiques »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…).
Préparer le terrain
Section intitulée « Préparer le terrain »Le script suivant déploie une application web, une application qui crashe (pour le debug) et un ConfigMap :
# Créer le namespace de labkubectl create namespace kubectl-lab
# Déployer une application de testkubectl -n kubectl-lab create deployment web --image=nginx:1.25 --replicas=2kubectl -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 labelskubectl -n kubectl-lab label deployment web env=staging tier=frontend
# Créer un ConfigMapkubectl -n kubectl-lab create configmap app-config --from-literal=ENV=staging --from-literal=LOG_LEVEL=info
kubectl -n kubectl-lab get allPour tout nettoyer à la fin : kubectl delete namespace kubectl-lab.
Les 8 étapes du lab
Section intitulée « Les 8 étapes du lab »-
Lister les Pods du namespace —
kubectl get pods -n kubectl-lab. Vous voyez 2 podsweb-xxxet 1 podcrashloopenCrashLoopBackOff. -
Inspecter le Pod en erreur —
kubectl describe pod crashloop -n kubectl-lab. La section Events montreBack-off restarting failed container. Pour les logs :kubectl logs crashloop -n kubectl-lab --previous. -
Sortie en format large —
kubectl get pods -n kubectl-lab -o wide.-o wideajoute les colonnes IP et NODE. -
Générer un manifeste YAML —
kubectl create deployment redis --image=redis:7 --dry-run=client -o yaml. Le manifeste s'affiche sans rien créer dans le cluster. -
Scaler le déploiement —
kubectl scale deployment web --replicas=4 -n kubectl-lab. Vérifiez aveckubectl get pods -n kubectl-lab -l app=web. -
Mettre à jour l'image —
kubectl set image deployment/web nginx=nginx:1.26 -n kubectl-lab. Suivez le rollout :kubectl rollout status deployment/web -n kubectl-lab. -
Port-forward vers le service —
kubectl port-forward svc/web 8080:80 -n kubectl-lab. Un tunnel local est ouvert sur127.0.0.1:8080. -
Exécuter une commande dans un Pod —
kubectl exec -it deployment/web -n kubectl-lab -- /bin/sh. Vous obtenez un shell interactif dans le conteneur nginx.
Exercices progressifs
Section intitulée « Exercices progressifs »Ces exercices vont de l'inspection de base au pipeline CI/CD complet. Lisez l'énoncé, cherchez la commande, puis dépliez la solution.
Niveau fondations
Section intitulée « Niveau fondations »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
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
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
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
kubectl config current-context && kubectl config set-context --current --namespace=stagingcurrent-context montre le cluster actif ; set-context --current modifie le namespace par défaut sans changer de cluster.
Niveau composition
Section intitulée « Niveau composition »Exercice 5 — Diff avant apply. Comparez un fichier deploy.yaml modifié avec l'état actuel du cluster.
Indice : kubectl diff.
Voir la solution
kubectl diff -f deploy.yamldiff 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
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
kubectl auth can-i create deployments -n production && kubectl auth can-i --list -n productionauth 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
kubectl rollout restart deployment/api -n staging && kubectl rollout status deployment/api -n staging --timeout=120srollout 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
kubectl get pods -n prod -o custom-columns=NOM:.metadata.name,IP:.status.podIP,NOEUD:.spec.nodeNamecustom-columns définit exactement les colonnes voulues à partir de chemins JSONPath.
Niveau industrialisation
Section intitulée « Niveau industrialisation »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
kubectl debug -it api --image=busybox --target=api -- /bin/shdebug 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
kubectl cordon worker-02 && kubectl drain worker-02 --ignore-daemonsets --delete-emptydir-data --timeout=120scordon 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
kubectl diff -f deploy.yaml && kubectl apply -f deploy.yaml && kubectl wait --for=condition=Available deployment/web --timeout=120sdiff vérifie, apply applique, wait bloque jusqu'à ce que le deployment soit disponible.
Dépannage
Section intitulée « Dépannage »Quand une commande kubectl échoue, ces méthodes de diagnostic et ces erreurs fréquentes couvrent la grande majorité des cas.
Méthodes de diagnostic
Section intitulée « Méthodes de diagnostic »# Vérifier le contexte et le namespace actifskubectl config current-context
# Événements récents triés par datekubectl get events --sort-by=.metadata.creationTimestamp -n <namespace> | tail -20
# Repérer les Pods qui ne tournent paskubectl 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émoirekubectl top pods -n <namespace> --sort-by=memory && kubectl top nodes
# Vérifier les droits RBACkubectl auth can-i --list -n <namespace>Erreurs fréquentes
Section intitulée « Erreurs fréquentes »| Erreur | Cause probable | Solution |
|---|---|---|
The connection to the server localhost:8080 was refused | Kubeconfig absent, cluster non démarré, ou KUBECONFIG incorrect | Configurer 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 namespace | Chercher avec -A, ou préciser le bon -n <namespace> |
ErrImagePull / ImagePullBackOff | Image inexistante, registry privé sans secret, ou réseau | Corriger l'image/tag, ajouter imagePullSecrets, vérifier la connectivité |
CrashLoopBackOff | Application qui crashe, liveness probe trop stricte, ou OOMKilled | kubectl logs <pod> --previous, ajuster les probes ou les limites de ressources |
Aide-mémoire kubectl
Section intitulée « Aide-mémoire kubectl »À garder sous la main : la cheat sheet complète, regroupée par usage — contexte, syntaxe, commandes, filtres, déploiement, RBAC et debug.
Contexte et cluster
Section intitulée « Contexte et cluster »| Syntaxe | Signification | Exemple |
|---|---|---|
config get-contexts | Lister tous les contextes | kubectl config get-contexts |
config use-context CTX | Changer de cluster actif | kubectl config use-context staging |
config current-context | Savoir sur quel cluster on est | kubectl config current-context |
config set-context --current --namespace=NS | Namespace par défaut | kubectl config set-context --current --namespace=prod |
cluster-info | URL de l'API Server et services | kubectl cluster-info |
version --short | Version client et serveur | kubectl version --short |
Syntaxe et options globales
Section intitulée « Syntaxe et options globales »| Syntaxe | Signification | Exemple |
|---|---|---|
kubectl [verbe] [type] [nom] [options] | Format général | kubectl get pods -n production |
-n NS | Cibler un namespace | -n kube-system |
-A / --all-namespaces | Tous les namespaces | kubectl get pods -A |
-o yaml/json/wide/name | Format de sortie | -o wide |
-o jsonpath='{...}' | Extraire un champ | -o jsonpath='{.status.podIP}' |
-o custom-columns=COL:.path | Colonnes personnalisées | -o custom-columns=NAME:.metadata.name |
--context CTX | Cibler un contexte sans changer | kubectl --context=prod get pods |
--kubeconfig FILE | Config alternative | kubectl --kubeconfig=/tmp/admin.conf get nodes |
Commandes de lecture et d'écriture
Section intitulée « Commandes de lecture et d'écriture »| Syntaxe | Signification | Exemple |
|---|---|---|
get TYPE [-o wide] | Lister les ressources | kubectl get deploy,svc,pods -n prod |
describe TYPE NOM | Détails complets et events | kubectl describe pod my-app -n prod |
api-resources | Lister les types disponibles | kubectl api-resources --verbs=list |
explain TYPE.champ --recursive | Documentation intégrée | kubectl explain deploy.spec --recursive |
top pod -n NS | CPU/mémoire des Pods | kubectl top pod -n prod --sort-by=memory |
apply -f FICHIER | Créer/maj déclaratif (idempotent) | kubectl apply -f deploy.yaml |
create TYPE NOM | Créer impératif | kubectl create ns staging |
delete TYPE NOM | Supprimer une ressource | kubectl delete pod my-pod |
edit TYPE NOM | Éditer dans $EDITOR | kubectl edit deploy web -n prod |
patch TYPE NOM -p JSON | Modifier un champ ciblé | kubectl patch deploy web -p '{"spec":{"replicas":5}}' |
Logs et filtres
Section intitulée « Logs et filtres »| Syntaxe | Signification | Exemple |
|---|---|---|
logs POD -f | Suivre en temps réel | kubectl logs deploy/web -f -n prod |
logs --since=DURÉE | Filtrer par ancienneté | kubectl logs deploy/web --since=10m |
logs --tail=N | N dernières lignes | kubectl logs pod/web-xxx --tail=200 |
logs --previous | Logs du conteneur crashé | kubectl logs pod/web-xxx --previous |
-l key=value | Sélecteur de labels | -l app=nginx,env=prod |
--field-selector CHAMP=VAL | Filtre sur les champs de l'objet | --field-selector=status.phase=Running |
--sort-by=.CHEMIN | Trier la sortie | --sort-by=.metadata.creationTimestamp |
Déploiement
Section intitulée « Déploiement »| Syntaxe | Signification | Exemple |
|---|---|---|
scale --replicas=N | Changer le nombre de réplicas | kubectl scale deploy web --replicas=5 |
set image DEPLOY CONT=IMG | Mettre à jour une image | kubectl set image deploy/web nginx=nginx:1.26 |
rollout restart | Redémarrer sans changer le YAML | kubectl rollout restart deploy/web |
rollout status [--timeout] | Suivre un déploiement | kubectl rollout status deploy/web --timeout=120s |
rollout undo [--to-revision=N] | Rollback | kubectl rollout undo deploy/web --to-revision=3 |
rollout history | Historique des révisions | kubectl rollout history deploy/web |
autoscale --min --max --cpu | Créer un HPA | kubectl autoscale deploy web --min=2 --max=10 --cpu-percent=80 |
CI/CD, RBAC et accès
Section intitulée « CI/CD, RBAC et accès »| Syntaxe | Signification | Exemple |
|---|---|---|
--dry-run=client -o yaml | Générer du YAML sans créer | kubectl create deploy x --image=y --dry-run=client -o yaml |
diff -f FICHIER | Comparer avec le cluster | kubectl diff -f manifest.yaml |
apply --server-side --force-conflicts | Apply server-side (production) | kubectl apply -f k8s/ --server-side --force-conflicts |
wait --for=condition=COND | Attendre un état (CI/CD) | kubectl wait --for=condition=Ready pod/x --timeout=60s |
auth can-i VERBE TYPE -n NS | Vérifier un droit | kubectl auth can-i create pods -n production |
auth can-i --list -n NS | Tous mes droits dans un namespace | kubectl auth can-i --list -n production |
exec -it POD -- CMD | Shell dans un conteneur | kubectl exec -it pod/web -- /bin/sh |
debug -it POD --image=IMG | Conteneur éphémère (distroless) | kubectl debug -it pod/api --image=busybox --target=api |
port-forward TYPE/NOM LOCAL:DIST | Tunnel local | kubectl port-forward svc/web 8080:80 -n prod |
cordon / drain NOEUD | Maintenance d'un nœud | kubectl drain worker-01 --ignore-daemonsets --delete-emptydir-data |
Checklist de maîtrise
Section intitulée « Checklist de maîtrise »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,describeetlogs. - Je sais extraire des données avec
jsonpathetcustom-columns. - Je sais générer des manifestes avec
--dry-run=client. - Je sais utiliser
diffavantapply. - Je sais gérer les rollouts (status, undo, restart, history).
- Je sais déboguer avec
execetdebug. - Je sais préparer un nœud pour maintenance.
- Je sais automatiser avec
waitetdiffdans 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
toppour le debug day-2.