Cheatsheet CKAD : commandes kubectl essentielles

Cheatsheet centrée sur la vitesse d'exécution. Examen 100% pratique avec plusieurs tâches à résoudre rapidement en ligne de commande. Cette page couvre les commandes les plus rentables, organisées par domaine CKAD.

Infos examen CKAD

Critère	Valeur
Durée	2 heures
Score requis	66%
Validité	2 ans
Retake inclus	1
Version Kubernetes	v1.35
Prix	445 USD
Éligibilité après achat	12 mois

Glissez pour voir

Tableau "besoin → commande"

Ce tableau se lit dans le sens de l'examen : vous partez d'un énoncé, pas d'une commande. Deux raccourcis y reviennent en permanence et sont définis juste après : k est un alias vers kubectl, et $do une variable qui contient les options de génération de YAML. Sans eux, chaque ligne est deux fois plus longue à taper.

Besoin	Commande
Générer un Pod YAML	k run nginx --image=nginx $do > pod.yaml
Générer un Deployment YAML	k create deploy webapp --image=nginx $do > deploy.yaml
Exposer rapidement un Deployment	k expose deploy webapp --port=80
Mettre à jour l'image d'un Deployment	k set image deploy webapp webapp=nginx:1.28
Voir pourquoi un Pod ne démarre pas	k describe pod <nom>
Lire les logs d'un crash	k logs <pod> --previous
Trouver la syntaxe d'un champ	k explain pod.spec.containers
Changer de namespace rapidement	kn <namespace> (alias ci-dessous)
Voir les événements récents	k get events --sort-by='.lastTimestamp'
Rollback d'un Deployment	k rollout undo deploy webapp

Glissez pour voir

Bootstrap de session

Vérifiez ces éléments dès le début de l'examen :

# Vérifier les alias disponibles
alias

# L'alias k doit exister
alias k=kubectl

# Variable pour génération YAML (LA plus importante)
export do="--dry-run=client -o yaml"

# Alias pour changer de namespace rapidement
alias kn='kubectl config set-context --current --namespace'

# Autocomplétion
source <(kubectl completion bash)
complete -F __start_kubectl k

# Éditeur
export KUBE_EDITOR="vim"

Piège fréquent : Oublier de vérifier le namespace. Chaque question peut cibler un namespace différent.

# Voir le namespace actuel
k config view --minify | grep namespace

# Changer de namespace
kn production

---

Application Design and Build (20%)

Ce domaine porte sur la création des objets qui exécutent votre code : Pods, Deployments, Jobs et CronJobs. La technique gagnante est toujours la même, générer un squelette YAML avec une commande impérative, puis l'éditer pour ajouter ce que la ligne de commande ne sait pas exprimer, comme les volumes ou les sondes de santé.

Créer un Pod

La forme la plus directe crée le Pod immédiatement dans le namespace courant, sans passer par un fichier.

k run nginx --image=nginx

But : Créer un Pod simple. Quand : Test rapide, Pod éphémère. Piège : Oublier de générer le YAML si vous devez ajouter des volumes ou probes.

# Générer le YAML pour modification
k run nginx --image=nginx $do > pod.yaml

Options utiles pour kubectl run

Ces options évitent d'éditer le YAML pour les cas simples. La dernière est la plus utile en examen : --command -- sleep 3600 garde un Pod vivant alors que son image se terminerait immédiatement.

Option	Usage
--port=80	Expose un port (documentation)
--labels="app=web"	Ajoute des labels
--env="DB_HOST=mysql"	Variable d'environnement
--requests="cpu=100m,memory=128Mi"	Ressources minimales
--limits="cpu=200m,memory=256Mi"	Ressources maximales
--command -- sleep 3600	Remplace ENTRYPOINT

Glissez pour voir

Créer un Deployment

Contrairement à run, la sous-commande est create deploy et accepte directement le nombre de réplicas.

k create deploy webapp --image=nginx --replicas=3

But : Déployer une application avec réplicas. Quand : Application stateless avec scaling. Piège : Le label app=webapp est ajouté automatiquement.

# Générer le YAML
k create deploy webapp --image=nginx --replicas=3 $do > deploy.yaml

Job et CronJob

