Pourquoi Kubernetes

Pourquoi

Dans les cours précédents, Signalements a appris à vivre dans un conteneur (Docker : les fondamentaux), puis sur deux instances dans deux zones (Le cloud : les fondamentaux), avec une unité systemd qui lance le conteneur et le relance s'il s'arrête. Cette architecture fonctionne. Regardons ce qu'elle demande à l'équipe le jour où l'application grandit.

Une métropole cliente annonce une campagne de communication : le trafic va tripler pendant deux semaines. Il faut une troisième, puis une quatrième machine. Pour chacune : créer l'instance, attendre cloud-init, l'ajouter au répartiteur de charge. Quand la campagne se termine, il faut les retirer, sans couper les requêtes en cours.

Une nouvelle version sort. Il faut, machine par machine, retirer l'instance du répartiteur, arrêter l'ancien conteneur, lancer le nouveau, vérifier /sante, remettre l'instance en service, et revenir en arrière si la troisième machine montre des erreurs. Le cours cloud a décrit la procédure ; il faut maintenant la scripter, et que le script gère tous les cas d'échec.

Une machine tombe en panne une nuit. systemd relance un conteneur qui plante, mais il ne peut rien pour une machine éteinte : il faut que quelqu'un, ou quelque chose, recrée la charge ailleurs.

L'équipe ajoute un deuxième service, un traitement des photos, puis un troisième. Chacun a besoin de savoir où joindre les autres, avec des adresses qui changent à chaque remplacement de machine. Et chaque machine est à moitié vide, parce que personne n'ose placer à la main deux services sur la même.

Chacun de ces problèmes a une solution artisanale : scripts, fichiers d'inventaire, conventions de nommage. Ensemble, ils forment un logiciel que l'équipe n'a pas envie d'écrire et encore moins de maintenir. Ce logiciel existe : c'est un orchestrateur de conteneurs, et Kubernetes est celui qui s'est imposé. Il prend en charge, pour tout un parc de machines :

• le placement : sur quelle machine faire tourner chaque conteneur, selon les ressources libres ;
• la guérison (self-healing) : relancer un conteneur qui s'arrête, recréer ailleurs ce qui tournait sur une machine perdue ;
• les mises à jour progressives et le retour arrière ;
• la découverte de services et la répartition de charge : un nom stable devant un ensemble de conteneurs qui changent ;
• la mise à l'échelle, à la main ou automatique ;
• la configuration et les secrets injectés dans les conteneurs sans reconstruire les images.

Cette liste reprend, à peu de chose près, celle de la page de présentation de la documentation officielle. Ce cours vous apprend à vous en servir, et à comprendre ce qui se passe dessous.

Les concepts

L'idée centrale : l'état voulu et les boucles de contrôle

Si vous avez suivi le cours GitOps avec Argo CD, vous connaissez déjà l'idée qui fonde Kubernetes : on ne lui donne pas des ordres (« lance trois conteneurs »), on lui déclare un état voulu (« il doit y avoir trois exemplaires de ce conteneur »), et des programmes travaillent sans arrêt à rapprocher la réalité de cette déclaration.

La documentation de Kubernetes explique ces programmes par l'analogie du thermostat. Vous réglez la température voulue ; la température de la pièce est l'état actuel ; le thermostat allume ou éteint le chauffage pour rapprocher l'un de l'autre, et il recommence sans fin. Dans Kubernetes, ces thermostats s'appellent des contrôleurs (controllers) : chacun observe un type d'objet, compare l'état voulu à l'état observé, et agit pour réduire l'écart. Ce mécanisme s'appelle la réconciliation.

Les conséquences pratiques sont considérables :

• Une panne n'est qu'un écart de plus. Si une machine disparaît avec deux des trois conteneurs de Signalements, le contrôleur constate qu'il en manque deux et en recrée deux ailleurs. Aucune procédure spéciale « panne de machine » : c'est la même boucle que pour le démarrage initial.
• Une mise à jour est un changement d'état voulu. On remplace « version 1.2.0 » par « version 1.3.0 » dans la déclaration ; un contrôleur fait la transition, progressivement.
• L'état voulu est un document. Il s'écrit dans un fichier texte (un manifeste, en YAML), se versionne dans Git, se relit en revue de code. C'est ce qui rend le GitOps naturel avec Kubernetes.

La documentation pousse l'idée jusqu'à affirmer que Kubernetes n'est pas un simple système d'orchestration au sens d'une suite d'étapes A, puis B, puis C : c'est un ensemble de processus de contrôle indépendants qui ramènent continuellement l'état actuel vers l'état voulu, sans que l'ordre des étapes ait d'importance.

