Prérequis et installation

1.1 Prérequis

• Docker installé et démarré (docker ps doit répondre)

• Au moins 4 Go de RAM disponibles pour Docker

• kubectl installé

• Linux, macOS ou Windows (les exemples ci-dessous sont pour Linux)

⚠️ Prérequis noyau (Linux) — limites inotify. Chaque node vind est un conteneur qui fait tourner systemd + kubelet + apiserver, gros consommateurs d’inotify. La valeur Linux par défaut fs.inotify.max_user_instances = 128 est vite épuisée dès qu’on a plusieurs clusters/nodes en parallèle. Symptôme typique : la création se fige sur Waiting for vCluster standalone node to be joined... puis fatal ... Node couldn't join: signal: killed, et les logs du control plane montrent error creating fsnotify watcher: too many open files. Relevez les limites une fois pour toutes :

sudo tee /etc/sysctl.d/99-vcluster-inotify.conf >/dev/null <<'EOF'
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches   = 524288
EOF
sudo sysctl --system

(Même prérequis que kind ou k3d en multi-cluster.)

1.2 Installer la CLI vcluster

vind n’est pas un binaire séparé : c’est un driver de la CLI vcluster.

# Linux AMD64
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64" \
  && sudo install -c -m 0755 vcluster /usr/local/bin \
  && rm -f vcluster

Autres plateformes :

# macOS (Homebrew)
brew install loft-sh/tap/vcluster

# Linux ARM64
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-arm64" \
  && sudo install -c -m 0755 vcluster /usr/local/bin \
  && rm -f vcluster

Vérification :

vcluster --version
# vcluster version 0.34.x ou plus récent

1.3 Activer le driver Docker (= vind)

Par défaut, vcluster déploie des clusters virtuels dans un cluster Kubernetes existant. Pour les labs, on bascule sur le driver docker — c’est ça, vind :

vcluster use driver docker

Ce réglage est persistant. Pour revenir en arrière plus tard : vcluster use driver helm.

✅ Checkpoint : vcluster --version répond et le driver docker est activé.

1.4 ⚠️ Desktop Linux : isolez vos labs dans une VM

vind lance chaque node dans un conteneur --privileged qui exécute un vrai systemd. Sur un poste de travail Linux (session graphique), ce conteneur voit les périphériques de l’hôte — avec deux effets de bord sévères constatés :

• le getty du conteneur s’attache à la console tty physique → écran de login parasite, session graphique figée ;

• le systemd-logind du conteneur capte le bouton power de l’hôte → extinction brutale de la machine (le conteneur a CAP_SYS_BOOT).

Parade recommandée : faites tourner les labs dans une VM (multipass, virt-manager, Proxmox…). C’est le setup utilisé dans toute la suite de cette formation : si un lab dérape, seule la VM trinque. Sur un serveur headless ou dans un CI, le risque console/bouton power ne se pose pas.

Alternative : l’image patchée labs/Dockerfile, qui masque gettys, systemd-logind et ctrl-alt-del.target dans le node :

cd labs
docker build -t vm-container-nogetty:latest .

Elle est ensuite référencée via experimental.docker.image (voir les fichiers labs/vcluster-*.yaml).