Les nouveautés de Kubernetes 1.23

Ambient IT revient sur toutes les nouveautés qu’apporte Kubernetes 1.23. Kubernetes 1.23 est vient de sortir, et il est plein de nouveautés et de corrections ! Dès 7 décembre 2021, nous pouvons profiter toutes les nouvelles fonctionnalités de Kubernetes qui vont certainement faciliter votre travail. Les nouvelles fonctionnalités incluses dans cette version sont généralement petites, mais en même temps vraiment significatives. Par exemple, la commande kubectl events, le support de OpenAPI v3, ou les sondes gRPC.

Cette version apporte 47 améliorations, comparant avec les 56 de Kubernetes 1.22 et les 50 de Kubernetes 1.21. Sur ces 45 améliorations, 11 passent à la version stable, 17 sont des fonctionnalités existantes qui continuent de s’améliorer et 19 sont entièrement nouvelles.

Cette version est constituée par toutes les fonctionnalités qui atteignent l’état de GA. La liste est longue : CronJobs, support dual-stack IPv4/IPv6, volumes éphémères et l’API HPA, pour n’en citer que quelques-unes. Nous sommes vraiment enthousiastes à propos de cette version !

Sans oublier de faire attention à toutes les dépréciations et suppressions dans cette version !

Il y a beaucoup à dire, alors commençons par les nouveautés de Kubernetes 1.23.

Nous pouvons vous proposer une formation complète de 3 jours sur Kubernetes et Kubernetes Avancé.
Ces formations dispensées par des formateurs expérimentés vous présenteront la dernière version de Kubernetes.

L’équipe d’AMBIENT IT

Par ailleurs, nous vous invitons à lire notre article sur Kubernetes 1.22 si vous souhaitez en savoir plus sur la version précédente de Kubernetes.

API de Kubernetes

Pour les API il y 4 passages en Alpha

• CRD Langage d’expression de validation

Regardons en détail, le CRD ou Langage d’expression de validation. Cette amélioration met en œuvre un mécanisme de validation pour les définitions de ressources personnalisées (CRD), en complément du mécanisme existant basé sur les webhooks. Toutes les informations d’une CRD se trouve au même endroit/ Vous pourrez simplifier considérablement les développements sans avoir besoin de webhooks. Ces règles de validation utilisent le langage d’expression commun (CEL) et sont incluses dans les schémas CustomResourceDefinition à l’aide de l’extension x-kubernetes-validations.

• La validation des champs inconnus côté serveur KEP

Cette amélioration résume le travail d’implémentation de la validation sur kube-apiserver, et sera mise en œuvre en plusieurs phases (d’abord implémenter la validation sur le serveur, mettre à jour les clients pour utiliser la validation côté serveur plus tard). Cette amélioration permettra à chaque client implémenter la validation.

• Types d’Enum OpenAI

Cette fonction améliore le générateur OpenAPI de Kubernetes, afin qu’il puisse reconnaître les types marqués par +enum, et chercher à détecter automatiquement les valeurs possibles pour un enum.

Le générateur Kubernetes OpenAPI peut reconnaître que les valeurs acceptées sont uniquement TCP, UDP et SCTP. Cette information est à la disposition d’autres outils qui, à l’avenir, pourraient afficher ces champs sous forme de listes déroulantes au lieu de champs de texte non limités.

• Open API V3

Cette fonctionnalité ajoute un support à kube-apiserver et les types tels que des objets OpenAPI v3.

Actuellement, ils sont disponibles en tant qu’objets OpenAPI v2 au point de terminaison $cluster/openapi/v2 cluster. Cependant, les CRDs peuvent être définis en utilisant la v3 d’OpenAPI, qui permet des définitions plus compliquées, comme les types enum. Lorsqu’ils sont traduits pour être servis sur le point de terminaison v2, certaines informations manquent, comme les définitions de type transformées en « accept anything ».

Lorsque le portail de fonctionnalités OpenApiv3 est activé, un nouveau point de terminaison /openapi/v3/apis/{group}/{version} est disponible. Il sert un schéma par ressource au lieu de tout agréger en un seul.

1 changement majeur en Bêta – Priorité et équité pour les requêtes du serveur API

Cette fonction vous permettra d’activer un nouveau gestionnaire de requête max-in-flight dans le serveur API grâce à la fonctionnalité APIPriorityAndFairness. Vous pouvez vous assurer que le serveur d’API Kubernetes sera réactif pour les tâches d’administration et de maintenance pendant les charges élevées, en définissant de différents types de demandes avec des objets RequestPriority.

Apps de la nouvelle version

Apps nous présentent 6 nouvelles fonctionnalités qui seront en Alpha, en Bêta et aussi en Stable

• Le premier passage en Alpha lié à la suppression automatique des PVCs créés par Stateful. Un nouveau champ facultatif .spec.persistentVolumeClaimRetentionPolicy, a été ajouté pour contrôler comment et si les réclamations de volume persistantes (PVC) sont supprimées pendant le cycle de vie d’un StatefulSet. Désormais vous pouvez décider de conserver ou de supprimer les PVCpour tout Pod supprimé (whenDeleted), ou uniquement pour les répliques de Pod en cours de réduction (whenScaled).

