Monter un cluster Kubernetes 1.35 CKAD avec kind sur VPS Hostinger 2026

📍 Article principal du cluster : CKAD Certified Kubernetes Application Developer — guide pratique 2026

Ce tutoriel fait partie du cluster certification CKAD. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Avant d’attaquer les manifests YAML et les patterns CKAD, il faut un cluster Kubernetes réel sur lequel pratiquer. Pas un docker-compose, pas une application K8s simulée — un vrai cluster avec un control plane, un kubelet, un kube-proxy, et un CNI fonctionnel. Ce tutoriel monte un cluster Kubernetes 1.35 en 25 minutes sur un VPS Hostinger en utilisant kind (Kubernetes IN Docker), configure kubectl avec les alias indispensables pour l’examen, et installe les outils complémentaires que vous devez avoir sous la main : `kubectx`, `kubens`, `stern`, `k9s`. À la fin, vous aurez un environnement de pratique identique à celui du simulateur officiel Linux Foundation.

Prérequis

• VPS Hostinger Premium Web Hosting Ubuntu 24.04 (4 Go RAM minimum)
• Accès SSH root
• Notions Linux de base (apt, systemctl, vim/nano)
• 30 minutes

Étape 1 — Préparer le VPS

On installe d’abord les utilitaires de base et Docker, puisque kind utilise Docker comme runtime pour héberger les nœuds Kubernetes virtuels. Le choix de Docker ici est délibéré : c’est l’environnement le plus proche de ce qui est testé sur le simulateur Linux Foundation et dans la majorité des entreprises ouest-africaines.

apt update && apt upgrade -y
apt install -y curl wget gnupg2 software-properties-common ca-certificates jq

# Installation Docker depuis le dépôt officiel
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
apt update && apt install -y docker-ce docker-ce-cli containerd.io
systemctl enable --now docker
docker run --rm hello-world

La sortie doit afficher le message « Hello from Docker! » qui confirme que le démon tourne et qu’il peut télécharger des images depuis Docker Hub. Si vous obtenez « Cannot connect to the Docker daemon », vérifiez `systemctl status docker` et les logs `journalctl -u docker -n 50`.

Étape 2 — Installer kubectl 1.35

kubectl est le couteau suisse de l’examen CKAD. Vous passerez 95 % de votre temps dans cette commande. La version doit correspondre exactement à la version du cluster pour éviter les incompatibilités d’API mineures.

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
install -m 0755 -o root -g root kubectl /usr/local/bin/kubectl
kubectl version --client

La sortie doit indiquer `Client Version: v1.35.x`. Si vous voyez une version 1.34 ou inférieure, le binaire pris est obsolète — re-téléchargez en forçant la version : `curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl`.

Étape 3 — Installer kind et créer le cluster

kind crée des clusters Kubernetes en utilisant des conteneurs Docker comme nœuds. Pour CKAD, on monte un cluster avec 1 control plane et 2 workers — la topologie minimale qui ressemble à ce qu’on rencontre en entreprise.

curl -Lo /usr/local/bin/kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-amd64
chmod +x /usr/local/bin/kind
kind version

cat > /tmp/kind-ckad.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: ckad-prep
nodes:
- role: control-plane
- role: worker
- role: worker
networking:
  apiServerAddress: "127.0.0.1"
  apiServerPort: 6443
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
EOF

kind create cluster --config /tmp/kind-ckad.yaml --image kindest/node:v1.35.0
kubectl cluster-info --context kind-ckad-prep
kubectl get nodes -o wide

La création prend 90-120 secondes. La sortie de `kubectl get nodes` doit lister 3 nœuds en état `Ready`. Si un nœud reste en `NotReady`, c’est généralement le CNI par défaut (kindnet) qui n’a pas fini son initialisation — attendez 30 secondes et relancez. Si le problème persiste, recréez le cluster avec `kind delete cluster –name ckad-prep` puis relancez la création.

Étape 4 — Configurer les alias kubectl indispensables

À l’examen, chaque seconde compte. Les alias et l’autocompletion bash réduisent le temps de frappe de 30-40 %. Cette configuration est exactement celle qui est disponible sur le simulateur officiel — autant l’avoir en main avant le jour J.

