Cluster API : des clusters Kubernetes déclaratifs

Déployer dans un cluster Kubernetes, tout le monde sait faire aujourd'hui : manifestes, Helm, GitOps avec FluxCD. Ce qui reste largement artisanal, c'est le cycle de vie du cluster lui-même. Comment on le crée, comment on ajoute des noeuds, comment on le met à niveau sans casser la production, comment on le détruit proprement en fin de vie. Cluster API (CAPI) répond à cette couche-là, pas à celle des applications qui tournent dedans.

Cluster API introduit un cluster Kubernetes dédié, appelé cluster de gestion (management cluster), dont le seul travail est de décrire et de faire converger l'état d'autres clusters, les clusters gérés (workload clusters). C'est la même logique que l'API Kubernetes appliquée récursivement : au lieu de décrire des Pods et des Deployments, on décrit des objets Cluster, Machine, MachineDeployment, MachineSet, et des contrôleurs font converger l'état réel vers l'état déclaré.

Concrètement, un MachineDeployment fonctionne comme un Deployment classique, mais chaque replica est une machine complète, VM ou serveur physique, avec son système d'exploitation et son kubelet, plutôt qu'un pod. La Machine est l'unité atomique : elle référence un template d'infrastructure (quelle VM, sur quel provider, avec quelles specs) et un template de bootstrap (comment initialiser Kubernetes dessus, généralement via kubeadm).

Ce cluster de gestion n'est pas un logiciel à part : c'est un cluster Kubernetes standard, avec les CRD et les contrôleurs de Cluster API installés dessus. On peut d'ailleurs faire pivoter la gestion d'un cluster de gestion temporaire (souvent un cluster local avec kind) vers un cluster de gestion définitif une fois que ce dernier existe, une opération appelée pivoting dans la documentation officielle.

Cluster API elle-même ne sait pas créer une VM chez un hébergeur ni provisionner un serveur bare metal. Ce travail est délégué à des providers d'infrastructure (Infrastructure Providers), des contrôleurs séparés qui implémentent un contrat d'interfaces standardisé : InfraCluster et InfraMachine.

L'écosystème couvre la plupart des cibles courantes : CAPV pour vSphere, CAPZ pour Azure, CAPA pour AWS, CAPO pour OpenStack, Cluster API Provider Docker pour les tests locaux, et plusieurs providers bare metal comme Metal3. Chaque provider traduit les objets abstraits Machine en appels API concrets vers son infrastructure : créer une VM, l'attacher à un réseau, la démarrer.

C'est là que le modèle prend tout son sens sur un environnement hétérogène ou multi-cloud : le même objet MachineDeployment décrit la même intention, quel que soit le provider en dessous. C'est aussi là que le coût d'entrée se voit : chaque provider a sa propre maturité, sa propre cadence de release, et son propre lot de bugs spécifiques à l'infrastructure cible. Un provider bare metal expose davantage de complexité opérationnelle qu'un provider cloud, parce qu'il doit gérer l'inventaire physique, pas seulement des appels API.

Le point le plus contre-intuitif pour qui vient de l'administration système classique : Cluster API ne met jamais à jour un noeud en place. Du point de vue du modèle, une Machine est immuable. Une fois créée, elle n'est jamais modifiée, sauf ses labels, ses annotations et son statut. Toute évolution de configuration, changement de version de Kubernetes, changement d'image système, changement de taille de VM, se traduit par la création d'une nouvelle machine et la suppression de l'ancienne.

Ce mécanisme s'appuie sur le même contrôleur de rolling update que celui utilisé pour un upgrade Kubernetes classique au niveau des workloads, mais appliqué à la couche des noeuds. Modifier le template d'infrastructure ou de bootstrap référencé par un MachineDeployment déclenche automatiquement une bascule progressive : de nouvelles machines sont créées avec la nouvelle configuration, l'ancien pool est drainé noeud par noeud, dans les limites de maxUnavailable et maxSurge, jusqu'à remplacement complet.

