Kubernetes 045 – Cluster initialization et premier master avec kubeadm

TL;DR

kubeadm init cree le premier control plane Kubernetes: certificats, manifests statiques, kubeconfigs et token de jointure. Apres l’init, il faut configurer kubectl, installer un CNI et verifier que les pods systeme deviennent Running.

La video de reference

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

Elle montre le passage concret de la preparation systeme au premier master fonctionnel.

Avant l’initialisation

Avant kubeadm init, chaque noeud doit avoir un runtime fonctionnel, kubelet, kubeadm, les modules kernel et une configuration reseau compatible.

Verifications rapides:

systemctl status containerd
systemctl status kubelet
swapoff -a
lsmod | grep br_netfilter

Le kubelet peut etre en erreur avant l’init, car il attend sa configuration. Ce n’est pas toujours anormal.

Commande kubeadm init

Exemple simple:

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

L’adresse advertise doit etre joignable par les autres noeuds. Le CIDR des pods doit correspondre au CNI choisi.

Ce que kubeadm cree

Apres l’init, on retrouve notamment:

• /etc/kubernetes/admin.conf pour administrer le cluster;
• /etc/kubernetes/manifests/ pour les composants statiques;
• des certificats dans /etc/kubernetes/pki;
• une configuration kubelet;
• un token et une commande de join.

Ces fichiers sont essentiels. Il ne faut pas les supprimer sans comprendre leur role.

Configurer kubectl

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes

Sans cette etape, kubectl ne sait pas comment contacter l’API Server.

Installer le CNI

Tant que le CNI n’est pas installe, le noeud reste souvent NotReady et CoreDNS ne fonctionne pas.

Exemple avec un plugin compatible avec le CIDR choisi:

kubectl apply -f <manifest-cni.yaml>
kubectl get pods -A
kubectl get nodes

Il faut suivre la documentation du CNI retenu, car les options varient.

Manifests statiques

Les composants control plane sont souvent lances comme pods statiques par kubelet:

ls /etc/kubernetes/manifests

On y trouve kube-apiserver, kube-controller-manager, kube-scheduler et parfois etcd.

Kubelet surveille ces fichiers et lance les pods correspondants.

Verifier le cluster

kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -n kube-system
kubectl describe node <nom-du-noeud>

Les events du noeud donnent des indications utiles si le statut reste NotReady.

Recuperer la commande de join

Si la commande affichee par kubeadm init est perdue:

kubeadm token create --print-join-command

Cette commande servira aux workers et, avec des options supplementaires, aux control planes additionnels.

Liens utiles

• Video: https://www.youtube.com/watch?v=em2ajkHft_4
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• kubeadm init: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/
• Creer un cluster kubeadm: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

FAQ

Pourquoi master et control plane ?

Le terme moderne est control plane. Beaucoup de supports anciens parlent encore de master.

Pourquoi CoreDNS reste Pending ?

Le CNI n’est probablement pas encore installe ou pas fonctionnel.

Peut-on relancer kubeadm init ?

Pas sans nettoyer correctement avec kubeadm reset et comprendre les fichiers restants.

Erreurs frequentes

• Choisir une mauvaise adresse advertise.
• Oublier de copier admin.conf.
• Installer un CNI incompatible avec le pod CIDR.
• Ignorer les preflight warnings sans les lire.

Pour pratiquer

Initialisez un control plane dans une VM, listez les manifests statiques, puis arretez temporairement kubelet pour voir l’impact sur les pods control plane.

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 046 – Ajout de masters et workers avec kubeadm.

Conclusion

Le premier kubeadm init est une etape fondatrice. Il cree le coeur du cluster, mais le cluster n’est vraiment exploitable qu’apres kubeconfig, CNI et verifications.