Kubernetes 1.35 arrive près de quatre mois après la mise à jour 1.34, qui intégrait une multitude d'améliorations pour la mise en réseau. La plateforme open source s'est imposée comme la technologie par défaut pour les conteneurs et elle est prise en charge par toutes les grandes plateformes cloud. Kubernetes alimente tout, depuis les applications web traditionnelles jusqu’aux clusters de formation IA distribués. À mesure que son adoption se généralise, la solution est soumise à une pression pour éliminer la dette technique tout en améliorant les capacités exigées par les entreprises. Kubernetes 1.35 répond à ces deux impératifs. D'abord la fonction d'ajustement des ressources de pods sur place, initiée depuis la v 1.27, est désormais disponible pour tous les administrateurs ce qui signifie qu'ils peuvent modifier les allocations de CPU et de mémoire sans temps d'arrêt. Dans la foulée, le projet abandonne le mode proxy IP Virtual Server, faisant évoluer la mise en réseau vers une architecture plus moderne. Cette version renforce également l'automatisation du cycle de vie des certificats et améliore les contrôles des politiques de sécurité.

Comme pour chaque dernière version, la communauté Kubernetes trouve un nom de code intéressant qui symbolise à la fois la version spécifique et ses principes. Pour la 1.35, elle a choisi Treenetes comme nom de code, en référence à la mythologie de l'Arbre du Monde. Ce symbolisme reflète à la fois la maturité du projet et la diversité de ses contributeurs. « Le projet ne cesse de se développer et le produit s'enracine pour devenir une base très mature pour les projets IA et edge computing à venir », a déclaré Drew Hagen, responsable de la version 1.35 de Kubernetes.

Des ajustements de ressources pods bons pour la production

La principale fonctionnalité de Kubernetes 1.35 est donc la disponibilité générale de la fonction des ajustements des ressources des pods. Suivie dans le projet sous le nom de Kubernetes Enhancement Proposal (KEP) 1287, elle a été proposée pour la première fois en 2019. Elle change fondamentalement la façon dont les administrateurs gèrent les ressources des conteneurs dans les clusters de production. « Cette fonctionnalité permet de mettre à jour les ressources, les demandes de ressources et les limites d'un pod, ce qui est vraiment très performant, car il n’est plus nécessaire de redémarrer un pod pour augmenter les ressources qui lui sont allouées », a expliqué M. Hagen. Auparavant, la modification des demandes ou des limites de ressources nécessitait la suppression du pod et la création d'un nouveau pod avec des spécifications mises à jour. Les applications étaient mises hors ligne pendant la transition. Les connexions réseau étaient interrompues. Le processus nécessitait des fenêtres de maintenance pour les tâches opérationnelles de routine. Cette implémentation modifie les paramètres cgroup (groupe de contrôle/control group) directement sur les conteneurs en cours d'exécution. Lorsque les spécifications des ressources changent, Kubernetes met à jour le cgroup existant plutôt que de recréer le pod. Les applications continuent de fonctionner sans interruption.

Cette fonction est particulièrement utile pour les charges de travail de formation de l’IA et les déploiements edge. Les tâches de formation peuvent désormais être adaptées verticalement sans redémarrage. Les environnements edge gagnent en flexibilité en termes de ressources sans la complexité liée à la recréation de pods. « Pour l'IA, il s'agit d'une tâche de formation très importante qui peut être adaptée et ajustée verticalement. Pour l’edge computing, c'est très important car cela ajoute de la complexité et nécessite d'ajuster ces charges de travail », a souligné M. Hagen. La fonctionnalité nécessite cgroups v2 sur les nœuds Linux sous-jacents. Kubernetes 1.35 abandonne le support de cgroups v1. La plupart des distributions Linux d'entreprise actuelles incluent cgroups v2, mais les déploiements plus anciens peuvent nécessiter des mises à niveau du système d'exploitation avant de pouvoir utiliser les ajustements de ressources sur place.

Planification groupée pour les workloads IA distribuées

