Lab multi-node : simuler une vraie topologie

Un seul node, c’est bien pour débuter, mais beaucoup de sujets k8s (scheduling, affinités, taints, DaemonSets, drain…) nécessitent plusieurs nodes. Avec vind, chaque worker est un conteneur Docker supplémentaire.

3.1 Déclarer les workers dans vcluster.yaml

Créez un fichier vcluster.yaml :

experimental:
  docker:
    nodes:
      - name: worker-1
      - name: worker-2

3.2 Créer le cluster multi-node

vcluster create lab-multinode --values vcluster.yaml
kubectl get nodes

Vous obtenez un control plane + 2 workers, le tout sur une seule machine Docker.

3.3 Ajouter ou supprimer un node à chaud

Pas besoin de détruire le cluster pour changer sa topologie.

Ajouter un node — déclarez-le dans la config puis relancez create avec --upgrade. vind réconcilie : il crée le conteneur manquant et le node rejoint le cluster en ~15 s.

# On passe de 2 à 3 workers
vcluster create lab-multinode --driver docker --upgrade \
  --set 'experimental.docker.nodes[0].name=worker-1' \
  --set 'experimental.docker.nodes[1].name=worker-2' \
  --set 'experimental.docker.nodes[2].name=worker-3'

kubectl get nodes   # worker-3 apparaît en STATUS Ready

💡 Avec un vcluster.yaml, ajoutez simplement l’entrée - name: worker-3 sous nodes: puis vcluster create lab-multinode --values vcluster.yaml --upgrade.

Supprimer un node — deux niveaux selon le besoin :

# 1. Retirer proprement le node du cluster (cordon + drain + suppression k8s)
vcluster node delete worker-3

⚠️ Piège vérifié : vcluster node delete retire le node de Kubernetes mais laisse tourner le conteneur Docker (il devient un « zombie », kubelet drainé mais process vivant). Pour libérer réellement CPU/RAM, supprimez aussi le conteneur :

# 2. Supprimer le conteneur Docker sous-jacent
docker rm -f vcluster.node.lab-multinode.worker-3

Pensez enfin à retirer l’entrée correspondante de votre vcluster.yaml : sinon un prochain create --upgrade recréerait le node zombie.

ℹ️ Convention de nommage des conteneurs vind : vcluster.node.<cluster>.<node> pour un worker, vcluster.cp.<cluster> pour le control plane. Un docker ps vous les liste.

3.4 Exercice : scheduling ciblé

Labelliser un node et y contraindre un déploiement :

kubectl label node worker-1 tier=frontend

kubectl create deployment web --image=nginx
kubectl patch deployment web -p '{"spec":{"template":{"spec":{"nodeSelector":{"tier":"frontend"}}}}}'

kubectl get pods -o wide   # les pods atterrissent sur worker-1

3.5 Exercice : taints et tolerations

Un taint NoSchedule n’évince pas les pods déjà en place : il faut créer de nouveaux pods pour observer l’effet. On taint worker-2, puis on déploie une application sans contrainte particulière :

kubectl taint node worker-2 dedicated=batch:NoSchedule

kubectl create deployment stress --image=nginx --replicas=6
kubectl get pods -o wide   # aucun pod "stress" n'atterrit sur worker-2

Sans toleration correspondante, le scheduler évite worker-2 — les 6 replicas se répartissent sur les autres nodes.

Idées d’exercices supplémentaires pour vos apprenants : DaemonSet (un pod par node), kubectl drain worker-1, podAntiAffinity entre les deux workers.

3.6 Nettoyage

vcluster delete lab-multinode

✅ Checkpoint : cluster à 3 nodes fonctionnel, scheduling et taints testés.