Kubernetes v1.34 améliore les fonctions réseaux

Les mises à jour de la dernière version de Kubernetes 1.34 lancée récemment devraient contribuer à améliorer les opérations natives du cloud. Elles concentrent plusieurs mises à niveau sur la partie réseau pour répondre aux difficultés opérationnelles rencontrées dans les déploiements à grande échelle. Comme le veut la tradition, cette version est associée à un thème. Cette fois, il s’appelle « Of Wind & Will » (O' WaW). « Ce qui fait avancer Kubernetes, ce ne sont pas des vents parfaits, mais la volonté de nos marins qui ajustent les voiles, manœuvrent la barre, tracent les routes et maintiennent le navire à flot », indique un communiqué.

La plateforme open source d'orchestration de clusters de conteneurs est utilisée par tous les principaux fournisseurs de cloud, Microsoft, Google et Amazon, lesquels proposent chacun leurs propres services. Il existe également plusieurs distributions pour les déploiements sur site et dans le cloud privé, notamment celles proposées par Red Hat, Suse, Canonical et VMware. Toutes les offres sont construites sur le projet open source fondamental, lequel propose trois versions par an, chacune introduisant des fonctionnalités. Les versions de Kubernetes comprennent trois catégories de mises à jour dites « d’améliorations, à savoir stable, alpha et bêta, chaque niveau indiquant le degré de maturité et de préparation à la production de la fonctionnalité spécifique. Kubernetes 1.34 compte au total 58 améliorations, dont 23 stables, 22 bêta et 13 alpha. Chaque amélioration d'une version est suivie via le processus Kubernetes Enhancement Proposal (KEP), qui définit le problème qu'une fonctionnalité donnée est censée résoudre.

Le trafic amélioré grâce à un routage localisé

Depuis la création de la plateforme il y a dix ans, le routage non optimisé du trafic est l'un des problèmes de performances réseau les plus persistants. Kubernetes se compose de nœuds et de clusters, et quand le trafic réseau intra-cluster est-ouest est important, il peut y avoir un impact sur la latence et les performances. C'est l'un des principaux défis que la KEP #3015 tente de résoudre. Intitulée « PreferSameZone and PreferSameNode Traffic Distribution », cette amélioration offre aux administrateurs réseau un contrôle précis sur les décisions de routage du trafic au sein des clusters. Selon la proposition, l'objectif est de rendre la distribution du trafic moins ambiguë. La méthode utilisée pour y parvenir est assez simple. « Il suffit d’ajouter une nouvelle valeur pour permettre la configuration d'un service et faire en sorte que les connexions soient acheminées vers un point de terminaison local quand c’est possible, et vers un point de terminaison distant dans le cas contraire », explique la KEP. D'un point de vue technique, cet objectif se traduit par la fonctionnalité de distribution du trafic PreferSameNode. Le champ spec.trafficDistribution dans un service Kubernetes donne aux utilisateurs la capacité d'exprimer leurs préférences quant à la manière dont le trafic doit être acheminé vers les points de terminaison du service.

La KEP #3015 déprécie PreferClose et introduit deux valeurs supplémentaires : PreferSameZone et PreferSameNode. PreferSameZone est un alias de l'existant PreferClose afin de clarifier sa sémantique. PreferSameNode propose aux connexions d'être acheminées vers un point de terminaison local lorsque cela est possible, en se rabattant sur un point de terminaison distant lorsque cela n'est pas possible. Cette fonctionnalité répond à un besoin critique d'optimisation des performances dans les systèmes distribués. En permettant au trafic de rester sur le même nœud lorsque cela est possible, les administrateurs peuvent réduire la latence du réseau et la consommation de bande passante tout en maintenant la disponibilité du service grâce à des mécanismes de repli automatisé. La mise en œuvre technique fonctionne via kube-proxy, qui comprend désormais ces préférences de distribution du trafic et prend les décisions de routage en conséquence. Lorsqu'un service spécifie PreferSameNode, le proxy essaye d'abord d'acheminer le trafic vers les points de terminaison fonctionnant sur le nœud local avant d'envisager des alternatives à distance.

Plus de flexibilité pour les DNS

Les administrateurs réseau opérant dans des environnements d'entreprise complexes sont souvent confrontés à des défis de résolution DNS, en particulier lorsqu'ils intègrent des clusters Kubernetes à l'infrastructure DNS existante de l'entreprise. La version1.34 résout ce problème grâce à la KEP #4427, qui assouplit la validation du chemin de recherche DNS. « Auparavant, la validation stricte du chemin de recherche DNS d'un pod dans Kubernetes créait souvent des difficultés d'intégration dans les environnements réseau complexes ou hérités », explique le communiqué. « Cette restriction pouvait bloquer des configurations nécessaires à l'infrastructure d'une entreprise, obligeant les administrateurs à mettre en œuvre des solutions de contournement difficiles. »

La solution technique offre aux administrateurs réseau un contrôle amélioré de la configuration DNS grâce à une modification spécifique du comportement du résolveur. Ce changement de configuration empêche le système DNS de Kubernetes de transférer inutilement les requêtes de domaine externes vers l'infrastructure DNS interne du cluster. Il en résulte une réduction de la charge de requêtes sur les services DNS internes et la fin des conflits de résolution potentiels qui peuvent survenir en cas de chevauchement des espaces de noms de domaine internes et externes.

Une automatisation de la sécurité réseau

La KEP #4601 se focalise sur la sécurité réseau qui améliore les capacités d'autorisation. Le système peut désormais prendre en compte les sélecteurs de réseau lors des décisions de contrôle d'accès. Cette avancée répond aux besoins de sécurité croissants dans les environnements multi-tenant. Les mécanismes d'authentification de Kubernetes sont des composants du serveur API Kubernetes qui déterminent si un utilisateur ou une entité est autorisé à exécuter une action particulière sur une ressource spécifique. Grâce à cette fonctionnalité, ces mécanismes peuvent à présent prendre des décisions d'autorisation en fonction des sélecteurs de champ et d'étiquette dans les requêtes entrantes.

Les implications pratiques sont considérables pour les architectures de sécurité réseau. Les entreprises peuvent dorénavant créer des politiques qui restreignent l'accès en fonction de la topologie du réseau. « Par exemple, il est possible de rédiger une politique d'autorisation qui accepte uniquement la liste des pods liés à un .spec.nodeName spécifique », indiquent les notes de mise à jour. « Le client (le kubelet sur un nœud particulier, par exemple) doit spécifier le sélecteur de champ requis par la politique, sinon la requête est interdite. » Cette amélioration donne des contrôles d'accès réseau plus sophistiqués. Elle est particulièrement utile dans les scénarios d'isolation par nœud. Les configurations multi-tenants personnalisées en bénéficient également lorsque la topologie du réseau joue un rôle essentiel dans les limites de sécurité.

Une extension des ressources gérées

Au-delà des améliorations spécifiques au réseau, cette version démontre la maturation continue de la plateforme dans son ensemble. L'une des principales évolutions concerne la mise en place d'une fonctionnalité d’allocation dynamique des ressources (DRA). « À l'origine, Kubernetes et son planificateur ne suivaient que le CPU et la RAM comme ressources pour les conteneurs », indique la KEP #4381. « Plus tard, la prise en charge du stockage et des GPU a été ajoutée. Mais pour de nombreux terminaux plus récents, cette approche et l'API Kubernetes pour demander ces ressources personnalisées sont trop limitées. » La DRA promet une gestion plus sophistiquée des périphériques pour des matériels réseaux comme les NIC, ainsi que des capacités de streaming améliorées pour les opérations API à grande échelle qui réduisent la pression sur la mémoire lors de charges de travail réseau intensives. « L'allocation dynamique des ressources (DRA) offre des moyens plus puissants de sélectionner, d'allouer, de partager et de configurer les GPU, les TPU, les NIC et d'autres périphériques », ajoute le communiqué.