Kubernetes 050 – Installation avec Ansible et kubeadm

TL;DR

Ansible permet de transformer l’installation kubeadm en playbooks: preparation systeme, installation de containerd, installation des paquets Kubernetes, initialisation du control plane, installation du CNI et join des workers. L’objectif est d’obtenir une procedure relancable et versionnee.

La video de reference

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

Elle conclut la sequence kubeadm en montrant une automatisation plus propre que des scripts shell isoles.

Pourquoi Ansible ?

Les scripts shell fonctionnent pour un lab, mais deviennent vite difficiles a maintenir. Ansible apporte un inventaire, des roles, des variables, de l’idempotence et une lecture plus claire des etapes.

Pour kubeadm, c’est un bon compromis entre comprehension manuelle et automatisation industrielle.

Inventaire simple

[masters]
master1 ansible_host=192.168.56.11

[workers]
worker1 ansible_host=192.168.56.21
worker2 ansible_host=192.168.56.22

[k8s:children]
masters
workers

Les groupes permettent d’appliquer des taches communes ou specifiques.

Organisation possible

inventory.ini
site.yml
roles/
  common/
  containerd/
  kubeadm/
  control-plane/
  worker/

Cette structure garde les responsabilites separees.

Taches communes

- name: Disable swap
  command: swapoff -a
  changed_when: false

- name: Load kernel modules
  modprobe:
    name: br_netfilter
    state: present

- name: Enable ipv4 forwarding
  sysctl:
    name: net.ipv4.ip_forward
    value: "1"
    state: present
    reload: true

Les modules Ansible rendent l’intention plus claire qu’une suite de commandes.

Initialiser le control plane

- name: Initialize first control plane
  command: kubeadm init --pod-network-cidr=10.244.0.0/16
  args:
    creates: /etc/kubernetes/admin.conf

L’option creates evite de relancer l’init si le cluster existe deja.

Recuperer la commande de join

- name: Create join command
  command: kubeadm token create --print-join-command
  register: join_command
  changed_when: false

Ensuite, on peut utiliser hostvars pour transmettre la commande aux workers.

Joindre les workers

- name: Join worker nodes
  command: "{{ hostvars[groups['masters'][0]].join_command.stdout }}"
  args:
    creates: /etc/kubernetes/kubelet.conf

Cette condition rend la tache plus relancable.

Installer le CNI

- name: Apply CNI manifest
  command: kubectl apply -f /tmp/cni.yaml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

Le CNI doit etre adapte au pod CIDR utilise par kubeadm.

Verification finale

ansible-playbook -i inventory.ini site.yml
ansible masters -i inventory.ini -a "kubectl --kubeconfig=/etc/kubernetes/admin.conf get nodes"

Dans un pipeline, on peut ajouter des checks jusqu’a ce que tous les noeuds soient Ready.

Idempotence

L’idempotence signifie qu’une relance ne casse pas l’etat existant. Avec kubeadm, c’est essentiel: relancer kubeadm init sur un cluster deja initialise n’est pas une operation anodine.

Il faut donc utiliser creates, des checks de fichiers, ou des conditions explicites.

Liens utiles

• Video: https://www.youtube.com/watch?v=0f7FIaUJFL4
• 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/
• Ansible: https://docs.ansible.com/

FAQ

Ansible remplace-t-il kubeadm ?

Non. Ansible orchestre les commandes et fichiers. kubeadm initialise Kubernetes.

Pourquoi ne pas utiliser seulement shell ?

On peut, mais Ansible structure mieux les roles, variables et relances.

Est-ce une solution de production complete ?

Pas seule. Il faut ajouter supervision, sauvegardes, upgrades, securite et HA.

Erreurs frequentes

• Relancer kubeadm init sans garde.
• Melanger variables de lab et production.
• Ne pas tester l’idempotence.
• Oublier les differences entre masters et workers.

Pour pratiquer

Transformez vos scripts Vagrant kubeadm en roles Ansible. Relancez le playbook deux fois et corrigez chaque tache non idempotente.

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 051 – CNI : installer des network namespaces.

Conclusion

Ansible rend l’installation kubeadm plus propre et plus partageable. C’est une etape logique apres l’apprentissage manuel et les scripts de lab.