Installer un cluster Kubernetes avec kubeadm

kubeadm est l’outil officiel pour bootstrapper un cluster Kubernetes conforme aux standards upstream. Ce guide vous accompagne dans l’installation d’un cluster multi-nœuds sur des machines virtuelles KVM, de la préparation des VMs jusqu’au déploiement d’applications. Vous apprendrez à configurer containerd, initialiser le control plane, joindre des workers et maintenir votre cluster.

Préparation CKA

Ce guide couvre principalement le domaine Cluster Architecture, Installation & Configuration (25%) de la certification CKA. La CKA évalue aussi d’autres domaines (Troubleshooting 30%, Networking 20%, Workloads 15%, Storage 10%) qui sont traités dans des guides dédiés. L’examen CKA utilise actuellement Kubernetes v1.34, mais les concepts et commandes restent identiques pour les versions 1.33+.

Quel type de cluster ce guide construit-il ?

Ce guide construit un cluster self-managed robuste pour le lab, la validation technique et la préparation CKA. Ce n’est pas un cluster de production stricte.

Pour un environnement de production, ajoutez :

• Registry mirror privé et politique d’images
• Sauvegarde etcd externalisée et chiffrée
• Supervision (Prometheus/Grafana) et logs centralisés (Loki/ELK)
• Chiffrement des Secrets at rest
• Pod Security Admission et NetworkPolicies
• PRA documenté et testé

Parcours	Ce qui est couvert dans ce guide
Lab / CKA	1 control plane + 2 workers, Flannel, commandes courtes, objectif : apprendre vite
Self-managed sérieux	3 control planes, HAProxy, config YAML, CNI avec NetworkPolicies, backup externalisé
Production	❌ Non couvert — voir les ajouts listés ci-dessus

Glissez pour voir

kubeadm vs autres solutions

Critère	kubeadm	k0s	k3s	Kubespray	RKE2
Type	Bootstrap tool	Distribution	Distribution	Playbooks Ansible	Distribution
Orientation	Standard upstream	Edge, prod, CI	Edge, IoT, dev	Prod, multi-cloud	Enterprise, sécurité
Installation	Commandes	k0sctl (YAML)	Script unique	Ansible	Script
CNI défaut	Aucun	kube-router	Flannel	Configurable	Canal
HA native	Manuel	✅ Multi-controller	✅ Multi-server	✅ Ansible	✅ Intégrée
Profil CIS	Manuel	Manuel	Manuel	Selon config	✅ Intégré
Cas d’usage	Bare metal, formation	Edge, CI/CD, prod	Edge, IoT, dev	Prod automatisée	Conformité, prod

Glissez pour voir

Ce que vous allez apprendre

Ce guide vous permettra de maîtriser l’installation et la maintenance d’un cluster Kubernetes avec kubeadm. À la fin, vous saurez :

• Provisionner des VMs KVM pour héberger le cluster, en comprenant pourquoi chaque configuration est nécessaire
• Installer containerd et les composants Kubernetes, en configurant correctement le cgroup driver pour éviter les problèmes de stabilité
• Initialiser un cluster avec kubeadm, en comprenant le rôle de chaque option et composant
• Joindre des nœuds workers au cluster et diagnostiquer les échecs de jointure
• Configurer la haute disponibilité avec plusieurs control planes et un load balancer
• Mettre à jour le cluster vers une nouvelle version en respectant les règles de version skew
• Sauvegarder et restaurer etcd, la base de données critique du cluster
• Dépanner les problèmes courants avec une méthodologie structurée

Prérequis

Pourquoi ces ressources matérielles ?

Avant de créer vos VMs, comprenez pourquoi Kubernetes impose des minimums stricts. Le control plane héberge l’API server, etcd, le scheduler et le controller-manager : ces composants consomment de la mémoire même au repos. Avec moins de 2 Go de RAM, etcd refusera de démarrer ou crashera sous charge. Les workers exécutent vos conteneurs applicatifs : 2 vCPU permettent de faire tourner plusieurs pods sans contention excessive.

Rôle	CPU	RAM	Disque	Quantité	Pourquoi ces specs
Control plane	2 vCPU	2 Go	20 Go	1 (ou 3 pour HA)	etcd + API server + scheduler + controller-manager
Worker	2 vCPU	2 Go	20 Go	2+	kubelet + pods applicatifs

Glissez pour voir

Pour un environnement de production, doublez ces valeurs minimum. En environnement de test ou pour la préparation CKA, ces minimums suffisent.

Logiciels requis sur l’hyperviseur

Vous aurez besoin d’un hyperviseur Linux avec KVM pour créer les machines virtuelles. Si vous n’avez pas de serveur dédié, vous pouvez utiliser votre poste de travail Linux avec suffisamment de RAM (16 Go recommandés pour faire tourner 3 VMs simultanément).

• KVM/QEMU et libvirt installés (le cœur de la virtualisation)
• virt-manager ou virsh pour gérer les VMs (interface graphique ou CLI)
• Une image cloud Ubuntu 24.04 ou Rocky Linux 9 (pré-configurée pour cloud-init)

Ports réseau à ouvrir

La communication entre les composants Kubernetes se fait sur des ports bien définis. Si vous utilisez un pare-feu entre les VMs (iptables, firewalld, ou un pare-feu réseau), vous devez ouvrir ces ports. Sur un réseau local sans pare-feu entre les VMs, cette étape n’est pas nécessaire.

Port	Composant	Qui se connecte	Pourquoi
6443	kube-apiserver	kubectl, kubelet, autres control planes	Point d’entrée de toute communication avec le cluster
2379-2380	etcd	API server, autres etcd (HA)	Base de données du cluster, réplication HA
10250	kubelet	API server, metrics-server	Gestion des pods, récupération des logs et métriques
10257	kube-controller-manager	Prometheus (optionnel)	Métriques du controller
10259	kube-scheduler	Prometheus (optionnel)	Métriques du scheduler
179	Calico BGP	Autres nœuds Calico	Routage BGP entre nœuds (si vous utilisez Calico)

Glissez pour voir

Création des machines virtuelles avec KVM

Architecture du lab

Le schéma ci-dessous représente l’architecture cible de notre cluster de test. Vous aurez un nœud control plane (cp1) qui héberge les composants de gestion, et deux workers (worker1, worker2) qui exécuteront vos applications. Tous les nœuds sont connectés au réseau virtuel par défaut de libvirt (virbr0, 192.168.122.0/24).

Cette architecture est suffisante pour apprendre Kubernetes et préparer la CKA. En production, vous ajouteriez 2 control planes supplémentaires pour la haute disponibilité (section dédiée plus loin).

Télécharger et préparer les images cloud

Les images cloud sont des disques système pré-configurés pour s’initialiser via cloud-init. Contrairement à une installation classique, elles démarrent en quelques secondes et se configurent automatiquement au premier boot. Nous utilisons la technique du “backing file” de QCOW2 : l’image de base reste intacte, et chaque VM stocke uniquement ses différences. Cela économise de l’espace disque et accélère la création des VMs.

Ubuntu 24.04

Ubuntu 24.04 LTS (“Noble Numbat”) est recommandée pour sa stabilité et son support long terme (jusqu’en 2029). L’image cloud inclut cloud-init et les modules kernel nécessaires.

