Blog Kubernetes RSS - TheNote.app

Blog Kubernetes RSS
Suivre

La page d'accueil officielle de Kubernetes, un système d'orchestration de conteneurs pour automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Cette plateforme propose une documentation exhaustive sur Kubernetes, un projet maintenu par la Cloud Native Computing Foundation. Elle comprend des informations sur l'exécution d'applications sans état et avec état, de travaux de batch et de flux de travail CI/CD à l'aide de Kubernetes. Le site inclut des guides détaillés, des tutoriels, des matériaux de référence, de la documentation API et des initiatives d'engagement communautaire pour aider les utilisateurs à commencer avec Kubernetes et à exploiter ses fonctionnalités de manière efficace pour gérer les applications basées sur le cloud de manière efficiente.

Kubernetes Blog kubernetes.io

RSS kubernetes.io

RSS Hunter • 22 août 2024

Fil de notes

Introduction du plugin Headlamp pour Karpenter - Mise à l'échelle et visibilité

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.

Introducing Headlamp Plugin for Karpenter - Scaling and Visibility kubernetes.io

RSS Hunter • 6 oct. 2025

Annonce de la prise en charge de l'API de suivi des blocs modifiés (alpha)

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.

Announcing Changed Block Tracking API support (alpha) kubernetes.io

RSS Hunter • 25 sept. 2025

Kubernetes v1.34 : Les ressources au niveau du Pod passent en bêta

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: Pod Level Resources Graduated to Beta kubernetes.io

RSS Hunter • 22 sept. 2025

Kubernetes v1.34 : Récupération après l'échec de l'expansion de volume (GA)

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.

Kubernetes v1.34: Recovery From Volume Expansion Failure (GA) kubernetes.io

RSS Hunter • 19 sept. 2025

Kubernetes v1.34 : Capacité consommable DRA

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: DRA Consumable Capacity kubernetes.io

RSS Hunter • 18 sept. 2025

Kubernetes v1.34 : Les pods signalent l'état des ressources 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 v1.34: Pods Report DRA Resource Health kubernetes.io

RSS Hunter • 17 sept. 2025

Kubernetes v1.34 : Déplacement des instantanés de groupe de volumes vers v1beta2

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.

Kubernetes v1.34: Moving Volume Group Snapshots to v1beta2 kubernetes.io

RSS Hunter • 16 sept. 2025

Kubernetes v1.34 : Le gestionnaire de taint découplé est maintenant stable

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.

Kubernetes v1.34: Decoupled Taint Manager Is Now Stable kubernetes.io

RSS Hunter • 15 sept. 2025

Kubernetes v1.34 : Autoconfiguration du pilote cgroup de nœud passe en disponibilité générale

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.

Kubernetes v1.34: Autoconfiguration for Node Cgroup Driver Goes GA kubernetes.io

RSS Hunter • 12 sept. 2025

Kubernetes v1.34 : Le provisionnement de nœuds CSI modifiables passe en bêta

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.

Kubernetes v1.34: Mutable CSI Node Allocatable Graduates to Beta kubernetes.io

RSS Hunter • 11 sept. 2025

Kubernetes v1.34 : Utiliser un conteneur d'initialisation pour définir les variables d'environnement de l'application

Kubernetes utilise traditionnellement les ConfigMaps et les Secrets pour les variables d'environnement, ce qui ajoute de la complexité et des appels d'API supplémentaires. Gérer les Pods et leurs configurations séparément, en particulier lors des mises à jour, peut être difficile. Cela est particulièrement vrai lorsqu'il s'agit de conteneurs de fournisseurs nécessitant des variables d'environnement sans vouloir les coder en dur ou utiliser des montages de volumes.Une nouvelle fonctionnalité alpha appelée EnvFiles offre une solution alternative pour ces scénarios. Si la fonctionnalité EnvFiles est activée, le kubelet peut charger les variables d'environnement d'un conteneur directement à partir d'un fichier dans un volume emptyDir. Cela élimine le besoin de monter le fichier dans le conteneur lui-même. La fonctionnalité principale permet à Kubernetes d'analyser un fichier, souvent généré par un initContainer, et de définir des variables d'environnement pour le conteneur principal au démarrage.Le fichier réside dans un volume emptyDir, qui est un stockage temporaire d'une durée de vie du pod. Le conteneur principal n'a pas besoin de monter ce volume ; le kubelet gère la lecture du fichier et l'injection des variables. La définition de ces variables implique l'utilisation du champ fileKeyRef dans la spécification du pod, en spécifiant le chemin du fichier et la clé à extraire.Le format de fichier prend en charge une syntaxe KEY=VALUE, et pour cette phase alpha, il doit être écrit dans un volume emptyDir. Un init container est requis pour écrire le fichier dans le volume emptyDir, mais le conteneur de l'application principale n'a pas besoin d'accéder au volume. Bien que cette fonctionnalité puisse gérer des données sensibles, il est important de noter que les opérateurs de nœuds ayant accès au système de fichiers pourraient potentiellement récupérer ces données à partir des volumes emptyDir. Par conséquent, des politiques de sécurité de cluster robustes sont essentielles pour protéger les nœuds contre tout accès non autorisé lors du stockage d'informations sensibles. Cette fonctionnalité EnvFiles simplifie la création d'applications et permet de nouveaux cas d'utilisation en réduisant les solutions de contournement complexes.

Kubernetes v1.34: Use An Init Container To Define App Environment Variables kubernetes.io

RSS Hunter • 10 sept. 2025

Kubernetes v1.34 : Cache du serveur d'API avec possibilité de snapshot

Kubernetes a considérablement amélioré la stabilité et les performances du serveur API en résolvant les problèmes liés aux requêtes de liste. Une avancée majeure est le cache du serveur API avec prise d'instantanés, désormais en version bêta dans la v1.34, permettant de servir la plupart des requêtes de lecture directement à partir de la mémoire du serveur API. Cette fonctionnalité s'appuie sur des améliorations précédentes telles que les lectures cohérentes à partir du cache de surveillance, introduites dans la v1.31, qui ont permis aux collections filtrées de contourner etcd. Dans la v1.33, des encodeurs de streaming ont été ajoutés pour gérer efficacement les réponses volumineuses en envoyant les éléments individuellement, évitant ainsi les pics de mémoire. Le cache avec prise d'instantanés comble le dernier vide en permettant aux requêtes LIST historiques, couramment utilisées pour la pagination, d'être également servies à partir du cache. Il fonctionne en créant des instantanés légers et économes en mémoire de l'état du cache pour chaque mise à jour. Lorsqu'une requête historique arrive, le serveur API récupère l'instantané pertinent et sert les données directement à partir de la mémoire. Cette synergie de fonctionnalités réduit considérablement la pression sur la mémoire du serveur API et la charge sur etcd. Par conséquent, les plans de contrôle Kubernetes sont désormais plus stables, évolutifs et fiables. La fonctionnalité SnapshottableCache est activée par défaut dans Kubernetes v1.34, ne nécessitant aucune action de l'utilisateur pour bénéficier de ces améliorations.

Kubernetes v1.34: Snapshottable API server cache kubernetes.io

RSS Hunter • 9 sept. 2025

Kubernetes v1.34 : VolumeAttributesClass pour la modification de volume GA

L'API VolumeAttributesClass est désormais disponible en version générale dans Kubernetes v1.34, permettant la modification dynamique des attributs de volume. Cette ressource à l'échelle du cluster agit comme un profil, permettant aux administrateurs de définir différents niveaux de QoS ou de performance de stockage. Les utilisateurs sélectionnent le profil souhaité via un volumeAttributesClassName dans leur PersistentVolumeClaim. Le pilote Container Storage Interface (CSI) applique ensuite ces modifications au système de stockage sous-jacent. Cela facilite la mise à l'échelle dynamique des performances, l'optimisation des coûts grâce à des ajustements à la volée et des opérations simplifiées en gérant les modifications au sein de l'API Kubernetes. La version GA introduit la prise en charge de l'annulation des erreurs non réalisables, empêchant les états de volume incohérents. Elle permet également l'application de quotas sur les PVC référençant des VolumeAttributesClasses spécifiques à l'aide de sélecteurs de portée ResourceQuota. Le pilote CSI Amazon EBS et le pilote CSI Google Compute Engine Persistent Disk prennent tous deux en charge ces modifications dynamiques d'attributs. Pour toute question, les utilisateurs sont invités à contacter la communauté SIG Storage.

Kubernetes v1.34: VolumeAttributesClass for Volume Modification GA kubernetes.io

RSS Hunter • 8 sept. 2025

Kubernetes v1.34 : La politique de remplacement des pods pour les Jobs passe en GA