Le -- sépare les options de kubectl de la commande exécutée dans le conteneur : tout ce qui suit est transmis tel quel et remplace la commande par défaut de l'image.

# Job ponctuel
k create job backup --image=busybox -- tar -czf /backup/data.tar.gz /data

# CronJob planifié
k create cronjob daily-backup --image=busybox --schedule="0 2 * * *" -- /scripts/backup.sh

Syntaxe cron rapide : */5 * * * * = 5 min, 0 * * * * = 1h, 0 2 * * * = 2h du matin.

---

Application Deployment (20%)

Ce domaine couvre la vie d'une application déjà déployée : changer son image, suivre le déploiement progressif, revenir en arrière et ajuster le nombre de réplicas. Toutes ces commandes agissent sur un Deployment existant et sont donc rejouables sans rien recréer.

Mettre à jour l'image

Cette commande modifie le Deployment en place, ce qui déclenche le remplacement progressif des Pods. La difficulté est que la commande attend le nom du conteneur, pas celui du Deployment, même s'ils sont souvent identiques.

k set image deploy webapp webapp=nginx:1.28

But : Déclencher un rolling update. Syntaxe : <conteneur>=<nouvelle-image>. Piège : Le nom du conteneur doit correspondre à celui défini dans le Deployment.

Suivre et annuler un rollout

Kubernetes conserve un historique de révisions du Deployment, ce qui permet de revenir à l'état précédent sans réécrire le YAML. La commande rollout status bloque le terminal jusqu'à la fin du déploiement, c'est le moyen le plus rapide de savoir si la mise à jour aboutit ou pas.

# Suivre le rollout
k rollout status deploy webapp

# Voir l'historique
k rollout history deploy webapp

# Rollback immédiat
k rollout undo deploy webapp

# Rollback à une révision spécifique
k rollout undo deploy webapp --to-revision=1

Piège : Pas de message d'erreur si le rollback échoue silencieusement. Vérifiez avec rollout status.

Scaler un Deployment

Le changement est immédiat et fonctionne dans les deux sens ; passer à 0 arrête l'application sans supprimer le Deployment.

k scale deploy webapp --replicas=5

Autoscaling

Cette commande crée un HorizontalPodAutoscaler, un objet qui ajuste seul le nombre de réplicas selon la charge CPU. Il ne fonctionne que si le cluster expose des métriques de consommation.

k autoscale deploy webapp --min=2 --max=10 --cpu-percent=80

---

Application Observability and Maintenance (15%)

Ce domaine est celui du diagnostic, et il obéit à un ordre précis : describe d'abord pour savoir si le Pod a seulement démarré, logs ensuite pour savoir ce que l'application a dit avant de s'arrêter, exec en dernier pour aller vérifier depuis l'intérieur. Inverser cet ordre fait perdre du temps sur un Pod qui n'a jamais tourné.

Logs

Les logs proviennent d'un seul conteneur à la fois : sur un Pod multi-conteneur, kubectl refuse de choisir et exige l'option -c.

k logs <pod>
k logs <pod> -c <conteneur>     # Multi-conteneur
k logs <pod> --previous         # Après un crash
k logs <pod> -f                 # Suivre en temps réel
k logs -l app=webapp            # Tous les Pods d'un label

Piège : Après un crash, les logs disparaissent. Utilisez --previous immédiatement.

Describe

La partie qui compte se trouve tout en bas de la sortie, dans la section Events : c'est là que Kubernetes explique pourquoi il n'a pas pu faire ce qu'on lui demandait.

k describe pod <nom>

But : Voir l'état complet + Events. Quand : Pod en Pending, ImagePullBackOff, CrashLoopBackOff.

Les Events révèlent :

• ImagePullBackOff : image inexistante
• CrashLoopBackOff : l'app crash au démarrage
• FailedScheduling : pas de node disponible
• OOMKilled : limite mémoire dépassée

Events du cluster

Les événements ne sont pas triés par défaut, d'où l'option --sort-by qui remonte les plus récents en fin de liste. Ils ne sont conservés qu'un temps limité, en général une heure : un incident ancien aura déjà disparu.

k get events --sort-by='.lastTimestamp'

