J’ai passé ces deux certifications proposées par la Linux Foundation fin novembre 2023. Le contexte d’apprentissage peut être suffisamment pénible et déroutant pour que je partage cette expérience afin de vous faire gagner du temps et vous épargner de la peine si vous souhaitez les passer.

Au départ, mon entreprise m’a proposé de passer ces certifications début décembre 2022. Comme vous pouvez le voir, j’ai mis presque un an à les passer. L’absence totale de convivialité des cours n’y est pas rien. A tel point que j’ai plusieurs fois pensé abandonner. Et puis j’ai finalement à me conditionner pour trouver les ressources mentales nécessaires pour passer les deux dans la foulée. Voici donc ma méthode et mes astuces.

CKA ou CKAD ? Laquelle passer en premier ?

Soyons brefs car plusieurs cas de figure peuvent se présenter :

• Vous ne passez qu’une seule seule certification et l’intitulé de la certification est important pour votre CV :
  • Votre profil est plutôt développeur : passez la CKAD (Certified Kubernetes Application Developer). Le cours correspondant est le LFD259 (Kubernetes for Developers).
  • Votre profil est plutôt devops : passez la CKA (Certified Kubernetes Administrator). Le cours correspondant est le LFS258 (Kubernetes Fundamentals)
• Vous pouvez passer les deux certifications : passez la CKAD avant la CKA car vous n’aurez plus que quelques notions de gestion de cluster et d’administration système à intégrer.

Les conditions d’examen

Il faut dès le début intégrer les spécificités de l’environnement d’examen :

• 15 à 20 tâches à réaliser en 120 minutes
• Environnement virtuel Ubuntu dans lequel on doit tout faire (rien ne peut se réaliser sur votre machine). Il faut donc prendre en compte un environnement plus petit que votre écran, qui sera plus chargé, qui va potentiellement subir des lenteurs et dans lequel les raccourcis de copier-coller seront différents selon que vous serez dans un terminal ou dans la doc via la navigateur.
• Environnement surveillé en permanence. Ne négligez pas le stress induit.

En plus des connaissances sur Kubernetes, vous allez donc être jugé sur votre aisance avec la ligne de commande kubectl, votre capacité à travailler en environnement dégradé et à trouver rapidement une ressource particulière dans la documentation. Retenez bien ça.

Dans la partie Certification du dashboard, il y a des étapes à valider avant de pouvoir réserver un créneau d’examen. Lisez les documents qui sont requis, ils contiennent des informations importantes à propos des conditions de passage de l’examen, de l’environnement, etc. Ne le faites pas au dernier moment juste pour cocher les cases vertes.

Préparer la CKAD

Au début de la formation, on est fortement incité à déployer un cluster sur AWS ou GCE. Je n’ai pas du tout suivi ce conseil car cela n’apporte rien à part dépenser de l’argent. Soyons clair : il n’y a pas besoin de débourser un centime en plus du prix de la formation.

J’ai passé la plupart de mon temps sur minikube, un mini cluster à un nœud à installer sur sa machine. J’ai renoncé à utiliser mon cluster à 3 nœuds installé sur un lab perso depuis des lustres pour pouvoir réinitialiser le cluster et les paramètres à loisir sans me prendre la tête. Appliquons la méthode KISS : Keep It Stupidly Simple.

Puis, vers la fin, une fois que j’étais à peu près à l’aise, j’ai lancé deux sessions Killer Shell à une semaine d’intervalle. Il ne faut pas le faire trop tard non plus car le corrigé détaillé regorge d’informations utiles.

La session Killer Shell permet deux choses :

• lancer une session d’examen blanc autant de fois que nécessaire pendant 36 heures sur des questions censées être plus dures que celles de l’examen (en fait, pas tellement car celles de l’examen réel sont en moyenne un peu plus simples, mais les énoncés sont parfois un peu fourbes)
• simuler l’environnement de l’examen auquel il faut s’habituer. Prenez le temps de prendre votre marques dans cet environnement de manière à ne pas vous faire surprendre inutilement le jour J.

Les ressources utiles pour apprendre

Voici les ressources sur lesquelles je me suis appuyées, dans l’ordre chronologique :

• Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours] – YouTube
• Mock Test – 1, CKAD Prep Exam
• Mock Test – 2, CKAD Prep Exam (Solution)
• Les scénarios CKAD de Killercoda
• https://github.com/dgkanatsios/CKAD-exercises
• Le corrigé détaillé de la session Killer Shell

J’ajoute ces deux ressources qu’un collègue a utilisées :

• La série de vidéos « Understanding Kubernetes in a visual way » d’Aurélie Vache
• https://github.com/bmuschko/ckad-crash-course/tree/master/exercises

Quelques conseils