La fonctionnalité de politique de remplacement des Pods pour les Jobs Kubernetes est désormais disponible en version générale. Par défaut, les Jobs remplacent immédiatement les Pods en cours de terminaison ou ayant échoué, ce qui peut potentiellement dépasser le parallélisme. Cela peut causer des problèmes pour les applications qui attendent des instances uniques par index, comme certains frameworks d'apprentissage automatique. Cela peut également entraîner des retards de planification, une mise à l'échelle inutile et des contournements temporaires des quotas. La nouvelle fonctionnalité permet aux utilisateurs de contrôler ce comportement avec le champ .spec.podReplacementPolicy. La politique TerminatingOrFailed, qui est la valeur par défaut, recrée les Pods dès qu'ils commencent à se terminer. La politique Failed, cependant, ne crée un nouveau Pod qu'après que l'ancien se soit complètement terminé et soit passé à la phase Failed. Pour les Jobs avec une politique d'échec de Pod, la politique de remplacement Failed est obligatoire. L'état des Pods en cours de terminaison peut être vérifié en utilisant kubectl get job myjob -o=jsonpath='{.status.terminating}'. Un exemple montre comment la définition de la politique sur Failed empêche le démarrage d'un nouveau Pod tant que le Pod en cours de terminaison n'est pas complètement terminé. Cette amélioration vise à fournir un contrôle plus robuste sur la gestion du cycle de vie des Pods des Jobs.

Kubernetes v1.34: Pod Replacement Policy for Jobs Goes GA kubernetes.io

RSS Hunter • 5 sept. 2025

Les indicateurs PSI pour les diplômés de Kubernetes passent en version bêta

"Kubernetes v1.34 a promu les métriques Pressure Stall Information (PSI) en version Beta, offrant un outil essentiel pour surveiller la santé des nœuds dans les clusters en croissance. PSI, une fonctionnalité du noyau Linux, quantifie la pression sur les ressources en mesurant le temps d'attente des tâches dû à la contention, plutôt que simplement l'utilisation. Il fournit des métriques pour le CPU, la mémoire et les E/S, catégorisées comme pression "partielle" (au moins une tâche en attente) ou pression "totale" (toutes les tâches non inactives en attente). Ces métriques sont disponibles sur des fenêtres glissantes de 10 secondes, 1 minute et 5 minutes. La fonctionnalité KubeletPSI permet au kubelet de collecter et d'exposer les métriques PSI via l'API Summary et le point de terminaison Prometheus /metrics/cadvisor. De nouvelles métriques Prometheus telles que container_pressure_cpu_stalled_seconds_total sont désormais accessibles. Ces métriques aident à identifier les fuites de mémoire, à optimiser les requêtes de ressources et à déclencher l'autoscaling. Pour activer PSI, les nœuds doivent exécuter le noyau Linux 4.20+ avec cgroup v2, et la fonctionnalité KubeletPSI doit être activée. Les métriques PSI sont spécifiques à Linux et ne sont pas disponibles sur les nœuds Windows. Cette fonctionnalité bêta est activement développée et les commentaires sont encouragés."

PSI Metrics for Kubernetes Graduates to Beta kubernetes.io

RSS Hunter • 4 sept. 2025

Kubernetes v1.34 : L'intégration des jetons de compte de service pour les extractions d'images passe en Beta

Kubernetes v1.34 promeut l'intégration des jetons de compte de service pour les fournisseurs d'informations d'identification Kubelet en version bêta. Cette amélioration permet aux fournisseurs d'informations d'identification d'utiliser des jetons de compte de service spécifiques à la charge de travail pour les informations d'identification du registre, remplaçant les secrets d'extraction d'image à longue durée de vie. La version bêta introduit un champ cacheType obligatoire pour les configurations des fournisseurs d'informations d'identification. Deux stratégies de mise en cache sont disponibles : Token, pour les informations d'identification liées à la durée de vie du jeton, et ServiceAccount, pour les informations d'identification valables pour tous les pods utilisant le même compte de service. La version bêta fournit également une isolation de sécurité améliorée, garantissant que les pods ne peuvent accéder qu'aux images tirées à l'aide de leurs ServiceAccounts autorisés. Ce système suit l'identité du compte de service et la vérifie lorsqu'un module utilise une image mise en cache. Les administrateurs peuvent révoquer l'accès aux images en supprimant et en recréant les comptes de service. Cette fonctionnalité s'appuie sur la restriction de l'audience du nœud du compte de service pour les demandes de jetons sécurisés. Pour utiliser la fonctionnalité bêta, assurez-vous que Kubernetes v1.34 ou plus récent et mettez à jour les fournisseurs d'informations d'identification. La migration à partir de la version alpha nécessite l'ajout du champ cacheType et la révision des stratégies de mise en cache. La communauté Kubernetes souhaite recevoir des commentaires sur cette fonctionnalité, en particulier de la part des fournisseurs d'informations d'identification. Un développement plus poussé et la collecte de commentaires sont prévus pour les prochaines versions.

Kubernetes v1.34: Service Account Token Integration for Image Pulls Graduates to Beta kubernetes.io

RSS Hunter • 3 sept. 2025

Kubernetes v1.34 : Présentation de l’option de stratégie statique du gestionnaire de processeur pour l’alignement du cache uncore

Kubernetes v1.34 introduit la fonctionnalité bêta prefer-align-cpus-by-uncorecache pour la stratégie statique CPU Manager. Cette option optimise les charges de travail sur les processeurs avec des architectures de cache non core divisées. Le cache non core, également connu sous le nom de cache de dernier niveau, est partagé entre les cœurs de processeur. Les processeurs modernes utilisent des caches uncore divisés pour réduire la latence en divisant le cache entre les groupes de processeurs. Cette fonctionnalité permet à Kubernetes de placer les processeurs de conteneur dans le même cache non core, ce qui minimise la latence et les contentions. Ce placement prenant en charge le cache améliore le débit des applications sensibles. Par défaut, Kubernetes utilise une méthodologie compressée, ce qui peut entraîner des problèmes de voisinage bruyants et une latence entre caches. L’activation de cette fonctionnalité isole les conteneurs dans des caches individuels, ce qui résout les conflits. Les cas d’utilisation incluent les applications de télécommunications telles que vRAN, mais les avantages dépendent de la charge de travail, en particulier pour les applications liées à la bande passante mémoire. Pour l’activer, définissez la stratégie du Gestionnaire de processeur sur statique et activez CPUManagerPolicyBetaOptions. La configuration implique la modification du fichier de configuration kubelet pour définir la politique et les options. La fonctionnalité fonctionne sur les processeurs de cache monolithiques uncore en imitant l’alignement des sockets.

Kubernetes v1.34: Introducing CPU Manager Static Policy Option for Uncore Cache Alignment kubernetes.io

RSS Hunter • 2 sept. 2025

Kubernetes v1.34 : DRA est passé en disponibilité générale (GA)

Kubernetes 1.34 apporte des améliorations significatives à l'allocation dynamique des ressources (DRA). La fonctionnalité principale de DRA est passée à la disponibilité générale, ce qui la rend stable et prête pour une adoption à long terme. DRA permet une gestion flexible du matériel spécialisé comme les GPU en permettant aux charges de travail de spécifier les besoins en périphériques et en laissant le planificateur allouer les périphériques réels. DRA étant désormais disponible en version générale, il est activé par défaut, de même que les fonctionnalités précédemment en version bêta.Plusieurs fonctionnalités sont passées en version bêta, notamment l'étiquetage de l'accès administrateur pour empêcher les utilisateurs autorisés d'utiliser à mauvais escient des fonctionnalités spécifiques. Les listes de priorités permettent aux charges de travail de spécifier plusieurs alternatives de périphériques acceptables pour une planification plus flexible. L'API kubelet a été mise à jour pour signaler les ressources Pod allouées par DRA, ce qui améliore la surveillance des nœuds.De nouvelles fonctionnalités alpha offrent un aperçu de l'avenir de DRA. Le mappage des ressources étendues prend en charge la publicité des ressources gérées par DRA en tant que ressources étendues, ce qui simplifie la consommation pour les charges de travail existantes. La capacité consommable introduit un partage flexible des périphériques, permettant à plusieurs pods non liés de partager un seul périphérique physique sur la base de politiques définies par l'administrateur. Les conditions de liaison améliorent la fiabilité de l'ordonnancement en retardant la liaison des pods jusqu'à ce que les ressources externes soient confirmées comme étant prêtes. Enfin, l'état de santé des ressources pour DRA améliore l'observabilité en exposant l'état de santé des appareils via l'état des pods. L'équipe prévoit d'apporter d'autres fonctionnalités alpha et bêta à GA dans les prochaines versions.

Kubernetes v1.34: DRA has graduated to GA kubernetes.io

RSS Hunter • 1 sept. 2025

Kubernetes v1.34 : Contrôle plus précis des redémarrages de conteneurs

