Kubernetes 1.27 vient de sortir le 11 avril 2023, soit 4 mois après la précédente version. Nous allons ici présenter ses fonctionnalités ainsi que les correctifs apportés par cette nouvelle version.
Il ne fait aucun doute que la version 1.27 de Kubernetes est riche en nouvelles fonctions ainsi qu’en correction de bugs. Au programme, une utilisation des ressources optimisée, de nouvelles options pour les pods et le contrôleur de tâches.
Nous avons sélectionné quelques futures fonctionnalités de Kubernetes 1.27. Si vous souhaitez avoir la liste complète des issues sur lesquelles travaillent les équipes, vous pouvez jeter un œil à la documentation de la release 1.27. Précédemment, nous avons également publié un article sur la version précédente : Kubernetes 1.26.
Update
La version 1.27 de Kubernetes est sur le point de corriger un bug vieux d’environ 6 ans : permettre aux jobs de se terminer même avec un sidecar en cours d’exécution.
La solution constiste à faire comprendre le concept de sidecar à Kubernetes. Il n’y aura pas de champ sidecar, mais ils seront spécifiés parmi les initContainers. Marqués avec un restartPolicy défini sur Always, cela signifie qu’ils ne devraient pas affecter la gestion de la terminaison du Pod ou du Job.
Pour en savoir plus sur ce correctif, vous pouvez lire le post LinkedIn de Lars Larsson
Quand sortira Kubernetes 1.27 ?
La timeline Kubernetes nous indique que la version 1.27 sera disponible en stable le 11 avril 2023. Elle sera donc prête juste à temps pour la Kubecon EU qui aura lieu du 17 au 21 avril à Amsterdam.
Il faut également noter que la version 1.26 ne sera pas abandonnée immédiatement puisque le support actif sera maintenu jusqu’en décembre 2023 et des maintenances seront effectuées jusqu’en février 2024.
Pour une maitrise complète de l’outil, suivez notre formation Kubernetes. Il s’agit d’une formation complète sur 3 jours lors de laquelle vous apprendrez à automatiser le déploiement, la mise à l’échelle et la gestion d’applications de manière conteneurisée.
Si vous êtes déjà expert de l’outil, la formation Kubernetes avancé vous apprendra à faire évoluer vos applications vers le standard micro-service, modulaire et scalable.
L’équipe Ambient IT
Comment sont développées les versions de Kubernetes ?
Chaque version de Kubernetes est développée par une équipe différente. Les releases managers (qui sont pour la majorité présents sur plusieurs versions) ouvrent les inscriptions de manière publique sur google groups et n’importe quel développeur peut s’inscrire. Ils sont ensuite sélectionnés par les managers.
Cette méthode permet de recruter une équipe fraîche, souvent jeune et composée de véritables utilisateurs de Kubernetes. Les fonctionnalités et correctifs élaborés sont donc en accord avec l’utilisation réelle de l’outil et les nouvelles versions répondent à des besoins opérationnels.
Des visioconférences sur Zoom sont organisées pour que les développeurs puissent échanger et collaborer sur les différentes issues.
À noter que ce mode d’organisation ne permet pas encore un cycle régulier en termes de release, par exemple tous les 6 mois ou 1 an comme on aurait pu s’y attendre sur un projet de cette envergure, et ne définit pas non plus une roadmap très lisible sur le long terme. Néanmoins cette structure souple permet de répondre plus rapidement au besoin des utilisateurs et du marché, ce qui semble très bien fonctionner dans le cas du projet K8s chapeauté par la CNCF.
Maintenant que vous savez tout sur le développement de Kubernetes, passons aux nouvelles fonctionnalités.
Gel du registre d’image k8s.gcr.io
Kubernetes 1.27 supprime la dépendance à Google Cloud et permet le service d’image via le fournisseur cloud le plus facilement accessible. Cette nouveauté permet non seulement à Kubernetes de se détacher de Google mais assure également une efficacité technique avec des téléchargements d’image plus rapide et des déplacements de données moindre.
Instantané de groupe de volumes
Vous pourrez rendre cohérent tous les instantanés de volume de vos pods. Cette fonctionnalité va grandement améliorer le retour à l’état normal de vos clusters après un sinistre. Plus de risques de mauvais comportement d’une application car les volumes ont été sauvegardés avec quelques secondes de différences.
Cela permet également de faciliter les enquêtes de sécurité car les instantanés seront assurés de représenter réellement l’état du pod.
Mises à jour des pods
Vous pourrez enfin mettre à jour les ressources des pods sans avoir besoin de les redémarrer. Cette fonctionnalité permet de faciliter le travail des opérateurs gérant des charges de travail qui ne supportent pas les redémarrages et dont les ressources sont sujettes à des modifications régulières.
À noter que la surveillance des ressources dans un nœud se fera donc également via le PodStatus.
Workercount flag pour le contrôleur de nœuds
Ce PR permet de modifier le nombre de travailleurs dans le gestionnaire de control cloud. Avant cette fonctionnalité, toute la synchronisation des nœuds n’était faite que dans un seul thread.
Cela prenait beaucoup de temps et entrainait une dégradation des performances en cas d’utilisation de nombreux nœuds. En fixant le flag à un nombre plus élevé, la synchronisation des nœuds sera plus rapide.
Amélioration de l’utilisation des ressources par les Sondes Kubelet TCP/HTTP
Pour chaque connexion, le système d’exploitation ouvre un socket. Une fois terminée, il ne libère pas toutes les ressources attribuées d’un seul coup et elles passent par un état TIME-WAIT.
Les sondes Kubelet créent des connexions de courte durée qui attribuent chacune un socket ou un port éphémère qui a besoin de 60 secondes pour être libéré.
Lorsqu’un système utilise déjà énormément de ressources réseau, utiliser un nombre élevé de sondes peut entrainer des problèmes de disponibilité des ressources. Kubernetes étant un système distribué, il est courant d’atteindre cette limite au quotidien.
Les défaillances causées par le manque de ressources sont très difficiles à résoudre, car elles peuvent entrainer un nombre de symptômes très variés.
Délais d’attente exponentiels
Lorsque la fonction JobTrackingWithFinalizers est activée, le contrôleur crée des pods sans aucun backoff. Le but était donc de faire en sorte de revenir au fonctionnement précédent où les pods étaient faits selon un délai de temporisation exponentiel (10s, 20s, 40s…).
Notons que la détection de l’échec d’un pod et la création d’un nouveau pod se déroulent maintenant dans la même boucle de réconciliation. Le second pod est donc créé directement après l’échec du premier. Le backoff n’est, lui, appliqué qu’après l’échec du deuxième. Le 3ᵉ pod est donc créé 10 secondes après le second.
Certains bugs sont également corrigés dans cette nouvelle version, notamment une mise à jour de uptatePod afin de s’assurer que les backoff sont bien appliqués au bon moment et des correctifs liés aux échecs transitoires des finaliseurs.
Planificateur Volumebinding
Ce changement permet d’exploiter le nouveau PreFilterResult pour réduire la liste des nœuds éligibles dans le POD. Seuls les nœuds dont l’affinité correspond seront désormais pris en compte dans les étapes suivantes.
Pour le moment, la vérification de l’affinité entre les nœuds est effectuée pendant l’étape de filtrage. Cela signifie que tous les nœuds sont pris en compte même ceux qui ne sont pas éligibles. Réduire la liste des nœuds dans le préfiltrage assure donc de ne garder que des nœuds pertinents pour la programmation.
Si une erreur apparait durant le préfiltrage ou que la réduction de la liste de nœuds ne peut pas être effectuée : tous les nœuds seront alors considérés.
Pour en savoir plus sur cette nouveauté, vous pouvez consulter le Github associé.
Options supplémentaires pour les affinités inter-pods
Il sera dorénavant possible pour le planificateur d’ignorer les affinités interpods préférées si le pod n’a pas d’affinité inter-pods déjà enregistrée.
Les règles d’affinités inter-pods ont tendance à être faites dans les deux sens. Un pod de type A a une affinité préférée pour le pod de type B et vice versa. L’inverse est également vrai. Si un pod n’en a pas, il est probable qu’aucun n’en ait à son égard.
Dans Kubernetes 1.27, l’utilisateur peut choisir d’optimiser cette fonctionnalité en supprimant l’analyse linéaire des pods. Cette option entraînera la sortie prématurée de PreScore si elle est activée et que le pod entrant n’a pas de règles d’affinité inter-pods.
Fakeclock pour UT dans le contrôleur de tâches
Inspiré du daemon_controller.go sur KMC, le job_controller.go est refactorisé pour accepter un clock.Clock afin de fournir un testingclock.FakeClock comme valeur d’un test unitaire.
Le job_controller_test.go est donc modifié pour pouvoir injecter directement la fake clock. Cela permet un meilleur comportement de test pour les éléments remis dans la workqueue.
Option pour limiter le nombre d’appels MKFS simultanés
Les développeurs de la version 1.27 ont observé que le pilote PDCSI passe en mode OOM (mémoire insuffisante) lorsqu’il tente de provisionner plus de 100 volumes simultanément en dépassant 4 appels MKFS par secondes. Ils ont donc ajouté une fonction pour restreindre le nombre d’appels, et ainsi réduire les pics de mémoire et rendre la collecte de données plus fiable.
Il reste de nombreuses autres issues ouvertes dans le journal de développement de Kubernetes 1.27. À l’heure où cet article est écrit (début février 2023), 93 % de la version est prête pour passer à l’étape de test et à l’alpha.