cat >> ~/.bashrc <<'EOF'
alias k=kubectl
complete -F __start_kubectl k
source <(kubectl completion bash)
export do="--dry-run=client -o yaml"
export now="--force --grace-period 0"
EOF

source ~/.bashrc

# Test des alias
k get nodes
k run nginx --image=nginx $do | head -10

L’export `do` est l’astuce la plus rentable du parcours CKAD : `k run nginx –image=nginx $do > pod.yaml` génère un manifest YAML prêt à éditer en une commande. L’export `now` permet une suppression immédiate sans grâce period quand un Pod est bloqué : `k delete pod nginx $now`. Ces deux variables sont autorisées sur le simulateur examen.

Étape 5 — Installer kubectx, kubens et stern

L’examen utilise plusieurs clusters et plusieurs namespaces. Lire à chaque énoncé « switch to cluster X namespace Y » avant de répondre est essentiel — et `kubectx`/`kubens` accélèrent ce switch de plusieurs commandes à un seul mot.

git clone https://github.com/ahmetb/kubectx /opt/kubectx
ln -s /opt/kubectx/kubectx /usr/local/bin/kubectx
ln -s /opt/kubectx/kubens /usr/local/bin/kubens

# stern — logs multi-pods en parallèle (utile pour debug observabilité)
curl -Lo /tmp/stern.tar.gz https://github.com/stern/stern/releases/download/v1.31.0/stern_1.31.0_linux_amd64.tar.gz
tar -xzf /tmp/stern.tar.gz -C /usr/local/bin stern

kubectx
kubens
stern --version

`kubectx` liste les contextes disponibles et permet de basculer avec `kubectx kind-ckad-prep`. `kubens` fait pareil pour les namespaces. `stern` agrège les logs de plusieurs Pods en temps réel — particulièrement utile pour le domaine 5 (observabilité) où on doit fréquemment debug une chaîne de microservices.

Étape 6 — Tester l’environnement avec un Pod simple

On valide tout avec un Pod nginx minimaliste. C’est le réflexe à avoir pour vérifier qu’un environnement est opérationnel avant de commencer du travail sérieux.

k run test-pod --image=nginx
k get pods -w &
sleep 15
k get pod test-pod
k describe pod test-pod | head -20
k port-forward pod/test-pod 8080:80 &
sleep 3
curl -s http://localhost:8080 | head -5
k delete pod test-pod $now

Vous devez voir le Pod passer par les états Pending → ContainerCreating → Running, puis répondre à la requête HTTP avec la page d’accueil nginx par défaut. Si le Pod reste en Pending, `kubectl describe pod test-pod` affiche les Events qui expliquent pourquoi (souvent un problème de ressources ou d’image pulling).

Étape 7 — Installer k9s pour la navigation interactive

k9s n’est pas obligatoire à l’examen mais c’est un excellent outil pour s’entraîner — il visualise interactive les ressources Kubernetes dans le terminal. Particulièrement utile pour comprendre les relations entre Deployments, ReplicaSets et Pods en temps réel.

curl -sS https://webinstall.dev/k9s | bash
source ~/.config/envman/PATH.env
k9s --version
# Lancer l'interface : k9s

k9s affiche un dashboard textuel par défaut sur les Pods. Naviguez avec les flèches, `:deployments` pour basculer sur les Deployments, `?` pour l’aide. Pour ressortir, `:q`. C’est l’équivalent de l’UI Kubernetes Dashboard mais en terminal — beaucoup plus rapide pour le debug quotidien.

Étape 8 — Sauvegarder l’état du cluster pour reprise rapide

kind permet d’exporter et restaurer un cluster, mais en pratique pour le CKAD on supprime et recrée plutôt — c’est plus rapide que toute manipulation d’export. Néanmoins, il est utile de versionner votre fichier de configuration kind et vos manifests d’exemple dans un dépôt Git pour reprise rapide après réinstallation.

mkdir -p ~/ckad-prep/manifests
cd ~/ckad-prep
cp /tmp/kind-ckad.yaml ./
git init && git add . && git commit -m "CKAD prep environment"

