Kubernetes
| Fiche express | |
|---|---|
| Type | Système d'orchestration de conteneurs |
| Control plane | etcd · kube-apiserver · kube-controller-manager · kube-scheduler · cloud-controller-manager |
| Nœud (worker) | kubelet · container runtime · kube-proxy |
| Unité de base | Pod |
| Voir aussi | Kubeadm · Kubectl · Minikube · Réseau Kubernetes — Modèle et primitives |
Kubernetes (souvent abrégé k8s) est un système d'orchestration de conteneurs : il planifie, déploie, fait évoluer et surveille des charges de travail conteneurisées sur un ensemble de machines (le cluster), en maintenant en continu l'état déclaré par l'utilisateur. Cette page donne une vue d'ensemble de l'architecture ; pour la mise en service pratique d'un cluster voir Kubeadm (multi-nœuds) ou Minikube (poste de travail local), et pour le modèle réseau voir Réseau Kubernetes — Modèle et primitives.
Architecture
Un cluster Kubernetes est divisé en deux plans : le control plane, qui pilote le cluster, et les nœuds (nodes), qui exécutent réellement les charges de travail.
<mermaid> flowchart TB
subgraph CP["Control plane"]
API["kube-apiserver"]
ETCD["etcd"]
CM["kube-controller-manager"]
SCHED["kube-scheduler"]
CCM["cloud-controller-manager"]
API <--> ETCD
API --> CM
API --> SCHED
API --> CCM
end
subgraph N["Nœud worker"]
KUBELET["kubelet"]
CRI["Container runtime"]
PROXY["kube-proxy"]
POD1["Pod"]
POD2["Pod"]
KUBELET --> CRI
CRI --> POD1
CRI --> POD2
PROXY -.-> POD1
PROXY -.-> POD2
end
API <--> KUBELET
</mermaid>
Le schéma d'architecture de référence de la documentation officielle (habituellement diffusé sous le nom Kube-archi) représente ces deux plans côte à côte : à gauche le control plane avec ses composants pilotés par API, à droite un ou plusieurs nœuds exposant kubelet, le container runtime et kube-proxy, avec les Pods qu'ils hébergent.
Composants du control plane
- etcd — base de données clé-valeur distribuée qui stocke l'état complet du cluster ; c'est la source de vérité unique.
- kube-apiserver — point d'entrée de l'API REST du cluster ; seul composant qui dialogue directement avec etcd, tout le reste (kubectl, kubelet, controllers) passe par lui.
- kube-controller-manager — exécute les boucles de contrôle (reconciliation) qui rapprochent en continu l'état observé de l'état déclaré (contrôleur de nœuds, de réplication, d'endpoints, etc.).
- kube-scheduler — choisit sur quel nœud placer chaque Pod nouvellement créé, en fonction des ressources disponibles, des contraintes d'affinité/anti-affinité et des taints/tolerations.
- cloud-controller-manager — interface avec l'API du fournisseur cloud sous-jacent (création de LoadBalancer, attachement de volumes, routes réseau) ; absent ou non pertinent sur un cluster bare-metal installé via kubeadm sans intégration cloud.
Composants de chaque nœud
- kubelet — agent qui tourne sur chaque nœud du cluster ; il s'assure que les conteneurs décrits dans les PodSpecs assignés à son nœud sont bien démarrés et en bonne santé.
- Container runtime — exécute effectivement les conteneurs (containerd, CRI-O ; Docker a longtemps servi via un adaptateur dockershim, retiré des versions récentes — à vérifier selon la version ciblée).
- kube-proxy — proxy réseau qui programme les règles sur le nœud pour permettre aux Services de router le trafic vers les bons Pods ; voir Réseau Kubernetes — Modèle et primitives pour le détail de ses modes de fonctionnement (iptables, IPVS, eBPF).
Le Pod, unité de base
Le Pod est la plus petite unité déployable de Kubernetes : un ou plusieurs conteneurs qui partagent le même espace de noms réseau (une IP commune) et, optionnellement, des volumes. Un Pod à conteneur unique est le cas le plus courant ; le regroupement de plusieurs conteneurs étroitement couplés dans un même Pod (sidecar, init container) est traité dans Kubernetes multicontainers. Les Pods sont normalement créés et gérés par un contrôleur de niveau supérieur — typiquement un Deployment — plutôt que directement, sauf cas particulier des static Pods gérés en direct par un kubelet.
Mettre en place un cluster
Deux approches courantes :
- Kubeadm — outil officiel pour amorcer un cluster multi-nœuds réaliste (control plane + workers), suivant les bonnes pratiques du projet. C'est la voie à privilégier pour un cluster destiné à ressembler à de la production.
- Minikube — cluster mono-nœud local, pensé pour le développement et l'apprentissage sur un poste de travail, sans provisionner d'infrastructure.
Les prérequis systèmes (désactivation du swap, modules noyau overlay/br_netfilter, paramètres sysctl, choix et installation du container runtime), l'initialisation du control plane, le déploiement d'un add-on réseau CNI et la jonction des nœuds workers sont détaillés dans Kubeadm plutôt que répétés ici. Les exemples de commandes qu'on y trouve ciblent Kubernetes 1.27 et 1.31 (à vérifier selon la version effectivement utilisée : les paquets, dépôts et options de kubeadm init évoluent d'une version mineure à l'autre).
Objets applicatifs courants
Une fois le cluster disponible, l'essentiel du travail quotidien passe par Kubectl pour manipuler des objets tels que :
- les namespaces, pour partitionner logiquement le cluster ;
- les Deployments, pour gérer replicas, rolling updates et rollbacks d'une application ;
- les Services, pour exposer un ensemble de Pods derrière une adresse stable.