# Télécharger l'image cloud Ubuntu (environ 700 Mo)
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img \
  -O /var/lib/libvirt/images/ubuntu-24.04-cloud.img

# Créer un snapshot pour chaque VM (20 Go max, mais démarre petit)
# Le backing file (-b) permet de partager l'image de base entre toutes les VMs
qemu-img create -f qcow2 -b /var/lib/libvirt/images/ubuntu-24.04-cloud.img \
  -F qcow2 /var/lib/libvirt/images/cp1.qcow2 20G
qemu-img create -f qcow2 -b /var/lib/libvirt/images/ubuntu-24.04-cloud.img \
  -F qcow2 /var/lib/libvirt/images/worker1.qcow2 20G
qemu-img create -f qcow2 -b /var/lib/libvirt/images/ubuntu-24.04-cloud.img \
  -F qcow2 /var/lib/libvirt/images/worker2.qcow2 20G

Rocky Linux 9

Rocky Linux 9 est l’alternative RHEL-compatible, gratuite et supportée par la communauté. Elle est particulièrement adaptée si vous travaillez avec des clusters d’entreprise basés sur RHEL.

# Télécharger l'image cloud Rocky Linux (environ 1 Go)
wget https://download.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-GenericCloud.latest.x86_64.qcow2 \
  -O /var/lib/libvirt/images/rocky-9-cloud.qcow2

# Créer un snapshot pour chaque VM
qemu-img create -f qcow2 -b /var/lib/libvirt/images/rocky-9-cloud.qcow2 \
  -F qcow2 /var/lib/libvirt/images/cp1.qcow2 20G
qemu-img create -f qcow2 -b /var/lib/libvirt/images/rocky-9-cloud.qcow2 \
  -F qcow2 /var/lib/libvirt/images/worker1.qcow2 20G
qemu-img create -f qcow2 -b /var/lib/libvirt/images/rocky-9-cloud.qcow2 \
  -F qcow2 /var/lib/libvirt/images/worker2.qcow2 20G

Configurer cloud-init

Cloud-init est l’outil standard pour initialiser les instances cloud. Il configure le hostname, crée les utilisateurs, injecte les clés SSH et peut exécuter des commandes au premier boot. Créez un fichier de configuration pour chaque VM en adaptant l’adresse IP et le hostname.

Le fichier ci-dessous configure le control plane (cp1). Les points importants :

• Utilisateur kube : compte dédié avec sudo sans mot de passe pour simplifier les manipulations
• Clé SSH : remplacez par votre clé publique pour vous connecter sans mot de passe
• IP statique : garantit que les nœuds gardent la même IP après reboot
• Swap désactivé : kubelet refuse de démarrer si le swap est actif

cloud-init-cp1.yaml

#cloud-config
hostname: cp1
fqdn: cp1.kube.local
manage_etc_hosts: true

users:
  - name: kube
    sudo: ALL=(ALL) NOPASSWD:ALL
    groups: sudo
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... votre-clé-publique

# Réseau statique - adaptez à votre réseau libvirt
network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 192.168.122.10/24
      gateway4: 192.168.122.1
      nameservers:
        addresses:
          - 192.168.122.1

# Commandes exécutées au premier boot
runcmd:
  - swapoff -a
  - sed -i '/swap/d' /etc/fstab

Créez des fichiers similaires pour worker1 (IP .20) et worker2 (IP .21).

Créer les VMs avec virt-install

Maintenant que les images et la configuration cloud-init sont prêtes, créons les VMs. La commande cloud-localds génère un disque ISO contenant la configuration cloud-init, que la VM lira au premier boot.

# Générer l'ISO cloud-init pour le control plane
cloud-localds /var/lib/libvirt/images/cp1-cidata.iso cloud-init-cp1.yaml

# Créer la VM control plane
# --import : utilise un disque existant au lieu de lancer une installation
# --noautoconsole : ne pas attacher de console (la VM démarre en arrière-plan)
virt-install \
  --name cp1 \
  --ram 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/cp1.qcow2,format=qcow2 \
  --disk path=/var/lib/libvirt/images/cp1-cidata.iso,device=cdrom \
  --os-variant ubuntu24.04 \
  --network network=default \
  --graphics none \
  --console pty,target_type=serial \
  --import \
  --noautoconsole

Répétez l’opération pour worker1 et worker2 en adaptant les noms et les fichiers cloud-init.

Vérification : après une minute de boot, testez la connexion SSH. Si la connexion échoue, vérifiez que votre clé publique est correcte dans le fichier cloud-init.

ssh kube@192.168.122.10
# Doit se connecter sans demander de mot de passe

Installation des prérequis sur tous les nœuds

Cette section prépare le système pour exécuter Kubernetes. Chaque étape a une raison précise, et sauter une étape causera des problèmes difficiles à diagnostiquer. Exécutez ces commandes sur tous les nœuds (control plane et workers).

1. Configurer les modules kernel pour le réseau des conteneurs

   Kubernetes utilise des bridges réseau virtuels pour connecter les conteneurs. Le module overlay permet le stockage en couches des images conteneur. Le module br_netfilter permet au trafic réseau qui traverse les bridges d’être traité par iptables, ce qui est essentiel pour les règles de Services Kubernetes.

   # Charger les modules au démarrage
   cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
   overlay
   br_netfilter
   EOF
   
   # Charger les modules immédiatement (sans reboot)
   sudo modprobe overlay
   sudo modprobe br_netfilter

   Vérification : les modules doivent apparaître dans la liste des modules chargés.

   lsmod | grep -E 'overlay|br_netfilter'
   # br_netfilter          32768  0
   # overlay              151552  0

2. Configurer sysctl pour le forwarding réseau

   Ces paramètres kernel permettent au trafic réseau de traverser les interfaces virtuelles. Sans eux, les pods ne pourraient pas communiquer entre eux ni avec l’extérieur. Le paramètre ip_forward active le routage IP, indispensable car chaque nœud agit comme un routeur pour ses pods.

   cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
   net.bridge.bridge-nf-call-iptables  = 1
   net.bridge.bridge-nf-call-ip6tables = 1
   net.ipv4.ip_forward                 = 1
   EOF
   
   # Appliquer sans reboot
   sudo sysctl --system

   Vérification : les valeurs doivent être à 1.

   sysctl net.ipv4.ip_forward
   # net.ipv4.ip_forward = 1

3. Désactiver le swap (obligatoire)

   Le kubelet refuse catégoriquement de démarrer si le swap est actif. Pourquoi ? Le scheduler Kubernetes prend des décisions de placement basées sur la mémoire disponible. Si le système swape, ces calculs deviennent faux et les performances s’effondrent. Si cloud-init l’a déjà fait, cette commande est inoffensive.

   # Désactiver immédiatement
   sudo swapoff -a
   
   # Supprimer l'entrée swap du fstab pour que ça persiste au reboot
   sudo sed -i '/swap/d' /etc/fstab

   Vérification : la commande free ne doit montrer aucun swap.

   free -h | grep Swap
   # Swap:            0B          0B          0B

