Kubernetes 1.33 : les principales fonctionnalités stabilisées

Cette fois-ci, c'est la bonne pour le modèle side-car.

Ce pattern exploré de longue date consiste à déployer des conteneurs auxiliaires pour gérer des éléments tels que le réseau, la sécurité, la journalisation et la synchronisation de données. Le voilà officiellement stabilisé avec Kubernetes 1.33.

D'autres fonctionnalités atteignent le même stade en parallèle. En voici quelques-unes.

Des limites de backoff par index

Le backoff définit le nombre de tentatives d'exécution d'un job avant de considérer qu'il a échoué.

Dans le cas des jobs indexés, chaque index peut désormais avoir sa propre limite de backoff. Une option censée assurer que l'échec d'index spécifiques n'interrompe pas le traitement des autres.

Des stratégies pour cadrer la réussite des jobs

On peut maintenant spécifier, avec spec.successPolicy, quels index doivent réussir (succeededIndexes) et combien de pods doivent réussir.

Une capacité idéale pour les workloads de simulation où une réussite partielle suffit. Ainsi que pour les patterns leader-worker où seule la réussite du leader détermine le résultat du job.

Une sécurité améliorée pour les tokens

Kubernetes 1.33 inclut, dans les tokens, un identifiant unique et des informations relatives aux noeuds.

En plus de permettre une validation et un audit plus précis, ces éléments assurent que les tokens ne sont utilisables que sur des noeuds désignés.

La prise en charge des sous-ressources dans kubectl

L'argument --subresource permet, pour commencer, de traiter trois types de sous-ressources : status, resize et scale (cette dernière n'étant pas supportée avec kubectl edit).

De multiples IP par service interne

Kubernetes 1.33 implémente une nouvelle logique d'attribution des IP de service. À l'appui des API ServiceCIDR et IPAddress, elle accroît dynamiquement le nombre d'adresses disponibles pour les services exposés à l'intérieur du cluster.

Un back-end nftables pour kube-proxy

Cette option est censée améliorer la performance et la scalabilité de l'implémentation de services.

Pour des raisons de compatibilité, iptables reste le choix par défaut sur les noeuds Linux.

Du routage topologique

En exploitant des indices dans l'API EndpointSlices, des composants comme kube-proxy peuvent acheminer le trafic vers des points de terminaison situés dans la même zone.

Sur cette base, un champ trafficDistribution est ajouté dans la spécification des services. La valeur PreferClose met en oeuvre ce routage topologique.

Le rejet des workloads non adaptés au SMT

Le kubelet sait maintenant rejeter les worlkloads non adaptées aux configurations SMT (Simultaneous Multithreading).

Il peut ainsi, lorsqu'un pod demande une exclusivité sur des coeurs CPU, allouer l'ensemble des threads sur les systèmes compatibles, évitant ainsi les partages indésirables de ressources.

Des clés pour définir plus finement les affinités

Kubernetes 1.33 ajoute des clés dans les règles d'affinité des pods, par l'intermédiaire de champs matchLabelKeys et mismatchLabelKeys. Objectif : complètent le sélecteur d'étiquette et en pallier les limites. Notamment le fait qu'il ne permet pas au planificateur de distinguer, lors des mises à jour propagées (rolling upgrades), les anciennes et les nouvelles versions d'un pod.

Cette absence de distinction est susceptible d'engendrer une allocation non optimale. Jusqu'à distribuer les anciens pods à travers toutes les topologies et ainsi empêcher les nouveaux pods de trouver des noeuds à cause des anti-affinités. Le champ matchLabelKeys est censé y remédier. Quant à mismatchLabelKeys, il favorise l'isolation de services (placement des pods d'un même locataire exclusivement sur un même domaine).

Une prise en compte des taints et des tolérances pour la distribution des pods

Le composant PoTopologySpread accueille des champs nodeAffinityPolicy et nodeTaintsPolicy. Ils permettent de préciser s'il faut prendre en compte les règles d'affinité lors du calcul de la distribution des pods.

Dans le comportement par défaut, seuls les noeuds cohérents vis-à-vis de l'affinité ou du sélecteur sont inclus dans le calcul - et les taints ne sont pas pris en compte.

Cette fonctionnalité est censée, notamment, éviter que des pods restent en attente à cause de contraintes non satisfaites.

Un prépeuplement des volumes à partir de diverses sources de données

Kubernetes gérait jusqu'à présent le prépeuplement à partir de snapshots de volumes ou de clones de PVC (PersistentVolumeClaims).

Le champ dataSourceRef lui permet d'aller piocher dans des ressources personnalisées, d'une manière plus flexible que dataSource. Un contrôleur spécifique (volume-data-source-validator) valide ces références.

Un respect systématique de la politique de récupération des volumes persistants

Jusqu'ici, cette politique n'était pas toujours honorée. En particulier si un volume persistant était supprimé avant le PVC associé. Le stockage sous-jacent était alors laissé intact.

Désormais, Kubernetes place des finalisateurs (clés de namespaces) sur les PV pertinents pour assurer une mise en oeuvre systématique de la politique de récupération.