Sur le plan opérationnel, c'est un vrai changement de discipline. On ne se connecte plus en SSH sur un noeud pour corriger une dérive de configuration : on corrige le template, et le contrôleur reconstruit le noeud proprement. Ça élimine par construction la dérive de configuration qui s'accumule sur des noeuds mis à jour en place pendant des années, la même logique que porte Talos Linux à l'échelle du système d'exploitation entier, où même l'OS refuse la modification en place.

Ce confort a un prix, et il n'est pas négligeable. D'abord, le cluster de gestion lui-même est une pièce de production à opérer : sa disponibilité conditionne la capacité à réagir à un incident sur les clusters gérés (même si les clusters gérés continuent de fonctionner de façon autonome si le cluster de gestion tombe, seule la réconciliation s'arrête). Ensuite, chaque provider apporte sa propre courbe d'apprentissage, ses propres CRD, ses propres modes de panne. Enfin, le remplacement systématique des noeuds à chaque changement suppose une infrastructure sous-jacente capable d'absorber le churn : provisioning rapide, réseau qui s'attache proprement à une nouvelle VM, stockage qui suit le noeud plutôt que d'y être lié.

Sur un parc de trois à cinq clusters avec un rythme de changement faible, monter un cluster de gestion Cluster API dédié, choisir et maîtriser un provider d'infrastructure, et former l'équipe au modèle de remplacement de noeuds représente un investissement disproportionné par rapport au problème réel. Un déploiement k3s piloté par des playbooks Ansible répond à la même question, provisionner et maintenir des noeuds Kubernetes, avec un outillage que l'équipe maîtrise déjà, sans introduire une nouvelle API à apprendre ni un cluster de gestion supplémentaire à sécuriser et sauvegarder.

Le seuil se déplace avec deux facteurs, pas un seul. Le premier est le nombre de clusters : en dessous d'une dizaine de clusters gérés, le coût fixe de mise en place de Cluster API dépasse rarement le gain. Le second est la fréquence de changement d'infrastructure : sur un parc stable, provisionné une fois et peu modifié, le remplacement automatisé des noeuds n'apporte pas grand-chose de plus qu'un playbook Ansible bien écrit et testé.

Cluster API commence à se justifier nettement au-delà d'une dizaine de clusters gérés, en particulier quand plusieurs équipes provisionnent des clusters de façon autonome à partir d'un même catalogue de templates, ou quand l'infrastructure cible change souvent (montée en charge fréquente, création et destruction de clusters éphémères pour du CI, multi-provider assumé). En dessous, la simplicité d'un k3s scripté gagne sur tous les critères qui comptent en exploitation réelle : temps de formation, surface d'attaque, nombre de composants à sauvegarder et à superviser.

Cluster API n'est pas un remplaçant de vos outils de provisioning actuels sur un petit parc, c'est une couche d'orchestration pour qui gère des clusters à l'échelle d'une flotte. La question à se poser avant d'adopter le modèle n'est pas « est-ce que c'est plus moderne », c'est « est-ce que je gère assez de clusters, avec assez de changement, pour amortir un cluster de gestion supplémentaire ». Sur moins de dix clusters stables, la réponse honnête est non.

Dimensionner l'outillage de gestion de cluster sur le nombre réel de clusters à opérer, pas sur la tendance du moment, c'est un arbitrage qu'on tranche avant chaque déploiement Kubernetes qu'on opère. Si votre parc de clusters grandit au point où chaque mise à niveau devient un projet en soi, on peut évaluer avec vous si Cluster API ou un outillage plus léger correspond à votre échelle réelle.

• Introduction - The Cluster API Book : documentation officielle du projet, concepts de cluster de gestion et de clusters gérés.
• Concepts - The Cluster API Book : détail des objets Cluster, Machine, MachineDeployment et du modèle d'immuabilité des noeuds.
• Upgrading management and workload clusters - The Cluster API Book : mécanique de mise à niveau par remplacement de noeuds et paramètres de rolling update.
• InfraMachine - The Cluster API Book : contrat d'interface implémenté par les providers d'infrastructure.