Kubernetes 046 – Ajout de masters et workers avec kubeadm

TL;DR

kubeadm join permet d’ajouter des noeuds a un cluster existant. Pour un worker, la commande rejoint simplement le cluster. Pour un control plane additionnel, il faut des options et certificats supplementaires. La haute disponibilite exige aussi un endpoint stable devant l’API Server.

La video de reference

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

L’episode poursuit l’installation kubeadm apres le premier control plane.

Ajouter un worker

La commande de join ressemble a ceci:

sudo kubeadm join 192.168.56.10:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Elle doit etre executee sur un noeud prepare avec containerd, kubelet et kubeadm.

Generer une nouvelle commande

Depuis un control plane existant:

kubeadm token create --print-join-command

Les tokens expirent. Generer une nouvelle commande est plus propre que reutiliser une vieille note.

Verifier le worker

kubectl get nodes -o wide
kubectl describe node <worker>
kubectl get pods -A -o wide

Le noeud doit passer Ready une fois kubelet et le CNI fonctionnels.

Ajouter un control plane

Ajouter un control plane n’est pas identique a ajouter un worker. Il faut rejoindre avec --control-plane et disposer des certificats necessaires.

Exemple de principe:

sudo kubeadm join <endpoint>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <certificate-key>

Les details dependent de la strategie de certificats et de HA choisie.

Certificate key

Pour permettre le partage temporaire des certificats control plane:

sudo kubeadm init phase upload-certs --upload-certs

La cle retournee doit etre protegee et utilisee rapidement.

Endpoint stable

Dans un cluster HA, les control planes doivent etre joints via un endpoint stable, souvent un load balancer:

k8s-api.example.local:6443

Sans endpoint stable, les clients et nouveaux noeuds dependent d’un seul control plane.

Etcd

Avec kubeadm, etcd peut etre local aux control planes ou externe selon l’architecture. Ajouter des control planes implique donc aussi de comprendre la topologie etcd.

Un cluster etcd doit respecter les notions de quorum. Ajouter des membres sans comprendre le quorum peut fragiliser le cluster.

Commandes de controle

kubectl get nodes
kubectl get pods -n kube-system -o wide
kubectl -n kube-system get endpoints kube-controller-manager
kubectl -n kube-system get endpoints kube-scheduler

Ces commandes aident a voir ou tournent les composants systeme.

Liens utiles

• Video: https://www.youtube.com/watch?v=0zKnj9gafcw
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• kubeadm join: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/
• Haute disponibilite kubeadm: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

FAQ

Un worker a-t-il besoin du kubeconfig admin ?

Non. Il rejoint avec kubeadm et kubelet recoit sa configuration.

Pourquoi mon token ne marche plus ?

Il a peut-etre expire. Creez-en un nouveau.

Peut-on avoir deux control planes sans load balancer ?

Techniquement on peut tester, mais pour une vraie HA il faut un endpoint stable.

Erreurs frequentes

• Executer une commande worker pour ajouter un control plane.
• Oublier --control-plane.
• Joindre via une IP qui disparaitra.
• Ne pas verifier le quorum etcd.

Pour pratiquer

Ajoutez un worker, deployez des pods, puis drainez ce worker pour observer la reaction du cluster. Ajoutez ensuite un second control plane dans un lab dedie.

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 047 – Installation automatique avec Vagrant et kubeadm.

Conclusion

kubeadm join parait simple, mais le contexte change tout. Worker, control plane, certificats et endpoint HA doivent etre clairement distingues.