4. Installer containerd comme runtime de conteneurs

   Kubernetes a besoin d’un runtime de conteneurs conforme à l’interface CRI (Container Runtime Interface). Depuis Kubernetes 1.24, Docker n’est plus supporté nativement. containerd est devenu le standard de fait : léger, stable, et utilisé par tous les clouds publics. Nous l’installons depuis le dépôt Docker car il fournit des binaires à jour.

   Ubuntu/Debian

   # Installer les dépendances pour ajouter des repos HTTPS
   sudo apt-get update
   sudo apt-get install -y ca-certificates curl gnupg
   
   # Ajouter la clé GPG du repo Docker
   sudo install -m 0755 -d /etc/apt/keyrings
   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
     sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
   
   # Ajouter le repo Docker
   echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
     https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
     sudo tee /etc/apt/sources.list.d/docker.list
   
   # Installer containerd
   sudo apt-get update
   sudo apt-get install -y containerd.io

   Rocky/RHEL

   # Ajouter le repo Docker
   sudo dnf config-manager --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
   
   # Installer containerd
   sudo dnf install -y containerd.io

5. Configurer containerd avec le cgroup driver systemd

   C’est l’étape la plus critique et la plus souvent oubliée. Kubernetes et containerd doivent utiliser le même cgroup driver. Sur les distributions modernes avec systemd, ce driver doit être systemd (pas cgroupfs). Si vous oubliez cette configuration, le kubelet crashera avec des erreurs cryptiques.

   # Générer la configuration par défaut
   sudo mkdir -p /etc/containerd
   containerd config default | sudo tee /etc/containerd/config.toml
   
   # CRITIQUE : activer le cgroup driver systemd
   sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
   
   # Redémarrer pour appliquer
   sudo systemctl restart containerd
   sudo systemctl enable containerd

   Vérification : containerd doit être actif et la configuration correcte.

   sudo systemctl status containerd
   # ● containerd.service - containerd container runtime
   #      Active: active (running)
   
   grep SystemdCgroup /etc/containerd/config.toml
   # SystemdCgroup = true

   Erreur fréquente CKA

   Oublier SystemdCgroup = true est une erreur classique. Le symptôme : kubelet crashe en boucle avec des erreurs de cgroup. Vérifiez toujours ce paramètre quand vous déboguez un kubelet qui ne démarre pas.

   Note 2026 : depuis Kubernetes 1.34, kubelet peut détecter automatiquement le cgroup driver depuis le runtime CRI (KubeletCgroupDriverFromCRI est GA). Containerd 2.0+ supporte cette auto-détection. Cependant, garder SystemdCgroup = true explicite reste une bonne pratique pour éviter toute ambiguïté. En 1.36, le fallback automatique disparaîtra.

6. Installer kubeadm, kubelet et kubectl

   Ces trois binaires forment le cœur de l’installation :

   • kubeadm : outil de bootstrap qui initialise le cluster et génère les certificats
   • kubelet : agent qui tourne sur chaque nœud et gère les containers
   • kubectl : CLI pour interagir avec l’API Kubernetes
   Ubuntu/Debian

   # Ajouter la clé GPG du repo Kubernetes
   sudo mkdir -p /etc/apt/keyrings
   curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
     sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
   
   # Ajouter le repo Kubernetes
   echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
     https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /' | \
     sudo tee /etc/apt/sources.list.d/kubernetes.list
   
   # Installer les composants
   sudo apt-get update
   sudo apt-get install -y kubelet kubeadm kubectl
   
   # Bloquer les mises à jour automatiques (important pour les upgrades contrôlés)
   sudo apt-mark hold kubelet kubeadm kubectl

   Rocky/RHEL

   # Ajouter le repo Kubernetes
   cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
   [kubernetes]
   name=Kubernetes
   baseurl=https://pkgs.k8s.io/core:/stable:/v1.35/rpm/
   enabled=1
   gpgcheck=1
   gpgkey=https://pkgs.k8s.io/core:/stable:/v1.35/rpm/repodata/repomd.xml.key
   EOF
   
   # Installer les composants
   sudo dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
   sudo systemctl enable kubelet

   Vérification : les binaires doivent être installés à la bonne version.

   kubeadm version
   # kubeadm version: &version.Info{Major:"1", Minor:"35", GitVersion:"v1.35.2"...}
   
   kubectl version --client
   # Client Version: v1.35.2

Initialisation du cluster

L’initialisation du cluster est le moment où kubeadm génère tous les composants du control plane : certificats TLS, fichiers de configuration, et pods statiques. Cette étape ne s’exécute que sur le premier nœud control plane.

Comprendre les options de kubeadm init

Avant de lancer la commande, comprenez chaque option pour pouvoir adapter à votre environnement :

Option	Signification	Pourquoi c’est important
--pod-network-cidr	Plage d’adresses pour les pods	Le CNI (Flannel, Calico) utilisera ce CIDR. 10.244.0.0/16 est le défaut pour Flannel
--apiserver-advertise-address	IP sur laquelle l’API server écoute	Les workers et kubectl utiliseront cette IP
--control-plane-endpoint	Endpoint stable pour le control plane	Indispensable pour HA : permet d’ajouter d’autres control planes plus tard

Glissez pour voir

Méthode recommandée : fichier de configuration YAML

Plutôt que des options CLI longues, utilisez un fichier de configuration kubeadm. C’est reproductible, versionnable et compatible avec IaC (Ansible, Terraform).

Créez un fichier kubeadm-config.yaml :

kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.35.2
controlPlaneEndpoint: "192.168.122.10:6443"
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Puis initialisez avec :

sudo kubeadm init --config kubeadm-config.yaml

Avantages de la configuration YAML

• Reproductibilité : le fichier est versionnable dans Git
• HA simplifiée : ajoutez --upload-certs à la commande, pas au fichier
• Passage IaC : le fichier peut être généré par Ansible ou Terraform
• Lisibilité : toutes les options sont documentées au même endroit

Initialiser avec la ligne de commande (alternative)

Si vous préférez ne pas créer de fichier YAML pour un lab rapide, vous pouvez utiliser les options CLI. Sur le nœud cp1 uniquement, lancez l’initialisation :

sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=192.168.122.10 \
  --control-plane-endpoint=192.168.122.10:6443

Pourquoi spécifier --control-plane-endpoint ?

Même si vous ne prévoyez pas de haute disponibilité, spécifiez --control-plane-endpoint. Cela permet de passer en HA plus tard sans recréer le cluster. Utilisez l’IP du load balancer si vous en avez un, ou l’IP du premier control plane sinon.

Sortie attendue (les tokens seront différents) :

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

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

...

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.122.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:...

Copiez et sauvegardez la commande kubeadm join affichée ! Vous en aurez besoin pour joindre les workers. Le token expire après 24 heures.

Configurer kubectl pour l’utilisateur courant

kubectl a besoin d’un fichier kubeconfig pour savoir comment contacter l’API server et s’authentifier. Le fichier admin.conf généré par kubeadm contient un certificat client avec les droits administrateur. On le copie dans le répertoire home de l’utilisateur pour que kubectl le trouve automatiquement.

# Créer le répertoire de configuration kubectl
mkdir -p $HOME/.kube

