Kubernetes 006 – Cluster : le lightweight de K0s pour debuter

TL;DR

K0s est une distribution Kubernetes orientee simplicite d’installation. Pour debuter, l’objectif n’est pas de construire une plateforme de production parfaite, mais d’obtenir rapidement un cluster fonctionnel pour pratiquer kubectl, les pods et les objets de base.

La video de reference

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

Elle arrive au bon moment dans la serie: apres les concepts, il faut un terrain d’experimentation.

Pourquoi une distribution legere ?

Installer Kubernetes a la main peut etre formateur, mais aussi long et source de confusion. Une distribution legere reduit la friction: moins de composants a assembler soi-meme, plus de temps pour comprendre l’API, les manifests et les comportements.

K0s fait partie des options possibles pour un lab. D’autres outils existent selon le besoin: kind, minikube, k3s, kubeadm ou les clusters manages.

Ce qu’il faut verifier apres installation

kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -A
kubectl version

Ces commandes confirment que le client kubectl dialogue avec le cluster et que les composants systeme sont visibles.

Attention au contexte d’usage

Un cluster de formation n’est pas automatiquement un cluster de production. Pour produire, il faudra traiter la haute disponibilite, les sauvegardes, la supervision, le reseau, la securite, les mises a jour et les politiques d’acces.

Liens utiles

• Video: https://www.youtube.com/watch?v=jRKhHYoFsmU
• K0s: https://k0sproject.io/
• Installation Kubernetes: https://kubernetes.io/docs/setup/
• Outils pour environnement d’apprentissage: https://kubernetes.io/docs/setup/learning-environment/
• Formation Enix Kubernetes: https://2026-05-enix.container.training/2.yml.html

FAQ

K0s est-il obligatoire pour apprendre Kubernetes ?

Non. C’est une option. L’important est d’avoir un cluster fiable pour manipuler les objets.

Peut-on apprendre avec un cluster local ?

Oui, tant que l’environnement permet de pratiquer les commandes et les manifests.

Quelle commande confirme que le cluster repond ?

kubectl cluster-info donne un premier signal simple.

Ce qu’on attend d’un cluster de lab

Un cluster de lab doit etre simple a recreer, suffisamment proche de Kubernetes standard, et assez leger pour permettre des essais rapides. Le but n’est pas d’avoir toutes les garanties d’une plateforme de production, mais de pratiquer sans passer son temps a reparer l’installation.

Pour cette raison, il faut documenter trois choses des le depart: comment installer, comment recuperer le kubeconfig, et comment nettoyer ou reconstruire le cluster. Un bon lab est un environnement que l’on ose casser.

Verifications apres installation

Apres avoir installe un cluster, ne commencez pas directement par deployer une application. Verifiez d’abord l’etat global:

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods -A
kubectl get componentstatuses

Selon les versions, certaines commandes peuvent etre depreciees ou moins utiles, mais l’idee reste la meme: verifier le client, les noeuds et les pods systeme.

Lab contre production

Un cluster de lab accepte des compromis: un seul noeud, stockage local, securite simplifiee, pas de haute disponibilite. En production, ces compromis deviennent des risques. Il faudra traiter les sauvegardes d’etcd, les mises a jour, la supervision, les logs, l’authentification, RBAC, les policies et la strategie de reseau.

Erreurs frequentes

• Passer trop vite a des workloads complexes alors que le cluster n’est pas sain.
• Ne pas sauvegarder le kubeconfig.
• Confondre une distribution legere avec une architecture de production.
• Oublier que kubectl agit toujours sur le contexte courant.

Pour pratiquer

Une fois le cluster disponible, creez un pod simple, observez son noeud, puis supprimez-le:

kubectl run nginx --image=nginx
kubectl get pods -o wide
kubectl describe pod nginx
kubectl delete pod nginx

Cette sequence valide le chemin complet: client, API Server, scheduler, kubelet et runtime.

Ce que K0s simplifie

K0s permet de reduire le nombre de decisions a prendre pour obtenir un cluster utilisable. Dans un apprentissage Kubernetes, c’est important: si l’installation devient trop longue, on risque de passer plus de temps sur les details de bootstrap que sur les objets Kubernetes eux-memes.

Cela ne veut pas dire que ces details sont inutiles. Le reseau, le runtime, le stockage, les certificats et les composants du control plane sont des sujets importants. Mais ils peuvent etre etudies progressivement, une fois les bases acquises: pods, API Server, manifests, contexts, labels, Services et controleurs.

Questions a se poser avant de choisir un cluster de lab

Avant de choisir K0s, kind, minikube, k3s ou kubeadm, il faut clarifier le besoin:

• faut-il un cluster local ou plusieurs machines ?
• veut-on tester du reseau entre noeuds ?
• veut-on reproduire un environnement proche production ?
• faut-il pouvoir supprimer et recreer souvent ?
• le stockage persistant est-il important dans les exercices ?

Pour une serie d’apprentissage, la reponse est souvent la simplicite. Un cluster que l’on comprend un minimum et que l’on peut reconstruire rapidement vaut mieux qu’un cluster ambitieux mais fragile.

Routine de verification quotidienne

Quand on reprend un lab apres quelques jours, il est utile de refaire un petit controle avant de travailler:

kubectl config current-context
kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp

Cette routine revele rapidement un noeud NotReady, un composant systeme en erreur, un contexte inattendu ou des evenements recurrents. Elle evite de perdre du temps a deboguer une application alors que le cluster lui-meme n’est pas sain.

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 007 – API Server : authentification et autorisations.

Conclusion

Un cluster d’apprentissage doit rester simple. K0s permet de se concentrer sur Kubernetes lui-meme: API, pods, contexts, manifests et premiers workloads.