Kubernetes 1.34 introduit une fonctionnalité alpha appelée Stratégie et Règles de Redémarrage de Conteneur. Cette fonctionnalité permet un contrôle individuel sur les redémarrages de conteneurs au sein d'un Pod, remplaçant la stratégie de redémarrage globale du Pod. Elle permet également des redémarrages conditionnels pour les conteneurs en fonction de leurs codes de sortie. Auparavant, tous les conteneurs dans un Pod partageaient une seule stratégie de redémarrage. Cette limitation empêchait des scénarios tels que celui d'avoir un conteneur d'initialisation qui s'exécute une seule fois tandis que le conteneur d'application principale redémarre toujours. La nouvelle fonctionnalité, activée par la porte de fonctionnalité alpha ContainerRestartRules, résout ce problème en permettant des stratégies et règles de redémarrage par conteneur. Les cas d'utilisation incluent les redémarrages sur place pour les travaux d'entraînement avec des codes de sortie spécifiques, les conteneurs d'initialisation à essai unique et les Pods avec plusieurs conteneurs ayant des besoins de redémarrage différents. Pour utiliser cette fonctionnalité, la porte de fonctionnalité ContainerRestartRules doit être activée. Des exemples démontrent comment configurer les redémarrages en fonction de codes de sortie spécifiques, mettre en œuvre des conteneurs d'initialisation à essai unique et attribuer des stratégies de redémarrage différentes à plusieurs conteneurs. Cette fonctionnalité alpha accueille les commentaires de la communauté et est développée par SIG Node. Les plans futurs incluent le support pour le redémarrage de Pods entiers.

Kubernetes v1.34: Finer-Grained Control Over Container Restarts kubernetes.io

RSS Hunter • 29 août 2025

Kubernetes v1.34 : Les préférences utilisateur (kuberc) sont disponibles pour les tests dans kubectl 1.34

Les préférences de l'utilisateur kubectl atteignent maintenant la version bêta dans Kubernetes v1.34, offrant des options de personnalisation. Cette fonctionnalité permet aux utilisateurs de définir des paramètres personnalisés pour les commandes kubectl. Un fichier de préférences de l'utilisateur, généralement nommé kuberc, est situé dans le répertoire de configuration kube par défaut, $HOME/.kube. Ce fichier utilise une structure apiVersion et kind similaire à celle des manifestes Kubernetes. La section des valeurs par défaut permet de définir des valeurs par défaut pour les options de commandes kubectl, comme utiliser toujours la suppression interactive. Ces valeurs par défaut peuvent être remplacées en fournissant explicitement des options différentes lors de l'exécution de la commande. Une autre valeur par défaut recommandée est d'activer l'application côté serveur pour les commandes kubectl apply. La section des alias permet aux utilisateurs de créer des raccourcis pour les commandes fréquemment utilisées, économisant du temps et de l'effort. Les alias peuvent être définis pour mapper des commandes kubectl spécifiques avec des arguments et des options pré définis. Le mécanisme prend en charge à la fois la préfixation et la postfixation d'arguments à la commande kubectl sous-jacente. Les informations de débogage pour cette fonctionnalité peuvent être accessibles avec une verbosité accrue, comme en utilisant -v=5. Les commentaires des utilisateurs sont très encouragés tandis que la fonctionnalité mûrit, et les utilisateurs peuvent contribuer via Slack, les problèmes GitHub ou les réunions de la communauté.

Kubernetes v1.34: User preferences (kuberc) are available for testing in kubectl 1.34 kubernetes.io

RSS Hunter • 28 août 2025