# Copier le fichier de configuration admin
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# Donner les droits à l'utilisateur courant
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Vérification : kubectl doit maintenant pouvoir contacter l’API server.

kubectl get nodes
# NAME   STATUS     ROLES           AGE   VERSION
# cp1    NotReady   control-plane   30s   v1.35.2

Le statut NotReady est normal à ce stade : le CNI (Container Network Interface) n’est pas encore installé. Sans CNI, les pods ne peuvent pas obtenir d’adresses IP et le nœud ne peut pas être considéré comme prêt.

Installer le plugin réseau CNI

Le CNI (Container Network Interface) fournit le réseau aux pods. Sans lui, les pods resteront en Pending et le nœud en NotReady.

Choisissez votre CNI selon votre cas d’usage :

CNI	Usage conseillé	NetworkPolicies	Complexité	Quand l’utiliser
Flannel	Lab, démo, apprentissage	❌ Non	⭐ Faible	Vous débutez ou n’avez pas besoin de NetworkPolicies
Calico	Production classique	✅ Oui	⭐⭐ Moyenne	Vous avez besoin d’isolation réseau entre namespaces
Cilium	Production avancée, observabilité	✅ Oui + eBPF	⭐⭐⭐ Plus élevée	Vous voulez de l’observabilité réseau poussée

Glissez pour voir

Flannel (lab/CKA)

Flannel est le CNI le plus simple à installer. Parfait pour apprendre et pour la CKA. Il ne supporte pas les NetworkPolicies, mais ce n’est pas un problème pour un lab.

# Installer Flannel
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Calico (self-managed/prod)

Calico supporte les NetworkPolicies et offre plus de contrôle sur le réseau. Recommandé pour les clusters self-managed sérieux et la production.

# Installer l'opérateur Calico
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

# Installer Calico avec le bon CIDR (doit correspondre à --pod-network-cidr)
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

CIDR Calico

Par défaut, Calico utilise 192.168.0.0/16 pour les pods. Si vous avez utilisé 10.244.0.0/16 dans kubeadm init, modifiez custom-resources.yaml avant de l’appliquer.

Cette commande crée un namespace dédié, un DaemonSet, des ConfigMaps et les RBAC nécessaires. Attendez environ 30 secondes que les pods CNI démarrent.

Vérification : le nœud doit passer en Ready et Flannel doit tourner.

# Le nœud doit maintenant être Ready
kubectl get nodes
# NAME   STATUS   ROLES           AGE   VERSION
# cp1    Ready    control-plane   2m    v1.35.2

# Le pod Flannel doit être Running
kubectl get pods -n kube-flannel
# NAME                    READY   STATUS    RESTARTS   AGE
# kube-flannel-ds-xxxxx   1/1     Running   0          30s

# Vérifier aussi les pods système
kubectl get pods -n kube-system
# Tous les pods doivent être Running ou Completed

Joindre les workers au cluster

Chaque worker doit s’enregistrer auprès du control plane pour recevoir des pods. La commande kubeadm join utilise un token et un hash de certificat pour authentifier le nœud auprès du cluster.

Sur chaque worker (worker1 et worker2), exécutez la commande copiée lors de l’initialisation :

sudo kubeadm join 192.168.122.10:6443 \
  --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:...

Le token est valide 24 heures. Si vous l’avez perdu ou s’il a expiré, générez-en un nouveau sur le control plane :

# Sur le control plane : regénérer la commande join complète
kubeadm token create --print-join-command

Échec de jointure : que vérifier

Si un worker refuse de joindre, vérifiez dans cet ordre :

1. Connectivité : ping 192.168.122.10 depuis le worker
2. Port 6443 : nc -zv 192.168.122.10 6443 doit répondre
3. Kubelet : sudo journalctl -u kubelet -xe pour les erreurs
4. Token : vérifiez que le token n’est pas expiré (kubeadm token list)

Vérification finale depuis le control plane : tous les nœuds doivent être Ready.

kubectl get nodes -o wide
# NAME      STATUS   ROLES           AGE   VERSION   INTERNAL-IP      OS-IMAGE
# cp1       Ready    control-plane   5m    v1.35.2   192.168.122.10   Ubuntu 24.04
# worker1   Ready    <none>          2m    v1.35.2   192.168.122.20   Ubuntu 24.04
# worker2   Ready    <none>          1m    v1.35.2   192.168.122.21   Ubuntu 24.04

Félicitations ! Vous avez un cluster Kubernetes fonctionnel. Les sections suivantes couvrent la haute disponibilité, les mises à jour et le dépannage.

Configuration haute disponibilité

En production, un seul control plane représente un point de défaillance unique (SPOF). Si cp1 tombe, l’API server devient inaccessible et vous ne pouvez plus gérer le cluster. Les workers continuent de faire tourner les pods existants, mais vous ne pouvez plus déployer, scaler ou modifier quoi que ce soit.

La haute disponibilité (HA) résout ce problème avec 3 control planes et un load balancer devant eux. Même si un control plane tombe, les deux autres continuent de répondre.

HA et CKA

Pour la CKA, vous devez comprendre :

• Pourquoi on utilise 3 control planes (quorum etcd nécessite un nombre impair)
• Le rôle du load balancer (endpoint stable pour tous les clients)
• La différence entre stacked etcd (etcd sur les mêmes nœuds que le control plane) et external etcd (cluster etcd dédié)
• Comment joindre des control planes supplémentaires avec --upload-certs

Choisir votre topologie etcd

Kubernetes HA supporte deux architectures etcd. Comprenez les différences avant de choisir :

Architecture	Description	Avantages	Inconvénients	Quand l’utiliser
Stacked etcd	etcd sur les mêmes nœuds que le control plane	Moins de VMs, plus simple	Couplage control plane/etcd, risque de contention ressources	Lab, CKA, clusters < 50 nœuds
External etcd	Cluster etcd dédié (3 VMs séparées)	Isolation ressources, scaling indépendant	Plus de VMs, complexité certificats	Production critique, > 50 nœuds

Glissez pour voir

Ce guide utilise stacked etcd (la topologie par défaut de kubeadm).

Attention au load balancer comme SPOF

Le load balancer (HAProxy) lui-même peut devenir un point de défaillance unique. En production stricte :

• Utilisez 2 instances HAProxy avec Keepalived pour une VIP flottante
• Ou un load balancer cloud (AWS ELB, GCP LB) qui est nativement HA

Architecture HA

Le schéma ci-dessous montre une architecture HA typique avec 3 control planes. HAProxy distribue le trafic entre les API servers. Chaque control plane héberge son propre etcd (architecture “stacked”). Les workers contactent uniquement HAProxy.

Installer HAProxy sur une VM dédiée

HAProxy agit comme un load balancer TCP pour le port 6443 de l’API server. Créez une VM dédiée (IP 192.168.122.5) ou utilisez un LB existant. Cette configuration utilise le health check TCP : si un control plane ne répond pas, HAProxy arrête de lui envoyer du trafic.

sudo apt-get install -y haproxy

Configurez HAProxy pour distribuer le trafic entre les 3 control planes. Le mode tcp est utilisé car l’API server utilise TLS et HAProxy ne doit pas terminer la connexion SSL.

