Kubernetes 047 – Installation automatique avec Vagrant et kubeadm

TL;DR

Vagrant permet de provisionner plusieurs VM et d’executer les scripts d’installation kubeadm automatiquement. L’interet n’est pas seulement de gagner du temps: c’est de transformer une installation manuelle fragile en scenario reproductible.

La video de reference

Video: https://www.youtube.com/watch?v=p4v4QII3zB0

Elle montre comment automatiser les etapes vues dans les episodes kubeadm precedents.

Pourquoi automatiser ?

Une installation kubeadm contient beaucoup d’etapes: paquets, modules kernel, containerd, kubelet, init, CNI, join. Les faire a la main est pedagogique au debut, mais rapidement source d’erreurs.

Un lab automatise permet de tester plusieurs fois et de repartir d’un etat propre.

Structure possible

Un projet simple peut contenir:

Vagrantfile
scripts/common.sh
scripts/master.sh
scripts/worker.sh

common.sh prepare tous les noeuds. master.sh initialise le control plane. worker.sh rejoint le cluster.

Vagrantfile simplifie

Vagrant.configure("2") do |config|
  config.vm.box = "debian/bookworm64"

  ["master", "worker1", "worker2"].each_with_index do |name, i|
    config.vm.define name do |node|
      node.vm.hostname = name
      node.vm.network "private_network", ip: "192.168.56.#{10 + i}"
      node.vm.provision "shell", path: "scripts/common.sh"
    end
  end
end

Il faut ensuite specialiser le provisioning du master et des workers.

Script commun

#!/usr/bin/env bash
set -euo pipefail

swapoff -a
modprobe overlay
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1

apt-get update
apt-get install -y containerd kubelet kubeadm kubectl
systemctl enable --now containerd

Ce script doit etre adapte a la distribution et aux depots utilises.

Script master

#!/usr/bin/env bash
set -euo pipefail

kubeadm init \
  --apiserver-advertise-address=192.168.56.10 \
  --pod-network-cidr=10.244.0.0/16

mkdir -p /home/vagrant/.kube
cp /etc/kubernetes/admin.conf /home/vagrant/.kube/config
chown -R vagrant:vagrant /home/vagrant/.kube

kubeadm token create --print-join-command > /vagrant/join.sh

Le fichier /vagrant/join.sh est partage avec l’hote et peut etre utilise par les workers.

Script worker

#!/usr/bin/env bash
set -euo pipefail

while [ ! -f /vagrant/join.sh ]; do
  sleep 5
done

bash /vagrant/join.sh

En lab, cette logique suffit souvent. En production, on utiliserait un outil plus structure comme Ansible.

Points de synchronisation

L’automatisation doit gerer l’ordre: le master doit finir kubeadm init avant les workers. Le CNI doit etre applique avant d’attendre un cluster totalement Ready.

Ne pas gerer ces attentes produit des erreurs aleatoires.

Commandes Vagrant

vagrant up
vagrant ssh master
kubectl get nodes
kubectl get pods -A
vagrant destroy -f

La derniere commande est destructive, mais utile pour reconstruire un lab propre.

Liens utiles

• Video: https://www.youtube.com/watch?v=p4v4QII3zB0
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• kubeadm: https://kubernetes.io/docs/reference/setup-tools/kubeadm/
• Vagrant: https://developer.hashicorp.com/vagrant/docs

FAQ

Pourquoi ne pas tout faire avec Vagrant seulement ?

Vagrant cree les VM. Les scripts installent Kubernetes. Les deux roles sont complementaires.

Peut-on utiliser Ansible avec Vagrant ?

Oui, c’est meme une progression naturelle pour mieux organiser l’automatisation.

Le lab est-il adapte a la production ?

Non. Il sert a apprendre et tester.

Erreurs frequentes

• Lancer les workers avant que le token existe.
• Ne pas rendre le script idempotent ou relancable.
• Oublier d’installer le CNI.
• Coder en dur des IP sans verifier le reseau Vagrant.

Pour pratiquer

Ajoutez un troisieme worker dans le Vagrantfile, relancez le lab, puis verifiez que la commande de join reste reutilisable dans votre scenario.

Notions et definitions

• Control plane: ensemble des composants qui exposent l’API et prennent les decisions.
• Worker node: machine qui execute les pods applicatifs.
• Runtime et kubelet: briques locales responsables du lancement et du suivi des conteneurs.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Dans un cluster kubeadm, l’API Server recoit les manifests, le scheduler choisit un noeud, puis le kubelet demande au runtime de lancer les conteneurs.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Verifier les prerequis systeme: swap, modules kernel, runtime, reseau.
• Initialiser ou rejoindre le cluster selon le role du noeud.
• Installer un CNI avant d’attendre des pods applicatifs fonctionnels.
• Valider CoreDNS, nodes Ready et un deploiement de test.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser les composants d’un cluster, leur installation et les responsabilites entre control plane, workers et runtime. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get nodes -o wide
• kubectl -n kube-system get pods -o wide
• sudo crictl ps ou sudo systemctl status containerd kubelet sur les noeuds

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre installation reussie et cluster exploitable dans la duree
• ne pas verifier DNS, CNI, certificats et horloge apres l’installation
• oublier que la haute disponibilite depend aussi du load balancer et du reseau

Exercice conseille

Preparez une checklist post-installation: nodes Ready, CoreDNS fonctionnel, CNI actif, pod de test joignable et redemarrage d’un composant kube-system observe.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 048 – High Availability avec HAProxy et kubeadm.

Conclusion

Automatiser kubeadm avec Vagrant transforme une suite de commandes en lab reproductible. C’est une excellente transition entre apprentissage manuel et industrialisation.