La lampe frontale est une plateforme open-source pour explorer, gérer et déboguer les ressources des clusters Kubernetes. Karpenter est un projet d'autoscaling Kubernetes qui provisionne efficacement de nouveaux nœuds et gère leur cycle de vie. Un nouveau plugin Headlamp a été développé pour fournir une visibilité en temps réel sur les opérations de Karpenter directement dans l'interface utilisateur de Headlamp. Ce plugin visualise les connexions entre les ressources Karpenter et les objets Kubernetes de base. Il affiche des métriques en direct telles que l'utilisation des ressources, les perturbations autorisées et la latence de provisionnement. Les utilisateurs peuvent inspecter les pods en attente et comprendre les décisions de mise à l'échelle de Karpenter, ce qui facilite le débogage. Le plugin offre également un éditeur de configuration avec validation pour des modifications en direct sécurisées des ressources Karpenter. Il fournit des vues en temps réel des ressources Karpenter telles que les NodeClaims à mesure que le cluster évolue. Un tableau de bord met en évidence les pods en attente et les raisons de leur impossibilité de planification. Le plugin a été testé avec les fournisseurs Karpenter AWS et Azure, offrant des informations spécifiques au fournisseur. Les utilisateurs sont encouragés à soumettre des problèmes pour les fournisseurs non testés ou pour des commentaires. Les instructions d'utilisation sont disponibles dans le fichier README du plugin.

Une nouvelle fonctionnalité alpha dans Kubernetes améliore l'écosystème de stockage avec le suivi des blocs modifiés. Ce mécanisme permet aux pilotes de stockage CSI d'identifier efficacement les blocs modifiés dans les instantanés de volumes persistants. En suivant les modifications au niveau des blocs, les opérations de sauvegarde deviennent considérablement plus rapides et plus efficaces en termes de ressources. Au lieu de scanner des volumes entiers, les sauvegardes peuvent désormais se concentrer uniquement sur les données altérées. Cette amélioration est intégrée à l'interface de stockage de conteneurs (CSI) et au support de stockage Kubernetes. La fonctionnalité est actuellement limitée aux volumes de blocs et ne prend pas en charge les volumes de fichiers. Les méthodes de sauvegarde traditionnelles peinent avec de longues fenêtres de sauvegarde, une utilisation élevée des ressources et des coûts de stockage accrus en raison des données redondantes. L'API de suivi des blocs modifiés offre un support natif Kubernetes pour les sauvegardes incrémentielles via l'interface CSI. Les composants clés comprennent l'API CSI SnapshotMetadata Service, une définition de ressource personnalisée Kubernetes (CustomResourceDefinition) et un sidecar externe de métadonnées d'instantané. Les fournisseurs de stockage doivent implémenter des RPC CSI spécifiques et disposer de capacités backend pour suivre les modifications de blocs. Les solutions de sauvegarde doivent gérer l'authentification, implémenter un code client de streaming et optimiser leurs flux de travail pour tirer parti de ces nouvelles métadonnées. Pour utiliser la fonctionnalité, assurez-vous que votre pilote CSI prend en charge les instantanés et les capacités de métadonnées, et que la ressource personnalisée SnapshotMetadataService est enregistrée. L'API fournit les fonctions GetMetadataAllocated et GetMetadataDelta pour identifier les blocs. Les plans futurs incluent la promotion de cette implémentation en version Beta en fonction des retours et de l'adoption.

Kubernetes v1.34 introduit les ressources au niveau du Pod, passant en Beta et activées par défaut. Cette fonctionnalité permet de définir les ressources CPU et mémoire au niveau du Pod, offrant flexibilité et simplifiant la gestion des ressources. Cela permet un partage plus facile des ressources au sein d'un Pod et réduit les complexités dans les spécifications au niveau du conteneur. Les ressources au niveau du Pod sont compatibles avec les définitions au niveau du conteneur, les premières prévalant. Cette fonctionnalité améliore également la planification et le comportement QoS et est compatible avec les fonctionnalités Kubernetes existantes. Pour utiliser cette fonctionnalité, définissez les requêtes et les limites de ressources dans le champ `resources` du Pod dans le manifeste. Les limites au niveau du Pod agissent comme des plafonds stricts pour l'utilisation globale des ressources, influençant la qualité de service du pod. Le redimensionnement sur place des ressources au niveau du pod n'est pas encore pris en charge dans cette version. Seules les ressources CPU, mémoire et hugepages peuvent être spécifiées au niveau du pod pour le moment. La fonctionnalité des ressources au niveau du Pod n'est pas compatible avec les pods Windows. Les utilisateurs doivent fournir des commentaires via les canaux Kubernetes.