/etc/haproxy/haproxy.cfg

global
    daemon
    maxconn 256

defaults
    mode tcp
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend kubernetes-frontend
    bind *:6443
    default_backend kubernetes-backend

backend kubernetes-backend
    balance roundrobin
    option tcp-check
    server cp1 192.168.122.10:6443 check
    server cp2 192.168.122.11:6443 check
    server cp3 192.168.122.12:6443 check

Redémarrez HAProxy et vérifiez qu’il écoute sur le port 6443 :

sudo systemctl restart haproxy
sudo systemctl enable haproxy

# Vérifier que HAProxy écoute
ss -tlnp | grep 6443
# LISTEN  0  128  *:6443  *:*  users:(("haproxy",...))

Initialiser le premier control plane HA

L’initialisation en mode HA diffère par l’option --upload-certs qui chiffre et stocke les certificats dans un Secret Kubernetes. Les autres control planes récupéreront ces certificats lors de leur jointure.

sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --control-plane-endpoint="192.168.122.5:6443" \
  --upload-certs

Points importants :

• --control-plane-endpoint pointe vers HAProxy (pas vers cp1)
• --upload-certs génère une clé de déchiffrement valide 2 heures

La sortie affiche deux commandes kubeadm join :

• Une pour les workers (sans --control-plane)
• Une pour les control planes (avec --control-plane --certificate-key)

Joindre les autres control planes

Sur cp2 et cp3, exécutez la commande spéciale pour control planes :

sudo kubeadm join 192.168.122.5:6443 \
  --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:... \
  --control-plane \
  --certificate-key ...

Clé de certificat expirée

La --certificate-key expire après 2 heures. Si vous dépassez ce délai, regénérez-la sur le premier control plane :

sudo kubeadm init phase upload-certs --upload-certs
# Copier la nouvelle clé affichée

Vérification : les 3 control planes doivent apparaître avec le rôle control-plane.

kubectl get nodes
# NAME   STATUS   ROLES           AGE   VERSION
# cp1    Ready    control-plane   10m   v1.35.2
# cp2    Ready    control-plane   5m    v1.35.2
# cp3    Ready    control-plane   3m    v1.35.2

Mise à jour du cluster

La mise à jour (upgrade) d’un cluster Kubernetes est une compétence essentielle pour la CKA. Kubernetes suit un cycle de release rapide (3 versions mineures par an), et vous devez savoir mettre à jour sans interruption de service.

Règles de version skew

Kubernetes impose des règles strictes de compatibilité entre versions. Le version skew définit l’écart de version autorisé entre composants :

Composant	Skew autorisé par rapport à kube-apiserver
kubelet	-2 versions mineures (ex: API 1.35 → kubelet 1.33 OK)
kubectl	±1 version mineure
kube-controller-manager, kube-scheduler	Même version ou -1

Glissez pour voir

Règle pratique : mettez à jour le control plane avant les workers, et ne sautez pas de version mineure.

À retenir pour la CKA

Vous ne pouvez pas passer de 1.33 à 1.35 directement. Vous devez d’abord passer à 1.34, puis à 1.35. De même, mettez toujours à jour kubeadm en premier, puis appliquez la mise à jour, et enfin mettez à jour kubelet/kubectl.

Mettre à jour le control plane

La mise à jour du control plane se fait en plusieurs étapes. Cette procédure minimise le temps d’indisponibilité de l’API server.

Checklist avant upgrade

Avant toute mise à jour, vérifiez ces points :

1. Sauvegardez etcd : etcdctl snapshot save /tmp/etcd-pre-upgrade-$(date +%Y%m%d).db
2. Lisez les release notes : vérifiez les breaking changes
3. Vérifiez le skew : pas de saut de version mineure
4. Pré-pullez les images (optionnel) : kubeadm config images pull --kubernetes-version v1.35.2

1. Vérifier les versions disponibles

   Avant de mettre à jour, vérifiez quelle version est disponible dans le dépôt. Cela vous permet de planifier la mise à jour et de vérifier que la version cible existe.

   # Lister les versions disponibles de kubeadm
   apt-cache madison kubeadm | head -5
   # kubeadm | 1.35.2-1.1 | https://pkgs.k8s.io/...
   # kubeadm | 1.35.1-1.1 | https://pkgs.k8s.io/...
   # kubeadm | 1.35.0-1.1 | https://pkgs.k8s.io/...

2. Mettre à jour kubeadm en premier

   kubeadm doit être à la version cible avant de pouvoir appliquer la mise à jour. On débloque temporairement le paquet, on met à jour, puis on rebloque.

   # Débloquer kubeadm
   sudo apt-mark unhold kubeadm
   
   # Mettre à jour le cache et installer la nouvelle version
   sudo apt-get update
   sudo apt-get install -y kubeadm=1.35.2-1.1
   
   # Rebloquer pour éviter les mises à jour automatiques
   sudo apt-mark hold kubeadm

3. Vérifier le plan de mise à jour

   Cette commande affiche exactement ce qui va être mis à jour. Elle vérifie aussi les prérequis et signale les problèmes potentiels. Lisez attentivement la sortie avant de continuer.

   sudo kubeadm upgrade plan
   # [upgrade] Fetching available versions to upgrade to
   # Components that must be upgraded manually after you have upgraded the control plane:
   # COMPONENT   CURRENT       TARGET
   # kubelet     v1.35.1       v1.35.2
   #
   # Upgrade to the latest stable version:
   # COMPONENT                 CURRENT   TARGET
   # kube-apiserver            v1.35.1   v1.35.2
   # kube-controller-manager   v1.35.1   v1.35.2
   # kube-scheduler            v1.35.1   v1.35.2
   # kube-proxy                v1.35.1   v1.35.2
   # CoreDNS                   v1.11.1   v1.11.3
   # etcd                      3.5.15    3.5.16

4. Appliquer la mise à jour

   Cette commande met à jour les composants du control plane. Elle télécharge les nouvelles images, met à jour les manifestes des pods statiques, et redémarre les composants. Le cluster reste accessible pendant ce processus (quelques secondes d’indisponibilité possibles).

   sudo kubeadm upgrade apply v1.35.2
   # [upgrade] Are you sure you want to proceed? [y/N]: y

5. Mettre à jour kubelet et kubectl

   kubelet et kubectl doivent être mis à jour séparément. Le kubelet gère les pods sur ce nœud, donc un redémarrage est nécessaire.

   # Débloquer les paquets
   sudo apt-mark unhold kubelet kubectl
   
   # Installer les nouvelles versions
   sudo apt-get install -y kubelet=1.35.2-1.1 kubectl=1.35.2-1.1
   
   # Rebloquer
   sudo apt-mark hold kubelet kubectl
   
   # Recharger la configuration systemd et redémarrer kubelet
   sudo systemctl daemon-reload
   sudo systemctl restart kubelet

   Vérification : le nœud control plane doit afficher la nouvelle version.

   kubectl get nodes
   # NAME   STATUS   ROLES           AGE   VERSION
   # cp1    Ready    control-plane   1d    v1.35.2   # ← nouvelle version

