Les nouveautés de la version Kubernetes 1.24

La nouvelle version de Kubernetes 1.24 apporte 46 améliorations, ce chiffre est semblable aux nombres d’améliorations des précédentes versions de Kubernetes (45 pour Kubernetes 1.23 et 56 de Kubernetes pour 1.22). Sur ces 46 améliorations, 13 passent en version stable, 14 sont des fonctionnalités existantes améliorées, 13 sont complètement nouvelles et six sont des fonctionnalités dépréciées.

Comme d’habitude, nous voulons vous informer de tous les changements à venir au sujet de la nouvelle version de Kubernetes 1.24. Cette version dépréciera plusieurs API (bêta) au profit de versions stables. Le principal changement apporté par la version de Kubernetes 1.24 est la suppression de Dockershim. Ce dernier est abordé ci-dessous et sera approfondi.

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

Nous pouvons vous proposer une formation complète 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

Suppression de Dockershim

Il est important de noter que la suppression qui a fait l’objet de la plus grande attention avec la sortie de Kubernetes 1.24 est Dockershim. Dockershim a été déprécié dans la v1.20. Comme indiqué dans le changelog de Kubernetes 1.20 : “La prise en charge de Docker dans le kubelet est désormais dépréciée et sera supprimée dans une prochaine version ». Le kubelet utilise un module appelé « dockershim » qui implémente le support CRI pour Docker et qui a connu des problèmes de maintenance dans la communauté Kubernetes. » Avec la prochaine version de Kubernetes 1.24, le Dockershim sera finalement supprimé ».

Docker comme moteur d’exécution sous-jacent est déprécié au profit de moteurs d’exécution qui utilisent l’interface CRI (Container Runtime Interface) créée pour Kubernetes. Les images produites par Docker continueront à fonctionner dans votre cluster avec tous les runtimes, comme elles l’ont toujours faites.

Plusieurs guides ont été créés avec des informations utiles sur la migration de dockershim vers des runtimes de conteneurs directement compatibles avec Kubernetes.

Suppression et dépréciation des APIs Kubernetes

Kubernetes contient un grand nombre de composants qui évoluent au fil du temps. Dans certains cas, cette évolution entraîne la suppression d’API, de flags ou de fonctionnalités entières. Pour éviter que les utilisateurs ne soient pas confrontés à des changements brutaux, les contributeurs de Kubernetes ont adopté une politique de dépréciation des fonctionnalités. Cette politique garantie que les API stables ne peuvent être dépréciées que lorsqu’une version stable plus récente de cette même API est disponible. Ainsi que les APIs doivent avoir une durée de vie minimale, comme indiqué par les niveaux de stabilité suivants :

• Les versions d’API généralement disponibles (GA) ou stables peuvent être marquées comme dépréciées, mais ne doivent pas être supprimées dans une version majeure de Kubernetes.
• Les versions bêta ou préversion de l’API doivent être prises en charge pendant trois versions après leur dépréciation.
• Les versions alpha ou expérimentales de l’API peuvent être supprimées dans n’importe quelle version sans avis préalable de dépréciation.

Les suppressions suivent la même politique de dépréciation, qu’une API soit supprimée en raison du passage d’une fonctionnalité bêta à la version stable ou parce que cette API n’a pas fait ses preuves. Kubernetes continuera à s’assurer que les options de migration sont documentées lorsque des API sont supprimées.

Les API dépréciées sont celles qui ont été marquées pour être supprimées dans une future version de Kubernetes. Les API supprimées sont celles qui ne peuvent plus être utilisées dans les versions actuelles et prises en charge de Kubernetes après avoir été dépréciées. Ces suppressions ont été remplacées par des API plus récentes, stables et généralement disponibles (GA).

Les Nouvelles Fonctionnalités

• #1432 Surveillance de la santé des volumes CSI.

La possibilité de charger un sidecar qui vérifie la santé des volumes persistants est un ajout majeur. Désormais,
les administrateurs de clusters seront en mesure de mieux réagir et plus rapidement à des événements tels que la
suppression d’un volume persistant en dehors de Kubernetes. Cela augmentera la fiabilité des clusters Kubernetes.

Vicente J. Jiménez Miras – Security Content Engineer at Sysdig

• #2943 Statut de la politique réseau

Une des meilleures pratiques en matière de sécurité des conteneurs est de créer des politiques de réseau qui suivent une approche de confiance zéro. Cependant, il arrive parfois que vous obteniez une erreur difficile à déboguer et que vous finissiez par ouvrir votre politique plus que vous ne le souhaitez. La possibilité de déboguer ces situations rendra les clusters Kubernetes plus sûrs.

Miguel Hernández – Security Content Engineer at Sysdig

