Kubernetes orchestre des conteneurs, mais sa mécanique repose sur deux abstractions fondamentales : le cluster et le nœud. Comprendre leur articulation permet de saisir comment une application conteneurisée passe d’un fichier de configuration à un processus actif sur une machine physique ou virtuelle. Le sujet paraît balisé, mais les évolutions récentes du projet (suppression de cgroup v1, fin de maintenance d’Ingress-NGINX, arrivée de Gateway API) redessinent ce que signifie concrètement administrer un cluster et préparer un nœud.
Nœud Kubernetes : ce que le noyau et le runtime imposent au cluster
Un nœud est une machine (physique ou virtuelle) enregistrée dans le cluster. Il exécute les conteneurs via un runtime compatible et communique avec le plan de contrôle grâce au composant kubelet. Jusque-là, la définition est connue.
Lire également : Qu'est-ce qu'un VLAN pour les nuls ?
Ce qui l’est moins, c’est l’impact direct de la couche système sur l’appartenance au cluster. Kubernetes 1.35 a supprimé le support de cgroup v1, imposant cgroup v2 comme base attendue pour tout nœud moderne. Un serveur dont le noyau Linux ne supporte pas cgroup v2 ne peut plus rejoindre un cluster à jour sans intervention sur sa configuration système.
La compatibilité du runtime de conteneurs entre aussi en jeu. Les versions 1.x de containerd posent désormais des contraintes de transition lors des mises à niveau. Un nœud ne se résume pas à une machine capable d’exécuter des conteneurs : son noyau, son runtime et son système de contrôle des ressources conditionnent sa compatibilité avec le cluster.
A découvrir également : Qu'est-il préférable d'apprendre, Kubernetes ou Docker ?
Ce durcissement des prérequis signifie qu’ajouter un nœud à un cluster récent demande une vérification préalable de la pile système, pas seulement l’installation d’un agent.
Plan de contrôle et nœuds de travail : la séparation qui structure un cluster Kubernetes
Un cluster Kubernetes se compose au minimum d’un plan de contrôle et d’un ou plusieurs nœuds de travail. Le plan de contrôle maintient l’état souhaité du cluster : il décide où placer les pods, surveille la santé des nœuds et expose l’API avec laquelle les administrateurs interagissent (via kubectl, par exemple).
Les nœuds de travail, eux, exécutent les charges applicatives. Chaque nœud de travail héberge :
- Un kubelet, agent qui reçoit les instructions du plan de contrôle et s’assure que les conteneurs demandés tournent dans leurs pods respectifs.
- Un kube-proxy, composant réseau qui gère les règles de routage pour que les services du cluster soient accessibles entre nœuds.
- Un runtime de conteneurs (containerd, CRI-O), responsable du cycle de vie effectif des conteneurs sur la machine.
Cette séparation n’est pas qu’organisationnelle. En production, le plan de contrôle est généralement répliqué sur plusieurs machines pour garantir la disponibilité. Si un nœud de travail tombe, le plan de contrôle replanifie les pods sur les nœuds restants. Si le plan de contrôle lui-même est indisponible, les conteneurs en cours continuent de tourner, mais aucune opération de gestion (déploiement, mise à l’échelle) n’est possible.
Réseau du cluster Kubernetes : d’Ingress-NGINX à Gateway API
Les explications classiques du cluster mentionnent les services et l’objet Ingress pour exposer des applications sur le réseau. Cette couche est en train de changer de manière significative.
Le contrôleur Ingress-NGINX, longtemps le choix par défaut pour exposer un cluster sur Internet, est en fin de maintenance. Les raisons documentées pointent vers un manque de mainteneurs et une dette technique accumulée autour de nombreuses annotations spécifiques. L’API Ingress elle-même reste supportée dans Kubernetes, mais n’évolue plus activement.
La migration recommandée s’oriente vers Gateway API, qui introduit une séparation des responsabilités absente du modèle Ingress. Là où un objet Ingress concentrait l’exposition et le routage, Gateway API distingue plusieurs ressources :
- GatewayClass : définit le type de contrôleur réseau disponible dans le cluster, géré par l’équipe plateforme.
- Gateway : représente le point d’entrée réseau lui-même (adresse, ports, protocoles).
- HTTPRoute : décrit les règles de routage applicatif, configuré par les équipes de développement.
Cette architecture permet de séparer clairement ce que l’équipe infrastructure contrôle (la gateway, la classe) de ce que les équipes applicatives configurent (les routes). Pour un cluster en production, le choix du contrôleur réseau est devenu un enjeu de maintenabilité, pas seulement de connectivité.
Pods et ressources : ce que le cluster gère réellement à l’intérieur des nœuds
Le pod est la plus petite unité déployable dans Kubernetes. Il encapsule un ou plusieurs conteneurs partageant le même espace réseau et les mêmes volumes de stockage. Un pod tourne toujours sur un seul nœud ; il ne peut pas être réparti entre plusieurs machines.
Le cluster utilise un ordonnanceur (scheduler) pour attribuer chaque pod à un nœud disposant des ressources nécessaires (CPU, mémoire, affinités, tolérances). Si un nœud manque de ressources, le pod reste en attente jusqu’à ce qu’un nœud compatible soit disponible.
Les espaces de noms (namespaces) apportent une isolation logique à l’intérieur du cluster. Ils permettent de segmenter les ressources par équipe, par environnement ou par application, sans multiplier les clusters physiques. En revanche, les namespaces n’offrent pas d’isolation réseau par défaut : des politiques réseau (NetworkPolicy) doivent être configurées explicitement pour restreindre les communications entre pods de namespaces différents.
Gérer plusieurs clusters Kubernetes : les limites pratiques
Beaucoup d’organisations ne gèrent pas un seul cluster mais plusieurs, répartis entre cloud, infrastructure locale et parfois périphérie du réseau. La gestion multi-cluster pose des questions concrètes de cohérence : comment appliquer les mêmes politiques de sécurité, les mêmes versions de composants, les mêmes configurations réseau sur des clusters hétérogènes.
Les retours terrain divergent sur la bonne granularité. Certaines équipes préfèrent un cluster par environnement (développement, staging, production), d’autres isolent par domaine métier. Aucun modèle universel ne s’est imposé, et le choix dépend du niveau de maturité opérationnelle et des contraintes réglementaires propres à chaque organisation.
L’évolution rapide des prérequis systèmes (cgroup v2, migration Gateway API, versions de runtime) rend les mises à niveau de clusters plus exigeantes qu’il y a quelques années. Un cluster laissé sans montée de version pendant plusieurs cycles peut devenir difficile à rattraper, car les chemins de migration s’accumulent. Anticiper ces transitions fait désormais partie de la gestion courante d’un cluster Kubernetes, au même titre que le dimensionnement des nœuds ou la supervision des pods.