Kubernetes v1.34 introduit une amélioration significative : la récupération automatisée après l'échec de l'extension de volume. Auparavant, la correction des erreurs d'extension, telles que la spécification d'une taille de stockage incorrecte, nécessitait une intervention manuelle et des privilèges d'administrateur de cluster. Cette nouvelle fonctionnalité permet aux utilisateurs de réduire la taille demandée du PVC en cas d'erreur lors de l'extension, tant que l'extension n'est pas terminée. Kubernetes corrigera alors automatiquement la taille, restituant tout quota consommé et redimensionnant le PersistentVolume. Un exemple illustre comment un utilisateur peut corriger une faute de frappe dans une demande de stockage. La taille corrigée doit toujours être supérieure à la taille du volume d'origine, car la réduction des volumes n'est pas prise en charge. La mise en œuvre a impliqué une refonte complète de l'extension de volume, introduisant de nouveaux champs d'API pour surveiller la progression de l'extension. Une meilleure gestion des erreurs et des rapports sont désormais présents, les erreurs persistant en tant que conditions PVC et les extensions ayant échoué étant relancées à un rythme plus lent. Cette fonctionnalité corrige également des bogues de longue date dans le flux de travail de redimensionnement. Les utilisateurs sont encouragés à signaler tout problème rencontré. Le développement de cette fonctionnalité a bénéficié des commentaires et des contributions de diverses personnes et de la communauté Kubernetes.

L'allocation dynamique des ressources (DRA) dans Kubernetes gère les ressources rares comme les périphériques pour les Pods, allant au-delà de la simple allocation de périphériques. DRA permet de demander des périphériques spécifiques avec des configurations personnalisées, y compris le partage de ressources. Ce blog détaille la nouvelle fonctionnalité de capacité consommable de DRA dans Kubernetes 1.34, cruciale pour un partage de périphériques plus précis. La capacité consommable permet de partager un périphérique entre plusieurs ResourceClaims ou DeviceRequests, même entre des espaces de noms. Le scheduler prend désormais en charge l'allocation de portions de ressources de périphériques, gérant la capacité globale. Une nouvelle contrainte DistinctAttribute empêche qu'un seul périphérique soit alloué plusieurs fois dans la même demande. Cette fonctionnalité nécessite l'activation du feature gate DRAConsumableCapacity dans divers composants Kubernetes. Les développeurs peuvent autoriser plusieurs allocations en définissant AllowMultipleAllocations, et peuvent définir des politiques pour les demandes de capacité des périphériques. Les utilisateurs peuvent demander des portions de périphériques via ResourceClaims, et l'état du périphérique peut inclure des informations dynamiques comme les adresses IP. Cette amélioration prend en charge la mise en réseau sensible à la bande passante et le partage de périphériques multi-locataires, améliorant la planification et le contrôle des ressources. Le blog encourage l'expérimentation et les commentaires pour affiner davantage DRA.

Kubernetes v1.34 introduit une fonctionnalité alpha offrant un aperçu de l'état du matériel spécialisé tel que les GPU utilisés dans les Pods. Cette nouvelle fonctionnalité, basée sur KEP-4680, étend les pilotes de Dynamic Resource Allocation (DRA). L'état de santé des périphériques est désormais signalé directement dans le champ de statut d'un Pod via DRA. L'exposition de l'état de santé des périphériques aide les utilisateurs à diagnostiquer rapidement les problèmes dans les applications stateful ou les tâches de longue durée. Cela permet aux opérateurs et aux développeurs d'identifier les défaillances matérielles sous-jacentes. Ceci est réalisé grâce à un nouveau service de santé gRPC défini dans le groupe d'API dra-health. Le Kubelet s'intègre aux pilotes DRA, stockant les mises à jour de santé dans un cache. Le statut du Pod est mis à jour lorsqu'un changement d'état de santé d'un périphérique survient, se reflétant dans le champ `allocatedResourcesStatus`. Cela permet aux utilisateurs d'identifier les défaillances matérielles en inspectant le statut d'un Pod à l'aide de `kubectl`. Pour utiliser la fonctionnalité, le feature gate `ResourceHealthStatus` doit être activé. Les améliorations prévues comprennent des messages de santé détaillés et des délais configurables. La communauté Kubernetes vise à améliorer la gestion des défaillances matérielles et accueille les commentaires des utilisateurs.

Kubernetes a introduit les instantanés de groupe de volumes en tant que fonctionnalité Alpha, passant en Beta et maintenant à une deuxième version Beta. Cette fonctionnalité fournit des instantanés cohérents en cas de crash pour un groupe de volumes via des API d'extension. Kubernetes utilise des sélecteurs de labels pour regrouper les PersistentVolumeClaims pour la création d'instantanés, dans le but de restaurer la charge de travail à partir d'un instantané. La fonctionnalité repose sur les pilotes de volume CSI pour l'implémentation. La récente version Beta 2 corrige un problème avec le champ restoreSize lorsque le pilote CSI ne dispose pas de l'appel RPC ListSnapshots. L'API v1beta2 introduit la structure VolumeSnapshotInfo et VolumeSnapshotInfoList pour des informations détaillées sur les instantanés. Les objets v1beta1 existants seront convertis en v1beta2 à l'aide d'un webhook de conversion. Le projet vise la disponibilité générale (GA) en fonction des commentaires et de l'adoption de la communauté. Des ressources sont fournies pour un apprentissage plus approfondi, notamment la spécification de conception, le référentiel de code et la documentation CSI. La communauté accueille de nouveaux contributeurs au SIG de stockage Kubernetes et au groupe de travail sur la protection des données.