6. Vérifier les add-ons après upgrade

   Après l’upgrade, vérifiez que les composants critiques fonctionnent toujours :

   # Vérifier CoreDNS
   kubectl get pods -n kube-system -l k8s-app=kube-dns
   # Tous doivent être Running
   
   # Vérifier kube-proxy
   kubectl get pods -n kube-system -l k8s-app=kube-proxy
   # DaemonSet, un pod par nœud
   
   # Vérifier le CNI (Flannel ou Calico)
   kubectl get pods -n kube-flannel  # ou -n calico-system
   # Tous doivent être Running
   
   # Vérifier qu'il n'y a pas d'erreurs dans les events
   kubectl get events -A --field-selector type=Warning --sort-by='.lastTimestamp' | head -10

Mettre à jour les workers

Les workers sont mis à jour un par un pour maintenir la disponibilité des applications. La procédure drain/upgrade/uncordon garantit que les pods sont déplacés avant toute intervention.

1. Drainer le nœud pour évacuer les pods

   Le drain déplace gracieusement tous les pods vers d’autres nœuds. Les DaemonSets restent car ils doivent tourner sur chaque nœud. Les pods avec des volumes emptyDir perdent leurs données, d’où l’option --delete-emptydir-data.

   # Depuis le control plane
   kubectl drain worker1 --ignore-daemonsets --delete-emptydir-data
   
   # Vérifier que le nœud est cordoned (SchedulingDisabled)
   kubectl get nodes
   # worker1   Ready,SchedulingDisabled   <none>   1d   v1.35.1

2. Mettre à jour kubeadm et kubelet sur le worker

   Sur le worker lui-même (pas sur le control plane), mettez à jour les composants. La commande kubeadm upgrade node met à jour la configuration locale du kubelet.

   # Sur le worker (SSH kube@192.168.122.20)
   sudo apt-mark unhold kubeadm kubelet
   sudo apt-get update
   sudo apt-get install -y kubeadm=1.35.2-1.1 kubelet=1.35.2-1.1
   sudo apt-mark hold kubeadm kubelet
   
   # Mettre à jour la configuration kubelet
   sudo kubeadm upgrade node
   
   # Redémarrer kubelet
   sudo systemctl daemon-reload
   sudo systemctl restart kubelet

3. Remettre le nœud en service

   Une fois la mise à jour terminée, autorisez à nouveau le scheduling sur ce nœud. Les pods en attente seront automatiquement schedulés dessus.

   # Depuis le control plane
   kubectl uncordon worker1
   
   # Vérifier que le nœud est Ready et à la nouvelle version
   kubectl get nodes
   # worker1   Ready   <none>   1d   v1.35.2

Répétez cette procédure pour chaque worker. En production, attendez que les pods soient stables sur un nœud avant de passer au suivant.

Sauvegarde et restauration d’etcd

etcd est la base de données du cluster Kubernetes. Elle contient tout : Deployments, Services, Secrets, ConfigMaps, état des pods, etc. Si etcd est corrompu ou perdu sans sauvegarde, le cluster est irrécupérable. La sauvegarde régulière d’etcd est donc critique en production.

etcd et CKA

Pour la CKA, vous devez savoir sauvegarder et restaurer etcd avec etcdctl. C’est une question classique de l’examen. Maîtrisez les chemins des certificats et la variable ETCDCTL_API=3.

Comprendre où sont stockées les données etcd

etcd tourne comme un pod statique sur chaque control plane. Ses données sont dans /var/lib/etcd/ et ses certificats dans /etc/kubernetes/pki/etcd/. Pour interagir avec etcd, vous avez besoin de 3 certificats :

Certificat	Chemin	Rôle
CA	/etc/kubernetes/pki/etcd/ca.crt	Autorité de certification etcd
Certificat client	/etc/kubernetes/pki/etcd/server.crt	Authentification du client
Clé privée	/etc/kubernetes/pki/etcd/server.key	Signature des requêtes

Glissez pour voir

Sauvegarder etcd

La sauvegarde crée un snapshot de toutes les données etcd. Cette opération est non-bloquante et peut être exécutée sur un cluster en production.

# Créer un snapshot d'etcd
# ETCDCTL_API=3 est obligatoire pour utiliser la v3 de l'API
ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Vérification : contrôlez que le snapshot est valide et contient des données. Depuis etcd 3.5.x, etcdctl snapshot status est déprécié ; utilisez plutôt etcdutl :

# Méthode recommandée (etcd 3.5+)
etcdutl --write-out=table snapshot status /tmp/etcd-backup.db
# +----------+----------+------------+------------+
# |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
# +----------+----------+------------+------------+
# | a1b2c3d4 |    12345 |       1024 |     2.1 MB |
# +----------+----------+------------+------------+

# Alternative si etcdutl n'est pas disponible
ETCDCTL_API=3 etcdctl snapshot status /tmp/etcd-backup.db --write-out=table

Bonnes pratiques de sauvegarde

En production, automatisez et externalisez les sauvegardes :

• Stockage externe : copiez les snapshots vers S3, GCS, NFS ou un stockage distant
• Chiffrement : chiffrez les snapshots (ils contiennent les Secrets du cluster)
• Tests réguliers : testez la restauration sur un cluster de test tous les mois
• Rétention : gardez au moins 7 jours de snapshots quotidiens

Restaurer etcd

La restauration d’etcd est une opération destructive : elle écrase toutes les données actuelles. Utilisez-la uniquement pour récupérer d’un désastre ou migrer vers un nouveau cluster.

Attention

La restauration d’etcd écrase toutes les données actuelles. Testez toujours la procédure sur un cluster de test avant de la faire en production. Arrêtez les services avant de restaurer.

1. Arrêter le control plane

   Arrêtez kubelet pour que les pods statiques (API server, etc.) s’arrêtent. etcd doit être arrêté pour la restauration.

   sudo systemctl stop kubelet

2. Restaurer le snapshot dans un nouveau répertoire

   La restauration crée un nouveau répertoire de données. Elle ne modifie pas /var/lib/etcd directement.

   ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
     --data-dir=/var/lib/etcd-restored

3. Remplacer les données etcd

   Sauvegardez l’ancien répertoire (au cas où) et mettez le nouveau en place.

   sudo mv /var/lib/etcd /var/lib/etcd.old
   sudo mv /var/lib/etcd-restored /var/lib/etcd

4. Redémarrer le control plane

   kubelet va redémarrer les pods statiques, y compris etcd avec les données restaurées.

   sudo systemctl start kubelet

5. Vérifier que le cluster fonctionne

   Attendez quelques minutes que tous les composants redémarrent.

   kubectl get nodes
   kubectl get pods -A

Renouvellement des certificats

Les certificats Kubernetes générés par kubeadm expirent après 1 an par défaut. Un certificat expiré bloque complètement l’accès au cluster : kubectl ne fonctionne plus, les nœuds perdent le contact avec l’API server.

Vérifier l’expiration des certificats

Cette commande affiche la date d’expiration de chaque certificat. Planifiez le renouvellement avant l’expiration.

sudo kubeadm certs check-expiration
# CERTIFICATE                EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
# admin.conf                 Mar 15, 2027 10:00 UTC   364d            no
# apiserver                  Mar 15, 2027 10:00 UTC   364d            no
# apiserver-etcd-client      Mar 15, 2027 10:00 UTC   364d            no
# ...