Exec dans un conteneur

L'accès interactif suppose que le Pod tourne et que l'image embarque un shell, ce qui n'est pas le cas des images minimales. Là encore, le -- sépare les options de kubectl de la commande à exécuter.

k exec -it <pod> -- /bin/sh
k exec <pod> -- ls -la /app
k exec -it <pod> -c <conteneur> -- /bin/sh  # Multi-conteneur

Dans le conteneur :

env                    # Variables d'environnement
cat /etc/resolv.conf   # Config DNS
wget -qO- localhost:80 # Test local

---

Application Environment, Configuration and Security (25%)

C'est le domaine le plus lourdement pondéré de l'examen. Il regroupe tout ce qui est injecté dans un Pod sans être dans l'image : configuration via ConfigMap, données sensibles via Secret, et identité du Pod via ServiceAccount. Les trois objets se créent de la même façon, seule leur destination change.

ConfigMap

Une ConfigMap stocke des paires clé/valeur en clair. Le choix entre les deux formes de création dépend de ce que l'application attend : des variables d'environnement séparées, ou un fichier de configuration complet.

# Créer depuis littéraux
k create cm app-config --from-literal=DB_HOST=mysql --from-literal=LOG_LEVEL=debug

# Créer depuis fichier
k create cm app-config --from-file=config.properties

# Vérifier
k describe cm app-config

Piège : --from-literal pour valeurs simples, --from-file pour fichiers entiers.

Secret

Le mot-clé generic désigne le type le plus courant ; il en existe d'autres, dédiés aux registres d'images et aux certificats TLS. kubectl encode les valeurs en base64 pour vous, ne le faites pas vous-même.

k create secret generic db-creds --from-literal=username=admin --from-literal=password=secret123

Piège : Les secrets sont encodés base64, pas chiffrés.

ServiceAccount

Un ServiceAccount est l'identité sous laquelle un Pod s'adresse à l'API Kubernetes. Créer le compte ne lui donne aucun droit : il faut ensuite le référencer dans le Pod et lui attacher un rôle.

k create sa my-sa

---

Services and Networking (20%)

Un Service donne un nom et une adresse stables à un ensemble de Pods qui, eux, apparaissent et disparaissent. Le lien entre les deux ne se fait pas par un identifiant mais par des labels : c'est la source de presque toutes les pannes réseau rencontrées à l'examen.

Exposer un Deployment

expose fabrique le Service en reprenant automatiquement les labels du Deployment ciblé, ce qui évite de les écrire à la main.

# ClusterIP (défaut, interne)
k expose deploy webapp --port=80

# NodePort (externe via port du node)
k expose deploy webapp --port=80 --type=NodePort

# Avec target-port différent
k expose deploy webapp --port=8080 --target-port=80

Rappel : port = port du Service, targetPort = port du conteneur.

Vérifier un Service

Voir le Service exister ne prouve rien : un Service dont le sélecteur ne correspond à aucun Pod se crée sans erreur et renvoie simplement des connexions refusées. La vérification utile porte sur les endpoints.

k get svc webapp
k get endpoints webapp  # Voir les Pods sélectionnés

Piège : Si ENDPOINTS est vide, les labels du Service ne matchent aucun Pod.

Tester un Service depuis le cluster

Un Service de type ClusterIP n'est joignable que depuis l'intérieur du cluster : il faut donc y lancer un Pod jetable. L'option --rm le supprime dès la fin de la commande, ce qui évite de laisser des Pods de test derrière soi.

k run test --image=busybox --rm -it -- wget -qO- webapp:80

---

Exploration de l'API

L'examen se déroule avec un accès à la documentation officielle, mais la chercher coûte plus cher que d'interroger le cluster. Deux commandes suffisent à retrouver n'importe quelle information de structure : explain pour les champs d'un objet, api-resources pour la liste des objets et leurs abréviations.

kubectl explain

La notation pointée descend dans la hiérarchie du YAML et affiche, à chaque niveau, le type attendu et la description officielle du champ.

k explain pod.spec.containers
k explain pod.spec.containers.livenessProbe
k explain deployment.spec.strategy

But : Trouver la syntaxe exacte d'un champ sans mémoriser. Quand : Toujours, avant d'écrire du YAML complexe.