L'amélioration sépare la gestion du cycle de vie des nœuds et l'expulsion des pods en composants distincts. Auparavant, le contrôleur du cycle de vie des nœuds gérait à la fois le marquage des nœuds comme non sains et l'expulsion des pods. Désormais, un contrôleur d'expulsion de taint dédié gère les expulsions de pods. Le contrôleur du cycle de vie des nœuds est uniquement responsable de l'application des taints aux nœuds non sains. Cette séparation améliore l'organisation du code et facilite la personnalisation de l'expulsion basée sur les taints. Le portail de fonctionnalités SeparateTaintEvictionController est passé en disponibilité générale. Les utilisateurs peuvent désactiver l'expulsion basée sur les taints en configurant le kube-controller-manager. Des détails supplémentaires sont disponibles dans le KEP et l'annonce bêta. Les développeurs reconnaissent les contributions significatives de nombreuses personnes pour rendre cette fonctionnalité stable.

La configuration du pilote cgroup a toujours été un problème complexe pour les utilisateurs de Kubernetes. Les systèmes Linux utilisent deux pilotes cgroup : cgroupfs et systemd. Auparavant, le kubelet et l'implémentation CRI, tels que containerd ou CRI-O, devaient être configurés de manière identique pour éviter les dysfonctionnements du kubelet sans messages d'erreur clairs. Cela causait souvent une frustration considérable pour les administrateurs de cluster. Dans Kubernetes v1.28.0, le feature gate KubeletCgroupDriverFromCRI a été introduit. Cela permet au kubelet d'interroger l'implémentation CRI pour son pilote cgroup préféré. Après plusieurs cycles de publication, cette fonctionnalité a maintenant atteint la disponibilité générale (GA) dans Kubernetes 1.34.0. Pour l'utiliser, les administrateurs doivent s'assurer que leur implémentation CRI est suffisamment mise à jour. Containerd nécessite la version v2.0.0 ou ultérieure, tandis que CRI-O nécessite la version v1.28.0 ou ultérieure. Kubernetes déprécie le support des versions v1.y de containerd. Bien que les versions de CRI-O soient alignées sur les versions de Kubernetes, containerd a son propre cycle de publication, avec son support de fonctionnalités présent uniquement dans les versions v2.0 et supérieures. Kubernetes 1.34 prend toujours en charge les anciennes versions LTS de containerd comme v1.7. La communauté SIG Node de Kubernetes a défini un calendrier pour l'abandon progressif du support des versions v1.y de containerd. La dernière version de Kubernetes à inclure ce support sera la version finale de v1.35, le support se terminant dans v1.36.0. Pour faciliter cette transition, une métrique appelée kubelet_cri_losing_support peut être surveillée. Si cette métrique indique une version de containerd de 1.36.0, cela signale que le runtime containerd est obsolète pour les exigences à venir. Les administrateurs doivent mettre à niveau containerd vers la version v2.0 ou une version plus récente avant ou en même temps que la mise à niveau du kubelet vers v1.36.0.

La capacité des pilotes CSI à mettre à jour les décomptes de volumes attachables sur les nœuds est passée d'Alpha à Beta dans Kubernetes v1.34. Cette fonctionnalité vise à améliorer la précision de la planification des pods stateful. Auparavant, les pilotes CSI signalaient des limites de volume statiques, qui pouvaient devenir obsolètes. Les raisons de ces informations obsolètes incluent les opérations de volume externes, la consommation d'emplacements par le matériel et les interactions multi-pilotes. Cette inexactitude pouvait entraîner l'échec du démarrage des pods et leur blocage dans un état ContainerCreating. La nouvelle fonctionnalité permet aux pilotes CSI de signaler dynamiquement les capacités d'attachement des nœuds à l'exécution. Kubernetes prend désormais en charge deux mécanismes de mise à jour : des actualisations périodiques et des mises à jour immédiates en cas d'échec d'attachement. Pour activer cette fonctionnalité Beta, le portillon de fonctionnalité MutableCSINodeAllocatableCount doit être activé sur kube-apiserver et kubelet. Les pilotes CSI peuvent être configurés avec un nodeAllocatableUpdatePeriodSeconds pour les mises à jour périodiques, avec un intervalle minimum appliqué. Les mises à jour immédiates sont déclenchées par des erreurs ResourceExhausted lors des attachements de volumes, empêchant les pods de subir des échecs permanents. Il est encouragé aux utilisateurs d'activer et de tester cette fonctionnalité dans la v1.34 et de fournir des commentaires pour sa progression vers la disponibilité générale.