Kubernetes 1.26 : changement de registre pour l’orchestrateur

L’heure de la maturité pour CPUManager et DeviceManager ? Ces deux fonctionnalités natives du kubelet font partie des onze éléments officiellement stabilisés avec Kubernetes 1.26.

La prise en charge des conteneurs Windows à privilèges l’est aussi. Cela leur permet de fonctionner avec les mêmes droits que les processus qui s’exécutent directement sur l’hôte.

Le projet avance aussi sur la partie infrastructure, avec la disponibilité générale de son nouveau registre (registry.k8s.io). L’ancien (k8s.gcr.io) n’est pas encore décommissionné, mais les images officielles n’y sont plus publiées.

L’infra initiale se fondait sur un domaine Google Container Registry. Avec le nouveau registre, elle s’étend, en s’appuyant sur plusieurs fournisseurs. Amazon est le premier à rejoindre la boucle. Promesse : sur le principe du CDN, améliorer les performances et réduire les coûts de transfert.

Le point de terminaison du nouveau registre redirige les clients vers le serveur le plus proche. Le back-end étant amené à évoluer en continu, les éventuelles stratégies de contrôle réseau – en tête desquelles les listes blanches d’adresses IP – peuvent entraîner des problèmes. Dans cette situation, on téléchargera les images dans un registre privé.

Outre CPUManager et DeviceManager, Kubernetes 1.26 stabilise la migration CSI pour vSphere et pour Azure Files.
Cette fonctionnalité permet d’exploiter des pilotes de stockage externes par l’intermédiaire de ladite CSI (Container Storage Interface, sur RPC) plutôt que le plug-in interne, inclus dans le code de l’orchestrateur.
En s’appuyant sur la CSI, le projet Kubernetes n’aura plus, à terme, qu’à maintenir une seule version de chaque plug-in interne. Ce qui allègera le code comme les tâches de maintenance.

Toujours côté stockage, est stabilisée la fonction de délégation FSGroup pour les pilotes CSI. Elle permet à ces derniers d’utiliser les options de montage pour contrôler les permissions des volumes.

Kubernetes plus souple sur le multiprotocole

Parmi les autres éléments ayant atteint le stade stable, on notera :

– Contrôle des tâches sans persistance des pods
Jusqu’à présent, le contrôleur exigeait, pour suivre le statut d’une tâche, de ne pas supprimer les pods arrivés à la fin de leur cycle de vie.

– Prise en charge du multiprotocole pour l’équilibrage de charge
À l’aide d’un feature flag, le projet Kubernetes desserre un peu l’étau sur le paramétrage du multiprotocole au sein des services de type load balancer. Étau au sens où historiquement, l’orchestrateur n’autorise pas l’intégration de plusieurs protocoles dans une même définition de service. Essentiellement pour des raisons de coûts, certains fournisseurs de services d’équilibrage de charge ayant une facturation par protocole.

– Extension de la récupération dynamique des credentials pour les registres
Kubernetes implémente désormais un plug-in extensible censé permettre cette récupération chez tout CSP. Il conserve, pour le moment, les trois implémentations réalisées au sein du kubelet pour les registres d’AWS, Azure et Google Cloud (mais elles disparaîtront à terme).

Illustration © projet Kubernetes