Parmi les fonctions présentées en bêta dans cette dernière version figure une fonctionnalité appelée gang scheduling (planification groupée), référencée sous le nom KEP-4671. Elle est destinée à aider les applications distribuées qui nécessitent le démarrage simultané de plusieurs pods. « Cette fonctionnalité ajoute une charge de travail qui peut être déployée via le cluster et qui regroupe plusieurs pods. Soit les pods démarrent tous ensemble, soit aucun pod ne démarre, ce qui permet en quelque sorte de mieux regrouper certaines dépendances des applications distribuées qui ont été exécutées ensemble », a précisé M. Hagen. La mise en œuvre ajoute un objet de charge de travail déployé via le cluster. Les pods du groupe démarrent tous ensemble ou aucun ne démarre. Cela simplifie la mise en ligne des dépendances des applications distribuées dans le bon ordre. M. Hagen fait remarquer que les charges de travail IA, où les entreprises ont plusieurs instances qui fonctionnent ensemble et des données d'entraînement, constituent un très bon cas d’usage de la planification groupée. La version 1.35 comprend également un aperçu d'une fonctionnalité déclarée par les nœuds (KEP-5328), qui permet aux nœuds d'annoncer leurs capacités. Les pods ne seront pas planifiés sur les nœuds qui ne disposent pas des fonctionnalités requises, ce qui évite les échecs d'exécution dus à des incompatibilités de capacités.

Des améliorations de sécurité

Kubernetes 1.35 améliore aussi des fonctions de sécurité visant à empêcher la compromission des clusters et à permettre des architectures zero trust. L'usurpation d'identité par abus de délégation ou constrained impersonation (KEP-5284) entre en phase alpha dans cette version. Cette fonctionnalité empêche les machines malveillantes d'usurper l'identité de nœuds légitimes afin d'extraire des informations sensibles des applications et des pods en cours d'exécution. « La fonctionnalité empêche une machine d'entrer dans le cluster, d'usurper l'identité d'un nœud et d'extraire des informations sensibles des applications et des pods en cours d'exécution », a indiqué M. Hagen. Les certificats de pod pour l’authentification TLS mutuelle (KEP-4317) qui permettent l'authentification TLS mutuelle entre les pods, atteignent le statut bêta. Cette fonctionnalité prend en charge les modèles de réseau zero-trust où la communication entre pods nécessite une vérification cryptographique. Cette version comprend également des améliorations de la source de volume d'image OCI (open container initiative) (KEP-4639) pour l’edge computing et le stockage en périphérie. Cette fonctionnalité permet d'attacher des volumes de données en lecture seule en tant qu'artefacts OCI, ce qui simplifie la distribution des données dans les déploiements edge.

Le mode proxy IPVS déprécié

Cette version de Kubernetes ne se limite pas à l'ajout de fonctionnalités, elle en supprime également d'anciennes. Par exemple elle déprécie le mode proxy IP Virtual Server (IPVS) pour l'équilibrage de charge des services. Cette décision oblige les équipes réseau à migrer vers des implémentations basées sur nftables. L’IPVS est une option réseau essentielle depuis Kubernetes 1.8. Ce mode exploite le répartiteur de charge IPVS du noyau Linux pour distribuer le trafic de service. De nombreux déploiements en production ont adopté l’IPVS, car il surpassait le kube-proxy original basé sur le mode iptables, en particulier dans les clusters comportant des milliers de services. Nftables représente le framework moderne de filtrage de paquets Linux. Il a remplacé iptables dans la pile réseau du noyau et offre de meilleures performances avec une gestion des règles plus flexible. Le framework consolide le filtrage des paquets, le NAT et l'équilibrage de charge dans une interface unifiée. Les administrateurs réseau doivent tester la compatibilité du mode nftables avec les implémentations existantes du maillage de services et les politiques réseau. Le calendrier de dépréciation s'étend sur plusieurs versions, ce qui laisse aux équipes le temps de planifier les migrations. « Il semble que Kubernetes soit un projet très mature, et nous arrivons à un point où nous n'avons plus peur de nous débarrasser de la dette technique pour pouvoir aller de l'avant avec certaines de ces fonctionnalités importantes », a fait valoir M. Hagen.