La CKAD consiste essentiellement à créer et modifier des ressources de base assez rapidement. Donc ne perdez pas de temps à construire un cluster, installer des extensions, des solutions de load balancing, etc. La certification demande de l’aisance dans la ligne de commande, la recherche dans la doc et l’édition de fichiers yaml. Concentrez-vous sur ces points.

Une fois parti sur les exercices, je ne me suis référé qu’à la seule documentation officielle pour m’aider car c’est la seule ressource autorisée. J’ai donc vite appris à mémoriser les termes de recherche qui me donne accès à la bonne page, à la bonne section qui contient le bon yaml à copier et même le nom de la page (et si elle est dans la section concepts ou tasks par exemple). Seule la pratique et la répétition permettent d’acquérir cette aisance.

J’avais un peu d’appréhension vis-à-vis de vim car même en l’utilisant régulièrement de manière basique, les conseils que j’ai vu en ligne laissent à penser qu’il faut être un gourou. En fait non. Dans l’environnement d’examen, l’affichage des yaml est colorisé, ce qui est pratique pour repérer les problèmes d’espace entre clés et valeurs.

Les seules choses m’ont été utiles sont :

• la recherche : « / » pour chercher puis « n » ou « N » pour sauter à l’occurrence suivante ou précédente.
• Shift + C : efface tout ce qui est à droite du curseur et entre en mode insertion
• Shift + V : entre en mode sélection
• d : efface une ligne ou le bloc de lignes sélectionnées
• u : revenir en arrière (équivalent du Ctrl/Cmd + Z)
• : + numéro de ligne : qui permet de placer le curseur sur la bonne ligne en cas de message d’erreur
• Et… c’est tout. J’avais appris beaucoup d’autres choses, dont l’indentation par blocs, mais je ne m’en suis pas servi. Finalement, ça allait plus vite en ajoutant ou supprimant des espaces ligne par ligne.

Je pensais aussi qu’il me faudrait maîtriser tmux, mais là encore, pas besoin : avec une fenêtre de terminal pour la ckad et deux onglets pour la cka, pas besoin d’apprendre un truc en plus. Bien sûr, si vous maîtrisez ou que vous voulez en profiter pour apprendre, pas de soucis.

Killer Shell propose quelques raccourcis utiles. Seul celui pour changer de namespace m’a été utile : alias kn="kubectl config set-context --current --namespace "

Il y a moins d’horaires disponibles pour le passage de la CKAD que pour la CKA. Il faut vérifier à l’avance que le jour/horaire souhaité est disponible. Réservez-le longtemps à l’avance. D’abord ça permet de sécuriser le slot, et en plus ça fait un moteur de motivation en plus.

Ne rushez pas l’examen dès la première seconde. Prenez un peu de temps au début pour vous décontracter, placer vos fenêtres, ouvrir la documentation dans une fenêtre de navigateur correctement ajustée et créer vos raccourcis. Ensuite, détendez-vous, et lisez la première question. Ça commence doucement, donc prenez vos aises. On parle de deux minutes, pas d’un quart d’heure !

Surveillez votre namespace et votre context comme le lait sur feu. Vous pouvez parfaitement réussir un exercice compliqué sur le bout des doigts, s’il est dans le mauvais context/namespace, vous aurez zéro.

Enfin, n’abordez pas l’examen avec un handicap : appliquez uniquement ce que vous maîtrisez, n’improvisez pas. Vous n’êtes pas super à l’aise avec l’indentation par bloc dans vim ? Vous ne maîtrisez pas parfaitement tmux ? Pas grave, le les utilisez pas, n’empilez pas les strates techniques non maîtrisées, n’explorez pas une partie de la doc inconnue alors que vous savez que la ressource est dans un autre endroit, même si vous ne vous souvenez plus exactement du nom (cherchez la page en question, vous raccrocherez plus vite les wagons). Le temps est précieux.

Même si les exercices peuvent paraître techniquement relativement simples, n’oubliez pas qu’il faut les gérer en condition d’examen avec un certain stress.

CKA

J’ai vu passer pas mal de questions pour savoir quelle certification est la plus dure. Mon avis est que si vous passez directement la CKA, alors cette dernière est plus difficile que la CKAD car elle contient les connaissances de la CKAD en plus de la partie gestion de cluster.

Mais si vous venez de passer la CKAD, alors la CKA est une formalité.

Je me suis décidé très tardivement à la passer et la fin de l’abonnement annuel était proche. J’avais donc beaucoup moins de temps pour la préparer (à peu près une semaine).

Les acquis de la CKAD étaient tout frais, j’ai donc adopté une stratégie différente avec une approche beaucoup plus directe du sujet :