• Deuxième amélioration ajoute le champ Job.status.ready qui compte le nombre de Job Pods qui ont une condition de disponibilité, similaire aux champs existants active, succeeded et failed. Le nouveau champ ready diffère du champ active dans la mesure où active inclut les Job Pods qui sont à la fois dans les phases Running et Pending. Comme ces travaux peuvent rester en phase d’attente pendant un certain temps, le champ actif peut donner une fausse impression de progression aux utilisateurs finaux ou aux autres contrôleurs. Le nouveau champ ready peut réduire la nécessité d’écouter les mises à jour des pods afin d’obtenir une image plus correcte de l’état actuel.

• Dans cette nouvelle version, CronJobs devient plus stable. CronJobs exécute des tâches périodiques dans un cluster Kubernetes, de manière similaire à cron sur les systèmes de type UNIX.

• La deuxième fonctionnalité stable TTL après la fin. Cette fonctionnalité s’occupe des tâches terminées et complètes. C’est utile, car ces travaux ne sont plus nécessaires dans le système et les conserver génère plus de charges dans le serveur API. Un champ ttlSecondsAfterFinished peut désormais être configuré pour avoir un contrôleur.
• Pour finir avec les Apps on peut noter deux passages en bêta. Le Suivi des emplois sans gousses persistantes, cette amélioration va libérer des ressources dans le cluster en supprimant les pods terminés. Une autre amélioration ajoute aux StatefulSets le champ optionnel appelé minReadySeconds qui était déjà disponible sur les Deployments, DaemonSets, ReplicasSets, et Replication Controllers.

Les nouveautés au niveau de l’instrumentation

• Au niveau de l’instrumentation, nous pouvons noter une dépréciation des drapeaux spécifiques à klog dans les composants Kubernetes. Ce passage en Alpha simplifie la journalisation dans ses composants et supprime certains drapeaux dans klog. Ce changement vient de la décision d’utiliser la bibliothèque glog pour la journalisation lors des premiers jours de Kubernetes. Plus tard cette bibliothèque a été transformée en klog pour gagner en flexibilité. Maintenant, une plus grande flexibilité est demandée, il est donc le temps de faire l’amélioration des performances, remplir les exigences de scalabilité de Kubernetes, supprimer les fonctionnalités de glog qui ne sont plus nécessaires pour préparer la bibliothèque à de nouvelles fonctionnalités.

• Enregistrement structuré encore une amélioration qui définit une structure standard pour les messages de log de Kubernetes.

Network de Kubernetes 1.23

• Pour Network la nouvelle version Kubernetes présente deux améliorations en état stable. L’ajout du support dual-stack IPv4qui, une amélioration qui résume le travail effectué pour prendre en charge de manière native le mode dual-stack dans votre cluster, afin que vous puissiez attribuer des adresses IPv4 et IPv6 à un pod donné. L’autre amélioration stable liée aux paramètres de classe d’entrée à portée d’espace de nom. Cette amélioration vous permettra spécifier des paramètres pour une IngressClass avec une portée Namespace.
• Une amélioration en bêta qui vient de Network. Cette amélioration nommée Topology Aware Hints remplacera la fonctionnalité ServiceTopology gate qui a été introduite dans Kubernetes.

Nodes de Kubernetes 1.23

Les améliorations suivantes ont été réalisées pour les nodes de Kubernetes :

• Statistiques des conteneurs et des pods sans cAdvisor, avec CRI complet
• Arrêt progressif basé sur la valeur de la classe de priorité
• Ajout d’une sonde gRPC au pod
• Option de politique CPUManager pour distribuer les CPUs sur les nœuds NUMA
• Conteneurs éphémères
• Support Kubelet CRI
• Extension de l’API podresources pour signaler les ressources allouables

La planification

Toutes les améliorations sont en bêta.

• Passage de l’API de configuration du composant ordonnanceur à la version v1beta3 et abandon de la v1beta1. Cette amélioration rend la configuration des composants plus dynamique et directement accessible via l’API Kubernetes.

Dans cette version, plusieurs plugins ont été supprimés :

NodeResourcesLeastAllocated
NodeResourcesMostAllocated
RequestedToCapacityRatio
NodeLabel
ServiceAffinity
NodePreferAvoidPods

• Configuration simplifiée du plugin multi-point pour le programmateur. Cette amélioration simplifie la configuration des plugins de planification, en permettant l’enregistrement de plugins pour plusieurs points d’extension simultanément.
• La dernière amélioration permet de mettre à jour des contraintes d’affinité entre les nœuds des travaux suspendus.

Cette amélioration s’appuie sur le « #2232 Stopped Job » de Kubernetes 1.21, qui a ajouté le champ .spec.suspend pour mettre les tâches en pause. Dans Kubernetes 1.23, il sera possible de mettre à jour les champs affinité de nœuds, sélecteur de nœuds, tolérances, étiquettes et annotations dans le modèle de pod d’un job avant qu’il ne démarre. Ainsi, vous pourrez influencer l’endroit où les pods seront exécutés, par exemple tous dans la même zone, ou dans des nœuds ayant le même modèle de GPU.

Stockage de Kubernetes 1.23

Une grande partie de nouvelles fonctionnalités vient de stockage de Kubernetes. Voici quelques-unes :

En Alpha

• Récupération des échecs de redimensionnement
• Toujours respecter la politique de réclamation
• Déléguer FSGroup au pilote CSI au lieu de Kubelet
• Migration de Portworx file in-tree vers CSI driver
• Migration de Ceph RBD in-tree provisioner vers le pilote CSI

Nouveau : Découvrez notre article sur les nouveautés de la version suivante : Kubernetes 1.24.