• #2578 Disponibilité opérationnelle de Windows et convergence des outils

Depuis son introduction dans Kubernetes 1.14, la prise en charge de Windows ne cesse de croître version après version, ouvrant Kubernetes à un large éventail d’entreprises qui ne l’auraient pas envisagé autrement. Grâce à la norme définie par Kubernetes 1.24, il sera plus facile de comparer la prise en charge de Windows entre les fournisseurs de Kubernetes. Espérons que cela rendra l’adoption de Kubernetes dans ces environnements un peu moins incertaine.

Daniel Simionato – Security Content Engineer at Sysdig

• #108004 Kubelet : exposer les métriques OOM

Il s’agit d’une minuscule amélioration qui aura des répercussions importantes. À partir de la version 1.24, kubelet offre une nouvelle métrique Prometheus qui enregistre le nombre des événements OutOfMemory qui se sont produits dans un conteneur. Cela offre plus de visibilité sur un problème récurrent dans les opérations Kubernetes lorsque les limites de mémoire ne répondent pas à l’utilisation et aux besoins du conteneur. Avec cette nouvelle mesure, le SRE peut mieux comprendre la cause finale du problème et mieux déterminer s’il s’agit d’un problème récurrent ou d’un cas limite. Un dépannage plus rapide, des utilisateurs plus heureux.

David de Torres – Manager of Engineering at Sysdig

Suppression et dépréciation des APIs

• Configuration dynamique du kubelet : DynamicKubeletConfig est utilisé pour activer la configuration dynamique du kubelet. L’indicateur DynamicKubeletConfig a été déprécié dans Kubernetes 1.22. Dans la v1.24, cette porte de fonctionnalité sera supprimée du kubelet.

• Nettoyage dynamique des logs : La fonctionnalité expérimentale de désinfection dynamique des logs est obsolète et sera supprimée dans la v1.24. Cette fonctionnalité introduisait un filtre de journalisation qui pouvait être appliqué à tous les logs des composants du système Kubernetes pour empêcher divers types d’informations sensibles de fuir via les logs.

• Migration du provisionneur In-tree vers le pilote CSI : Ceci s’applique à une multitude de plugins in-tree, y compris Portworx.

• Suivi de la capacité de stockage pour la programmation des pods : L’API CSIStorageCapacity assure l’exposition de la capacité de stockage actuellement disponible via les objets CSIStorageCapacity et améliore l’ordonnancement des pods qui utilisent des volumes CSI avec une liaison tardive. Dans la v1.24, l’API CSIStorageCapacity sera stable. La stabilité de cette fonction entraîne la dépréciation de l’API CSIStorageCapacity v1beta1.

• L’étiquette master n’est plus présente sur les nœuds du plan de contrôle kubeadm. Pour les nouveaux clusters, l’étiquette ‘node-role.kubernetes.io/master‘ ne sera plus ajoutée aux nœuds du plan de contrôle, seule l’étiquette ‘node-role.kubernetes.io/control-plane’ sera ajoutée.

• VolumeSnapshot v1beta1 CRD sera supprimé. La fonctionnalité d’instantané, de restauration, de volume, d’interface de stockage des conteneurs (CSI), l’ajout de la prise en charge de l’instantané/restauration de volume pour les pilotes de volume CSI est entrée en version bêta dans la v1.20. VolumeSnapshot v1beta1 a été déprécié dans la v1.21 et n’est désormais plus pris en charge.

L’avenir de Kubernetes

Les versions 1.25 et 1.26 de Kubernetes, prévues pour la fin de l’année, cesseront de proposer des versions bêta de
plusieurs API Kubernetes actuellement stables. La version 1.25 supprimera également PodSecurityPolicy, déprécié avec la version 1.21 de Kubernetes et ne passera pas à la version stable.

La liste officielle des suppressions d’API prévues pour Kubernetes 1.25 est la suivante :

• L’API bêta CronJob (batch/v1beta1)
• L’API bêta EndpointSlice (discovery.k8s.io/v1beta1)
• La version bêta de l’API Event (events.k8s.io/v1beta1)
• La version bêta de l’API HorizontalPodAutoscaler (autoscaling/v2beta1)
• La version bêta de l’API PodDisruptionBudget (policy/v1beta1)
• La version bêta de l’API PodSecurityPolicy (policy/v1beta1)
• L’API bêta RuntimeClass (node.k8s.io/v1beta1)
• La liste officielle des suppressions d’API prévues pour Kubernetes 1.26 est la suivante :

Les API bêta FlowSchema et PriorityLevelConfiguration (flowcontrol.apiserver.k8s.io/v1beta1)
L’API bêta HorizontalPodAutoscaler (autoscaling/v2beta2)

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