• Environnement :
  • abandon de minikube et utilisation massive du playground de killerkoda (c’est un cluster à 2 nœuds sur lesquels on a la main complète : ssh en root, possibilité de reset un nœud, de reset le cluster, tout faire buguer et réparer, upgrade, join, etc.). Il ne faut pas passer à côté de cette ressource.
  • session Killer Shell : j’ai pris du temps pour peaufiner ma mise en place. Pendant l’examen, il va falloir jongler entre plusieurs contexts et entrer dans des nodes en ssh. Il est important de pouvoir rapidement se localiser. J’ai donc opté pour une présentation que je détaille plus bas.
• Ressources d’apprentissage :
  • Playground et scénarios Killercoda
  • Cette playlist Youtube : CKA Exam
  • Github : Exercices (Questions)
  • Github : Exercices (Réponses)
  • Killer Shell

Une fois la compréhension de l’univers, j’ai entamé une exploration personnelle du systèmes et des composants (tous les fichiers de configuration, les nouveaux outils crictl, systemctl, journalctl et etcdctl, les fichiers de composants de /var/lib/, /var/log, /etc/kubernetes, /etc/systemd/system).

J’ai aussi exploré plusieurs scénarios de type « what if » : Que se passes-t-il si je modifie l’intérieur des fichiers par de mauvaises données à différents niveaux ? Si ça plante, comment est-ce que je peux retrouver la source de l’erreur ? Etc.

L’utilisation de la commande kubectl explain est aussi très utile (et elle est récursive, comme la commande kubectl help).

Prenons un exemple : vous voulez définir explicitement un port dans le yaml d’un pod. Plutôt que de perdre du temps dans la doc, comme on se doute que cette déclaration se fait au niveau du container, la commande kubectl explain Pod.spec.containers va révéler qu’on peut ajouter un champ ports. La commande kubectl explain Pod.spec.containers.ports montre qu’on peut ajouter des champs name, protocol et hostPort sous forme de liste. On voit d’ailleurs que le champ name reconnaît les noms compatibles IANA. Au lieu d’indiquer le port 80, on peut donc mettre name: http. Et voilà.

Les commandes kubectl [n'importe quoi] help et kubectl [n'importe quoi] explain sont à manipuler et comprendre avant le jour J évidemment. Bien utilisées, elle sont plus rapides que la documentation sur bien des aspects.

Juste avant l’examen, j’ai fait révision rapide de la ckad pour consolider les acquis et me remettre en tête quelques points particuliers (revue rapide de ma session Killer Shell CKAD, des scénarios Killercoda et des exercices sur Gihub).

Pendant l’examen : j’ai fidèlement répété la mise en place étudiée lors de la session Killer Shell :

• Une fenêtre de terminal de monitoring des contexts (il y en a plusieurs) avec pour titre « == CONTEXTS == » réduite au maximum possible avec l’option « Aways on top », qui affiche le résultat commande watch kubectl config get-contexts. De cette manière, j’avais toujours un oeil sur les context et namespace actifs, ce qui est important.
• Une fenêtre de terminal de travail contenant deux onglets. De cette manière, je peux vérifier quelque-chose dans un onglet pendant que je travail dans l’autre (édition d’un fichier dans vim ou écriture d’une longue commande par exemple).
• C’est dans cette fenêtre de terminal que j’entre dès le début de la session le seul alias qui m’est réellement utile : alias kn="kubectl config set-context --current --namespace "
• Enfin, une page web qui affiche la doc de Kubernetes

Pour la CKAD, l’environnement était assez grand (une fenêtre de terminal et une page de navigateur pour la doc), mais pour la CKA, la taille était un peu petite. Je m’attendais à ça et c’est toute l’importance des sessions Killer Shell : s’habituer à travailler vite en environnement dégradé.

Contrairement à la CKAD, la session Killer Shell est véritablement plus compliquée que l’examen réel et mérite d’être conservé comme ressource pour le futur.

En conclusion

Vous vous demanderez peut-être où se trouve la référence au contenu de la formation dans les ressources d’apprentissage ? C’est une bonne question et je vous remercie de l’avoir posée.

Pour moi, le passage de ces certifications, comme toute certification, revêt un intérêt fondamental au-delà de la réussite à l’examen, celui d’avoir pu explorer un domaine en profondeur et d’acquérir de nouvelles compétences et connaissances. Je vais maintenant explorer tranquillement la CKS (le volet sécurisation) sans acheter de formation ni passer de certification, mais en suivant le même processus d’apprentissage que les CKA et CKAD, via les mock exams.

Pour la suite, j’ai déjà de nouvelles idées en tête, mais je les garde pour moi afin de rester serein et maître de mes décision de m’y engager ou non, sans pression.

J’espère que ce retour d’expérience vous sera utile. Dites-moi en commentaire si vous avez aussi une expérience similaire ou si cela vous a aidé dans votre parcourt.