# Pour repartir from scratch :
# kind delete cluster --name ckad-prep
# kind create cluster --config kind-ckad.yaml

Cette discipline de versioning est utile au-delà de l’examen : les manifests CKAD que vous écrirez pendant la pratique deviennent la base de votre future bibliothèque personnelle de patterns Kubernetes.

Comprendre kind vs minikube vs k3s — choisir le bon outil pour pratiquer

Trois alternatives populaires existent pour monter un Kubernetes de pratique. kind (ce tutoriel) utilise Docker comme runtime et permet de lancer plusieurs clusters en parallèle sur la même machine. Léger, rapide, identique au simulateur officiel CKAD. Limitation : pas de LoadBalancer cloud-natif, pas de Persistent Volumes dynamiques sans configuration additionnelle.

minikube est l’outil historique de la CNCF. Il supporte plusieurs drivers (Docker, VirtualBox, KVM, Podman) et propose des addons natifs pour ingress nginx, dashboard, metrics-server, registry. C’est un excellent choix si vous voulez tester des fonctionnalités avancées qui ne sont pas couvertes par CKAD mais qui restent utiles au quotidien.

k3s est la distribution Kubernetes minimaliste de Rancher. Elle remplace etcd par sqlite par défaut et tourne en un seul binaire de moins de 60 Mo. Idéale pour de la production légère sur un VPS Hostinger Cloud Startup ou pour un edge computing. Moins représentative de l’environnement examen CKAD mais excellente pour des projets personnels post-certification.

Pour la préparation CKAD strictement, restez sur kind. Pour la pratique post-certification, expérimentez les trois pour comprendre leurs trade-offs.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les apprenants à Dakar, Abidjan ou Bamako qui montent un labo CKAD personnel, le VPS Hostinger Premium à 2,99 USD/mois est largement suffisant pour un cluster kind 3 nœuds. Comptez environ 2 Go de RAM utilisés en charge légère. Si vous voulez tester du Helm avec des charts gourmands (Prometheus stack, Loki, Grafana), passez à Hostinger Cloud Startup à 9,99 USD/mois pour avoir 3 Go RAM dédiés et 200 Go SSD. Cette montée en gamme est nécessaire à partir de la semaine 7 quand vous attaquerez le domaine observabilité avec des stacks de monitoring complètes.

Côté connectivité, kubectl fonctionne très bien sur des connexions 4G+ depuis le terrain — moins de 100 Ko de bande passante par commande hors logs streaming. Le simulateur d’examen Linux Foundation, en revanche, nécessite une connexion stable supérieure à 5 Mbps avec faible jitter. Testez votre connexion via `mtr -r www.linuxfoundation.org` la veille de l’examen.

Tutoriels frères

• Pods, multi-conteneurs et workloads — patterns CKAD essentiels (à venir)
• ConfigMaps, Secrets et ServiceAccounts — sécuriser une application Kubernetes (à venir)

Pour aller plus loin

• 🔝 Retour au pilier : CKAD Certified Kubernetes Application Developer — guide pratique 2026
• Documentation kind : kind.sigs.k8s.io
• Documentation kubectl : kubernetes.io/docs/reference/kubectl
• Repository kubectx : github.com/ahmetb/kubectx

FAQ

Pourquoi kind plutôt que minikube ?
kind est le plus proche du simulateur officiel CKAD et démarre plus vite (90 sec vs 3 min). Pour la préparation pure, c’est l’outil de référence en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer ; vérifier la source officielle avant toute décision technique).

Faut-il vraiment 3 nœuds pour pratiquer ?
Non, 1 control + 1 worker suffit pour la majorité des exercices CKAD. Les 3 nœuds permettent de pratiquer les pod scheduling, taints/tolerations, et NetworkPolicies multi-nœud. Si votre VPS a moins de 4 Go RAM, partez sur 2 nœuds.

Mots-clés secondaires : kind kubernetes 1.35, ckad pratique vps, kubectl alias examen, kind multi nodes, k9s ckad, kubectx kubens