Aujourd’hui, j’ai décidé de te partager mon expérience de préparation à la CKA (Certified Kubernetes Administrator). Sache que je ne suis pas un administrateur Kubernetes de profession. Je suis Architecte Solution : mon quotidien, c’est de concevoir les clusters et la manière dont les applications s’y déploient. La gestion quotidienne (Ops) du cluster n’est donc clairement pas une activité que je réalise à la main tous les jours.
Tu te demandes alors : Pourquoi passer la CKA et pas la CKAD ? C’est simple, j’ai plutôt besoin des compétences de la CKS (Certified Kubernetes Security Specialist) dans mon univers professionnel qui nécessite une sécurité renforcée. Or, pour obtenir la CKS, le prérequis absolu est d’avoir la CKA. Bien sûr, je pourrais me contenter de suivre une formation sur la sécurité de Kubernetes, mais pourquoi m’arrêter là ? C’est un challenge personnel et professionnel. Les certifications (même si elles doivent être renouvelées tous les 2 ans) forcent à se maintenir à niveau. C’est aussi un excellent ticket pour maintenir un haut niveau d’employabilité.
Maintenant que le contexte est posé, voici mon plan d’attaque pour la préparation à la CKA.
Ma méthode d’apprentissage :
- La documentation officielle : Incontournable. Leur site est très bien fait. Je retiens particulièrement la section sur les configurations d’objets Kubernetes et les cas d’usage.
- Les blogs et vidéos YouTube : Pour la vulgarisation et les retours d’expérience.
- La pratique acharnée : C’est le plus formateur. Quand on n’est pas SRE, c’est difficile de voir des problèmes variés au quotidien. Il faut donc s’imposer des exercices.
1. Les Ressources de Formation
Formations en ligne (Gratuites)
- Les bases de Kubernetes : kubernetes.io/docs/tutorials/kubernetes-basics/
- L’initiation à Kubernetes (edX) : LinuxFoundationX LFS158x
- L’excellent blog de Stéphane Robert : blog.stephane-robert.info (Une mine d’or en français)
Formations en ligne (Payantes)
- Les fondamentaux (Linux Foundation) : Kubernetes Fundamentals (LFS258)
- KillerCoda (Scénarios interactifs) : killercoda.com/course/cka (Un excellent investissement)
Note : J’ai opté pour le pack d’apprentissage annuel de la Linux Foundation. Dans notre métier où tout évolue vite, se former est une discipline de vie. Je n’attends pas toujours que mon employeur ou le CPF finance ces formations.
2. Les Exercices de Préparation
Avec le voucher de l’examen, vous avez droit à deux passages sur le simulateur officiel (Killer.sh). Ne les prenez pas à la légère !
- Le simulateur est souvent plus difficile que l’examen lui-même. Lors de mon premier passage, mon niveau de manipulation était trop juste.
- Le temps est une composante cruciale : j’ai eu 9/74 dans les 2 premières heures, puis j’ai mis 11h au total pour boucler le reste (score final 68/74).
- La correction fournie est géniale : elle montre souvent des chemins beaucoup plus courts (commandes impératives) pour arriver au même résultat.
Le passage sur l’environnement de l’examen m’a perturbé car les raccourcis clavier (notamment le copier/coller) diffèrent de ceux de mon Mac. Entraînez-vous dans les mêmes conditions !
3. Les Conditions de l’Examen
- Un environnement strict : Navigateur vierge, bureau vide, pas de livres, pas de double écran, et pas de papier/crayon ! (Très dur quand on a l’habitude de dessiner des architectures pour débugger).
- 100% Pratique : Aucun QCM. Vous résolvez des problèmes sur des clusters live (mise en place HA, déploiements, sécurité, et surtout corriger des installations cassées).
4. Les Thèmes de l’Examen & Documentation Officielle
Domain 1 : Cluster Architecture, Installation & Configuration 25%
Mise en place et configuration avec kubeadm, gestion du RBAC, certificats TLS, HA du control plane, mise à jour du cluster et backup/restore d’etcd.
- Outils : kubeadm, kubectl, etcdctl, kubelet, crictl, openssl.
- Références officielles à bookmark :– Installation kubeadm– Backup / Restore etcd– RBAC
Domain 2 : Workloads & Scheduling 15%
Déploiements, rolling updates, rollbacks, ConfigMaps, Secrets, contraintes de planification (nodeSelector, taints/tolerations, affinity), ressources limits et HPA.
- Outils : kubectl rollout, scale, autoscale.
- Références officielles à bookmark :– Deployments– Taints & Tolerations– ConfigMaps
Domain 3 : Services & Networking 20%
Modèle réseau, Services, Ingress, NetworkPolicies. Résolution DNS (CoreDNS) et fonctionnement de kube-proxy.
- Outils : CoreDNS, Ingress Controllers, netshoot, port-forward.
- Références officielles à bookmark :– Services– Network Policies– Ingress
Domain 4 : Storage 10%
Volumes persistants (PV), Claims (PVC), StorageClasses et access modes (RWO, RWX).
- Références officielles à bookmark :– Persistent Volumes– Storage Classes
Domain 5 : Troubleshooting 30%
Le gros morceau. Diagnostic de pods (CrashLoopBackOff, ImagePullBackOff), vérification des composants du control plane, analyse des logs système.
- Outils : kubectl describe/logs/events, journalctl, crictl.
- Références officielles à bookmark :– Troubleshoot Clusters– Debug Running Pods
5. Les 5 Erreurs Classiques à Éviter
kubectl est indispensable.kubectl ... --dry-run=client -o yaml > file.yaml.kubectl config use-context <nom> avant chaque question.kubectl get ou describe que l’état attendu est atteint.6. Mes Exercices Pratiques (Exemples)
Q1. Création rapide de Pod
Enoncé : Vous devez créer un pod nommé nginx-pod utilisant l’image nginx:1.25, dans le namespace production, avec une limite mémoire de 256Mi.
# Editer le fichier pod.yaml pour ajouter la section resources.limits.memory
Explication : La commande imperative kubectl run est la plus rapide. Attention, l’ancienne syntaxe avec --limits a été dépréciée dans les versions récentes pour les pods simples. Générer le YAML avec --dry-run et l’éditer avec vi reste la méthode la plus fiable et rapide à l’examen.
Q2. Diagnostic de Planification (Scheduling)
Enoncé : Un pod reste en état ‘Pending’. kubectl describe pod indique FailedScheduling: 0/3 nodes are available: 3 node(s) had untolerated taint.
Solution attendue : Ajouter une toleration dans le manifeste du Pod (spec.tolerations) correspondant aux taints présents sur les nœuds cibles.
Explication : Les taints empêchent la planification des pods qui n’ont pas la tolération correspondante. Retirer les taints des nœuds fonctionnerait techniquement, mais c’est une mauvaise pratique qui casse la conception de l’architecture. Comprendre la différence entre taints/tolerations (répulsion) et nodeAffinity (attraction) est crucial.
Q3. Backup ETCD
Enoncé : Vous devez sauvegarder la base de données etcd avant une mise à jour majeure. Quelle est la procédure ?
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /tmp/etcd-backup.db
Explication : etcd nécessite l’API v3 et l’authentification mutuelle TLS. Oublier les certificats fera échouer la commande. Cette question tombe systématiquement à l’examen : mémorisez les chemins des certificats /etc/kubernetes/pki/etcd/ par cœur !