📍 Article principal : CKA depuis l’Afrique de l’Ouest. Ce tutoriel déploie un cluster Kubernetes via kubeadm sur trois VPS Hetzner pour préparer la CKA dans des conditions identiques à l’examen.
L’examen CKA exige des compétences pratiques d’administration que seul un cluster kubeadm réel permet de développer. Les solutions managées (GKE, EKS, AKS) cachent les composants control plane qu’il faut justement maîtriser. Ce tutoriel monte un cluster trois nœuds (un control plane + deux workers) sur des VPS Hetzner CX22 à environ 5 EUR par mois chacun, soit 15 EUR par mois total — environnement réaliste qui prépare directement aux tâches d’examen comme l’etcd backup, le bootstrap de nouveaux nodes ou le upgrade kubeadm.
Prérequis
- Compte Hetzner Cloud avec carte bancaire validée
- Trois VPS CX22 minimum (2 vCPU, 4 Go RAM, 40 Go SSD chacun, Ubuntu 24.04)
- Notions Linux et SSH
- Niveau : intermédiaire
- Temps estimé : 4 à 5 heures
Étape 1 — Provisionner les trois VPS et préparer le réseau
Créer trois VPS Hetzner avec Ubuntu 24.04 LTS comme image. Nommer explicitement : cka-cp1 pour le control plane, cka-w1 et cka-w2 pour les workers. Ajouter une clé SSH commune pour faciliter l’administration. Hetzner attribue à chaque VPS une IP publique IPv4 et IPv6, plus une IP privée si on configure un Network Hetzner — recommandé pour isoler le trafic Kubernetes interne.
Créer un Network Hetzner avec la plage 10.0.0.0/16 et l’attacher aux trois VPS. Cela donne à chaque nœud une IP secondaire 10.0.0.x utilisable comme adresse interne du cluster. Les communications entre nœuds passent ainsi par le réseau privé Hetzner — gratuit, sécurisé, et plus performant que l’IP publique. Cette architecture imite les bonnes pratiques cloud d’AWS VPC ou Azure VNet.
Configurer ensuite les hostnames dans /etc/hosts sur les trois nœuds pour la résolution croisée. Désactiver swap (obligatoire pour kubeadm) : swapoff -a et commenter la ligne swap dans /etc/fstab. Activer les modules kernel br_netfilter et overlay, ajuster les sysctl pour le forward IP. Ces préparations sont les mêmes que celles attendues à l’examen — les pratiquer ici construit le réflexe.
Étape 2 — Installer containerd et kubeadm
Sur les trois nœuds, installer le runtime containerd (remplaçant officiel de Docker depuis la dépréciation de dockershim). Ajouter le dépôt Docker, installer containerd.io, configurer le SystemdCgroup à true dans /etc/containerd/config.toml — étape souvent oubliée qui empêche kubeadm init de réussir.
apt update && apt install -y containerd.io mkdir -p /etc/containerd containerd config default | tee /etc/containerd/config.toml sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml systemctl restart containerd
Installer ensuite kubeadm, kubelet et kubectl depuis le dépôt officiel Kubernetes. Pour préparer la CKA, choisir la version mineure correspondant à l’examen actuel (v1.34 en 2026) : apt-get install -y kubelet=1.34.* kubeadm=1.34.* kubectl=1.34.*. Verrouiller ces versions avec apt-mark hold pour éviter les mises à jour automatiques qui casseraient le cluster.
Étape 3 — Initialiser le control plane
Sur le nœud cka-cp1, initialiser le cluster avec kubeadm en spécifiant l’IP privée Hetzner comme advertise-address et la plage CIDR pour les pods.
kubeadm init \ --apiserver-advertise-address=10.0.0.2 \ --pod-network-cidr=192.168.0.0/16 \ --kubernetes-version=v1.34.0
kubeadm pull les images, génère les certificats, démarre etcd, configure l’API server et les autres composants control plane. Au bout de quelques minutes, l’output affiche la commande kubeadm join à exécuter sur les workers. Copier cette commande pour la suite. Configurer ensuite kubectl côté admin :
mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config kubectl get nodes # cka-cp1 NotReady — c'est normal, manque CNI
Le statut NotReady persiste tant que le CNI (Container Network Interface) n’est pas installé. Déployer Calico pour bénéficier de NetworkPolicy — fonctionnalité testée à l’examen : kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/calico.yaml. Attendre 1 à 2 minutes que les pods Calico démarrent, le node passe alors en statut Ready.
Étape 4 — Joindre les workers
Sur cka-w1 puis cka-w2, exécuter la commande kubeadm join précédemment copiée. La commande contient un token et un hash de certificat qui authentifient le worker auprès du control plane. Si le token a expiré (validité 24 heures), regénérer côté control plane avec kubeadm token create --print-join-command.
Au bout de quelques secondes, vérifier depuis le control plane : kubectl get nodes doit afficher les trois nœuds en Ready. Le cluster est opérationnel. Tester en déployant un pod basique : kubectl run nginx --image=nginx, vérifier qu’il démarre. À ce stade, l’environnement de pratique CKA est prêt.
Étape 5 — Pratiquer les tâches d’examen
Sur ce cluster, pratiquer systématiquement les tâches récurrentes de la CKA. Premier : etcd backup et restore. Snapshot avec etcdctl snapshot save, simulation de perte de données, restauration avec etcdctl snapshot restore. Refaire l’exercice cinq fois jusqu’à pouvoir l’exécuter sans documenter. Deuxième : upgrade du control plane via kubeadm upgrade — drainer les nœuds, upgrader kubeadm puis kubelet, valider le bon fonctionnement.
Troisième tâche essentielle : bootstrap d’un nouveau worker via kubeadm join avec génération de token. Quatrième : configuration RBAC complète — créer un compte de service, lui attribuer un Role et un RoleBinding limités à un namespace, vérifier les permissions avec kubectl auth can-i. Cinquième : NetworkPolicy qui isole un namespace en autorisant uniquement certains flux. Ces cinq exercices couvrent à eux seuls une part significative du score d’examen.
Automatisation du provisioning avec Terraform
Pour gagner du temps lors de la reprovisioning du cluster (snapshots Hetzner ne préservent pas toujours toutes les configurations réseau), automatiser via Terraform. Un fichier main.tf minimaliste de 50 lignes décrit les trois VPS, le Network Hetzner, les firewalls, les clés SSH. Une commande terraform apply reproduit l’environnement complet en moins de cinq minutes. Pour les apprenants intensifs, cette automatisation économise des dizaines d’heures sur la durée de la préparation.
Combiner Terraform avec Ansible pour la configuration post-provisioning. Ansible installe containerd, kubeadm, configure les sysctl, désactive le swap. L’ensemble VPS-bare à cluster fonctionnel tient en quinze minutes automatiques. Cette chaîne IaC est en plus une compétence valorisée à l’examen — les questions sur l’installation et la configuration tombent fréquemment et l’expérience hands-on de répétitions reproductibles construit la confiance.
Architecture HA pour aller plus loin
Une fois le cluster mono-control-plane maîtrisé, passer à une architecture HA avec trois control planes. Cette configuration n’apparaît pas systématiquement à l’examen mais constitue un excellent exercice de consolidation. Déployer un loadbalancer (HAProxy ou keepalived) devant les trois APIs servers, ajuster kubeadm init avec --control-plane-endpoint pointant vers le LB, joindre les autres control planes avec un certificat partagé. Cette architecture résiliente correspond aux clusters de production réels chez les grandes entreprises ouest-africaines qui ont basculé sur Kubernetes.
L’investissement en VPS pour une architecture HA (5 à 6 VPS au total avec workers) tourne autour de 30 EUR par mois. Pour les apprenants qui veulent se positionner comme architectes Kubernetes seniors, cette pratique est non négociable. Les recruteurs distinguent immédiatement un candidat qui a opéré un cluster HA d’un candidat qui n’a touché qu’à un mono-nœud — différence de salaire de plusieurs centaines de milliers de XOF par mois en CDI senior.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| kubeadm init échoue avec « swap not disabled » | Swap actif | swapoff -a et commenter dans /etc/fstab |
| Pods en pending éternel après init | CNI non installé | Déployer Calico ou Flannel après kubeadm init |
| SystemdCgroup non configuré | Containerd par défaut utilise cgroupfs | Modifier /etc/containerd/config.toml et redémarrer |
| Workers ne joignent pas | Firewall ou ports bloqués | Ouvrir 6443, 2379-2380, 10250 entre nœuds |
Adaptation au contexte ouest-africain
Pour les apprenants depuis Dakar ou Abidjan, la latence vers Hetzner Falkenstein reste autour de 80 ms — parfaitement acceptable pour la pratique kubectl et SSH. Pour économiser, l’idéal est de provisionner les VPS uniquement pendant les sessions de pratique et de les supprimer entre temps via les snapshots Hetzner. Un snapshot coûte quelques centimes par mois et permet de restaurer le cluster en deux minutes pour la session suivante. Cette discipline ramène le coût total de pratique à environ 2 à 5 EUR par mois selon l’intensité d’usage.
Optimisation du temps de pratique
Pour maximiser le rendement des heures investies, structurer chaque session de pratique en trois phases. Premier : 15 minutes de révision théorique du sujet visé (par exemple NetworkPolicy). Deuxième : 60 à 90 minutes de pratique intensive sur le cluster avec exercices type Killer.sh. Troisième : 15 minutes de prise de notes des points difficiles, des commandes utiles découvertes, des concepts à approfondir. Cette discipline transforme du temps brut en apprentissage durable.
Pour les apprenants en groupe, organiser des sessions hebdomadaires où chacun à tour présente une tâche d’examen et la résout en live. Les autres observent, suggèrent des optimisations, partagent leurs propres approches. Cette dynamique d’entraide accélère drastiquement la montée en compétence collective et crée une émulation positive. À ITSkillsCenter, plusieurs cohortes ont validé la CKA en groupe via cette méthode avec des taux de réussite supérieurs à 80 % à la première tentative.
Variantes d’architecture pour la pratique avancée
Au-delà du cluster kubeadm standard, plusieurs architectures alternatives méritent la pratique. Variante 1 : cluster avec containerd remplacé par CRI-O. CRI-O est le runtime alternatif officiel pour Kubernetes, plus léger que containerd. Le déployer permet de comprendre les abstractions du Container Runtime Interface et de débugger les problèmes runtime côté node — compétence valorisée à l’examen quand les troubleshooting questions touchent au CRI.
Variante 2 : cluster avec Cilium au lieu de Calico. Cilium est le CNI moderne basé sur eBPF qui apporte des performances supérieures et des fonctionnalités avancées (Hubble pour l’observabilité, ClusterMesh pour multi-cluster). La maîtrise de Cilium devient un différenciateur majeur sur le marché DevOps senior. Variante 3 : ajout d’un node Linux mais avec des taints dédiés à des workloads spéciaux — exercice qui prépare aux questions sur les taints/tolerations et node selectors.
Sauvegarde et reprise de l’environnement
Pour ne pas perdre les heures de configuration patiemment construites, scripter la sauvegarde régulière du cluster. Backup etcd via etcdctl snapshot save hebdomadaire vers un Storage Box Hetzner à 4 EUR par mois. Conserver aussi les fichiers de configuration kubeadm dans un dépôt Git privé. Ces sauvegardes facilitent la reprise rapide après un incident lors d’une session de pratique trop ambitieuse — par exemple casser intentionnellement le cluster pour pratiquer le troubleshooting et restaurer en cinq minutes.
Cette pratique du chaos contrôlé est extrêmement formatrice. Casser le DNS du cluster, débrancher etcd, tuer un pod control plane, supprimer accidentellement un namespace — chaque scénario simule une vraie panne et oblige le candidat à mobiliser ses connaissances de troubleshooting. Plus l’environnement de pratique est résilient à ces expérimentations, plus la confiance en sortie est élevée le jour de l’examen.
Intégration avec un cluster managé pour comparaison
Une fois la maîtrise de kubeadm acquise, déployer en parallèle un cluster GKE Autopilot ou EKS pour comparer les approches. Le cluster managé cache les composants control plane mais expose la même API kubectl — exercice formateur pour comprendre où s’arrête la responsabilité de l’administrateur sur chaque type de plateforme. Pour les freelances qui prévoient de travailler avec des clients sur AWS ou GCP, cette double exposition est précieuse : l’examen valide kubeadm mais le marché valorise aussi la connaissance des plateformes managées.
Hetzner Cloud propose aussi depuis 2024 un service Kubernetes managé en bêta. Pour les apprenants qui veulent rester dans l’écosystème Hetzner par simplicité, c’est une voie alternative. Toutefois, la pratique sur kubeadm reste indispensable pour la CKA — l’examen porte sur l’administration manuelle du cluster, pas sur l’utilisation d’un service managé.
Communauté locale et entraide
Plusieurs groupes Telegram et Discord rassemblent des apprenants Kubernetes francophones d’Afrique de l’Ouest. Les meetups CNCF Dakar et Abidjan se réunissent trimestriellement pour échanger sur les retours d’expérience CKA, CKAD, CKS. Participer à ces communautés accélère drastiquement la progression — questions techniques qui auraient pris des heures à creuser seul se résolvent en quelques minutes par échange. Plusieurs cohortes ITSkillsCenter ont validé leur certification grâce à ces dynamiques d’entraide structurées.
Pour les apprenants qui se sentent isolés, contribuer à des projets open source Kubernetes en français (documentation, traductions, packaging Helm communautaire) construit un réseau professionnel international tout en gagnant en compétence pratique. Cette stratégie d’apprentissage par la contribution est l’un des meilleurs investissements pour un ingénieur en début de carrière.
L’écosystème CNCF francophone se développe rapidement et offre des opportunités de visibilité aux contributeurs ouest-africains qui s’investissent dans la durée.
Pour aller plus loin
🔝 Retour à l’article principal : CKA depuis l’Afrique de l’Ouest. Documentation kubeadm officielle : kubernetes.io/docs/setup/production-environment/tools/kubeadm, dépôt Calico : docs.tigera.io. La pratique régulière sur ce cluster construit progressivement les automatismes nécessaires à l’examen — la différence entre un candidat qui réussit du premier coup et un qui échoue tient principalement à l’aisance opérationnelle développée par la répétition pratique.
Documenter dans un journal personnel chaque session de pratique avec les tâches réalisées, les erreurs rencontrées, les commandes mémorisées. Cette discipline transforme les heures de pratique en compétence durable et facilite la révision finale avant l’examen. Pour les apprenants ITSkillsCenter qui passent la CKA en groupe, partager ce journal entre pairs accélère l’apprentissage collectif et crée une dynamique d’entraide précieuse pendant la phase intensive de préparation.