EN
en direct

Kubernetes 1.38 entre en bêta cette semaine avec 86 améliorations et quinze feature-gates retirées

La première bêta de Kubernetes 1.38 sort le 4 novembre 2026, avant un gel du code le 17 novembre et une disponibilité générale le 16 décembre. Quinze feature-gates sont retirées et cinq verrouillées : auditez vos drapeaux et vos manifestes maintenant, car un composant qui reçoit une gate inconnue refuse de démarrer.

Une lame de serveur à moitié sortie d’un rack dense de lames identiques, une unique LED d’activité ambre allumée sur sa façade.

4 novembre 2026. Kubernetes 1.38 publie sa première bêta, v1.38.0-beta.0. 17 novembre 2026. Le gel du code fige la liste des fonctionnalités. 16 décembre 2026. La version stable 1.38.0 est attendue, avec 86 améliorations au compteur. Pourquoi c’est important : ce cycle est d’abord une version de nettoyage — quinze feature-gates disparaissent et cinq sont verrouillées — et la première bêta est le moment où les équipes doivent vérifier leurs drapeaux, pas le jour de la sortie stable.

Quinze feature-gates retirées, cinq verrouillées

Le piège classique d’une montée de version se joue avant même le redémarrage du cluster. Un composant Kubernetes qui reçoit via --feature-gates le nom d’une gate qu’il ne connaît plus refuse de démarrer. Autrement dit : la première chose à faire n’est pas de lire les nouveautés, mais de passer en revue ses propres drapeaux.

Les quinze gates retirées en 1.38 couvrent des fonctions passées en stable ou abandonnées. Parmi elles : DynamicResourceAllocation, NFTablesProxyMode, PodSchedulingReadiness, SeparateTaintEvictionController, MatchLabelKeysInPodAffinity, CustomResourceFieldSelectors, MultiCIDRServiceAllocator, KubeletTracing, ServiceAccountTokenPodNodeInfo ou encore WindowsHostNetwork. Le changelog en nomme neuf ; les six autres se déduisent en comparant la liste de référence versioned_feature_list.yaml du tronc avec v1.37.0.

En face, cinq gates sont verrouillées sur « on » : StrictIPCIDRValidation, DRADeviceTaints, DRADeviceTaintRules, EnvFiles et HPAGeneration. Là aussi, la sanction est binaire : poser une gate verrouillée à false est une erreur de démarrage. Les deux listes se traitent de la même façon, avec un simple grep sur les fichiers de configuration et les manifestes de kubeadm.

bash
# Inventaire des feature-gates encore utilisées dans la configuration
# (à lancer AVANT la montée en version 1.38) :
grep -R "feature-gates" /etc/kubernetes/ 2>/dev/null
grep -R "featureGates" --include="*.yaml" --include="*.yml" .
# Toute gate retirée ou verrouillée doit être supprimée ou mise à true.

Ce qui monte en bêta

Les fonctionnalités les plus utiles sont déjà visibles en alpha dans 1.37 et passent en bêta : elles restent derrière une gate, mais la sortie approche.

La stratégie Recreate pour les StatefulSet. Un déploiement qui tombe sur un pod bloqué en ImagePullBackOff s’arrête jusqu’à ce qu’un humain supprime le pod à la main. Avec updateStrategy.type: Recreate, le contrôleur supprime tous les anciens pods, attend leur terminaison, puis crée la nouvelle révision — au prix d’un temps d’arrêt, mais les PVC sont conservés. C’est la réponse au cas classique où l’on corrige le template sans pouvoir débloquer le rollout.

Le gang scheduling pour les Jobs. Un Job pourra porter spec.scheduling pour demander que tous ses pods soient placés ensemble — ou aucun. Le contrôleur de Job crée lui-même les objets Workload et PodGroup. Utile pour les charges de type entraînement distribué, où placer trois pods sur quatre ne sert à rien. À tester sur un cluster dédié, car la gate active le comportement pour chaque Job sans owner.

Les signaux d’arrêt dans la spec du pod. lifecycle.stopSignal permet d’envoyer SIGUSR1 ou SIGQUIT à la fermeture sans reconstruire l’image ni écrire un hook preStop. L’API rejette le champ si spec.os.name n’est pas renseigné, et un runtime trop ancien l’acceptera puis l’ignorera.

Des sondes HTTP/2 et gRPC en TLS. Deux champs évitent d’ouvrir un second port pour les health checks : protocol: HTTP2 sur une sonde httpGet envoie du HTTP/2 en clair, et mode: TLS sur une sonde grpc se connecte en TLS — sans vérifier le certificat. À réserver aux cas où le port de santé est déjà chiffré.