Surveillez la colonne RESIDUAL TIME. Renouvelez quand il reste moins de 30 jours.

Rotation automatique des certificats kubelet

Kubeadm configure par défaut la rotation automatique des certificats client kubelet. Ces certificats sont renouvelés automatiquement par kubelet avant expiration.

Les certificats que vous devez renouveler manuellement sont ceux du control plane :

• Certificats API server, etcd, controller-manager, scheduler
• Kubeconfig admin (admin.conf, controller-manager.conf, scheduler.conf)

Renouveler tous les certificats

Le renouvellement régénère tous les certificats avec une nouvelle validité d’un an. Les clients (kubectl, kubelet des workers) devront récupérer les nouveaux certificats.

# Renouveler tous les certificats du control plane
sudo kubeadm certs renew all

# Redémarrer les composants pour qu'ils utilisent les nouveaux certificats
sudo systemctl restart kubelet

Après le renouvellement, mettez à jour le fichier kubeconfig de votre utilisateur :

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

Automatisation : avec précautions

Vous pouvez automatiser le renouvellement avec un cronjob, mais avec précautions :

/etc/cron.d/kubernetes-certs-check

# Vérifie chaque semaine et alerte si expiration < 30 jours
0 9 * * 1 root kubeadm certs check-expiration | grep -E 'days|EXPIRED' | mail -s "[K8s] Certificats" admin@example.com

Ne pas faire : un cron qui renouvelle en aveugle. En cluster HA, le renouvellement doit être coordonné entre control planes. Préférez :

1. Surveillance : alertes quand expiration < 30 jours
2. Procédure documentée : renouveler manuellement control plane par control plane
3. Kubeadm 1.35+ : possibilité de personnaliser la durée avec certificateValidityPeriod

Dépannage du cluster

Le dépannage représente 30% de l’examen CKA — c’est le domaine le plus lourd. Cette section vous donne une méthodologie structurée et les commandes essentielles pour diagnostiquer rapidement les problèmes.

Méthodologie de diagnostic

Face à un problème, suivez cette approche en couches :

1. État du nœud : kubectl get nodes — le nœud est-il Ready ?
2. Pods système : kubectl get pods -n kube-system — les composants tournent-ils ?
3. kubelet : journalctl -u kubelet — le kubelet démarre-t-il ?
4. Composants : logs des pods statiques avec crictl
5. Réseau : connectivité entre pods, DNS, Services

Problèmes courants et solutions

Ce tableau couvre les situations les plus fréquentes. Pour chaque symptôme, la cause la plus probable et la solution directe.

Symptôme	Cause probable	Comment diagnostiquer	Solution
Nœud NotReady après init	CNI non installé	kubectl describe node → “network plugin is not ready”	Installer Flannel ou Calico
Nœud NotReady après reboot	kubelet ne démarre pas	journalctl -u kubelet -xe	Vérifier swap, cgroups, containerd
connection refused :6443	API server down	crictl ps -a | grep kube-api	Vérifier manifest /etc/kubernetes/manifests/kube-apiserver.yaml
Token expiré	Token > 24h	kubeadm token list	kubeadm token create --print-join-command
Certificat expiré	Certificats > 1 an	kubeadm certs check-expiration	kubeadm certs renew all
Pods en Pending	Pas de nœud disponible ou ressources insuffisantes	kubectl describe pod <pod> → Events	Ajouter des workers ou libérer des ressources
Pods en CrashLoopBackOff	Application qui crash	kubectl logs <pod> --previous	Corriger l’application
CoreDNS en CrashLoopBackOff	Problème CNI ou loop DNS	kubectl logs -n kube-system coredns-xxx	Vérifier CNI, /etc/resolv.conf
Worker ne joint pas	Connectivité, token, ou cgroups	journalctl -u kubelet -xe sur le worker	Vérifier les 3 causes ci-dessus

Glissez pour voir

Diagnostic du kubelet

Le kubelet est l’agent qui gère les conteneurs sur chaque nœud. S’il ne fonctionne pas, rien ne fonctionne sur ce nœud. Ces commandes sont vos premiers réflexes.

# État du service kubelet
sudo systemctl status kubelet
# Si inactive ou failed, regarder pourquoi :

# Logs détaillés du kubelet (les 100 dernières lignes)
sudo journalctl -u kubelet -n 100 --no-pager

# Logs en temps réel (pour voir ce qui se passe pendant un test)
sudo journalctl -u kubelet -f

# Erreurs spécifiques (--since pour limiter)
sudo journalctl -u kubelet --since "5 minutes ago" | grep -i error

Erreurs fréquentes dans les logs kubelet :

Message d’erreur	Cause	Solution
failed to run Kubelet: running with swap on is not supported	Swap actif	swapoff -a && sed -i '/swap/d' /etc/fstab
failed to get cgroup	Mauvais cgroup driver	Vérifier SystemdCgroup = true dans containerd
Unable to connect to the server	API server injoignable	Vérifier réseau et certificats
certificate has expired	Certificats expirés	kubeadm certs renew all

Glissez pour voir

Diagnostic des pods statiques du control plane

Les composants du control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) sont des pods statiques gérés directement par kubelet. Leurs manifests sont dans /etc/kubernetes/manifests/. Pour voir leurs logs, utilisez crictl (pas kubectl, qui nécessite un API server fonctionnel).

# Lister tous les conteneurs (y compris arrêtés)
sudo crictl ps -a

# Logs de l'API server
sudo crictl logs $(sudo crictl ps -q --name kube-apiserver)

# Logs d'etcd
sudo crictl logs $(sudo crictl ps -q --name etcd)

# Logs du scheduler
sudo crictl logs $(sudo crictl ps -q --name kube-scheduler)

# Logs du controller-manager
sudo crictl logs $(sudo crictl ps -q --name kube-controller-manager)

Ne pas utiliser kubectl get componentstatuses

La commande kubectl get componentstatuses (ou kubectl get cs) est dépréciée depuis Kubernetes 1.19. Elle retourne souvent des résultats incorrects ou incomplets. Préférez les méthodes ci-dessus pour vérifier l’état des composants.

Vérifier l’état d’etcd

etcd est la base de données du cluster. Si etcd ne fonctionne pas, l’API server ne peut pas stocker ni récupérer de données.

# Statut des endpoints etcd (santé du cluster etcd)
sudo ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Sortie attendue :
# https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 2.5ms

# Liste des membres du cluster etcd (utile en HA)
sudo ETCDCTL_API=3 etcdctl member list \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Diagnostic réseau et DNS

Les problèmes réseau sont fréquents. Ces commandes vérifient que les pods peuvent communiquer et que le DNS fonctionne.

# Vérifier que CoreDNS fonctionne
kubectl get pods -n kube-system -l k8s-app=kube-dns
# Les pods doivent être Running

# Tester la résolution DNS depuis un pod temporaire
kubectl run dnstest --image=busybox:1.28 --rm -it --restart=Never -- nslookup kubernetes
# Doit résoudre vers l'IP du service kubernetes (10.96.0.1 par défaut)

