La Cloud Native Computing Foundation (CNCF) a publié Kubernetes 1.27, nom de code "chill vibes". Cette version comprend 60 améliorations. 18 de ces améliorations entrent en Alpha, 29 passent en Beta et 13 passent en Stable.

Le registre d'images k8s.gcr.io est figé

Le projet Kubernetes a créé et gère le registre d'images registry.k8s.io, qui est entièrement contrôlé par la communauté et disponible depuis plusieurs mois. Cela signifie que l'ancien registre k8s.gcr.io est gelé et qu'aucune autre image de Kubernetes et des sous-projets associés ne sera publiée dans l'ancien registre.

Que signifie ce changement pour les utilisateurs finaux ?

• La version de Kubernetes v1.27 ne sera pas publiée dans le registre k8s.gcr.io.
• Les versions de correctifs pour v1.24, v1.25 et v1.26 ne seront plus publiées dans l'ancien registre après avril.
• À partir de la v1.25, le registre d'images par défaut a été défini sur registry.k8s.io. Cette valeur peut être remplacée dans kubeadm et kubelet, mais sa définition k8s.gcr.io échouera pour les nouvelles versions après avril car elles ne seront pas présentes dans l'ancien registre.
• Si vous souhaitez augmenter la fiabilité de votre cluster et supprimer la dépendance vis-à-vis du registre appartenant à la communauté ou si vous exécutez Kubernetes sur des réseaux où le trafic externe est restreint, vous devez envisager d'héberger des miroirs de registre d'images locaux. Certains fournisseurs de cloud peuvent proposer des solutions hébergées pour cela.

Accès au journal des nœuds via l'API Kubernetes

A remarquer parmi les nouveautés, cette nouvelle fonctionnalité aide les administrateurs de cluster à déboguer les problèmes liés aux services exécutés sur les nœuds en leur permettant d'interroger les journaux de service.

Sous Linux, il est supposé que les journaux de service sont disponibles via journald. Sous Windows, il est supposé que les journaux de service sont disponibles dans le fournisseur de journaux d'application. Vous pouvez également récupérer les journaux des répertoires /var/log/ et C:\var\log sous Linux et Windows, respectivement.

Un administrateur de cluster peut tester cette fonctionnalité alpha sur tous les nœuds de son cluster ou sur un sous-ensemble d'entre eux.

La prise en charge d'OpenAPI v3 passe à Stable

Pour mémoire, OpenAPI est un standard pour spécifier des API HTTP. Cette prise en charge permet donc à Kubernetes de publier une description de son API au format OpenAPI v3, contre le format v2 précemment.