Premier lab : un cluster k8s

2.1 Créer le cluster

vcluster create lab-1 \
  --set 'experimental.docker.nodes[0].name=worker-1' \
  --set 'experimental.docker.nodes[1].name=worker-2'

C’est tout. vind télécharge l’image, démarre le control plane dans un conteneur Docker, ajoute un conteneur par worker déclaré (ici 2) et configure automatiquement votre kubeconfig sur ce cluster.

ℹ️ Combien de replicas ? Avec vind, le nombre de workers = le nombre d’entrées dans experimental.docker.nodes (chaque --set 'experimental.docker.nodes[N].name=…' ajoute un node). Le control plane, lui, est toujours un conteneur unique : il n’y a pas de replicas de control plane avec le driver docker. La haute disponibilité du control plane (controlPlane.statefulSet.highAvailability.replicas) n’existe qu’avec le driver helm, dans un cluster Kubernetes hôte.

Pour un lab plus large, il suffit d’ajouter des entrées — ici 3 workers :

vcluster create lab-2 \
  --set 'experimental.docker.nodes[0].name=worker-1' \
  --set 'experimental.docker.nodes[1].name=worker-2' \
  --set 'experimental.docker.nodes[2].name=worker-3'

Et si vous avez besoin d’un control plane en 3 replicas (haute disponibilité), ce n’est pas le rôle de vind : basculez sur le driver helm dans un cluster Kubernetes hôte :

vcluster create lab-ha --driver helm \
  --set 'controlPlane.statefulSet.highAvailability.replicas=3' \
  --set 'controlPlane.backingStore.etcd.deploy.enabled=true' \
  --set 'controlPlane.backingStore.etcd.deploy.statefulSet.highAvailability.replicas=3'

⚠️ Ce mode HA nécessite un cluster hôte avec au moins 3 nodes (anti-affinité des replicas) et un backing store partagé — ici un etcd dédié déployé en 3 replicas lui aussi. Astuce : le cluster hôte peut être… un cluster vind multi-node (lab-1 ci-dessus) ! Un vCluster helm dans un cluster vind, c’est parfait pour un lab HA sur une seule machine.

❌ Piège testé pour vous : ces mêmes valeurs HA avec --driver docker ne fonctionnent pas — vind bascule en mode standalone mono-instance et backingStore.etcd.deploy pointe vers un Service Kubernetes (lab-ha-etcd:2379) qui n’existera jamais dans un réseau Docker. Résultat : lookup lab-ha-etcd … server misbehaving, l’apiserver ne démarre pas, timeout après 3 minutes. En driver docker, le backing store est géré en interne : ne configurez rien.

kubectl get nodes
kubectl get namespaces

ℹ️ Version de Kubernetes par défaut : v1.35. Chaque cluster est totalement isolé des autres.

2.2 Déployer une application avec un vrai LoadBalancer

Là où KinD nécessite MetalLB ou du port-mapping, vind fournit un LoadBalancer natif :

kubectl create deployment hello --image=nginx
kubectl expose deployment hello --port=80 --type=LoadBalancer
kubectl get service hello

Sur Linux, le service reçoit directement une EXTERNAL-IP joignable depuis votre machine :

curl http://<EXTERNAL-IP>

⚠️ Sur macOS, l’IP n’est pas routable directement (limitation Docker Desktop) : utilisez kubectl port-forward deployment/hello 8080:80 puis curl localhost:8080.

⚠️ Piège terminal : kubectl get service --watch et kubectl port-forward sont des commandes bloquantes — elles occupent le terminal jusqu’à Ctrl+C. Lancez-les dans un second terminal si vous voulez continuer à travailler.

2.3 Pause et reprise — la killer feature pour les labs

Fin de la session de formation ? On met le lab en pause au lieu de le détruire :

vcluster pause lab-1

Le cluster ne consomme plus ni CPU ni RAM, mais tout son état est conservé (déploiements, services, données etcd). Le lendemain :

vcluster resume lab-1
vcluster connect lab-1   # rebranche le kubeconfig
kubectl get pods         # tout est encore là

Lister ses clusters et leur état :

vcluster list

2.4 Nettoyage

vcluster delete lab-1

✅ Checkpoint : vous savez créer, exposer, mettre en pause, reprendre et supprimer un cluster.