# Si DNS échoue, vérifier le service CoreDNS
kubectl get svc -n kube-system kube-dns
kubectl get endpoints -n kube-system kube-dns

# Vérifier les logs CoreDNS
kubectl logs -n kube-system -l k8s-app=kube-dns

Diagnostic des Services et endpoints

Quand un Service ne répond pas, vérifiez la chaîne complète : Service → Endpoints → Pods.

# Lister les Services avec leurs ClusterIP
kubectl get svc -A

# Vérifier qu'un Service a des endpoints (pods cibles)
kubectl get endpoints <service-name>
# Si ENDPOINTS est vide, le selector ne matche aucun pod

# Vérifier les EndpointSlices (nouveau format)
kubectl get endpointslices -l kubernetes.io/service-name=<service-name>

# Tester la connectivité vers un Service depuis un pod
kubectl run curltest --image=curlimages/curl --rm -it --restart=Never -- \
  curl -v http://<service-name>.<namespace>.svc.cluster.local

Voir les événements récents

Les événements Kubernetes sont une mine d’or pour le dépannage. Ils montrent ce qui s’est passé récemment.

# Tous les événements du cluster, triés par date
kubectl get events -A --sort-by='.lastTimestamp'

# Événements d'un namespace spécifique
kubectl get events -n <namespace>

# Événements liés à un objet spécifique
kubectl describe pod <pod-name>  # Section Events en bas

# Filtrer les événements de type Warning
kubectl get events -A --field-selector type=Warning

Reset complet d’un nœud

Si un nœud est trop corrompu pour être réparé, réinitialisez-le complètement. Cette procédure efface toute la configuration Kubernetes du nœud.

Opération destructive

Cette commande supprime tous les certificats, configurations et données Kubernetes du nœud. Utilisez-la uniquement si vous voulez repartir de zéro.

# Réinitialiser kubeadm (supprime certificats et configuration)
sudo kubeadm reset -f

# Supprimer la configuration CNI
sudo rm -rf /etc/cni/net.d

# Supprimer le kubeconfig utilisateur
sudo rm -rf $HOME/.kube

# Nettoyer les règles iptables créées par kube-proxy
sudo iptables -F
sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -X

# Optionnel : nettoyer les images containerd
sudo crictl rmi --all

Après le reset, vous pouvez rejoindre le cluster avec kubeadm join.

Compétences CKA couvertes par ce guide

Ce guide couvre principalement le domaine Cluster Architecture, Installation & Configuration (25%) de la CKA. Le tableau ci-dessous résume ce que vous avez appris et ce qui reste à maîtriser dans d’autres guides.

Ce que ce guide couvre (25% de l’examen)

Objectif CKA	Section du guide	Compétence acquise
Préparer l’infrastructure pour installer un cluster	Création des VMs, prérequis	Configuration kernel, containerd, swap
Créer et gérer des clusters avec kubeadm	Initialisation, join workers	kubeadm init, kubeadm join, CNI
Gérer le cycle de vie d’un cluster	Mise à jour	kubeadm upgrade, drain/uncordon
Implémenter un control plane HA	Configuration HA	HAProxy, stacked etcd, join control planes
Comprendre les interfaces d’extension (CNI, CSI, CRI)	Installation containerd, CNI	CRI avec containerd, CNI avec Flannel
Sauvegarder et restaurer etcd	Sauvegarde/restauration	etcdctl snapshot save/restore

Glissez pour voir

Ce que ce guide ne couvre pas (à étudier ailleurs)

La CKA évalue aussi des compétences non couvertes ici. Consultez les guides dédiés :

Domaine CKA	Poids	Ce qu’il faut savoir	Guide recommandé
Troubleshooting	30%	Logs, events, debug réseau, kubelet	Ce guide + pratique intensive
Services & Networking	20%	Services, Ingress, NetworkPolicies, Gateway API, CoreDNS	Guide Réseau Kubernetes
Workloads & Scheduling	15%	Deployments, rollouts, ConfigMaps, Secrets, scheduling	Guide Workloads Kubernetes
Storage	10%	PV, PVC, StorageClass, access modes	Guide Storage Kubernetes

Glissez pour voir

Outils à maîtriser pour la CKA

La CKA attend que vous maîtrisiez certains outils de packaging et configuration :

Outil	Ce qu’il faut savoir	Couvert ici ?
kubectl	Toutes les commandes, output JSON/YAML, —dry-run	Partiellement
kubeadm	init, join, upgrade, certs, reset	✅ Oui
etcdctl	snapshot save/restore, endpoint health	✅ Oui
Helm	install, upgrade, rollback, values	❌ Guide dédié
Kustomize	bases, overlays, patches	❌ Guide dédié
crictl	ps, logs, images	✅ Oui

Glissez pour voir

Conseil pour l'examen

La CKA est un examen pratique de 2 heures. Vous devez être rapide avec kubectl. Apprenez les alias (k=kubectl), l’autocomplétion (source <(kubectl completion bash)), et les options --dry-run=client -o yaml pour générer des manifests rapidement.

Tester vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

Ce guide vous a appris à installer et maintenir un cluster Kubernetes avec kubeadm. Voici les points essentiels à retenir :

1. kubeadm est l’outil officiel de bootstrap — il génère certificats, manifests et configure le cluster selon les standards upstream

2. containerd avec SystemdCgroup = true est obligatoire — c’est l’erreur n°1 des débutants, vérifiez toujours ce paramètre

3. Les modules kernel overlay et br_netfilter sont indispensables pour le réseau des conteneurs

4. Le swap doit être désactivé — kubelet refuse de démarrer si le swap est actif

5. Le CNI (Flannel, Calico) s’installe après kubeadm init — sans lui, les nœuds restent en NotReady

6. Spécifiez --control-plane-endpoint même pour un cluster single-node, cela permet de passer en HA plus tard

7. Mettez à jour control plane avant workers — respectez le version skew (1 version mineure max)

8. Sauvegardez etcd régulièrement — c’est la seule source de vérité du cluster, sans backup = perte totale

9. Renouvelez les certificats avant expiration — ils expirent après 1 an, planifiez le renouvellement

10. Pour dépanner : kubelet logs → crictl logs → events → describe — suivez cette progression systématiquement

Prochaines étapes

Ce guide vous a donné les bases de l’installation. Pour compléter votre préparation CKA, explorez ces domaines complémentaires :

Architecture Kubernetes Comprendre control plane, workers, etcd et les flux de communication

kubectl : le guide complet Maîtrisez toutes les commandes kubectl essentielles pour la CKA

Services et Networking Services, Ingress, NetworkPolicies et Gateway API

Storage Kubernetes PersistentVolumes, PVC, StorageClass et provisioning dynamique

Installer avec Kubespray Alternative Ansible pour déployer des clusters production-ready

Ressources

Pour aller plus loin, consultez ces ressources officielles :

• Documentation kubeadm — référence officielle pour toutes les options et procédures
• CKA Certification — page officielle avec le curriculum et les objectifs de l’examen
• Kubernetes the Hard Way — installation manuelle pour comprendre chaque composant en profondeur
• GitHub kubeadm — issues et discussions sur kubeadm
• Best practices clusters de production — recommandations officielles pour la production

×

📖 Voir la documentation →