Kubernetes v1.30 aka "Uwubernetes" est maintenant arrivé avec une salve de fonctions inédites ou améliorées. Cette version de l'orchestrateur de clusters de containers, dont le développement est piloté par la CNCF, a bénéficié des contributions de 863 entreprises et de 1 391 personnes. En tout, 45 améliorations ont été annoncées dont 17 désormais stables, 18 maintenant en beta et 10 sorties de l'oeuf (alpha). Pour ses 10 ans (le premier dépôt de code K8s remonte au 6 juin 2014), K8s a notamment monté d'un cran sa sécurité ce qui n'est pas un luxe tant cette solution fait l'objet de failles.

Les permissions et les contrôles d'accès sont ainsi revus à la hausse, conteneurs et pods étant maintenant sécurisables via le module Linux AppArmor pour appliquer des règles de sécurité lorsqu'ils sont en cours d'exécution. Les pods peuvent aussi être désignés avec des noms d'utilisateurs grâce à Kubernetes Enhancement Proposals (KEP) 127 (support user namespaces) pour isoler un peu mieux les UID (universally unique identifiers) et les GID (group unique identifiers). Les fonctionnalités Alpha de cette v1.30 comprennent également l'intégration du langage d'expression commun (CEL) pour le contrôle d'admission, qui ouvre la voie à des contrôles de politiques et des mécanismes de validation plus sophistiqués des clusters de containers. Ce n'est pas tout : les améliorations apportées aux jetons de compte de service améliorent également la sécurité et la gestion des comptes de service. L'introduction de montages de volumes de clusters de containers en lecture seule récursive (RRO) apporte de son côté une couche de sécurité supplémentaire. "Cette fonctionnalité vous permet de définir des volumes et leurs sous-montages en lecture seule, empêchant ainsi toute modification accidentelle, indique le billet de blog annonçant la dernière version de Kubernetes. "Les montages RRO garantissent que vos données restent intactes, renforçant ainsi la sécurité de votre cluster avec une protection supplémentaire. Cet aspect est particulièrement important dans les environnements étroitement contrôlés, où la moindre modification peut avoir des conséquences considérables."

Le changement récursif des étiquettes SELinux accéléré

D'autres fonctions (alpha) sont aussi de la partie pour muscler les performances. A commencer par l'accélération du changement récursif des étiquettes SELinux (fast recursive SELinux label change), le montage en lecture seule récursive (recursive read-only mounts), la politique de réussite et d'achèvement de job (job success/completion policy), ainsi que la répartition du trafic pour les services, et la migration de la version de stockage.

Depuis la version v1.27, Kubernetes inclut déjà une optimisation qui définit les étiquettes SELinux sur le contenu des volumes, mais ce dernier restait plus lent car il exigeait que le moteur d'exécution du conteneur parcoure récursivement l'ensemble des volumes et applique l'étiquetage SELinux individuellement à chaque fichier et répertoire. "Cela est particulièrement visible pour les volumes contenant un grand nombre de fichiers et de répertoires. Kubernetes v1.27 a gradué cette fonctionnalité en version bêta, mais l'a limitée aux volumes ReadWriteOncePod", poursuit le billet de blog. "Avec la v1.30, Kubernetes étend la prise en charge de l'option SELinux mount à tous les volumes grâce à SELinuxMount." Depuis Kubernetes v1.30, les jobs indexés prennent par ailleurs en charge .spec.successPolicy pour définir quand un job peut être déclaré comme bien exécuté en se basant sur l'exécution réussie des pods. "Cela vous permet de définir deux types de critères : succeededIndexes indique que le Job peut être déclaré réussi lorsque ces index ont réussi, même si d'autres index ont échoué. SucceededCount indique que le travail peut être déclaré réussi lorsque le nombre d'index réussis atteint ce critère. Une fois que le job répond à la politique de réussite, le contrôleur de jobs met fin aux pods en attente", peut-on lire dans le post de blog.

Robust VolumeManager et l'ordonnancement de pods aussi stabilisés

Cette mouture 1.30 introduit aussi le champ spec.trafficDistribution dans un service Kubernetes. Le but : exprimer des préférences sur la façon dont le trafic doit être acheminé vers les points d'extrémité du service. "Alors que les politiques de trafic se concentrent sur des garanties sémantiques strictes, la distribution du trafic vous permet d'exprimer des préférences (telles que le routage vers des points d'extrémité topologiquement plus proches). Cela permet d'optimiser les performances, les coûts ou la fiabilité ", assure l'équipe K8s.

Enfin, on retrouve dans cette version une API intégrée pour StorageVersionMigration sur laquelle Kubernetes pour réécrire les données à chaud dans certaines activités de maintenance, et plusieurs fonctions sont également stabilisées comme Robust VolumeManager (pour fournir des informations supplémentaires sur la façon dont les volumes existants sont montés lors du démarrage d'un kubelet), ou encore la préparation de l'ordonnancement des pods. "Cette fonctionnalité désormais stable permet à Kubernetes d'éviter d'essayer de planifier un pod qui a été défini, lorsque le cluster n'a pas encore les ressources provisionnées pour permettre de lier ce Pod à un nœud [...] le contrôle personnalisé de l'autorisation de programmation d'un module permet également de mettre en œuvre des mécanismes de quotas, des contrôles de sécurité, et bien d'autres choses encore", explique le billet de blog. Parmi les autres fonctions désormais stabilisées, on notera aussi Min domains in PodTopologySpread (définition du nombre minimum de domaines utilisables dans Cluster Autoscaler) et la bascule vers le dépôt de code Go workspaces for k/k.