# Vue récursive + grep
k explain pod.spec --recursive | grep -i volume

kubectl explain > mémorisation

À la CKAD, kubectl explain vaut souvent mieux que mémoriser toute la hiérarchie YAML. Utilisez-le systématiquement pour les champs complexes (probes, securityContext, volumes).

api-resources

Cette commande liste tous les types d'objets reconnus par le cluster, avec leur abréviation et leur groupe d'API. C'est aussi le moyen de vérifier qu'un objet apporté par une extension est bien disponible.

k api-resources

Short names utiles : po (pods), svc (services), deploy (deployments), cm (configmaps), pvc (persistentvolumeclaims).

---

Outputs et filtrage

Beaucoup de questions demandent d'extraire une seule valeur et de l'écrire dans un fichier. Le format jsonpath répond exactement à ce besoin en évitant tout post-traitement : il retourne la valeur brute, sans en-tête ni mise en forme. Les filtres par label, eux, servent à retrouver les objets concernés quand l'énoncé ne donne pas leur nom.

# Vue étendue (IP, node)
k get pods -o wide

# Exporter en YAML
k get pod nginx -o yaml > pod.yaml

# JSONPath
k get pod nginx -o jsonpath='{.status.podIP}'
k get pods -o jsonpath='{.items[*].metadata.name}'

# Filtrer par label
k get pods -l app=nginx
k get pods -l 'app in (nginx,redis)'

# Tous les namespaces
k get pods -A

# Trier par date
k get pods --sort-by='.metadata.creationTimestamp'

---

Commandes à connaître par cœur

Cette liste est le minimum à taper sans réfléchir le jour de l'examen. Elle tient volontairement en dix lignes : les quatre premières couvrent la création, les trois suivantes la mise à jour, les trois dernières le diagnostic. Tout le reste peut se retrouver avec kubectl explain.

k run ... $do                  # Générer Pod YAML
k create deploy ... $do        # Générer Deployment YAML
k expose deploy ...            # Créer Service
k set image deploy ...         # Mettre à jour image
k rollout status deploy ...    # Suivre rollout
k rollout undo deploy ...      # Rollback
k logs ... --previous          # Logs après crash
k describe pod ...             # État + Events
k explain ...                  # Syntaxe YAML
k get events                   # Événements cluster

À retrouver vite dans la doc

Ne perdez pas de temps à mémoriser ces éléments, retrouvez-les avec kubectl explain ou dans la doc :

• Détails d'Ingress (k explain ingress.spec)
• Champs avancés des probes (k explain pod.spec.containers.livenessProbe)
• Options de securityContext (k explain pod.spec.securityContext)
• Syntaxe exacte d'un CronJob (k explain cronjob.spec)
• Règles de NetworkPolicy (k explain networkpolicy.spec)

---

Dépannage rapide

Ce tableau associe un symptôme visible dans kubectl get pods à la commande qui donne la réponse. Retenez la coupure principale : un Pod bloqué avant de démarrer se diagnostique avec describe, un Pod qui a démarré puis s'est arrêté se diagnostique avec logs.

Symptôme	Commande	Cause probable
Pending	k describe pod	Pas de node, requests trop élevées
ImagePullBackOff	k describe pod	Image inexistante
CrashLoopBackOff	k logs --previous	L'app crash au démarrage
Service ne répond pas	k get endpoints	Labels incorrects (aucun Pod sélectionné)
ConfigMap absent	k get cm	Mauvais namespace

Glissez pour voir

---

À retenir

1. $do génère le YAML sans créer, toujours commencer par là
2. Vérifiez le namespace avant chaque question
3. kubectl explain pour la syntaxe, pas la mémoire
4. kubectl describe pour comprendre les erreurs
5. --previous pour les logs d'un crash
6. set image + rollout pour les mises à jour
7. Labels = sélection (Services, Deployments)
8. Events = diagnostic rapide du cluster

Pour aller plus loin

• Guide de préparation CKA : La marche suivante, côté administration du cluster.
• Exercices chronométrés CKA : S'entraîner en conditions d'examen sur le versant administrateur.

×

📖 Voir la documentation →