Les objets

Tout ce que l'on déclare à Kubernetes est un objet : un enregistrement persistant, que la documentation appelle un « enregistrement d'intention » (record of intent). Une fois l'objet créé, le système travaille en permanence à ce qu'il existe. Les principaux objets de ce cours :

Chaque objet a une partie spec (l'état voulu, écrit par vous) et une partie status (l'état observé, écrit par Kubernetes). La leçon 3 en détaille la structure.

Une brève histoire

Le nom vient du grec ancien et signifie « timonier » ou « pilote » ; l'abréviation K8s remplace les huit lettres entre le « K » et le « s ». Les auteurs de l'article Borg, Omega, and Kubernetes (ACM Queue, 2016) racontent ce que Kubernetes a repris de dix ans d'expérience chez Google, et ce qu'il a volontairement changé : le regroupement de conteneurs en Pods, une adresse IP par Pod plutôt que des ports partagés, des étiquettes souples plutôt qu'une hiérarchie figée, et une API unique par laquelle passent tous les composants.

Nomad reste un concurrent vivant, plus simple, apprécié pour mélanger conteneurs et binaires ; Docker Swarm subsiste dans Docker Engine. Mais l'écosystème (outils de déploiement, opérateurs, observabilité, sécurité) s'est construit autour de l'API de Kubernetes, et c'est elle que les offres managées de tous les fournisseurs exposent.

Ce que Kubernetes n'est pas

La documentation officielle prend soin de le dire, et c'est la source de beaucoup de déceptions :

• Ce n'est pas une plateforme applicative (PaaS) complète. Kubernetes fait tourner des conteneurs ; il ne déploie pas du code source, ne construit pas d'images et ne fournit pas de chaîne CI/CD. Il faut toujours un pipeline, comme celui du cours GitHub Actions.
• Il ne fournit pas de services applicatifs. Pas de base de données, de file de messages ni de cache intégrés. On peut en faire tourner dans Kubernetes, mais c'est vous qui les exploitez ; beaucoup d'équipes préfèrent les services managés du fournisseur (cours Scaleway en pratique).
• Il n'impose ni journalisation, ni supervision, ni alerting. Il faut les ajouter.
• Il ne gère pas les machines. Installer, mettre à jour et réparer les nœuds relève d'autres outils, ou du fournisseur dans une offre managée.
• Il ne rend pas le stockage magique. Un conteneur qui écrit sur son disque perd ses données quand il est recréé ailleurs ; le stockage persistant (leçon 9) est un sujet à part entière.

Le prix de la complexité, et quand s'en passer

Kubernetes coûte : un plan de contrôle à faire tourner ou à payer, des nœuds souvent sous-utilisés, une API riche à apprendre, des mises à jour de version trois fois par an, et une surface d'attaque nouvelle. Ce coût se justifie quand plusieurs des problèmes de la section Pourquoi se posent en même temps : plusieurs services, plusieurs équipes, des déploiements fréquents, des besoins de mise à l'échelle.

Il ne se justifie pas toujours. Quelques repères :

Lyneko, pour ses propres applications, a fait le choix de Kubernetes : un cluster Kapsule, lyneko-apps, héberge plusieurs applications (dont le site que vous lisez), déployées par Argo CD et exposées par Traefik. Le choix se justifie par le nombre d'applications et la volonté de les déployer toutes de la même façon ; pour une seule API, il aurait été disproportionné.

Managé, auto-géré, distributions

Kubernetes managé. Le fournisseur exploite le plan de contrôle (le « cerveau » du cluster, leçon 2), le met à jour et le rend disponible ; vous gérez vos charges de travail et, plus ou moins, vos nœuds. Chez Scaleway, l'offre s'appelle Kapsule ; ailleurs, Amazon EKS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), OVHcloud Managed Kubernetes. C'est le choix par défaut pour la plupart des équipes.

Kubernetes auto-géré. Vous installez et exploitez tout, avec kubeadm par exemple, sur vos machines ou des instances. C'est le cas des environnements déconnectés, des contraintes de souveraineté fortes (voir le cours Cloud souverain), ou des équipes qui veulent maîtriser chaque composant. Le cours Kubernetes : administrer un cluster le traite.

