Pourquoi Kubernetes ? Orchestration et architecture d'un cluster

Objectif

Comprendre le problème que résout Kubernetes, savoir nommer chaque composant d'un cluster et expliquer son rôle, et choisir la bonne distribution pour apprendre, tester ou produire.

L'essentiel

• Docker lance des conteneurs sur une machine. Kubernetes orchestre des conteneurs sur un groupe de machines : il les place, les relance, les met à l'échelle et les relie entre eux.
• Kubernetes est déclaratif : vous décrivez l'état voulu (« 3 copies de l'API, version 2.3 ») et des contrôleurs travaillent en boucle pour que la réalité rejoigne cette description.
• Un cluster = un plan de contrôle (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) + des nœuds de travail (kubelet, kube-proxy, runtime de conteneurs).
• Tout passe par l'API server : kubectl, les contrôleurs, le kubelet. Seul l'API server parle à etcd.
• Pour apprendre : kind ou minikube sur votre poste ; pour un petit serveur : k3s ; en production : kubeadm ou un service managé (EKS, AKS, GKE…).

Le problème : vos conteneurs en production

Prenons une plateforme de paiement marocaine fictive, AtlasPay. Son équipe a tout mis en conteneurs avec Docker : une API de paiement, un front web, un service de notifications SMS. Sur un seul serveur, docker compose up -d suffit. Puis viennent les vraies questions :

• Le serveur tombe un vendredi soir : qui relance les conteneurs sur une autre machine ?
• Le jour du Black Friday, le trafic est multiplié par dix : comment passer de 2 à 20 copies de l'API, sur plusieurs serveurs, et revenir à 2 ensuite ?
• Une nouvelle version de l'API doit sortir sans couper les paiements en cours.
• Comment les copies de l'API trouvent-elles la base de données, alors que leurs adresses IP changent à chaque redémarrage ?

C'est le travail d'un orchestrateur. Kubernetes (souvent écrit K8s : un K, huit lettres, un s) est l'orchestrateur devenu standard. Il est né chez Google, a été ouvert en 2014 et est maintenu aujourd'hui par la CNCF (Cloud Native Computing Foundation).

Ce que Kubernetes n'est pas : ce n'est pas une plateforme clé en main. Il ne compile pas votre code, ne fournit pas de base de données, n'impose pas d'outil de supervision. Il fournit des briques, et vous les assemblez.

Le modèle déclaratif

Avec Docker, vous donnez des ordres : « lance ce conteneur ». Avec Kubernetes, vous décrivez un état voulu dans un fichier YAML, puis vous le confiez à l'API :

# Extrait : « je veux 3 copies de l'API de paiement »
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-paiement
spec:
  replicas: 3

Un contrôleur compare en permanence l'état voulu (3 copies) et l'état réel. S'il n'en compte que 2 parce qu'un nœud est tombé, il en crée une nouvelle. C'est la boucle de réconciliation : observer, comparer, corriger, recommencer. Vous ne dites jamais « relance le conteneur », vous dites « il en faut 3 ».

L'architecture d'un cluster

                    ┌─────────────── PLAN DE CONTRÔLE ───────────────┐
  kubectl  ───────▶ │  kube-apiserver  ◀──▶  etcd (état du cluster)   │
  (vous)            │        ▲                                        │
                    │        ├── kube-scheduler  (où placer les Pods)  │
                    │        └── kube-controller-manager (boucles)     │
                    └────────┼────────────────────────────────────────┘
                             │ (HTTPS)
         ┌───────────────────┼──────────────────────┐
         ▼                   ▼                      ▼
   ┌─ nœud 1 ──────┐   ┌─ nœud 2 ──────┐      ┌─ nœud 3 ──────┐
   │ kubelet       │   │ kubelet       │      │ kubelet       │
   │ kube-proxy    │   │ kube-proxy    │      │ kube-proxy    │
   │ containerd    │   │ containerd    │      │ containerd    │
   │ [Pod][Pod]    │   │ [Pod]         │      │ [Pod][Pod]    │
   └───────────────┘   └───────────────┘      └───────────────┘

Le plan de contrôle

C'est le « cerveau » du cluster. En production, il tourne sur 3 machines dédiées pour la haute disponibilité.

Les nœuds

Ce sont les machines qui exécutent vos applications.

Depuis Kubernetes 1.24, Docker Engine n'est plus un runtime pris en charge directement. Les images construites avec Docker restent parfaitement utilisables : ce sont des images OCI standard, que containerd sait lancer.

Les modules complémentaires (addons)

Un cluster nu ne suffit pas. On ajoute presque toujours :

• un DNS interne (CoreDNS) : chaque Service reçoit un nom, par exemple api.paiement.svc.cluster.local ;
• un plugin réseau (CNI : Calico, Cilium, Flannel…) qui donne une IP à chaque Pod ;
• la collecte de métriques (metrics-server) et des journaux centralisés ;
• éventuellement le tableau de bord web (Dashboard).

Suivre une commande de bout en bout

Que se passe-t-il quand l'équipe d'AtlasPay crée un Deployment de 3 copies ?

kubectl apply -f api-paiement.yaml

1. kubectl lit le fichier et l'envoie en HTTPS à kube-apiserver.
2. L'API server vérifie votre identité et vos droits, valide le YAML, puis enregistre l'objet dans etcd.
3. Le contrôleur de Deployments (dans kube-controller-manager) voit le nouvel objet et crée un ReplicaSet, dont le contrôleur crée 3 Pods… qui n'ont pas encore de nœud.
4. kube-scheduler voit 3 Pods sans nœud et attribue à chacun le nœud le plus adapté.
5. Sur chaque nœud choisi, le kubelet voit qu'un Pod lui revient, demande au runtime de télécharger l'image et de lancer les conteneurs, puis remonte l'état à l'API server.
6. Vous voyez le résultat :

kubectl get pods -o wide
# NAME                            READY   STATUS    NODE
# api-paiement-6d8f9c7b5d-4kq2x   1/1     Running   noeud-1
# api-paiement-6d8f9c7b5d-9fz7m   1/1     Running   noeud-2
# api-paiement-6d8f9c7b5d-tw8rl   1/1     Running   noeud-3

Remarquez qu'aucun composant ne donne d'ordre direct à un autre : chacun observe l'API server et réagit. C'est ce qui rend Kubernetes robuste : si le scheduler redémarre, il reprend simplement les Pods encore sans nœud.

Les distributions : où faire tourner Kubernetes ?

Kubernetes est un projet ; pour l'utiliser, il faut une distribution ou un service qui l'installe pour vous.

Pour apprendre, sur votre poste

# kind : un cluster de 3 nœuds décrit dans un fichier (exemple du lab)
kind create cluster --name livraison --config kind-livraison.yaml
kubectl get nodes
# livraison-control-plane   Ready   control-plane
# livraison-worker          Ready   <none>
# livraison-worker2         Ready   <none>

# minikube : un nœud, en une commande
minikube start
kubectl get nodes

Pour un petit serveur ou la périphérie

k3s (projet CNCF) est une distribution certifiée et très légère : un seul binaire, quelques centaines de Mo de RAM. Idéal pour un serveur de test chez un hébergeur marocain, un Raspberry Pi ou un magasin. Comparable : MicroK8s (Canonical).

Pour la production

• kubeadm : l'outil officiel pour monter vous-même un cluster sur vos serveurs (sur site ou VPS). Vous gérez tout : mises à jour, sauvegardes d'etcd, certificats. Voir la leçon 4.2.
• Services managés : Amazon EKS, Azure AKS, Google GKE, et d'autres fournisseurs. Le fournisseur gère le plan de contrôle ; vous payez et gérez les nœuds. C'est le choix le plus courant quand on ne veut pas exploiter etcd soi-même.
• Distributions d'entreprise : Red Hat OpenShift, Rancher (RKE2), avec support commercial.

L'outil commun : kubectl

Quel que soit le cluster, vous lui parlez avec kubectl, qui lit l'adresse du cluster et vos identifiants dans ~/.kube/config :

kubectl version --client        # version du client, sans contacter de cluster
kubectl cluster-info            # adresse de l'API server (nécessite un cluster)
kubectl get nodes               # les nœuds et leur état
kubectl config get-contexts     # les clusters connus de votre kubeconfig

Dans les labs de cette formation, vous disposez de kubectl sans cluster : vous écrirez de vrais manifestes et utiliserez kubectl … --dry-run=client -o yaml, qui fonctionne hors ligne. Reproduisez ensuite chaque exercice sur un cluster kind ou minikube chez vous.

Les versions

Kubernetes publie environ trois versions mineures par an (1.32, 1.33, 1.34…). Chaque version est maintenue environ 14 mois. Conséquence pratique : un cluster doit être mis à jour au moins une fois par an, une version mineure à la fois. Les services managés vous y obligent d'ailleurs.

kubectl version
# Client Version: v1.34.x
# Server Version: v1.33.x     ← le client peut avoir une version mineure d'écart avec le serveur

Pièges fréquents

• Croire que Kubernetes remplace Docker : vous construisez toujours vos images avec Docker (ou Buildah, Podman) ; Kubernetes les exécute avec containerd.
• Monter un cluster kubeadm pour apprendre : commencez par kind ou minikube. kubeadm demande plusieurs machines et beaucoup de réglages.
• Négliger etcd : sans sauvegarde d'etcd, un incident sur le plan de contrôle d'un cluster kubeadm peut tout effacer.
• Penser « serveurs » plutôt que « état voulu » : on ne se connecte pas en SSH sur un nœud pour relancer un conteneur ; on corrige le manifeste et on laisse les contrôleurs agir.

Lab

Vous allez :

1. nommer le composant qui stocke l'état du cluster ;
2. trier une liste de composants pour ne garder que ceux du plan de contrôle ;
3. écrire le fichier de configuration d'un cluster kind à trois nœuds pour l'application de livraison, que vous pourrez réutiliser chez vous avec kind create cluster --config.

Pour écrire un fichier sans éditeur, utilisez cat > fichier <<EOF … EOF ou printf.

Quiz

1. Quel composant choisit le nœud sur lequel tournera un nouveau Pod ?
2. Quel est le seul composant qui lit et écrit directement dans etcd ?
3. Quel composant tourne sur chaque nœud et s'assure que les conteneurs de ses Pods fonctionnent ?
4. Vous voulez tester un cluster à 3 nœuds sur votre portable en deux minutes : quel outil choisissez-vous ?
5. Que signifie « Kubernetes est déclaratif » ?