Kubernetes v1.34 : Du Vent et de la Volonté (O' WaW)

La version v1.34 de Kubernetes, sur le thème "Of Wind & Will", introduit 58 améliorations, dont 23 atteignent le statut stable. L'allocation dynamique de ressources (DRA) pour la gestion des périphériques est désormais généralement disponible, permettant une sélection et une configuration des périphériques plus flexibles. Les jetons Projected ServiceAccount pour les fournisseurs d'identification d'images kubelet offrent une sécurité accrue en utilisant des jetons à courte durée de vie et spécifiques à la charge de travail. Un nouveau format de sortie, KYAML, est introduit en tant que fonctionnalité alpha pour kubectl, visant un YAML plus sûr et moins ambigu pour Kubernetes. Les contrôleurs de Jobs disposent désormais de la création de Pods de remplacement retardée pour éviter l'exécution simultanée et la contention des ressources. La récupération des échecs d'extension de volume est stable, permettant aux utilisateurs d'annuler et de réessayer les extensions de volume. VolumeAttributesClass est également stable, fournissant une API native Kubernetes pour modifier les paramètres de volume. La configuration structurée de l'authentification est désormais stable, améliorant la gestion et l'auditabilité de l'authentification des clients du serveur d'API. L'autorisation plus granulaire basée sur des sélecteurs améliore la sécurité et permet des règles de moindre privilège. Les requêtes anonymes peuvent être restreintes à des points de terminaison spécifiques, améliorant la sécurité sans perturber les sondes externes. La remise en file d'attente plus efficace des Pods non planifiables réduit les nouvelles tentatives inutiles et améliore le débit de planification. La suppression ordonnée des namespaces garantit une suppression déterministe et sécurisée des ressources, atténuant les risques de sécurité. Les réponses de liste en streaming améliorent la scalabilité en réduisant la pression sur la mémoire du serveur d'API. L'initialisation résiliente du cache de surveillance améliore la robustesse du plan de contrôle en rendant le processus d'initialisation du cache de surveillance plus résistant aux échecs.

Kubernetes v1.34: Of Wind & Will (O' WaW) kubernetes.io

RSS Hunter • 27 août 2025

Réglage de la mémoire d'échange Linux pour Kubernetes : une plongée en profondeur

La fonctionnalité NodeSwap de Kubernetes, qui devrait bientôt devenir stable, permet aux nœuds Linux d'utiliser l'espace d'échange pour obtenir une mémoire virtuelle supplémentaire. Cela vise à améliorer l'utilisation des ressources et à réduire les arrêts dus à une erreur de mémoire (OOM) lorsque la RAM physique est épuisée. Cependant, son efficacité dépend de la mise à jour de paramètres spécifiques du noyau Linux tels que vm.swappiness, vm.min_free_kbytes et vm.watermark_scale_factor. Le paramètre vm.swappiness contrôle la préférence du noyau entre l'échange de mémoire anonyme et la récupération de mémoire à base de fichiers. vm.min_free_kbytes agit comme un tampon de sécurité, influençant le moment où commence la récupération de pages agressive. vm.watermark_scale_factor ajuste l'écart entre les repères de mémoire libres, affectant la fenêtre d'échange. Les tests ont révélé que les paramètres du noyau par défaut peuvent entraîner des arrêts OOM et des redémarrages de nœud sous pression de mémoire. Augmenter vm.min_free_kbytes et vm.watermark_scale_factor s'est avéré crucial pour éviter les évictions prématurées et les arrêts OOM en donnant au noyau plus de temps pour échanger. Une swappiness plus élevée peut entraîner une attente I/O significative, tandis qu'une swappiness plus faible priorise la suppression du cache de fichiers. La mise à jour appropriée de ces paramètres, ainsi que des seuils d'éviction de Kubelet, crée une stratégie d'équilibre pour la gestion de la pression de mémoire. Les risques incluent une dégradation des performances due à un accès lent à l'espace d'échange et la dissimulation de fuites de mémoire.

Tuning Linux Swap for Kubernetes: A Deep Dive kubernetes.io

RSS Hunter • 19 août 2025

Présentation de l'assistant Headlamp IA

Headlamp a lancé un plugin d'assistant AI pour simplifier la gestion et la dépannage de Kubernetes. Cet outil exploite les modèles de langage naturel de grande taille pour permettre aux utilisateurs de poser des questions et de donner des commandes en langage naturel. L'assistant AI fournit des informations rapides, permettant aux utilisateurs de comprendre l'état du cluster et de diagnostiquer les problèmes avec des requêtes simples. Il offre des réponses ciblées et pertinentes en fonction de la vue actuelle de l'utilisateur dans l'interface Headlamp. De plus, l'assistant est orienté vers l'action, capable d'exécuter des tâches comme redémarrer des déploiements avec la permission de l'utilisateur. L'intégration utilise le contexte de ce que l'utilisateur est en train de voir pour fournir une assistance plus humaine. Par exemple, il peut identifier la cause racine d'un pod en échec et suggérer des corrections. L'assistant inclut également une prise en charge d'un outil Kubernetes pour récupérer des données et exécuter des actions sans nécessiter de basculement de vue. Les versions futures prévoient d'intégrer avec d'autres plugins Headlamp pour obtenir des informations plus riches dans des domaines tels que GitOps et la surveillance. Les utilisateurs peuvent installer l'assistant AI à partir du catalogue de plugins Headlamp ou via son image de conteneur. Les développeurs encouragent les utilisateurs à essayer la version précoce et à fournir des commentaires.

Introducing Headlamp AI Assistant kubernetes.io

RSS Hunter • 7 août 2025

Aperçu de Kubernetes v1.34

Kubernetes v1.34 est prévue pour être publiée à la fin août 2025. Cette version à venir ne introduira aucune suppression ou dépréciation, mais proposera de nombreuses améliorations. Un point fort est la cible de l'allocation de ressources dynamique (DRA) pour le statut stable. La DRA offre une méthode flexible pour gérer les périphériques comme les GPU au sein des clusters Kubernetes. L'intégration des jetons de compte de service pour les fournisseurs d'informations d'identification kubelet devrait atteindre le statut bêta, simplifiant l'authentification de téléchargement d'images. Une nouvelle fonctionnalité alpha pour les déploiements introduira une stratégie de remplacement de pod (podReplacementPolicy) pour contrôler la création de pod pendant les mises à jour. La traçabilité prête pour la production pour le kubelet et le serveur API, utilisant OpenTelemetry, est également censée atteindre le statut stable. Le champ trafficDistribution dans les services gagnera les valeurs PreferSameZone et PreferSameNode, visant le statut bêta. Un nouveau format de sortie, KYAML, un dialecte YAML plus sécurisé conçu pour Kubernetes, est attendu pour kubectl. Enfin, le contrôle d'autoscaling fin sera amélioré avec une tolérance configurable pour les autoscaleurs de pod horizontaux (HPA), passant au statut bêta.

Kubernetes v1.34 Sneak Peek kubernetes.io

RSS Hunter • 28 juil. 2025

Cryptographie post-quantique dans Kubernetes

La cryptographie post-quantique (CPQ) est une réponse à la menace que les ordinateurs quantiques font peser sur les normes cryptographiques actuelles. Les algorithmes CPQ sont conçus pour être sécurisés contre les attaques des ordinateurs classiques et quantiques. L'industrie travaille à standardiser et à adopter les algorithmes CPQ, le premier algorithme standardisé étant le mécanisme d'encapsulation de clés Module-Lattice (ML-KEM). La transition vers les normes CPQ est attendue entre 2030 et 2035. Dans TLS, l'échange de clés et les signatures numériques sont deux opérations cryptographiques principales qui doivent être sécurisées, l'échange de clés étant une priorité plus élevée en raison du risque d'attaques. Les mécanismes d'échange de clés hybrides, qui combinent des algorithmes classiques et CPQ, sont adoptés pour sécuriser l'échange de clés. Le soutien aux mécanismes d'échange de clés CPQ s'améliore rapidement à travers l'écosystème, avec Go, les navigateurs, OpenSSL et Apple ajoutant tous leur soutien au schéma hybride basé sur ML-KEM. Kubernetes v1.33, qui utilise Go 1.24, prend en charge par défaut l'échange de clés post-quantique hybride X25519MLKEM768 pour les connexions TLS, ce qui constitue un pas important vers la sécurisation quantique de Kubernetes. Cependant, il existe encore des limitations et des pièges potentiels, tels que les incompatibilités de version Go et les problèmes de taille de paquet, qui doivent être abordés. Les signatures numériques CPQ sont encore au stade précoce du développement et de l'adoption, avec des défis tels que les tailles de clés et de signatures plus grandes, les problèmes de performance et le soutien limité des outils.

Post-Quantum Cryptography in Kubernetes kubernetes.io

RSS Hunter • 18 juil. 2025

Naviguer les échecs dans les pods avec des appareils

Kubernetes fait face à des défis pour gérer les défaillances matérielles spécialisées dans les charges de travail d'apprentissage automatique et d'apprentissage profond (AI/ML). Ces charges de travail dépendent lourdement de GPU et d'autres accélérateurs, et les défaillances ont un impact significatif sur les performances. Le modèle Kubernetes existant suppose des ressources statiques, manquant de soutien robuste pour les défaillances matérielles. Les charges de travail d'AI/ML, notamment l'apprentissage et l'inférence, diffèrent significativement des applications traditionnelles dans leurs besoins en ressources et les implications de défaillance. Les travaux d'apprentissage sont intensifs en ressources et nécessitent des redémarrages coordonnés en cas de défaillance, tandis que les tâches d'inférence exigent une opération continue. Les hypothèses existantes de Kubernetes, comme le remplacement facile des ressources et la mise à l'échelle simple des pods, sont insuffisantes pour ces scénarios complexes. Malgré ces défis, Kubernetes demeure la plateforme préférée en raison de sa maturité et de son écosystème. Les solutions actuelles impliquent des contournements manuels, tels que des contrôleurs de santé personnalisés et des observateurs de pods, pour gérer les défaillances de périphériques. Ces solutions ont des limitations et nécessitent un accès privilégié, soulignant la nécessité d'une prise en charge native améliorée de Kubernetes. Le projet Kubernetes travaille activement à améliorer la gestion des défaillances de périphériques, visant à une meilleure fiabilité et une gestion des ressources.

Navigating Failures in Pods With Devices kubernetes.io

RSS Hunter • 3 juil. 2025

Compatibilité des images dans les environnements natifs du cloud

Dans des industries comme les télécommunications et l'informatique haute performance, les applications conteneurisées nécessitent des configurations spécifiques du système d'exploitation ou la présence de matériel spécifique. Malgré l'initiative Open Container (OCI), il y avait un manque dans l'expression des exigences de compatibilité. Le projet de découverte de fonctionnalités de nœud (NFD) de Kubernetes résout ce problème en détectant et en signalant les fonctionnalités matérielles et système des nœuds du cluster. NFD aide à planifier les charges de travail sur les nœuds qui répondent à des exigences système spécifiques, ce qui est crucial pour les applications ayant des dépendances matérielles ou système strictes. Les images de conteneur construites sur des images de base peuvent avoir des problèmes de compatibilité avec le système d'exploitation hôte, se manifestant par des dépendances à des pilotes, des bibliothèques, des modules de noyau ou des fonctionnalités. La définition de la compatibilité peut s'étendre à d'autres technologies de conteneur et à des artefacts OCI. Le groupe de travail sur la compatibilité des images vise à introduire un standard pour les métadonnées de compatibilité des images, permettant aux auteurs de conteneur de déclarer les fonctionnalités du système d'exploitation hôte requises. La spécification, mise en œuvre dans la découverte de fonctionnalités de nœud Kubernetes, définit une manière structurée d'exprimer la compatibilité dans les manifestes d'image OCI. La solution intègre les métadonnées de compatibilité dans Kubernetes, permettant une planification intelligente et une optimisation des charges de travail. L'adoption des métadonnées de compatibilité améliorera la fiabilité et les performances des applications conteneurisées spécialisées.

Image Compatibility In Cloud Native Environments kubernetes.io

RSS Hunter • 25 juin 2025

Modifications du Slack de Kubernetes

Le Slack de Kubernetes perd son statut spécial et passera à un Slack gratuit standard le 20 juin. Plus tard cette année, notre communauté devrait migrer vers une nouvelle plateforme. Si vous êtes responsable d'un canal ou d'un canal privé, ou membre d'un groupe d'utilisateurs, vous devrez prendre certaines mesures dès que possible.Au cours de la dernière décennie, Slack a soutenu notre projet avec un compte d'entreprise personnalisé gratuit. Ils nous ont informés qu'ils ne pouvaient plus le faire, notamment parce que notre Slack est l'un des plus grands et des plus actifs sur la plateforme. Par conséquent, ils vont le dégrader à un Slack gratuit standard tandis que nous décidons et mettons en œuvre d'autres options.Le vendredi 20 juin, nous serons soumis aux limitations de fonctionnalités du Slack gratuit. Les principales limitations qui nous affecteront seront la conservation de seulement 90 jours d'historique et la nécessité de désactiver plusieurs applications et workflows que nous utilisons actuellement. L'équipe d'administration Slack fera de son mieux pour gérer ces limitations.Les propriétaires de canaux responsables, les membres de canaux privés et les membres de groupes d'utilisateurs devraient prendre certaines mesures pour se préparer à la mise à niveau et préserver les informations dès que possible.Le personnel des projets CNCF a proposé que notre communauté examine la migration vers Discord. En raison de problèmes existants où nous avons repoussé les limites de Slack, ils ont déjà exploré ce que serait un Discord de Kubernetes. Discord nous permettrait d'implémenter de nouveaux outils et intégrations qui aideraient la communauté, tels que la synchronisation des groupes de membres GitHub. Le comité de direction discutera et décidera de notre plateforme future.Veuillez voir notre FAQ, et vérifiez la liste de diffusion kubernetes-dev et le canal #annonces pour obtenir des nouvelles supplémentaires. Si vous avez des commentaires spécifiques sur le statut de notre Slack, rejoignez la discussion sur GitHub.

Changes to Kubernetes Slack kubernetes.io

RSS Hunter • 16 juin 2025

Amélioration de la gestion des événements Kubernetes avec une agrégation personnalisée

Les événements Kubernetes offrent des informations précieuses sur les opérations de cluster, mais la gestion et l'analyse deviennent difficiles lorsque les clusters grandissent. Les défis incluent le volume des événements, la rétention limitée, le manque de corrélation, de catégorisation et d'agrégation. Un système d'agrégation d'événements personnalisé peut aider les équipes d'ingénierie à mieux comprendre le comportement du cluster et à résoudre les problèmes de manière plus efficace. Le système se compose de trois composants principaux : un watcher d'événements, un processeur d'événements et un backend de stockage. Le watcher d'événements surveille l'API Kubernetes pour les nouveaux événements, le processeur d'événements traite, catégorise et corrèle les événements, et le backend de stockage stocke les événements traités pour une rétention plus longue. Le processeur d'événements enrichit les événements avec un contexte et une classification supplémentaires, et le backend de stockage prend en charge les requêtes d'interrogation efficaces de grands volumes d'événements, des politiques de rétention flexibles et le support des requêtes d'agrégation. La mise en œuvre de bonnes pratiques pour la gestion des événements, telles que l'efficacité des ressources, la scalabilité et la fiabilité, est cruciale. Des fonctionnalités avancées telles que la détection de modèles et les alertes en temps réel peuvent être mises en œuvre pour identifier les problèmes récurrents et y répondre de manière plus efficace. Un système d'agrégation d'événements bien conçu peut améliorer significativement la visibilité et les capacités de dépannage du cluster, et les améliorations futures pourraient inclure l'apprentissage automatique pour la détection d'anomalies, l'intégration avec des plateformes d'observabilité populaires et des API d'événements personnalisés pour les événements spécifiques à l'application.

Enhancing Kubernetes Event Management with Custom Aggregation kubernetes.io

RSS Hunter • 10 juin 2025

Présentation de l'extension d'inférence de l'API de passerelle

L'extension Inference API Gateway répond aux défis de routage de Kubernetes posés par les sessions d'inférence de grands modèles linguistiques (LLM) gourmandes en ressources et de longue durée. Les équilibreurs de charge traditionnels sont insuffisants pour ces charges de travail complexes. Cette extension améliore l'API Gateway existante avec des fonctionnalités spécifiques à l'inférence. Elle introduit deux ressources personnalisées (Custom Resources) : InferencePool, gérant les pods du serveur de modèles, et InferenceModel, définissant les points de terminaison des modèles accessibles aux utilisateurs. Le flux de requête implique un routage via Gateway, une extension de sélection de point de terminaison pour une sélection optimale des pods, et une planification tenant compte de l'inférence. Cela se traduit par un routage amélioré tenant compte du modèle. Les tests de performance montrent un débit comparable aux services Kubernetes standard, mais une latence significativement plus faible, en particulier à des taux de requête plus élevés. Les développements futurs incluent des fonctionnalités telles que l'équilibrage de charge tenant compte du cache de préfixe et la prise en charge de divers types de modèles et d'accélérateurs. L'extension simplifie et standardise le routage du trafic AI/ML au sein de Kubernetes. Elle vise à améliorer l'efficacité et l'expérience utilisateur dans le déploiement et la gestion des services LLM.

Introducing Gateway API Inference Extension kubernetes.io

RSS Hunter • 5 juin 2025

Démarrer Sidecar en premier : Comment éviter les problèmes

Cet article de blog explore comment s'assurer qu'un conteneur sidecar Kubernetes démarre et devienne prêt avant le conteneur principal de l'application. Les conteneurs sidecar natifs dans Kubernetes démarrent avant l'application principale, souvent presque simultanément, ce qui n'est pas toujours souhaité. L'auteur examine les sondes de préparation (readiness probes), les sondes de démarrage (startup probes) et les hooks de cycle de vie postStart pour retarder le démarrage de l'application principale jusqu'à ce que le sidecar soit prêt. L'utilisation d'une sonde de préparation seule ne retarde pas le démarrage de l'application principale. Une sonde de démarrage, correctement configurée, retarde efficacement l'application principale jusqu'à ce que le sidecar soit prêt. L'article mentionne également brièvement les hooks postStart comme option. Les sondes de vivacité (liveness probes) redémarrent principalement le sidecar et n'influencent pas la préparation de l'application principale. La principale conclusion est qu'une sonde de démarrage est la méthode la plus efficace pour retarder le démarrage de l'application principale. L'auteur conclut en soulignant l'importance de contrôler l'ordre de démarrage des conteneurs lorsque l'application principale dépend d'un sidecar. Cela offre une solution lorsque la modification du code de l'application n'est pas possible.

Start Sidecar First: How To Avoid Snags kubernetes.io

RSS Hunter • 3 juin 2025

API Gateway v1.3.0 : Avancées en matière de duplication de requêtes, de CORS, de fusion de passerelles et de budgets de tentatives.

La Gateway API v1.3.0, publiée le 24 avril 2025, introduit la duplication de requêtes basée sur un pourcentage dans le canal Standard. Cette fonctionnalité permet de dupliquer un sous-ensemble de requêtes, ce qui est utile pour les services à fort volume. La publication ajoute également des fonctionnalités expérimentales, notamment le filtrage CORS, un mécanisme standardisé pour la fusion des listeners et des gateways (XListenerSets), et les budgets de tentatives (XBackendTrafficPolicy). Les ressources du canal expérimental utilisent désormais le groupe d'API gateway.networking.x-k8s.io et incluent un préfixe "X". Le filtrage CORS permet de configurer les requêtes inter-origines avec le nouveau filtre "CORS". Les XListenerSets permettent le partage de listeners et la fusion de Gateways, améliorant ainsi la gestion des listeners. Les budgets de tentatives permettent aux utilisateurs de configurer les limites de tentatives en utilisant la XBackendTrafficPolicy. L'API est compatible avec Kubernetes 1.26 ou version ultérieure. Plusieurs implémentations sont déjà conformes aux nouvelles fonctionnalités. La communauté encourage l'implication de chacun dans la définition de l'avenir des APIs de routage Kubernetes.

Gateway API v1.3.0: Advancements in Request Mirroring, CORS, Gateway Merging, and Retry Budgets kubernetes.io

RSS Hunter • 2 juin 2025

Kubernetes v1.33 : Redimensionnement de pod in situ promu au statut bêta

Le projet Kubernetes a annoncé que la fonctionnalité de redimensionnement de Pod en place a atteint le stade de développement et sera activée par défaut dans la version Kubernetes v1.33. Cette fonctionnalité permet aux utilisateurs de modifier les ressources de mémoire et de processeur attribuées à un conteneur sans nécessiter de redémarrage du conteneur. Le redimensionnement de Pod en place débloque plusieurs avantages clés pour la mise à l'échelle verticale, notamment une réduction des perturbations, une amélioration de l'utilisation des ressources et une mise à l'échelle plus rapide. La fonctionnalité a subi des changements significatifs depuis sa sortie alpha, notamment l'introduction d'une sous-ressource de redimensionnement, le statut de redimensionnement via des conditions, ainsi que le support des sidecars. La stabilité et la fiabilité de la fonctionnalité ont été améliorées grâce à une gestion raffinée des ressources allouées, une mise en veille et une piste d'état améliorées, ainsi qu'une détection de redimensionnement plus rapide. La communauté se concentre sur les étapes suivantes, notamment la stabilité et la production, l'adressage des limitations et l'intégration avec VerticalPodAutoscaler. Les utilisateurs peuvent commencer à expérimenter le redimensionnement de Pod avec la fonctionnalité activée par défaut. Les commentaires sont essentiels, et les utilisateurs peuvent signaler tout problème ou partager leurs expériences via les problèmes GitHub, les listes de diffusion et Slack. Les détails de conception approfondis peuvent être trouvés dans le KEP-1287 : Mise à jour en place des ressources de Pod. La communauté Kubernetes est impatiente de voir comment les utilisateurs exploitent le redimensionnement de Pod en place pour construire des applications plus efficaces et résilientes.

Kubernetes v1.33: In-Place Pod Resize Graduated to Beta kubernetes.io

RSS Hunter • 16 mai 2025

Annonce d'etcd v3.6.0

L'équipe etcd a publié la version v3.6.0, la première version mineure depuis la v3.5.0, qui introduit de nouvelles fonctionnalités, fait progresser les efforts de longue date concernant la prise en charge de la rétrogradation et la migration vers v3store, et corrige de nombreux problèmes critiques et majeurs. Cette version inclut également des optimisations importantes de l'utilisation de la mémoire, améliorant ainsi l'efficacité et les performances. Etcd a rejoint Kubernetes en tant que SIG (Special Interest Group), permettant au projet d'améliorer sa durabilité. Des tests de robustesse systématiques ont été introduits pour garantir l'exactitude et la fiabilité. Le groupe de travail etcd-operator prévoit d'améliorer la convivialité. Le v2store a été déprécié et le v3store est devenu la seule source de vérité pour les données d'adhésion. Etcd v3.6.0 est la première version à prendre entièrement en charge la rétrogradation, et le processus implique la migration du schéma de données vers la version cible, suivie d'une rétrogradation progressive. La version introduit également des "feature gates" (portes de fonctionnalités) de type Kubernetes pour la gestion des nouvelles fonctionnalités, et prend en charge les endpoints /livez et /readyz, s'alignant ainsi sur les sondes de vivacité (Liveness) et de disponibilité (Readiness) de Kubernetes. La version a également amélioré l'utilisation de la mémoire d'au moins 50 % et a permis une amélioration moyenne des performances d'environ 10 % en termes de débit de lecture et d'écriture.

Announcing etcd v3.6.0 kubernetes.io

RSS Hunter • 16 mai 2025

Kubernetes 1.33 : le succès de JobPolicy passe à la disponibilité générale

Le projet Kubernetes a annoncé que la stratégie de réussite des tâches (Job) est désormais disponible en général (General Availability) dans le cadre de la version. Dans les charges de travail par lots, les utilisateurs peuvent vouloir marquer une tâche comme réussie même si certains followers échouent. La stratégie de réussite des tâches permet aux utilisateurs de spécifier des critères de sortie précoce en utilisant le champ .spec.successPolicy. Ce champ est particulièrement précieux pour les charges de travail de simulation scientifique, d'apprentissage automatique et de calcul haute performance. Les utilisateurs peuvent spécifier une taille minimale requise d'index réussis pour qu'une tâche soit considérée comme réussie. Une fois qu'une tâche les critères de réussite, elle est marquée comme réussie et tous les pods sont terminés. La stratégie de réussite peut être personnalisée pour spécifier un index ou un nombre d'index spécifique qui doivent réussir pour que la tâche soit marquée comme réussie. Le contrôleur de tâches ajoute une condition de critères de réussite atteints à l'état de la tâche une fois que la tâche atteint les critères de réussite, puis initie la suppression et la termination des pods. La tâche obtient une condition de complétion une fois que la suppression et la termination sont terminées.

Kubernetes 1.33: Job's SuccessPolicy Goes GA kubernetes.io

RSS Hunter • 15 mai 2025

Kubernetes v1.33 : Mises à jour du cycle de vie des conteneurs

Kubernetes v1.33 introduit des mises à jour du cycle de vie des conteneurs, notamment la prise en charge d'une durée de sommeil nulle dans les hooks du cycle de vie des conteneurs. L'action Sleep, introduite dans la version 1.29, permet aux conteneurs de se mettre en pause pendant une durée spécifiée après le démarrage ou avant la terminaison. Initialement, l'action Sleep ne prenait pas en charge une durée de sommeil nulle, mais cela a été ajouté dans la version 1.32 et est désormais activé par défaut dans la version 1.33. Kubernetes v1.33 introduit également une prise en charge alpha de la personnalisation du signal d'arrêt envoyé aux conteneurs lors de leur terminaison. Cela permet aux utilisateurs de spécifier un signal d'arrêt personnalisé dans la spécification du conteneur, qui est ajouté à l'API en tant que nouveau gestionnaire de cycle de vie. La configuration du signal d'arrêt est appliquée pour garantir qu'elle est valide pour le nœud sur lequel le Pod est planifié. Si aucun signal d'arrêt personnalisé n'est défini, l'environnement d'exécution du conteneur utilisera le signal d'arrêt défini dans l'image du conteneur ou le signal par défaut de l'environnement d'exécution. Cette fonctionnalité nécessite que Kubernetes et l'environnement d'exécution des conteneurs prennent en charge les signaux d'arrêt des conteneurs, ce qui est encore en cours de développement. Pour activer la fonctionnalité, les utilisateurs doivent activer la fonction "feature gate" dans le kube-apiserver et le kubelet. L'équipe SIG Node est à l'origine de cette fonctionnalité et se réjouit des commentaires, de la participation et de l'implication de la communauté.

Kubernetes v1.33: Updates to Container Lifecycle kubernetes.io

RSS Hunter • 14 mai 2025

Kubernetes v1.33 : la limite de réessai par index pour les travaux (Job) passe en disponibilité générale (GA)

Dans Kubernetes v1.33, la fonctionnalité de Limite de réessai par Index est devenue disponible généralement. Cette fonctionnalité permet aux utilisateurs de contrôler le nombre de réessais par index dans les travaux indexés. Auparavant, le champ spec.backoffLimit n'était pas suffisamment flexible pour les charges de travail où chaque index est considéré comme indépendant. La fonctionnalité de Limite de réessai par Index répond à cette limitation en spécifiant le nombre de défaillances de Pod tolérées par index. Le champ spec.backoffLimitPerIndex est utilisé pour spécifier le nombre de défaillances de Pod tolérées par index. En outre, les utilisateurs peuvent affiner la gestion des erreurs en spécifiant un plafond du nombre total d'index échoués et en définissant un court-circuit pour détecter un index échoué. Lorsque le nombre de défaillances tolérées est dépassé, l'index est marqué comme échoué et listé dans le champ status.failedIndexes du travail. Un exemple de spécification de travail démontre comment combiner la fonctionnalité de Limite de réessai par Index avec la fonctionnalité de Politique de défaillance de Pod. La fonctionnalité a été parrainée par le groupe de travail batch de Kubernetes et la communauté SIG Apps. Les utilisateurs intéressés par le travail sur de nouvelles fonctionnalités peuvent s'inscrire au canal et assister aux réunions communautaires régulières.

Kubernetes v1.33: Job's Backoff Limit Per Index Goes GA kubernetes.io

RSS Hunter • 13 mai 2025

Kubernetes v1.33 : La politique d'extraction d'image comme vous l'avez toujours imaginé !

La stratégie d'extraction d'image (imagePullPolicy) dans Kubernetes présente un comportement surprenant qui a été une faille de sécurité pendant plus de 10 ans, permettant aux pods d'accéder à des images authentifiées sans les fournir. La stratégie IfNotPresent permettait à un pod d'utiliser une image déjà présente sur un nœud, même si elle ne fournissait pas de crédentials pour extraire l'image. C'est une faille de sécurité car les pods sans crédentials peuvent accéder à des images privées. Dans Kubernetes v1.33, la stratégie IfNotPresent a été mise à jour pour s'assurer que les pods doivent fournir des crédentials pour utiliser une image privée déjà extraite. Le Kubelet vérifiera les crédentials du pod avant de lui permettre d'utiliser l'image. L'option imagePullPolicy: Never ne récupère pas les images, mais nécessite des crédentials pour utiliser une image déjà présente. L'option imagePullPolicy: Always a toujours fonctionné comme prévu, nécessitant une authentification pour chaque demande d'image. La nouvelle fonctionnalité utilise des caches persistants basés sur des fichiers sur chaque nœud pour vérifier les crédentials des pods. La fonctionnalité est basée sur l'enregistrement de l'intention d'extraire une image, l'extraction des crédentials et l'enregistrement des réussites des extractions. La fonctionnalité est disponible dans Kubernetes v1.33 et peut être activée en activant la porte de fonctionnalité KubeletEnsureSecretPulledImages.

Kubernetes v1.33: Image Pull Policy the way you always thought it worked! kubernetes.io

RSS Hunter • 12 mai 2025

Kubernetes v1.33 : Réponses de listes en flux

La gestion de la stabilité du cluster Kubernetes est cruciale lorsque l'infrastructure grandit, et la gestion des demandes de liste importantes peut impacter la stabilité du cluster. La communauté Kubernetes a introduit l'encodage en flux pour les réponses de liste pour résoudre le problème de consommation de mémoire inutile avec les ressources importantes. Les encodeurs de réponse API actuels conservent les données de réponse complète dans un tampon unique, empêchant la libération de mémoire incrémentale pendant la transmission. Cette approche devient inefficace à grande échelle, entraînant une consommation de mémoire élevée et prolongée dans le processus kube-apiserver. Les packages encoding/json et Protocol Buffers ont des limitations pour gérer les jeux de données importants, soulignant la nécessité d'approches basées sur le flux. L'encodeur de flux nouveau traite et transmet chaque élément individuellement, permettant la libération progressive de la mémoire à mesure que les trames ou les blocs sont transmis. Cette approche réduit l'empreinte mémoire requise par le serveur API et maintient la consommation de mémoire prévisible et gérable. L'encodeur de flux est conçu pour être compatible avec les versions précédentes, garantissant une cohérence byte-for-byte avec l'encodeur original, et prend en charge tous les types de liste sans nécessiter de modifications côté client. L'introduction de l'encodage en flux a entraîné des gains de performance significatifs, notamment une réduction de la consommation de mémoire, une amélioration de la scalabilité et une augmentation de la stabilité. Les résultats des benchmarks ont montré une amélioration de 20 fois dans l'utilisation de la mémoire, la réduisant de 70-80 Go à 3 Go, démontrant l'efficacité du nouveau mécanisme d'encodage en flux.

Kubernetes v1.33: Streaming List responses kubernetes.io

RSS Hunter • 9 mai 2025

Kubernetes 1.33 : Les populatrices de volume passent à la disponibilité générale

Les populateurs de volumes Kubernetes sont désormais généralement disponibles, permettant aux utilisateurs de spécifier n'importe quelle ressource personnalisée comme source de données d'un PersistentVolumeClaim (PVC). Le mécanisme de contrôle des fonctionnalités AnyVolumeDataSource est considéré comme toujours activé pour Kubernetes v1.33. Le champ dataSourceRef dans un PVC permet aux utilisateurs de spécifier une ressource personnalisée comme source de données. Quatre améliorations majeures ont été apportées depuis la version bêta : la possibilité de rendre le pod populateur optionnel, l'introduction de fonctions basées sur des plugins, l'ajout de fonctions de mutation pour modifier les ressources Kubernetes, et une gestion flexible des métriques pour les fournisseurs. La version GA améliore également le populateur pour prendre en charge la suppression des ressources temporaires si le PVC original est supprimé. Pour l'essayer, les utilisateurs peuvent suivre les étapes décrites dans le précédent billet de blog sur la version bêta. Le groupe d'intérêt Kubernetes SIG Storage recherche des commentaires sur les améliorations fonctionnelles potentielles, notamment la synchronisation multiple, la synchronisation bidirectionnelle, la population de données avec des priorités et la population de données à partir de plusieurs sources.

Kubernetes 1.33: Volume Populators Graduate to GA kubernetes.io

RSS Hunter • 8 mai 2025

Kubernetes v1.33 : Des Secrets aux Comptes de Service : L'évolution des Pull d'Images Kubernetes

"Kubernetes évolue pour réduire sa dépendance aux identifiants de longue durée stockés dans l'API, avec un exemple notable étant la transition des jetons de compte de service Kubernetes (Service Account tokens) de jetons statiques à des jetons éphémères avec une sémantique conforme à OpenID Connect. Cependant, une lacune majeure subsiste dans l'authentification de l'extraction d'images (image pull), où les clusters Kubernetes s'appuient actuellement sur des secrets d'extraction d'images de longue durée ou sur des fournisseurs d'identifiants kubelet au niveau du nœud. Cela présente des défis de sécurité et opérationnels, car les secrets d'extraction d'images sont difficiles à faire tourner (rotation) et leur compromission peut entraîner un accès non autorisé aux images. Pour résoudre ce problème, Kubernetes introduit l'intégration des jetons de compte de service pour les fournisseurs d'identifiants Kubelet (Service Account Token Integration for Kubelet Credential Providers), qui permet aux fournisseurs d'identifiants d'utiliser des jetons de compte de service spécifiques aux pods pour obtenir des identifiants de registre. Cette amélioration élimine le besoin de secrets d'extraction d'images de longue durée et fournit une authentification spécifique à la charge de travail, des identifiants éphémères et une intégration transparente avec les mécanismes d'authentification Kubernetes existants. La nouvelle approche permet aux fournisseurs d'identifiants kubelet d'utiliser l'identité de la charge de travail (workload identity) lors de la récupération des identifiants du registre d'images, offrant des avantages tels que la sécurité, un contrôle d'accès granulaire et une simplicité opérationnelle. La fonctionnalité est actuellement disponible en alpha et devrait être livrée en version bêta pour Kubernetes v1.34, avec un développement ultérieur axé sur la mise en œuvre de mécanismes de mise en cache et l'amélioration de la flexibilité pour les fournisseurs d'identifiants. Les utilisateurs peuvent essayer la fonctionnalité en activant le "feature gate" ServiceAccountTokenForKubeletCredentialProviders et en modifiant leur fournisseur d'identifiants pour utiliser les jetons de compte de service pour l'authentification. La communauté Kubernetes accueille les commentaires et encourage les utilisateurs à s'impliquer dans le développement de cette fonctionnalité via le canal SIG Auth sur Kubernetes Slack."

Kubernetes v1.33: From Secrets to Service Accounts: Kubernetes Image Pulls Evolved kubernetes.io

RSS Hunter • 7 mai 2025

Kubernetes v1.33 : Le contrôle précis des SupplementalGroups passe en version bêta

Kubernetes a introduit une nouvelle fonctionnalité appelée supplementalGroupsPolicy, qui permet un contrôle plus précis des groupes supplémentaires dans les conteneurs, améliorant ainsi la posture de sécurité et la transparence des détails UID/GID. Cette fonctionnalité est passée de la phase alpha à la phase bêta dans Kubernetes v1.33. Elle permet la mise en œuvre d'un contrôle plus précis des groupes supplémentaires dans les conteneurs, en particulier pour l'accès aux volumes. Par défaut, Kubernetes fusionne les informations de groupe du Pod avec les informations définies dans /etc/group dans l'image du conteneur, ce qui peut entraîner des risques de sécurité. Le champ supplementalGroupsPolicy dans le contexte de sécurité du Pod permet de contrôler la façon dont Kubernetes calcule les groupes supplémentaires pour les processus de conteneur au sein d'un Pod. La politique Strict ignore les appartenances aux groupes définies dans /etc/group pour l'utilisateur principal du conteneur, garantissant que seuls les ID de groupe spécifiés sont attachés en tant que groupes supplémentaires aux processus du conteneur. Cette fonctionnalité expose également l'identité du processus attaché au premier processus du conteneur via le champ .status.containerStatuses[].user.linux. La politique supplementalGroupsPolicy n'affecte que l'identité du processus initial, et un conteneur disposant de privilèges suffisants peut modifier son identité de processus. La politique Strict nécessite un runtime CRI qui prend en charge cette fonctionnalité, tel que containerd v2.0 ou ultérieur, et CRI-O v1.31 ou ultérieur.

Kubernetes v1.33: Fine-grained SupplementalGroups Control Graduates to Beta kubernetes.io

RSS Hunter • 6 mai 2025

Kubernetes v1.33 : Empêcher les fuites de Volume Persistant lors de la suppression hors ordre passe à la disponibilité générale

Kubernetes v1.33 a vu une fonctionnalité passer à la disponibilité générale (GA) pour éviter les fuites de volumes persistants (PV) lors de la suppression dans le désordre. Cette fonctionnalité assure que les ressources de stockage sont récupérées correctement, empêchant les fuites indésirables. Dans les versions précédentes de Kubernetes, la suppression d'un PV avant son PVC lié empêchait la politique de réclamation d'être respectée. Cela signifiait que la ressource de stockage associée dans l'infrastructure externe n'était pas supprimée. Avec Kubernetes v1.33, ce problème est maintenant résolu, et la politique de suppression configurée est fiablement respectée, même lorsque les PV sont supprimés avant leurs PVC liés. Cela est rendu possible par l'utilisation de finalisateurs, garantissant que le backend de stockage libère la ressource de stockage allouée comme prévu. Pour les volumes CSI, un finalisateur est ajouté aux nouveaux et anciens PV, qui n'est supprimé qu'après que la suppression du stockage du backend. Cette fonctionnalité ne s'applique pas aux volumes de plugin en arbre statiquement provisionnés. Pour bénéficier du nouveau comportement, les utilisateurs doivent mettre à jour leur cluster vers Kubernetes v1.33 et exécuter la version 5.0.1 ou ultérieure du provisionneur externe CSI. Le groupe d'intérêt Kubernetes Storage (SIG) accueille de nouveaux contributeurs pour s'impliquer dans la conception et le développement de CSI ou de la partie du système de stockage Kubernetes.

Kubernetes v1.33: Prevent PersistentVolume Leaks When Deleting out of Order graduates to GA kubernetes.io

RSS Hunter • 5 mai 2025

Kubernetes v1.33 : Comptage mutable CSI des noeuds attribuables

Kubernetes v1.33 introduit une fonctionnalité alpha appelée comptage mutable des allocations de nœud CSI, permettant aux pilotes CSI de mettre à jour dynamiquement le maximum de volumes qu'un nœud peut gérer. Cette fonctionnalité améliore l'exactitude des décisions d'ordonnancement des pods et réduit les échecs d'ordonnancement. Traditionnellement, les pilotes CSI signalent une limite de volume d'attachement statique, qui peut changer au cours du cycle de vie d'un nœud en raison de diverses raisons. La signalisation statique peut causer Kubernetes à planifier des pods sur des nœuds qui semblent avoir une capacité, ce qui fait que les pods restent dans un état de création de conteneur. Avec la nouvelle porte de fonctionnalité MutableCSINodeAllocatableCount, Kubernetes permet aux pilotes CSI d'ajuster et de signaler les capacités d'attachement de nœud à l'exécution. Cela garantit que le planificateur a la vue la plus précise et la plus à jour de la capacité du nœud. La fonctionnalité prend en charge deux mécanismes pour mettre à jour les limites de volume de nœud signalées : les mises à jour périodiques et les mises à jour réactives. Pour utiliser cette fonctionnalité alpha, vous devez activer la porte de fonctionnalité MutableCSINodeAllocatableCount dans les composants kube-apiserver et kubelet. La communauté Kubernetes accueille les commentaires sur cette fonctionnalité et encourage les tests et les discussions pour façonner son évolution vers une stabilité beta et GA.

Kubernetes v1.33: Mutable CSI Node Allocatable Count kubernetes.io

RSS Hunter • 2 mai 2025

Kubernetes v1.33 : Nouvelles fonctionnalités dans DRA

L'allocation de ressources dynamique Kubernetes (DRA) approche de la disponibilité générale, ciblée pour la version v1.34. Initialement une fonctionnalité alpha dans la version v1.26, la DRA a subi une révision pour la version v1.31 et a atteint le stade bêta dans la version v1.32. La DRA offre une API plus robuste et adaptable pour les demandes de périphériques par rapport au plug-in de périphérique. La version v1.33 voit le statut de revendication de ressource propriétaire du pilote promu au stade bêta, permettant des rapports de statut de périphérique spécifiques au pilote. Les nouvelles fonctionnalités alpha dans la version v1.33 comprennent les périphériques partitionnables pour le partitionnement de périphériques à la demande, les tâches et les tolérances pour marquer la disponibilité des périphériques, et la liste priorisée pour spécifier les préférences de périphériques. L'accès administrateur a été raffiné, restreignant la création d'objets de revendication de ressource avec le champ d'accès administrateur aux utilisateurs autorisés. Une nouvelle API v1beta2 améliore l'expérience utilisateur et prépare les fonctionnalités futures. Les règles RBAC améliorées et les mises à jour de pilote DRA sans heurt sont également incluses. La feuille de route v1.34 vise à rendre la DRA disponible par défaut sur tous les clusters v1.34. Les fonctionnalités alpha de la version v1.33 sont prévues pour être promues au stade bêta dans la version v1.34. L'implication de la communauté est encouragée par le canal Slack WG Device Management et les réunions.

Kubernetes v1.33: New features in DRA kubernetes.io

RSS Hunter • 1 mai 2025

Kubernetes v1.33 : Évaluation de la capacité de stockage des nœuds pour la provision dynamique

Kubernetes v1.33 introduit StorageCapacityScoring, une fonctionnalité alpha de provisionnement de volume sensible à la topologie. Cette fonctionnalité permet la planification des pods en fonction de la capacité de stockage des nœuds, en priorisant les nœuds avec le plus ou le moins d'espace disponible. Auparavant, il n'était possible que de filtrer les nœuds avec une capacité insuffisante, nécessitant des extensions de planificateur pour la planification basée sur la capacité. StorageCapacityScoring améliore la provision de PV locaux en attribuant des PV aux nœuds avec suffisamment d'espace pour une expansion future. Elle facilite également la réduction des coûts dans les environnements cloud en maximisant l'utilisation des ressources et en remplissant les nœuds séquentiellement. Pour activer cette fonctionnalité, définissez StorageCapacityScoring=true dans les portes de fonctionnalités du planificateur kube-scheduler. Le paramètre VolumeBinding configure les priorités des nœuds en fonction de l'utilisation du stockage. Par défaut, les nœuds avec une capacité disponible plus élevée sont priorisés, mais cela peut être inversé. Cette nouvelle fonctionnalité remplace la fonctionnalité alpha dépréciée VolumeCapacityPriority, qui priorisait les nœuds avec une capacité disponible plus faible lors de la provision statique. La documentation fournit des détails supplémentaires et des exemples de configuration. Reportez-vous à KEP-4049 pour obtenir des informations plus approfondies.

Kubernetes v1.33: Storage Capacity Scoring of Nodes for Dynamic Provisioning (alpha) kubernetes.io

RSS Hunter • 30 avr. 2025

Kubernetes v1.33 : Les volumes d'images passent en phase bêta !

Les volumes d'image Kubernetes, introduits en version alpha dans la v1.31, passent en version bêta dans la v1.33. La fonctionnalité reste désactivée par défaut en raison d'un support limité des runtimes de conteneurs. CRI-O v1.31 offre un support initial, avec un support bêta prévu dans la v1.33, tandis que le support alpha de containerd arrive dans la v2.1.0, la version bêta étant en cours de développement. Les principales améliorations de la version bêta incluent la prise en charge de subPath et subPathExpr pour le montage en lecture seule de sous-répertoires spécifiques d'images. Les sous-répertoires inexistants ne peuvent pas être montés, et Kubernetes valide les chemins pour la sécurité. Les runtimes doivent également vérifier les chemins, signalant les erreurs via les événements kubelet. Trois nouvelles métriques kubelet suivent les demandes de volumes d'image, les montages réussis et les erreurs de montage. Les utilisateurs peuvent spécifier subPath ou subPathExpr dans volumeMounts pour monter des sous-répertoires existants. Un exemple illustre le montage d'un sous-répertoire nommé dir au sein d'un pod. Cet article de blog célèbre le passage de la fonctionnalité en version bêta, en remerciant les contributeurs et en encourageant les commentaires via Slack ou la liste de diffusion SIG Node. Des ressources de lecture complémentaires sur l'utilisation des volumes d'image avec les pods et une vue d'ensemble des volumes d'image sont disponibles.

Kubernetes v1.33: Image Volumes graduate to beta! kubernetes.io

RSS Hunter • 29 avr. 2025

Kubernetes v1.33 : Tolérance configurable pour l'HorizontalPodAutoscaler

Kubernetes 1.33 introduit une tolérance configurable pour le Horizontal Pod Autoscaling (HPA), une fonctionnalité alpha permettant un comportement d'adaptation personnalisé. Le HPA ajuste automatiquement le nombre de réplicas en fonction de l'utilisation des ressources, visant une valeur cible comme 75% d'utilisation du CPU. Auparavant, une tolérance fixe de 10% empêchait l'adaptation due aux petites fluctuations des métriques. Ce seuil par défaut de 10% à l'échelle du cluster s'avérait souvent trop grossier pour les déploiements importants. La nouvelle fonctionnalité permet de spécifier la tolérance dans spec.behavior.scaleDown et spec.behavior.scaleUp au sein de l'objet HorizontalPodAutoscaler. Cela permet d'avoir des tolérances différentes pour l'augmentation et la diminution d'échelle, offrant un contrôle plus fin. Un cas d'utilisation courant est de définir une tolérance plus faible pour l'augmentation d'échelle, assurant une réponse rapide aux pics d'activité, tandis qu'une tolérance plus élevée pour la diminution d'échelle empêche les ajustements fréquents du nombre de réplicas. L'activation du gate de fonctionnalité HPAConfigurableTolerance est nécessaire pour utiliser cette fonctionnalité. Un exemple de configuration montre une tolérance de 5% pour la diminution d'échelle et de 0% pour l'augmentation d'échelle. Des détails techniques supplémentaires sont disponibles dans le KEP-4951, et l'issue 4951 suit la progression de la fonctionnalité vers sa disponibilité générale.

Kubernetes v1.33: HorizontalPodAutoscaler Configurable Tolerance kubernetes.io

RSS Hunter • 28 avr. 2025

Kubernetes v1.33 : les espaces de noms d'utilisateur activés par défaut !

Kubernetes v1.33 active maintenant les espaces de noms d'utilisateur par défaut, améliorant la sécurité des pods. Les espaces de noms d'utilisateur, une fonctionnalité du noyau Linux distincte des espaces de noms Kubernetes, isolent les UID et GID des conteneurs du hôte. Cette isolation empêche les mouvements latéraux entre les conteneurs et améliore la sécurité de l'hôte même si un conteneur s'échappe. L'activation des espaces de noms d'utilisateur permet d'exécuter des applications nécessitant des opérations privilégiées sans accorder un accès racine complet à l'hôte. Les pods optent pour les espaces de noms d'utilisateur en définissant hostUsers: false dans la spécification du pod. La fonctionnalité nécessite des systèmes de fichiers prenant en charge les montages idmap, une fonctionnalité du noyau Linux simplifiant la mise en correspondance des UID/GID. Bien qu'une version de noyau 6.3 ou supérieure soit recommandée pour une prise en charge complète, les noyaux plus anciens peuvent fonctionner avec des limitations. Les espaces de noms d'utilisateur atténuent de nombreux CVE en empêchant les privilèges root sur l'hôte même si un conteneur est compromis. Cela améliore significativement la sécurité en limitant l'impact des évasions de conteneur et en renforçant la protection du système dans son ensemble. Des informations et des ressources supplémentaires sont disponibles pour une compréhension et une mise en œuvre plus approfondies.

Kubernetes v1.33: User Namespaces enabled by default! kubernetes.io

RSS Hunter • 25 avr. 2025

Poursuivant la transition des Endpoints vers les EndpointSlices

"L'API Endpoints de Kubernetes est maintenant dépréciée à partir de la version 1.33, avec des avertissements émis pour son utilisation, car les EndpointSlices offrent plus de fonctionnalités. Les nouvelles fonctionnalités de service comme la mise en réseau dual-stack ne sont prises en charge que par les EndpointSlices. Le plan est d'éventuellement supprimer l'exigence pour les clusters de exécuter le contrôleur Endpoints. Les utilisateurs ayant des workloads API Endpoints existants devraient migrer vers les EndpointSlices. Contrairement aux Endpoints, un service peut avoir plusieurs EndpointSlices, notamment pour la mise en réseau dual-stack ou lorsqu'il dépasse 100 points de terminaison. Les EndpointSlices sont récupérés par étiquette, et non par nom, en utilisant "kubernetes.io/service-name". La génération d'EndpointSlices implique l'utilisation du nouveau type d'API et l'organisation des informations de manière différente. Les EndpointSlices nécessitent une déclaration explicite du type d'adresse (IPv4 ou IPv6). Chaque tableau d'adresses dans un EndpointSlice contient, par convention, un seul élément. L'API EndpointSlice fournit des conditions comme "prêt : faux" pour les points de terminaison et prend en charge les indices de topologie."

Continuing the transition from Endpoints to EndpointSlices kubernetes.io

RSS Hunter • 24 avr. 2025