Les distributions. Plusieurs projets empaquettent Kubernetes avec des choix tout faits : k3s et k0s (légers, un seul binaire, pour l'embarqué et les petits clusters), RKE2 (orienté sécurité), OpenShift de Red Hat (une plateforme complète construite sur Kubernetes, avec ses propres ajouts). Pour s'assurer qu'une distribution ou une offre managée se comporte comme Kubernetes, la CNCF tient un programme de certification de conformité : une offre certifiée passe la suite de tests officielle de l'API.

Pour apprendre, ce cours utilise kind (Kubernetes IN Docker), qui crée un cluster complet dont chaque nœud est un conteneur Docker, sur votre poste. La fiche de l'outil en résume les pièges ; la leçon 3 l'installe.

Les versions et leur cycle de vie

Kubernetes publie environ trois versions mineures par an (1.35, 1.36, 1.37...). Le projet maintient les trois dernières ; chacune reçoit environ un an de correctifs, puis atteint sa fin de vie. Au 5 octobre 2026, la page officielle des versions indique :

Ce cours est écrit pour Kubernetes 1.36, qui reste maintenue jusqu'en juin 2027 ; tout ce qu'il enseigne s'applique à la 1.37. La conséquence pratique est importante : un cluster doit monter de version au moins une fois par an, sous peine de tourner sans correctifs de sécurité. Les offres managées imposent leur propre calendrier, souvent un peu décalé. Planifiez ces montées de version comme une tâche récurrente, pas comme un événement exceptionnel.

En pratique

Cette première leçon ne crée pas encore de cluster (ce sera la leçon 3). Elle installe kubectl, l'outil en ligne de commande de Kubernetes, et lit le premier manifeste.

Installer kubectl

La documentation officielle propose deux méthodes sous Linux. La plus simple à mettre à jour est le dépôt de paquets du projet, pkgs.k8s.io, qui a un dépôt par version mineure :

$ sudo apt-get update
$ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key \
    | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
$ sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' \
    | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update && sudo apt-get install -y kubectl

• La clé du dépôt est rangée dans /etc/apt/keyrings/ et limitée à ce dépôt par signed-by, comme le recommande le cours Linux : premiers pas.
• Le chemin contient v1.36 : pour passer à la 1.37, il faut changer de dépôt. C'est voulu, pour qu'une mise à jour de routine ne change pas de version mineure.

L'autre méthode télécharge le binaire et vérifie sa somme de contrôle :

$ curl -LO https://dl.k8s.io/release/v1.36.0/bin/linux/amd64/kubectl
$ curl -LO https://dl.k8s.io/release/v1.36.0/bin/linux/amd64/kubectl.sha256
$ echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
kubectl: OK
$ sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

La ligne kubectl: OK est celle qu'annonce la documentation quand la somme correspond. Vérifiez la version installée :

$ kubectl version --client
Client Version: v1.36.0
Kustomize Version: v5.8.1

Cette sortie a été produite sur le poste qui a servi à rédiger le cours. kubectl embarque Kustomize, un outil de personnalisation de manifestes (cours Kustomize). Sans --client, la commande interroge aussi le serveur du cluster courant, que nous n'avons pas encore.

Lire un premier manifeste

kubectl sait générer un manifeste sans rien envoyer à un cluster, grâce à l'option --dry-run=client. Demandons la déclaration d'un Deployment de Signalements avec deux exemplaires :

$ kubectl create deployment signalements \
    --image=ghcr.io/lyneko-formation/signalements:1.2.0 \
    --replicas=2 --port=8000 --dry-run=client -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: signalements
  name: signalements
spec:
  replicas: 2
  selector:
    matchLabels:
      app: signalements
  strategy: {}
  template:
    metadata:
      labels:
        app: signalements
    spec:
      containers:
      - image: ghcr.io/lyneko-formation/signalements:1.2.0
        name: signalements
        ports:
        - containerPort: 8000
        resources: {}
status: {}

Cette sortie est réelle. Lisons-la de haut en bas :

• apiVersion: apps/v1 et kind: Deployment disent quel type d'objet est décrit, et dans quelle version de l'API (leçon 3).
• metadata identifie l'objet : son nom et ses étiquettes (labels), ici app: signalements.
• spec est l'état voulu :
  • replicas: 2 : deux exemplaires ;
  • selector.matchLabels : le Deployment reconnaît « ses » Pods à l'étiquette app: signalements ;
  • template : le modèle de chaque Pod, avec ses propres étiquettes (les mêmes, sinon le Deployment ne les reconnaîtrait pas) et la liste de ses conteneurs : image, nom, port.
• status: {} est vide : c'est Kubernetes qui le remplira, avec ce qu'il observe.
• strategy: {} et resources: {} sont vides : les valeurs par défaut s'appliqueront. Les leçons 5 et 8 montrent pourquoi il ne faut pas en rester là.

Remarquez ce qui n'y est pas : aucune machine, aucune adresse IP, aucun ordre de démarrage. Vous déclarez ce qui doit exister ; l'ordonnanceur choisit les machines, les contrôleurs créent les Pods.

Enregistrez ce manifeste dans un fichier : il servira à la leçon 3, une fois le cluster créé.

$ kubectl create deployment signalements \
    --image=ghcr.io/lyneko-formation/signalements:1.2.0 \
    --replicas=2 --port=8000 --dry-run=client -o yaml > signalements-deployment.yaml

Sous le capot

Pourquoi « niveau » et pas « événement »

Les contrôleurs de Kubernetes sont conçus pour réagir à un état, pas à des événements. L'expression anglaise vient de l'électronique : un circuit déclenché par niveau (level-triggered) réagit tant que le signal est haut, un circuit déclenché par front (edge-triggered) réagit seulement au moment où le signal change.

Imaginez un contrôleur déclenché par événements : « un Pod vient de mourir, j'en recrée un ». S'il est redémarré au mauvais moment, ou si un message se perd, l'événement est manqué et le Pod n'est jamais recréé. Un contrôleur déclenché par niveau se contente de regarder, à chaque passage : « combien de Pods vivants ? Combien en faut-il ? ». S'il manque un événement, il rattrape l'écart au passage suivant. C'est ce qui rend Kubernetes robuste aux pannes de ses propres composants : la documentation insiste sur le fait que les contrôleurs peuvent échouer, et que le système est conçu pour cela.

La leçon 2 montre comment ces contrôleurs sont informés des changements sans interroger sans cesse le cluster.

Beaucoup de petits contrôleurs

Kubernetes ne contient pas un grand programme qui sait tout faire, mais des dizaines de contrôleurs simples, chacun responsable d'un aspect : un contrôleur pour les Deployments, un pour les ensembles de Pods répliqués, un pour les Jobs, un pour les nœuds, etc. Un contrôleur lit un type d'objet (l'état voulu) et en gère un autre : le contrôleur de Deployments crée des ReplicaSets, le contrôleur de ReplicaSets crée des Pods. Aucun ne lance lui-même de conteneur : ils écrivent tous dans l'API, et c'est l'agent de chaque machine, le kubelet, qui fait tourner les conteneurs (leçon 2).

Ce découpage a un avantage décisif : on peut ajouter des contrôleurs. C'est ainsi qu'Argo CD fonctionne : un contrôleur de plus, qui lit des objets Application et écrit dans l'API (cours GitOps avec Argo CD). Le cours Kubernetes : workloads avancés, CRD et opérateurs montre comment en écrire un.

Pièges courants

Adopter Kubernetes pour une seule application simple. Le coût d'apprentissage et d'exploitation dépasse alors le gain. Commencez par la question : quels problèmes de la section Pourquoi ai-je vraiment ?

Croire qu'un cluster managé ne demande plus d'exploitation. Le fournisseur gère le plan de contrôle ; vous gérez les montées de version de vos nœuds et de vos manifestes (des API disparaissent d'une version à l'autre), les ressources, la sécurité de vos charges de travail, la supervision.

Penser en commandes plutôt qu'en état. Lancer des Pods à la main avec des commandes impératives donne un cluster que personne ne sait reconstruire. Les manifestes versionnés sont la source de vérité ; les commandes impératives servent à explorer et à générer des manifestes.

Un kubectl trop éloigné de la version du cluster. Respectez l'écart d'une version mineure au plus. Sur un poste qui administre plusieurs clusters de versions différentes, gardez plusieurs binaires ou un gestionnaire de versions.

Laisser un cluster atteindre sa fin de vie. Une version sans correctifs, c'est des failles connues non corrigées sur le composant le plus exposé de l'infrastructure. Planifiez les montées de version.

Sécurité

• L'API de Kubernetes est le nouveau plan de contrôle à protéger. Qui peut écrire dans l'API peut lancer n'importe quel conteneur, avec les privilèges qu'il demande. L'accès à un cluster se traite comme l'accès administrateur à toutes les machines qui le composent (leçon 3 pour le fichier kubeconfig, cours Sécurité de Kubernetes pour le contrôle d'accès).
• Les valeurs par défaut ne sont pas sûres. Un Pod sans restriction peut tourner en root, sans limite de ressources, et joindre tous les autres Pods du cluster. Les leçons 4, 7 et 8 posent les premières protections.
• Un manifeste est du code. Il se relit, se versionne et s'analyse (Trivy sait analyser les manifestes, comme il analyse les configurations Terraform dans le cours Terraform).
• Les versions en fin de vie ne reçoivent plus de correctifs de sécurité : suivez le calendrier.

En production

• Managé d'abord. Sauf contrainte forte, un Kubernetes managé (Kapsule chez Scaleway) évite d'exploiter etcd et le plan de contrôle, qui sont la partie la plus délicate.
• Peu de clusters, bien tenus. Un cluster par environnement (préproduction, production) est un bon point de départ ; multiplier les clusters multiplie les montées de version.
• Tout passe par des manifestes versionnés, appliqués par un pipeline ou par un outil GitOps. Les modifications à la main sont une dérive, au même titre que dans le cours Terraform.
• Les montées de version sont un processus. Lire les notes de version (les API supprimées en particulier), tester en préproduction, monter le plan de contrôle puis les nœuds, une version mineure à la fois.

Exercices

1. Faut-il Kubernetes ? (niveau 100). Pour chacune des situations, dites si Kubernetes est justifié, et sinon ce que vous proposeriez : (a) une association qui héberge un site WordPress et une base MySQL ; (b) une équipe de douze développeurs, huit services, une dizaine de déploiements par jour ; (c) un traitement de fichiers qui tourne une heure chaque nuit ; (d) Signalements tel qu'il est aujourd'hui, avec deux instances et une base managée.

2. Réconciliation (niveau 100). Un Deployment déclare trois exemplaires de Signalements. Décrivez ce qui se passe, du point de vue des contrôleurs, dans chacun des cas : (a) un conteneur plante ; (b) la machine qui portait deux des trois Pods s'éteint ; (c) quelqu'un supprime un Pod à la main ; (d) quelqu'un modifie le manifeste pour demander cinq exemplaires.

3. Le cycle de support (niveau 100). Votre cluster est en 1.35 au 5 octobre 2026. Combien de temps vous reste-t-il avant la fin de vie de cette version, et quelle montée de version planifiez-vous ?

4. Lire un manifeste (niveau 100). Générez avec --dry-run=client -o yaml le manifeste d'un Deployment vignettes de trois exemplaires de l'image ghcr.io/lyneko-formation/vignettes:0.4.0. Quelle étiquette relie le Deployment à ses Pods ? Que se passerait-il si l'on modifiait à la main l'étiquette du modèle de Pod sans toucher au sélecteur ?

Récapitulatif

• Un orchestrateur gère le placement, la guérison, les mises à jour progressives, la découverte de services, la mise à l'échelle et la configuration d'applications conteneurisées sur un parc de machines.
• Kubernetes repose sur l'état voulu déclaré dans des objets et sur des contrôleurs qui réconcilient en permanence l'état observé avec lui. Une panne n'est qu'un écart de plus.
• Les contrôleurs réagissent à des niveaux, pas à des événements : ils rattrapent ce qu'ils ont manqué.
• Né en 2014 de l'expérience de Borg, version 1.0 en juillet 2015, premier projet diplômé de la CNCF en 2018.
• Kubernetes n'est pas un PaaS : pas de build, pas de CI, pas de base de données, pas de supervision intégrée, pas de gestion des machines.
• Il a un coût qui ne se justifie qu'avec plusieurs services, plusieurs équipes ou des déploiements fréquents.
• Managé (Kapsule, EKS, AKS, GKE) d'abord ; auto-géré sous contrainte ; distributions (k3s, k0s, RKE2, OpenShift) selon le contexte ; la CNCF certifie la conformité.
• Trois versions mineures par an, les trois dernières maintenues environ un an : un cluster monte de version au moins une fois par an. kubectl reste à une version mineure du cluster.

Pour aller plus loin

• La page Overview de la documentation officielle, et en particulier sa section sur ce que Kubernetes n'est pas.
• L'article Borg, Omega, and Kubernetes (ACM Queue, 2016), pour comprendre les choix de conception à la lumière de dix ans d'expérience chez Google.
• L'article Large-scale cluster management at Google with Borg (EuroSys 2015), pour les ordres de grandeur.
• La leçon suivante, qui ouvre le capot : les composants d'un cluster et le chemin d'une commande jusqu'au conteneur.