Préparation associée
Labs CKA
Administrer un cluster : installation, mises à jour, réseau, stockage, sauvegarde d'etcd et dépannage, dans un terminal, sur de vrais clusters.
Revenir aux 404 labsComment jouer un lab
- 25 labs
- 8 heures de pratique
- 25 sur machine virtuelle
Niveaux 2 débutant 15 intermédiaire 8 avancé
Objectifs officiels de l'examen publiés par CNCF
Ce ne sont pas des questions d'examen. Ce sont des exercices pratiques sur les compétences que l'examen mesure, notés sur l'état de votre machine.
La CLI d'abord, avec uv ou pipx : aucun droit d'administration, Python 3.11 suffit. uv tool install dsoxlab # ou : pipx install dsoxlab Installer DSOXLab
Kubernetes, CKA, CKAD et CKS
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training
CKA, Certified Kubernetes Administrator
25
-
Lab guidé 10m · intermédiaire · machines virtuelles
Poser un Pod statique sur un worker, sans passer par l'API
Faire tourner un Pod que le kubelet du worker gère seul, à partir d'un manifeste déposé sur le nœud, et le voir apparaître dans l'API sous son nom de miroir. Le fichier doit être au bon endroit, celui que la configuration du kubelet désigne, et le runtime du worker doit réellement exécuter le conteneur.
dsoxlab start cka-static-pod -
Lab guidé 10m · débutant · machines virtuelles
Un agent sur chaque nœud, control plane compris
Déployer un DaemonSet qui pose un agent sur tous les nœuds du cluster, y compris le control plane, protégé par son taint. Les tests comptent un Pod par nœud, vérifient que le taint est toujours là et que l'agent y tourne quand même, et lisent ses logs pour prouver qu'il fait son travail.
dsoxlab start cka-daemonset-all-nodes -
Lab guidé 15m · intermédiaire · machines virtuelles
Donner une identité à une application : ServiceAccount, Role, RoleBinding
Une application refuse de démarrer parce que son ServiceAccount n'existe pas. Le créer, lui accorder le droit de lire les Pods de son namespace et rien d'autre, puis prouver depuis l'intérieur du Pod, avec son propre jeton, que lister passe et que supprimer, lire les Secrets ou regarder ailleurs sont refusés.
dsoxlab start cka-rbac-serviceaccount -
Lab guidé 10m · intermédiaire · machines virtuelles
Réserver un nœud : taint, tolérance et nodeSelector
Réserver le worker à la production par un taint et un label, puis placer un Pod qui doit y aller, tolérance et nodeSelector, et un Pod qui ne doit pas y aller. Les tests lisent le nœud, le placement réel de chaque Pod et les mécanismes déclarés : un Pod épinglé par nodeName contourne le taint et ne passe pas.
dsoxlab start cka-taints-tolerations-placement -
Lab guidé 15m · intermédiaire · machines virtuelles
Placer avec nodeAffinity : contrainte obligatoire et préférence
Placer un Deployment par une affinité de nœud obligatoire sur un label à plusieurs valeurs, y ajouter une préférence pondérée, puis débloquer un Pod qui attend un nœud qui n'existe pas encore en posant le label qu'il exige. Les tests lisent les labels des nœuds, les affinités déclarées et le nœud réel de chaque Pod.
dsoxlab start cka-node-affinity -
Lab guidé 15m · intermédiaire · machines virtuelles
Isoler la base de données : seul le backend y accède
Écrire la NetworkPolicy qui ne laisse entrer vers la base que le backend de son namespace, sur son port, et rien d'autre. Les tests tentent les connexions : celle qui doit passer, celle du frontend qui doit être bloquée, celle d'un Pod au bon label mais dans un autre namespace, et vérifient que la base peut encore sortir.
dsoxlab start cka-networkpolicy-isolate-db -
Lab guidé 20m · intermédiaire · machines virtuelles
Router deux applications sur un seul hôte, et prouver que chacune reçoit la sienne
Deux applications, un seul nom d'hôte, et aucune règle disant laquelle est laquelle. Routez par le chemin, et prouvez-le de la seule façon qui compte : chaque chemin répond le nom de son application, et un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-ingress-path-routing -
Lab guidé 25m · avancé · machines virtuelles
Router avec la Gateway API, et voir la Gateway se déclarer programmée
Les deux mêmes applications, le même nom d'hôte unique, et le successeur de l'Ingress. Déclarez une Gateway, attachez-lui une route, et prouvez le routage : chaque chemin répond le nom de son application, un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-gateway-api-httproute -
Lab guidé 15m · intermédiaire · machines virtuelles
Un volume persistant : PersistentVolume, PersistentVolumeClaim et un Pod qui écrit
Sur un cluster sans provisionnement dynamique, créer un PersistentVolume sur le disque d'un nœud, le réclamer par un PersistentVolumeClaim, le monter dans un Pod qui y écrit. Les tests lisent le volume, la liaison, le montage, le fichier dans le Pod, puis le même fichier sur le disque du nœud : c'est là que se prouve la persistance.
dsoxlab start cka-pv-pvc-storageclass -
Lab guidé 25m · intermédiaire · machines virtuelles
Obtenir un volume sans qu'un administrateur l'ait créé, et voir ce qu'il devient
Une revendication bloquée en attente parce que personne n'a préparé de volume à la main. Laissez le cluster le provisionner à la demande, puis observez ce que la classe décide quand la revendication disparaît : le volume la suit.
dsoxlab start cka-storageclass-provisionnement-dynamique -
Lab guidé 15m · intermédiaire · machines virtuelles
Revenir en arrière sur un déploiement bloqué, puis livrer la bonne version
Une mise à jour est partie avec un nom d'image faux et le déploiement est bloqué. Revenir à la révision qui marchait par l'historique du Deployment, puis livrer l'image correcte avec une cause de changement. Les tests lisent les ReplicaSets et leurs numéros de révision : ils racontent ce qui s'est passé, et un Deployment recréé de zéro ne raconte rien.
dsoxlab start cka-deployment-rollout-rollback -
Lab guidé 15m · intermédiaire · machines virtuelles
Vider un worker pour une maintenance, sans couper le service
Protéger une application par un PodDisruptionBudget, retirer le worker du scheduling, l'évacuer en respectant ce budget et les DaemonSets, puis le remettre en service et tracer l'opération. Les tests prouvent que les Pods ont réellement été recréés ailleurs, que le nœud est revenu, et que le DaemonSet du CNI n'a pas bougé.
dsoxlab start cka-node-drain-cordon -
Lab guidé 20m · intermédiaire · machines virtuelles
Faire monter en charge automatiquement avec un HorizontalPodAutoscaler
Poser un HPA sur un Deployment, générer de la charge, voir la montée en replicas, puis couper la charge. Les tests lisent le HPA, ses métriques courantes, et l'event de redimensionnement que le contrôleur a émis : un HPA qui n'a jamais redimensionné n'est pas un HPA validé.
dsoxlab start cka-hpa-autoscaling -
Lab guidé 25m · intermédiaire · machines virtuelles
Plafonner un namespace sans bloquer ceux qui oublient de se déclarer
Un namespace sans plafond ni valeurs par défaut : une équipe peut prendre tout le cluster, et un Pod sans `requests` est placé à l'aveugle. Posez les deux, et prouvez chacun : un Pod qui demande trop est refusé, un Pod qui ne demande rien est accepté et complété.
dsoxlab start cka-resourcequota-limitrange -
Lab guidé 10m · débutant · machines virtuelles
Sortir un Pod de l'ImagePullBackOff
Un Pod ne démarre pas parce que son image ne se télécharge pas. Lire le message exact du runtime dans les events, corriger la référence d'image, et prouver que le serveur répond.
dsoxlab start cka-troubleshoot-imagepullbackoff -
Lab guidé 15m · intermédiaire · machines virtuelles
Sortir un Deployment du CrashLoopBackOff
Les Pods d'un Deployment redémarrent en boucle depuis la dernière livraison. Lire ce que le processus a dit avant de mourir, comprendre ce qui lui manque, corriger le Deployment, et prouver que l'application sert à nouveau.
dsoxlab start cka-troubleshoot-crashloopbackoff -
Lab guidé 15m · intermédiaire · machines virtuelles
Entrer dans un conteneur sans shell avec kubectl debug
Un Pod dont l'image ne contient aucun shell n'offre rien à kubectl exec. Lui adjoindre un conteneur éphémère qui partage ses processus, atteindre le système de fichiers du nœud par un Pod de débogage, et en laisser la preuve.
dsoxlab start cka-kubectl-debug -
Lab guidé 10m · intermédiaire · machines virtuelles
Rétablir la résolution DNS du cluster
Plus aucun Pod ne résout de nom de service. Trouver pourquoi le DNS du cluster ne répond plus, le remettre en service, et prouver qu'un Pod client résout et joint à nouveau un Service par son nom.
dsoxlab start cka-troubleshoot-dns -
Lab guidé 15m · avancé · machines virtuelles
Rétablir le trafic vers un Service
Un Service ne dessert plus ses Pods : selector faux, port faux, et une politique réseau qui ferme tout. Remettre le Service d'aplomb, rouvrir exactement ce qu'il faut sans retirer la politique de sécurité, et prouver qu'un client joint le Service par son nom.
dsoxlab start cka-troubleshoot-networking -
Lab guidé 15m · avancé · machines virtuelles
Ramener un nœud NotReady dans le cluster
Un worker est passé NotReady, et l'application qui lui est réservée est dégradée. Trouver sur le nœud pourquoi il ne parle plus au control plane, remettre son agent en service de façon durable, et prouver que l'application est revenue.
dsoxlab start cka-troubleshoot-node-notready -
Lab guidé 15m · avancé · machines virtuelles
Réparer un kubelet qui refuse de démarrer
Le kubelet d'un worker s'arrête aussitôt lancé, et le nœud est NotReady. Lire dans le journal ce qu'il reproche à sa configuration, corriger le fichier sans rien casser d'autre, et prouver que le nœud et son application sont revenus.
dsoxlab start cka-troubleshoot-kubelet -
Lab guidé 15m · avancé · machines virtuelles
Remettre l'API server en service
kubectl ne répond plus : l'API server du control plane sort en erreur au démarrage. Sans API, diagnostiquer sur le nœud, dans les conteneurs et les journaux du kubelet, corriger le manifeste statique, et prouver que l'API répond sans avoir affaibli son autorisation.
dsoxlab start cka-troubleshoot-apiserver -
Lab guidé 25m · avancé · machines virtuelles
Sauvegarder etcd, puis restaurer le cluster depuis un instantané
Un namespace a disparu. Prendre d'abord une sauvegarde fraîche de l'état courant, puis restaurer le cluster depuis l'instantané de la veille, sans arrêter le mauvais composant et sans laisser l'API server sur un cache périmé. Les tests prouvent qu'etcd tourne sur un répertoire produit pendant le lab, que les objets reviennent avec leur UID d'origine, et que ce qui a été écrit après la sauvegarde a disparu.
dsoxlab start cka-etcd-backup-restore -
Lab guidé 40m · avancé · machines virtuelles
Monter un cluster d'une version mineure, sans interrompre ce qui tourne
Un cluster en retard d'une version mineure, une application qui doit continuer à servir, et la montée à conduire : le plan de contrôle d'abord, le nœud ensuite, chacun avec sa propre commande. Les tests lisent les versions et vérifient que rien n'a été laissé vidé.
dsoxlab start cka-kubeadm-upgrade -
Examen blanc réussite 66 % 45m · avancé · machines virtuelles
Capstone : remettre le portail en service, sans personne à qui demander
Un namespace laissé par une équipe partie, un portail qui ne répond rien, et aucun ticket pour dire pourquoi. Trois défauts indépendants à trouver, deux exigences qui n'ont jamais été satisfaites, et une seule mesure de réussite : le portail répond sur chaque nœud du cluster.
dsoxlab start cka-capstone-portail