Kubernetes 036 – K0S : cluster multi-nodes avec Vagrant

TL;DR

k0s permet d’installer un cluster Kubernetes avec peu de dependances. Associe a Vagrant, il devient pratique pour construire un lab multi-noeuds jetable: une VM control plane, plusieurs workers, une configuration reseau stable et des commandes reproductibles.

La video de reference

Video: https://www.youtube.com/watch?v=HmldH-h819o

L’episode montre comment passer d’un cluster simple a un environnement multi-noeuds utile pour tester scheduling, reseau, services et contraintes.

Pourquoi utiliser Vagrant ?

Vagrant permet de declarer des machines virtuelles dans un fichier. Au lieu de creer manuellement plusieurs VM, on decrit leur nombre, leur image, leur IP et les scripts de provisionnement.

Pour apprendre Kubernetes, c’est tres utile: on peut casser le cluster, recommencer, modifier la topologie et garder une trace de l’installation.

Pourquoi k0s ?

k0s est une distribution Kubernetes legere. Elle embarque les composants necessaires et simplifie l’installation. Elle convient bien aux labs, a l’edge et aux environnements ou l’on veut limiter la complexite initiale.

Le but n’est pas de dire que k0s remplace toutes les distributions, mais de disposer d’un chemin rapide vers un cluster fonctionnel.

Topologie de lab

Une topologie simple peut ressembler a ceci:

• master1 avec l’API Server et les composants control plane;
• worker1 pour executer des pods;
• worker2 pour tester la repartition;
• un reseau prive Vagrant pour que les noeuds communiquent.

Cette topologie suffit pour observer le placement des pods et les effets d’une indisponibilite de worker.

Exemple de Vagrantfile simplifie

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

  {
    "master1" => "192.168.56.10",
    "worker1" => "192.168.56.11",
    "worker2" => "192.168.56.12"
  }.each do |name, ip|
    config.vm.define name do |node|
      node.vm.hostname = name
      node.vm.network "private_network", ip: ip
      node.vm.provider "virtualbox" do |vb|
        vb.memory = 2048
        vb.cpus = 2
      end
    end
  end
end

Ce fichier ne suffit pas a lui seul a installer k0s, mais il pose la base du lab.

Installation du control plane

Sur le noeud master, le principe est d’installer k0s puis de lancer le service control plane:

curl -sSLf https://get.k0s.sh | sudo sh
sudo k0s install controller --single
sudo systemctl start k0scontroller
sudo k0s kubectl get nodes

Selon la version et la topologie, les options exactes peuvent varier. Il faut toujours verifier la documentation k0s correspondant a la version utilisee.

Ajouter des workers

Le control plane genere un token de jointure:

sudo k0s token create --role=worker > worker.token

Sur chaque worker, on installe k0s puis on rejoint le cluster avec ce token:

curl -sSLf https://get.k0s.sh | sudo sh
sudo k0s install worker --token-file worker.token
sudo systemctl start k0sworker

La logique importante est la meme que dans d’autres installations: le control plane accepte le noeud, le kubelet demarre, puis le noeud apparait dans l’API.

Verifications

sudo k0s kubectl get nodes -o wide
sudo k0s kubectl get pods -A
sudo k0s kubectl run nginx --image=nginx
sudo k0s kubectl get pods -o wide

La colonne NODE permet de voir ou le pod a ete planifie.

Exporter le kubeconfig

Pour utiliser kubectl depuis la machine hote:

sudo k0s kubeconfig admin > kubeconfig
export KUBECONFIG=$PWD/kubeconfig
kubectl get nodes

Il faut adapter l’adresse de l’API Server si le kubeconfig pointe vers une adresse non accessible depuis l’hote.

Liens utiles

• Video: https://www.youtube.com/watch?v=HmldH-h819o
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Documentation k0s: https://docs.k0sproject.io/
• Noeuds Kubernetes: https://kubernetes.io/docs/concepts/architecture/nodes/

FAQ

k0s est-il Kubernetes ?

Oui, k0s distribue Kubernetes avec des choix d’installation et d’empaquetage.

Pourquoi plusieurs workers dans un lab ?

Pour observer le scheduling, les labels de noeuds, les tolerations et les pannes.

Vagrant est-il obligatoire ?

Non. Il sert surtout a rendre le lab reproductible localement.

Erreurs frequentes

• Ne pas attribuer assez de memoire aux VM.
• Oublier le reseau prive entre les noeuds.
• Utiliser un kubeconfig dont l’adresse API n’est pas joignable depuis l’hote.
• Confondre le role controller k0s et le role worker.

Pour pratiquer

Deployez trois replicas nginx et observez leur placement:

kubectl create deployment web --image=nginx --replicas=3
kubectl get pods -o wide

Arretez ensuite un worker Vagrant et observez les statuts des pods.

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 037 – Affinites : required de podAffinity et nodeAffinity.

Conclusion

k0s avec Vagrant fournit un excellent terrain d’apprentissage. On obtient un vrai cluster multi-noeuds, mais encore assez simple pour comprendre chaque etape.