Le mode des volumes et le propriétaire des fichiers. emptyDir.mode offre un /tmp avec les bons droits sans conteneur d’init qui lance un chmod, et defaultUser sur les volumes Secret, ConfigMap, downward API et projected écrit les fichiers sous l’UID choisi — précieux pour les logiciels qui exigent de posséder leur fichier de clé. Enfin, defaultPodSysctls dans la configuration du kubelet applique des sysctls namespacés à chaque nouveau pod du nœud, au lieu de les recopier dans chaque spec.

Les alphas à surveiller de loin

Rien de tout cela n’était encore fusionné début octobre, et les gates citées n’existent dans aucun build publié : ne les ajoutez pas prématurément à --feature-gates, une gate inconnue arrête le composant.

Deux entrées méritent l’attention : pids dans spec.resources pour plafonner les processus par pod sans toucher au podPidsLimit du nœud, et ephemeral-storage au niveau du pod pour dimensionner le disque local une seule fois. À côté, un syncPeriodSeconds configurable par HPA — de 3 à 3 600 secondes — pour réconcilier un autoscaler plus vite qu’un autre, au lieu du drapeau global de 15 secondes. Le reste est plus exotique : profils seccomp tirés d’un registre OCI, ulimits par conteneur, ou pods sans réseau du tout (defaultNetwork: None).

Ce qu’il faut vérifier avant la montée de version

Au-delà des gates, trois changements de comportement cassent des configurations discrètement.

La validation stricte des IP et des CIDR devient obligatoire. StrictIPCIDRValidation est verrouillé sur « on » et passe en GA avec KEP-4858 : les adresses IPv4 à zéro de tête (010.0.0.1) et les adresses IPv6 mappées IPv4 (::ffff:1.2.3.4) sont rejetées. Les objets existants passent par la validation « ratcheting », mais les templates qui créent de nouvelles ressources sous ces formes échoueront.

Le LimitRanger compare désormais les quantités exactement. Une requête de 0.9999 face à un minimum de 1 arrondissait jusqu’ici et passait ; elle est maintenant rejetée. Cela vaut pour la création de pods et de PVC, et pour leurs mises à jour et redimensionnements.

Enfin, kube-apiserver renvoie désormais un objet JSON Status pour les chemins inconnus situés sous /apis/, au lieu du corps texte 404 page not found — tout client qui faisait une correspondance sur cette chaîne doit être revu. Et côté dépendances : Go 1.27.1, etcd 3.7.1 par défaut, CoreDNS 1.14.7, et un kubelet désormais compilé sans CGO par défaut.

Verdict

Si vous exploitez un cluster en production, ne changez rien de spectaculaire cette semaine : la bêta du 4 novembre est le signal pour auditer — grep sur les feature-gates, vérification des templates qui créent des adresses IP à zéro de tête, revue des quantités passées au LimitRanger. Si vous maintenez des extensions ou des plugins, lisez la liste des quinze gates retirées et des cinq verrouillées avant tout test : c’est là que les démarrages échouent en premier. Si vous êtes curieux des nouveautés, montez un cluster de test pour le gang scheduling des Jobs et la stratégie Recreate des StatefulSet — ce sont les deux fonctions qui changent le plus le quotidien des équipes qui font tourner de l’entraînement distribué ou des déploiements à état. Le code freeze du 17 novembre arrive vite : tout ce qui n’est pas fusionné ce jour-là glisse vers 1.39.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

GitHub Actions bloque pull_request_target par défaut dans les dépôts publics le 2 décembre

Le 2 novembre 2026, GitHub annonce que l’événement pull_request_target sera bloqué par défaut dans tous les dépôts publics à partir du 2 décembre, après deux brownouts les 9 et 16 novembre. Les équipes qui dépendent de ce déclencheur pour accéder aux secrets du dépôt de base doivent l’autoriser explicitement via une politique d’événement Actions avant l’échéance.

Kubernetes Gateway API 1.7 promeut les retries HTTPRoute au canal Standard

Le 29 octobre 2026, la Gateway API Kubernetes livre sa version 1.7.0 : la configuration des retries HTTPRoute passe au canal Standard, pendant que le tracing distribué, les filtres de pré-routage et la persistance de session arrivent en expérimental. Les équipes qui exposent du trafic via plusieurs implémentations de gateway doivent reprendre leurs annotations de retry et leur politique de télémetrie avant la montée de version.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer