infra / kubernetes

Pourquoi Kubernetes et architecture du cluster

Leçon 11 exercice

Explication

Un peu d'histoire

Kubernetes est créé par Google et rendu open source en juin 2014. Il s'inspire directement de "Borg", le système interne que Google utilise en secret depuis le début des années 2000 pour orchestrer des millions de conteneurs sur ses propres centres de données. Le nom "Kubernetes" vient du grec ancien κυβερνήτης (kybernetes), qui signifie "pilote" ou "timonier" — d'où le logo du projet, en forme de roue de gouvernail de bateau.

Pourquoi apprendre Kubernetes aujourd'hui

Kubernetes est devenu le standard de facto pour orchestrer des conteneurs en production : redémarrer automatiquement un service qui plante, répartir la charge, scaler selon le trafic, déployer sans interruption de service. Confié en 2015 à la CNCF (Cloud Native Computing Foundation), il est aujourd'hui au cœur de la quasi-totalité des architectures cloud modernes, et la maîtrise de Kubernetes est une compétence extrêmement recherchée dans les métiers DevOps, SRE et Platform Engineering.

Ce que vous allez apprendre

Expliquer en une phrase ce que fait Kubernetes et pourquoi ce n'est pas un concurrent de Docker
Distinguer modèle déclaratif et modèle impératif, et pourquoi Kubernetes choisit le premier
Décrire la boucle de réconciliation et l'illustrer avec l'analogie du thermostat
Nommer les composants du control plane (API server, etcd, scheduler, controller manager) et leur rôle respectif
Distinguer le rôle du control plane (décider) de celui des nodes (exécuter)

Dans quel contexte ?

Un ingénieur SRE reçoit une alerte à 3h du matin : l'un des 15 serveurs de production vient de tomber en panne, emportant avec lui 40 conteneurs applicatifs. Sans orchestrateur, il faudrait se connecter manuellement, identifier les conteneurs perdus, et les relancer ailleurs à la main, sous pression et avec le risque d'erreur que cela implique. Avec Kubernetes, la boucle de réconciliation détecte l'écart entre l'état désiré (40 conteneurs) et l'état réel (0, suite à la panne), et replanifie automatiquement ces conteneurs sur les nœuds encore disponibles, souvent avant même que quiconque ait eu le temps de recevoir l'alerte.

Prérequis

Ce cours suppose une connaissance de base de Docker et des conteneurs (image, conteneur, port exposé). Si ces notions ne sont pas encore claires, mieux vaut suivre d'abord un cours Docker avant de continuer ici.

Le problème, très concrètement

D'abord, imagine que tu gères une dizaine de serveurs et une centaine de conteneurs. Un serveur tombe en panne à 3h du matin : qui redémarre les conteneurs ailleurs ? Le trafic augmente brutalement : qui ajoute des instances ? Faire tout cela à la main devient vite ingérable.

Une première idée : automatiser les décisions

Kubernetes est un orchestrateur : un logiciel qui prend ces décisions à ta place, en continu, 24h/24. Il ne remplace pas Docker, il ajoute une couche au-dessus pour gérer PLUSIEURS machines et PLUSIEURS conteneurs comme un seul système cohérent.

Comment il sait quoi faire : le modèle déclaratif

Plutôt que de dire "fais ceci, puis cela" (modèle impératif), tu décris un état désiré : "je veux 3 exemplaires de mon application, exposés sur le port 80". Kubernetes compare en permanence cet état désiré à l'état réel du cluster.

Une boucle qui tourne sans arrêt

Une fois qu'un écart apparaît entre l'état désiré et l'état réel, Kubernetes le corrige automatiquement. C'est une boucle de réconciliation, exactement comme un thermostat qui compare la température voulue à la température mesurée et ajuste le chauffage en conséquence.

Deux rôles bien séparés dans le cluster

Il reste à comprendre comment un cluster est organisé. Le control plane est le "cerveau" : il stocke l'état désiré, décide où placer chaque charge de travail, et surveille que tout se passe bien. Les workers (nodes), eux, sont les "bras" : ils exécutent réellement les conteneurs.

Composant	Rôle	Où il tourne
kube-apiserver	Point d'entrée unique ; toutes les requêtes passent par lui	Control plane
etcd	Stocke l'état désiré du cluster (source de vérité)	Control plane
kube-scheduler	Décide sur quel nœud placer chaque nouveau Pod	Control plane
kube-controller-manager	Fait tourner les boucles de réconciliation	Control plane
kubelet	Exécute réellement les conteneurs sur le nœud	Worker node

Pourquoi cette séparation compte pour la suite

Garde cette distinction en tête pour tout le cours : quand quelque chose ne fonctionne pas, il faut se demander si le problème vient d'une décision (control plane) ou d'une exécution (node). Cette question guidera presque tous tes diagnostics futurs.

Le piège à éviter dès le départ

Beaucoup de débutants confondent Kubernetes avec Docker. Docker fait tourner UN conteneur sur UNE machine ; Kubernetes orchestre des conteneurs sur PLUSIEURS machines. Ce n'est pas un concurrent de Docker, c'est une couche au-dessus.

Piège fréquent

Kubernetes a lui-même besoin d'un runtime de conteneurs (containerd, CRI-O...) pour fonctionner : ce n'est donc jamais un remplaçant de Docker, mais une couche d'orchestration qui s'appuie dessus (ou sur un runtime équivalent).

La leçon suivante te fait passer à la pratique : installer un cluster local et apprendre les toutes premières commandes de kubectl.

Commandes & code

Pourquoi Kubernetes ?

Kubernetes automatise le déploiement, le scaling et la résilience d'applications conteneurisées sur un ensemble de machines (le cluster).

Control Plane (cerveau du cluster)
├── kube-apiserver     -> point d'entrée unique (API REST/gRPC), tout passe par lui
├── etcd                -> base clé-valeur, source de vérité de l'état du cluster
├── kube-scheduler       -> décide sur quel nœud placer chaque nouveau Pod
├── kube-controller-manager -> boucles de contrôle (ReplicaSet, Node, etc.)
└── cloud-controller-manager -> intégrations avec le cloud (LoadBalancer, volumes...)

Worker Nodes (exécutent les charges de travail)
├── kubelet              -> agent qui fait tourner les conteneurs sur le nœud
├── kube-proxy            -> règles réseau pour joindre les Services
└── container runtime     -> containerd / CRI-O (exécute réellement les conteneurs)

# Vue d'ensemble d'un cluster
kubectl cluster-info
kubectl get nodes -o wide
kubectl get componentstatuses   # historique, souvent déprécié selon la distribution

# Voir tous les objets du control plane (dans le namespace kube-system)
kubectl get pods -n kube-system

# Le "modèle déclaratif" : on décrit l'état désiré, Kubernetes fait converger la réalité vers lui
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
# Ce fichier ne fait "rien" tout seul : il faut l'appliquer (leçon suivante)

Résumé

Kubernetes = boucle de réconciliation permanente : état désiré (YAML) vs état réel (cluster).
Control plane décide (API, scheduler, controllers) ; les nodes exécutent (kubelet, runtime).
etcd est la source de vérité : sa perte = perte de l'état du cluster.
Tout objet Kubernetes passe par le kube-apiserver, jamais d'accès direct à etcd.

Exercices pratiques

1 disponible

Mission : comprendre une panne à 3h du matin

Objectif : Diagnostiquer une panne de production en distinguant ce qui relève du control plane de ce qui relève des nodes, et expliquer comment la boucle de réconciliation réagit sans intervention humaine.

Contexte

Tu es l'ingénieur SRE de garde. Une alerte tombe à 3h du matin : un des 15 nodes de production vient de tomber en panne matérielle, emportant avec lui 40 Pods. Ton manager, réveillé lui aussi, te demande par message : "Le kube-scheduler a planté ?" avant même que tu aies eu le temps de te connecter au cluster. Tu dois poser le bon diagnostic avant d'agir.

Résoudre l’exercice →