Catégorie : Kubernetes

Si tu administres des clusters Kubernetes depuis un poste Windows, une ligne dans le changelog du 28 septembre a de bonnes chances de te concerner directement : kubectl cp peut écrire des fichiers en dehors du dossier que tu lui as donné comme destination. Pas besoin d’un cluster mal configuré ni d’un bug exotique côté serveur — juste un conteneur dont tu n’es pas totalement sûr, et un client kubectl pas encore à jour.

Ce que dit l’avis de sécurité

La faille porte la référence CVE-2026-19444, un CVSS v3.1 de 6.5 (vecteur AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N) selon le Kubernetes Security Response Committee. Elle a été signalée par la chercheuse Moriel Harush et corrigée avec Marly Salazar, Maciej Szulik et Vyom Yadav, suivie sous le ticket #141294 et publiée dans l’annonce officielle de sécurité Kubernetes du 28 septembre 2026.

Un détail change tout dans ce dossier : seuls les clients kubectl tournant sous Windows sont touchés. Linux et macOS en sont indemnes, pas parce qu’ils ont été corrigés plus tôt, mais parce que le mécanisme d’extraction qui pose problème est spécifique à Windows.

Le mécanisme : un tar qui ne fait pas ce qu’on croit

kubectl cp ne lit pas directement les fichiers du conteneur. Il lance un tar à l’intérieur du conteneur pour construire une archive, qui est ensuite transférée puis dépaquetée sur ta machine. Tout le problème tient dans cette confiance implicite : si le binaire tar du conteneur est malveillant (ou simplement remplacé), il peut fabriquer une archive dont les chemins internes sortent du dossier de destination une fois extraite côté Windows. Résultat : une écriture de fichier arbitraire, limitée uniquement par les droits du compte Windows qui exécute la commande.

Ce n’est pas un problème côté API server, côté etcd, ni côté kubelet — rien à corriger sur ton cluster. La faille vit entièrement dans le binaire client que tu lances depuis ton poste ou ton agent CI.

Versions concernées et correctifs

Trois branches sont touchées, chacune avec sa version corrigée :

• 1.34.0 à 1.34.11 → corrigé en 1.34.12
• 1.35.0 à 1.35.8 → corrigé en 1.35.9
• 1.36.0 à 1.36.4 → corrigé en 1.36.5

La branche 1.37 n’apparaît pas dans la liste des versions affectées : elle est sortie après le correctif. Dans tous les cas, la bonne pratique reste de garder kubectl dans une version proche de celle du control plane — pas une raison de plus pour sauter trois versions mineures d’un coup.

kubectl version --client

Cette commande suffit à savoir si un poste ou un agent est exposé. Fais-la tourner sur chaque machine Windows qui touche à un cluster, pas seulement sur le poste que tu utilises au quotidien.

Qui est vraiment exposé

Sur le papier, un CVSS de 6.5 n’a rien d’alarmant — il faut une interaction utilisateur et des privilèges élevés côté attaquant pour que l’exploitation ait un sens. Dans la pratique, trois scénarios rendent ce correctif prioritaire plutôt qu’optionnel :

• Un cluster multi-tenant, où tu n’as pas un contrôle total sur le contenu de chaque pod que tu peux être amené à inspecter.
• Un agent CI Windows qui copie des artefacts depuis des conteneurs de build, potentiellement issus d’un repository externe ou d’une pull request non fiable.
• Une investigation incident response, où tu copies justement le contenu d’un pod compromis pour l’analyser — le pire moment pour découvrir que l’outil d’analyse lui-même peut être retourné contre toi.

Dans les trois cas, le point commun, c’est que tu utilises kubectl cp sur un contenu dont tu n’as pas la certitude qu’il est sain. C’est précisément la situation que cette faille cible.

Ce qu’il faut faire, dans l’ordre

1. Inventorie tous les binaires kubectl.exe en circulation — pas seulement les postes interactifs, mais aussi les images de développement, les runners CI et ce que déploient tes outils de gestion de parc.
2. Mets à jour vers la version corrigée de ta branche (1.34.12, 1.35.9 ou 1.36.5).
3. En attendant le déploiement, évite kubectl cp depuis des workloads multi-tenant, des jobs de build ou tout pod dont tu ne maîtrises pas le contenu.

Le correctif ne touche que le client. Aucune action côté serveur, aucun redémarrage de composant de contrôle, aucune fenêtre de maintenance à prévoir pour l’appliquer.

FAQ

Mes clusters Linux ou mes nœuds sont-ils affectés ?
Non. La faille touche uniquement l’extraction de l’archive côté client Windows. Le control plane, les nœuds et les clients kubectl Linux/macOS ne sont pas concernés.

Un CVSS de 6.5, est-ce que ça vaut vraiment la mise à jour en urgence ?
Le score reflète les conditions d’exploitation (droits élevés, interaction utilisateur requise), pas la gravité de l’impact une fois ces conditions réunies — une écriture de fichier arbitraire reste une primitive dangereuse, en particulier en contexte CI où le compte qui exécute kubectl a souvent plus de droits qu’un simple poste utilisateur.

Faut-il aussi vérifier les plugins kubectl tiers ?
L’avis ne couvre que le binaire officiel kubectl. Si tu utilises des wrappers ou des forks qui réimplémentent cp à partir du même mécanisme tar, vérifie-les séparément — rien ne garantit qu’ils héritent du correctif upstream.

En pratique

Ce genre de faille ne fait jamais la une, mais elle rappelle une chose simple : un client d’administration qui fait confiance par défaut au contenu qu’il manipule reste un point d’entrée, même quand le cluster lui-même est irréprochable. Si la sécurisation de tes clusters en général mérite une remise à plat, notre guide complet pour sécuriser un cluster Kubernetes couvre le sujet plus largement. Et si cette CVE t’intéresse pour sa mécanique côté Windows, elle complète bien celle qu’on a détaillée sur la faille zero-day Windows Shell CVE-2026-96951 — même système d’exploitation, deux surfaces d’attaque très différentes.

La prochaine étape est simple : lance l’inventaire de tes kubectl Windows cette semaine, pas au prochain audit de sécurité.

Une requête humaine envoyée à un agent IA en déclenche en moyenne une vingtaine côté infrastructure — c’est le chiffre cité par Bob Killen et Daniel Krook, tous deux directeurs à la CNCF, dans un entretien repris par The New Stack le 16 octobre 2026. Ces agents attendent une réponse en moins de 200 millisecondes, alors qu’un pod Kubernetes n’est garanti de démarrer qu’en environ une seconde. L’écart entre ces deux chiffres, ce n’est pas un détail de perf : c’est en train de redéfinir ce qui fait tomber un control plane.

Et la réponse n’est pas « trop de nodes ». Joe Betz, tech lead du SIG API Machinery de Kubernetes, a publié via The New Stack une analyse qui mérite d’être lue par quiconque opère un cluster au-delà de quelques centaines de nodes — ou qui commence à y faire tourner des charges d’agents. Son argument : un control plane peut saturer selon trois axes complètement indépendants, et résoudre l’un ne fait strictement rien pour les deux autres.

Le nombre de nodes n’est que la moitié de l’histoire

Le réflexe classique, c’est de dimensionner le control plane en fonction du nombre de nodes attendu. Ça marche pour un type de charge précis, mais pas pour les deux autres que décrit Betz. Voici les trois axes, avec les chiffres qu’il donne pour chacun.

Axe 1 : saturé par les nodes (flottes d’entraînement ML, clusters géants)

Le symptôme classique : les heartbeats des kubelets finissent par noyer le control plane. Le kube-apiserver consomme de plus en plus de mémoire, et etcd commence à peiner. À 100 000 nodes avec un heartbeat toutes les 10 secondes, le simple maintien en vie (« liveness ») représente déjà environ 10 000 écritures par seconde — et dans les mesures de Betz, le renouvellement des leases (les baux de heartbeat) compte pour près de 70% du débit d’écriture total. Autrement dit : sur un très gros cluster, la majorité de la charge d’écriture d’etcd ne sert à rien d’autre qu’à dire « je suis toujours vivant ». C’est typiquement le profil des flottes d’entraînement ML qui pilotent des GPU via la Dynamic Resource Allocation — beaucoup de nodes, du heartbeat classique, pas forcément beaucoup de churn.

Axe 2 : saturé par le churn (plateformes d’agents)

Ici, le nombre de nodes reste modeste, mais le taux de rotation des objets explose. Une session d’agent est une custom resource qu’on crée, suspend, reprend et détruit, potentiellement des milliers de fois par minute. Chaque transition de cycle de vie est une écriture, donc le débit dépend de l’activité des sessions, pas du nombre de machines. C’est précisément l’axe qui devient pertinent avec les plateformes d’agents IA décrites plus haut, même sur un cluster de taille raisonnable.

Axe 3 : saturé par l’état (clusters de plateforme)

Beaucoup de types d’objets différents, et des dizaines de milliers d’objets globalement peu actifs — l’exemple donné par Betz évoque environ 200 opérateurs tournant sur le même cluster. Le piège : chaque kube-apiserver maintient un cache de watch complet en mémoire, donc le coût mémoire total se multiplie par le nombre d’instances d’apiserver. Ajouter des apiservers pour tenir la charge de requêtes — un réflexe courant, y compris dans la configuration par défaut de kOps — augmente donc aussi la consommation mémoire globale, pas seulement la capacité.

Quatre points de découplage, pas une solution miracle

Betz appelle ça des « seams » : des points de découplage entre composants, en général une frontière réseau, qui permettent de changer une pièce sans toucher au reste. Il en identifie quatre, chacun ciblant un axe précis.

Point de découplage	Ce qu’il contrôle	Axe soulagé	État
Contrat de stockage	Quel etcd stocke quel type de ressource	Churn	Le flag --etcd-servers-overrides existe déjà pour les ressources natives — rien d’équivalent pour les custom resources à ce jour
Contrat de liveness des nodes	Comment les heartbeats atteignent le control plane	Nombre de nodes	Une couche dédiée côté nodes absorbe les renouvellements ; le changement côté etcd (rafraîchir les leases en mémoire plutôt que par un commit Raft complet) bénéficie à tous les clusters
Axe de sharding	Comment contrôleurs, caches et stockage se répartissent les objets	Les trois à la fois	KEP-5866 propose un filtrage par plage de hash — la coordination entre shards reste un problème ouvert
Résidence du cache	Ce que chaque apiserver garde en mémoire	État	Un prototype à deux shards réduit le tas mémoire par shard d’environ moitié — pas encore disponible en amont

Un point que Betz insiste à corriger : etcd n’est pas le problème et ne doit pas être remplacé. Son argument, c’est qu’un stockage consistant généraliste ne devrait simplement pas absorber du trafic qui n’a pas besoin de durabilité forte — les events et les leases de nodes, typiquement.

L’échelle de recettes, en binaires upstream standards

Au-delà de la théorie, l’article propose une grille concrète de dimensionnement, composée uniquement à partir de briques déjà disponibles dans Kubernetes upstream :

• HA classique — jusqu’à 5 000 nodes, 2 à 3 control planes identiques, aucun point de découplage nécessaire. Configuration mesurée en conditions réelles.
• Role-Split — de 5 000 à 20 000 nodes, des pools de machines séparés pour l’API serving, le scheduler, le controller-manager et etcd. Déjà disponible, bénéfice pas encore formellement mesuré.
• Node Plane — de 20 000 à 65 000 nodes, Role-Split plus une couche dédiée qui absorbe les baux de heartbeat. Mesuré, sur un seul déploiement de référence.
• Partitioned Store — autour de 100 000 nodes, Node Plane plus un découpage des types de ressources sur des stockages indépendants. Démontré en externe.
• Sharded Slice — au-delà, K unités de shard, chacune un contrôleur plus un apiserver épinglé sur une plage de hash. N’existe pas encore en pratique.

Note que cette logique de répartition par unités indépendantes ressemble, à un niveau d’abstraction différent, à ce que fait Karmada pour répartir une charge sur plusieurs clusters plutôt que sur plusieurs shards d’un même control plane — deux réponses distinctes au même problème de fond : un seul control plane ne peut pas tout absorber indéfiniment.

Betz le dit sans détour : aucune recette testée à l’échelle n’a encore été publiée pour les clusters churn-bound ou state-bound. Pour le nombre de nodes, le chemin est balisé ; pour le churn et l’état, c’est encore un terrain de recherche.

Ce que ça change si ton cluster fait 500 nodes, pas 100 000

Sincèrement, si tu gères un cluster de taille courante, l’axe « nombre de nodes » ne te concerne probablement pas avant longtemps — les seuils dont parle Betz sont ceux des hyperscalers et des plus gros clusters d’entraînement ML. Ce qui change la donne, c’est l’axe churn : dès que tu fais tourner une plateforme d’agents IA, même sur un cluster modeste, le taux de création/destruction d’objets peut grimper très vite, et c’est un axe de saturation complètement indépendant de ta taille de cluster. Le réflexe utile ici n’est pas d’ajouter des nodes au control plane, mais de surveiller le débit d’écriture etcd (etcd_server_proposals_committed_total et la latence de etcd_disk_wal_fsync_duration_seconds sont de bons points de départ côté métriques) avant que ça ne devienne un incident. Sur ce terrain, le pattern RBAC strict et l’allowlist d’outils décrits pour les agents kagent valent aussi la peine d’être appliqués à n’importe quel contrôleur custom qui crée des objets à haute fréquence.

FAQ

Mon cluster de 50 nodes peut-il être concerné par ces problèmes ?

Pas par l’axe « node-bound » décrit ici, qui ne devient critique qu’à très grande échelle. Mais l’axe « churn-bound » peut te toucher dès qu’un contrôleur ou une plateforme d’agents crée et détruit des objets à haute fréquence, indépendamment de la taille du cluster.

Faut-il arrêter d’ajouter des instances d’apiserver pour tenir la charge ?

Pas systématiquement, mais il faut savoir ce que ça coûte : chaque apiserver supplémentaire porte son propre cache de watch complet en mémoire. Ça augmente la capacité de traitement des requêtes, mais ça multiplie aussi la consommation mémoire totale du cluster.

Le flag --etcd-servers-overrides est-il utilisable aujourd’hui ?

Oui, il est déjà documenté dans la référence officielle kube-apiserver et permet de router des types de ressources natifs vers des backends etcd séparés. Sa limite actuelle : il ne couvre pas les custom resources, qui nécessitent une configuration de stockage par CRD pas encore disponible.

Où en est KEP-5866 ?

C’est une proposition d’amélioration encore en phase de prototype, qui ajoute un filtrage par plage de hash pour répartir le trafic API. La coordination entre shards et le sharding du controller-manager restent des problèmes non résolus à ce stade.

À retenir avant ton prochain audit de capacité

La prochaine fois qu’un tableau de bord grafana montre un control plane sous tension, résiste à la tentation de regarder uniquement le nombre de nodes. Vérifie le débit d’écriture etcd et sa répartition entre leases, events et objets métier — ça te dira en deux minutes sur quel axe tu es en train de saturer, et donc quel correctif a une chance de fonctionner. Si tu fais déjà tourner une plateforme d’agents ou de CI à forte rotation d’objets sur Kubernetes, ce diagnostic vaut le coup d’être posé maintenant, avant que ça devienne un incident un vendredi soir.

Ingress-NGINX est mort depuis mars 2026. Si tu as lu notre article sur la fin de vie annoncée, tu sais déjà qu’il fallait bouger. Ce qui a changé depuis : il existe enfin un chemin de migration qui tient la route, avec une API stable pour le trafic TCP/UDP brut et un outil officiel qui fait le gros du travail de conversion.

Ce qui vient de devenir stable

Gateway API v1.6.0 est sorti le 30 juin 2026, et c’est la première version où TCPRoute et UDPRoute quittent le channel expérimental pour rejoindre le Standard channel, sous l’API gateway.networking.k8s.io/v1. Avant cette version, ces deux types de ressources vivaient en v1alpha2 — utilisables, mais sans garantie de stabilité, ce qui en bloquait l’adoption en production pour pas mal d’équipes.

Concrètement, une TCPRoute ne gère ni hostnames, ni matches, ni filtres : elle route une connexion vers un ou plusieurs backendRefs (16 maximum par règle), avec une répartition pondérée en support étendu si tu en as besoin. C’est volontairement minimaliste — pensé pour exposer une base de données, un serveur DNS ou tout protocole qui ne parle pas HTTP. Un exemple minimal :

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: postgres-route
spec:
  parentRefs:
    - name: my-gateway
      sectionName: postgres
  rules:
    - backendRefs:
        - name: postgres-svc
          port: 5432

Le détail qui compte : un parentRef se résout par sectionName (un listener nommé sur ta Gateway) ou par port. Si tu exposais déjà des flux TCP/UDP via des annotations maison sur Ingress-NGINX (c’était fréquent pour la base de données ou le LDAP), tu as maintenant un équivalent standard, documenté, et porté par plusieurs implémentations de la Gateway API. Voir la référence officielle TCPRoute pour le détail complet des champs.

L’outil qui change vraiment la donne : Ingress2Gateway

Le projet kubernetes-sigs/ingress2gateway a atteint la version 1.0 le 20 mars 2026, puis la 1.2 en juillet. Ce n’est pas un contrôleur, il ne touche à rien en prod : il lit tes manifestes Ingress (ou directement ton cluster via le kubeconfig courant) et génère les ressources Gateway API équivalentes.

ingress2gateway print \
  --providers=ingress-nginx \
  --emitter=kgateway \
  --input-file ./ingress.yaml \
  -o yaml

Quelques options utiles au quotidien : -n/--namespace pour restreindre la lecture à un namespace, -A pour tout le cluster, --allow-experimental-gw-api si tu veux aussi les champs encore expérimentaux, et --ingress-nginx-ingress-class si ta classe Ingress n’est pas la nginx par défaut. L’outil ne devine pas tout : les annotations propres à Ingress-NGINX qui n’ont pas d’équivalent direct (certaines logiques de rewrite avancées, par exemple) ressortent en avertissement plutôt qu’en conversion silencieuse — ce qui est exactement le comportement que tu veux avant une bascule en production.

Ta checklist de migration

• Choisis ton implémentation de la Gateway API avant de lancer la conversion (kgateway, Istio, Envoy Gateway, Cilium…) — les manifestes générés en dépendent directement.
• Lance ingress2gateway print sur un export de tes manifestes, pas directement en écriture sur le cluster : relis les avertissements avant d’appliquer quoi que ce soit.
• Vérifie que les politiques annexes (auth, rate limiting, retries) qui vivaient dans des annotations NGINX ont bien un équivalent — souvent via des Policy spécifiques à l’implémentation choisie, pas via HTTPRoute lui-même.
• Migre un service non critique en premier, garde l’ancien Ingress en place en parallèle le temps de valider DNS, TLS et comportement des redirections.
• Ne fais jamais tourner deux contrôleurs qui revendiquent le même trafic en même temps — bascule service par service, pas en big bang.

Pourquoi ça ne peut plus attendre

Ingress-NGINX n’a plus de patch de sécurité depuis sa fin de vie. Pour rappel, la dernière faille sérieuse avant la mise en retraite — CVE-2026-3288, score CVSS 8.8, injection de configuration nginx via l’annotation rewrite-target — permettait l’exécution de code dans le contexte du contrôleur et, de fait, la lecture de tous les Secrets qu’il pouvait voir. Elle a été corrigée dans les versions 1.13.8, 1.14.4 et 1.15.0, mais plus aucune version future ne recevra ce genre de correctif. Si tu fais tourner Ingress-NGINX aujourd’hui en te disant « ça tourne, je verrai plus tard », c’est ce genre de CVE qui ne sera jamais patchée pour toi.

Pour en savoir plus sur l’annonce initiale de retraite, voir le billet officiel du blog Kubernetes.

FAQ

Dois-je migrer vers Gateway API même si mon trafic est purement HTTP ?

Oui, à terme — HTTPRoute est stable depuis plus longtemps que TCPRoute/UDPRoute et c’est le remplaçant naturel d’Ingress pour le trafic web. Mais rien ne t’empêche de migrer en deux temps : HTTP d’abord, TCP/UDP ensuite si tu en as besoin.

Ingress2Gateway supporte-t-il d’autres contrôleurs qu’Ingress-NGINX ?

Le provider le mieux documenté reste ingress-nginx, mais le projet gère aussi d’autres providers d’entrée — vérifie la liste à jour avec ingress2gateway --help sur ta version installée, elle évolue vite.

Faut-il abandonner complètement les annotations NGINX ?

Celles qui correspondent à du routage pur (host, path, rewrite simple) se convertissent bien vers HTTPRoute. Celles qui pilotaient des comportements avancés (auth externe, limitation de débit fine) demandent presque toujours une politique spécifique à ton implémentation de la Gateway API — ce n’est pas automatique, prévois ce travail dans ton planning de migration.

Passe à l’action

Si tu as encore des Ingress NGINX en prod, le plus urgent n’est pas de tout migrer ce week-end : c’est de faire tourner ingress2gateway print une première fois sur un export de tes manifestes pour voir ce qui se convertit proprement et ce qui ne se convertit pas. Tu sauras en une commande où se trouve le vrai travail.

Le 31 octobre 2026, AKS supprime les images de nœuds Azure Linux 2.0. Si un de tes node pools tourne encore dessus, il ne pourra plus scaler. Rien ne casse le jour J : pas de nœud qui tombe, pas d’alerte rouge. Le problème apparaît le jour où l’autoscaler veut ajouter des nœuds pendant un pic de charge et n’y arrive pas.

Il te reste un peu plus de trois semaines. Cet article te donne deux requêtes pour repérer les pools concernés, le chemin de migration le moins risqué, et un rappel sur Kubernetes 1.34, qui arrive en fin de vie upstream quatre jours plus tôt, le 27 octobre.

Ce qui se passe exactement le 31 octobre

Azure Linux 2.0 n’est plus supporté sur AKS depuis le 30 novembre 2025. Depuis cette date, l’image de nœud est figée sur la release 202512.06.0 : aucun correctif de sécurité n’a été publié depuis bientôt un an. Le 31 octobre 2026, Microsoft retire ces images, et la documentation AKS est claire sur la conséquence : tu ne pourras plus scaler tes node pools. Toute opération qui doit provisionner un nœud neuf à partir de cette image est donc exposée, autoscaler compris.

Pourquoi des clusters tournent encore dessus ? Parce que l’OS SKU AzureLinux pointait par défaut sur Azure Linux 2.0 pour les versions Kubernetes 1.27 à 1.31. Un cluster créé en 2024 et jamais monté au-delà de 1.31 est presque toujours dans ce cas.

Le piège du LTS

Si ton cluster est en support long terme (LTS) sur 1.30 ou 1.31, tu te crois peut-être couvert. Tu ne l’es pas. Microsoft le précise dans le calendrier des versions AKS : Azure Linux 2.0 atteint sa fin de vie pendant la période LTS des versions 1.28 à 1.31. Le LTS prolonge Kubernetes, pas l’OS des nœuds.

Repérer les node pools concernés

Sur un cluster

az aks nodepool list \
  --resource-group rg-prod-aks \
  --cluster-name aks-prod-01 \
  --query "[].{pool:name, k8s:orchestratorVersion, osSku:osSku, image:nodeImageVersion}" \
  -o table

Un pool avec l’OS SKU AzureLinux (ou l’ancien nom CBLMariner), une version Kubernetes inférieure ou égale à 1.31 et une image encore en 202512.06.0 est quasi certainement en Azure Linux 2.0.

Sur tout ton parc

Si tu gères plus de deux ou trois clusters, passe par Azure Resource Graph plutôt que de boucler sur chaque abonnement :

az graph query -q "
resources
| where type =~ 'microsoft.containerservice/managedclusters'
| mv-expand pool = properties.agentPoolProfiles
| extend osSku = tostring(pool.osSKU), k8s = tostring(pool.orchestratorVersion)
| where osSku in~ ('AzureLinux', 'CBLMariner')
| project cluster = name, resourceGroup, subscriptionId,
          pool = tostring(pool.name), osSku, k8s,
          image = tostring(pool.nodeImageVersion)
| order by k8s asc
" --first 1000 -o table

Trie par version : les lignes en 1.31 et moins sont ta liste de travail. Les pools Azure Linux en 1.32 ou plus sont déjà sur Azure Linux 3.0, sauf exception que l’image te révélera.

Deux chemins de migration, un seul bon ordre

Tu as deux façons de sortir d’Azure Linux 2.0 :

• Changer l’OS sans toucher à Kubernetes avec az aks nodepool update --os-sku AzureLinux3. Cet OS SKU est supporté de Kubernetes 1.28 à 1.36, donc il fonctionne sur ton cluster actuel. Les nœuds sont réimagés, rien d’autre ne bouge.
• Monter Kubernetes en 1.32 ou plus avec l’OS SKU AzureLinux, qui bascule alors par défaut sur Azure Linux 3.0.

Mon conseil : fais la première option maintenant, et l’upgrade Kubernetes après, dans une fenêtre séparée. Un cluster encore en 1.31 doit de toute façon franchir plusieurs versions mineures pour revenir dans le support standard (AKS a mis fin au support de 1.31 le 1er novembre 2025). Changer l’OS et enchaîner trois ou quatre versions Kubernetes dans la même soirée, c’est empiler deux sources de casse sans pouvoir dire laquelle a cassé quoi. Avec trois semaines devant toi, une seule opération maîtrisée vaut mieux qu’un grand saut.

az aks nodepool update \
  --resource-group rg-prod-aks \
  --cluster-name aks-prod-01 \
  --name userpool1 \
  --os-sku AzureLinux3

Avant de lancer la commande

• Vérifie tes PodDisruptionBudgets. La réimage passe par un cordon puis un drain des nœuds. Un PDB avec maxUnavailable: 0 (ou un minAvailable égal au nombre de réplicas) bloque le drain, et l’opération reste coincée.
• Règle le surge du pool si ce n’est pas déjà fait (az aks nodepool update --max-surge 33%, par exemple) pour accélérer le roulement sans saturer le quota de cœurs de ton abonnement.
• Passe d’abord sur un pool hors production. Les agents tiers déployés en DaemonSet (EDR, agents de supervision) qui chargent un module noyau ou dépendent de paquets de l’OS sont les premiers à mal réagir à un changement de distribution. Demande à l’éditeur s’il supporte Azure Linux 3.0 avant le jour J.
• Commence par les pools utilisateurs, puis le pool système une fois que tu as vu le comportement.

Kubernetes 1.34 : l’autre échéance d’octobre

Côté upstream, Kubernetes 1.34 est en mode maintenance depuis le 27 août et atteint sa fin de vie le 27 octobre 2026, d’après la page des patch releases. Son dernier patch connu est le 1.34.12, publié le 15 septembre.

Sur AKS, tu as un peu plus de marge : le calendrier donne une fin de vie de 1.34 à fin novembre 2026. Ce n’est pas une raison pour attendre. Pour un cluster en 1.34, je viserais 1.36 plutôt que 1.37 : la 1.37 arrive tout juste en GA sur AKS ce mois-ci, et laisser passer les premiers patchs ne coûte rien. La 1.36 reste supportée jusqu’en juin 2027. Si tu veux savoir ce que la 1.37 apporte quand même, j’ai détaillé les nouveautés de Kubernetes 1.37 dans un article précédent.

Pour ne plus découvrir ces échéances par hasard, AKS publie maintenant des notifications de fin de support dans Azure Resource Graph : KubernetesVersionEOLTwoWeeks, KubernetesVersionEOLOneWeek, puis KubernetesVersionOutOfSupport chaque semaine une fois la date passée. Pas besoin d’add-on ni de fenêtre de maintenance pour les recevoir. Branche-les sur une alerte et tu auras deux semaines de préavis.

FAQ

Mon cluster est en LTS 1.30, je suis tranquille ?

Non. Le LTS couvre la version Kubernetes, pas Azure Linux 2.0. Tes nœuds sont concernés par le 31 octobre comme les autres.

Est-ce que az aks nodepool update --os-sku réimage tous les nœuds d’un coup ?

Non, AKS procède par vagues, avec cordon et drain, selon le surge configuré sur le pool. C’est justement pour ça que les PDB et le surge comptent.

Je peux revenir à Azure Linux 2.0 si ça se passe mal ?

Techniquement oui avant le 31 octobre, tant que la version Kubernetes supporte encore cet OS. Mais revenir sur un système sans correctif depuis onze mois, ce n’est pas un plan B, c’est un pansement. Prévois plutôt un pool de repli en Ubuntu si un composant résiste vraiment.

Et les pools Ubuntu, ils ont aussi une échéance ?

Oui, plus lointaine : Ubuntu 20.04 n’est plus supporté sur AKS à partir du 17 mars 2027, et Ubuntu 22.04 à partir du 30 juin 2027. Avec l’OS SKU Ubuntu, la bascule vers 24.04 se fait automatiquement quand tu passes Kubernetes en 1.35 ou plus.

Où suivre l’annonce officielle ?

Microsoft suit ce retrait dans l’issue GitHub AKS #4988. Les nouvelles dates éventuelles y apparaissent en premier.

Ce que tu peux faire aujourd’hui

Lance la requête Resource Graph ci-dessus. Si elle ne retourne rien, tu as gagné ta journée. Si elle sort des lignes, planifie la migration AzureLinux3 d’un premier pool hors production cette semaine, et garde l’upgrade Kubernetes pour novembre. Profite aussi du passage pour relire tes bonnes pratiques de sécurisation de cluster : un parc qui traînait des nœuds non patchés depuis un an a sûrement d’autres angles morts.

Deux clusters Kubernetes, ça se gère encore à coups de contextes kubectl et de scripts bash. À partir de cinq ou six, avec des équipes différentes qui déploient dessus et des contraintes de placement (proximité GPU, région, conformité), le bricolage s’effondre. C’est le problème que Karmada attaque de front, et le projet vient de franchir une étape qui change la donne côté crédibilité : la graduation CNCF, annoncée le 7 septembre 2026.

Pour resituer : la CNCF classe ses projets en trois étages — Sandbox, Incubating, Graduated. Graduated, c’est le niveau que Kubernetes lui-même, Prometheus ou Envoy ont atteint : audit de sécurité tiers indépendant passé, gouvernance formalisée avec un comité de direction, adoption du code de conduite CNCF, badge CII Best Practices actif. Ce n’est pas une formalité administrative — c’est la garantie qu’un projet ne dépend plus d’un seul contributeur ou d’une seule entreprise, et qu’il a survécu à un audit externe sur sa sécurité.

Ce que fait vraiment Karmada

Karmada (« Kubernetes Armada ») étend l’API Kubernetes standard plutôt que de la remplacer. Concrètement, tes manifests, tes contrôleurs et tes outils existants fonctionnent sans modification sur un control plane Karmada — c’est le point de différenciation qu’ils mettent en avant, et c’est ce qui change la donne comparé à une solution qui t’obligerait à réécrire tes déploiements dans un format propriétaire.

Le control plane repose sur quatre briques : un karmada-apiserver, un karmada-controller-manager, un karmada-scheduler, et une instance etcd dédiée, isolée de celle de tes clusters membres. Par-dessus, quatre contrôleurs orchestrent la propagation des ressources : Cluster Controller, Policy Controller, Binding Controller et Execution Controller.

PropagationPolicy et OverridePolicy : les deux API qui font le travail

Deux CRD custom portent toute la logique métier :

• PropagationPolicy associe une politique à un ensemble de charges de travail (relation 1:n) et définit les contraintes de placement et de répartition.
• OverridePolicy permet de réécrire une configuration spécifiquement pour tel ou tel cluster — utile quand un cluster de prod a des limites de ressources différentes d’un cluster de dev, par exemple.

Un exemple minimal pour distribuer un déploiement nginx sur deux clusters membres :

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2

Tu peux créer la ressource et la policy dans n’importe quel ordre — Karmada rattrape la propagation dès que les deux existent. C’est un détail, mais ça évite les race conditions bêtes dans un pipeline CI/CD qui applique du YAML en parallèle.

Installer Karmada : compter cinq minutes, pas une journée

La commande d’installation la plus directe passe par le plugin kubectl :

kubectl karmada init

La documentation officielle annonce environ cinq minutes pour que tous les composants soient prêts dans le namespace karmada-system. Une installation via Helm est disponible aussi, pour les équipes qui préfèrent tout garder dans un chart versionné plutôt que d’exécuter une commande interactive.

Ensuite, joindre un cluster membre se fait selon deux modes. En mode push, depuis le control plane, avec le kubeconfig du cluster à joindre :

kubectl karmada join ${MEMBER_CLUSTER_NAME} --cluster-kubeconfig=$HOME/.kube/config

Ou en mode pull, depuis le cluster membre lui-même, ce qui évite de faire transiter un kubeconfig complet vers le control plane :

kubectl karmada register 172.18.0.3:32443 --token [token] --discovery-token-ca-cert-hash [hash]

Le mode pull est clairement préférable dès que tes clusters membres appartiennent à des équipes ou des environnements réseau distincts : tu n’as pas besoin de centraliser des identifiants d’accès à chaque cluster dans le control plane Karmada.

Karmada vs les alternatives : pas de solution universelle

Le multi-cluster n’a pas un seul bon outil, il a plusieurs outils pour plusieurs problèmes différents, et Karmada ne prétend pas tout couvrir :

• Cluster API gère le cycle de vie des clusters eux-mêmes (créer, mettre à jour, détruire) — pas le placement des charges de travail dessus. Les deux se complètent plutôt qu’ils ne s’opposent.
• Argo CD ApplicationSets ou Rancher Fleet déploient le même manifeste sur plusieurs clusters via une approche GitOps déclarative. C’est plus simple à adopter si ton besoin, c’est « le même état partout », mais tu n’as pas de scheduler dynamique qui décide où placer une charge selon la capacité ou la priorité au runtime.
• Open Cluster Management (OCM) propose une architecture hub-and-spoke centrée sur l’inventaire de clusters. Le projet reste en phase Sandbox CNCF, donc à un niveau de maturité clairement inférieur à Karmada aujourd’hui.
• KubeFleet / Azure Fleet Manager est l’option native Microsoft si tu es full-Azure avec plusieurs clusters AKS. Elle s’intègre mieux à l’écosystème Azure (RBAC, Azure Policy), mais elle t’enferme dans ce fournisseur — pas d’option pour orchestrer un cluster GCP ou on-prem à côté.

Si ton besoin réel est du placement dynamique (répartir une charge selon la capacité GPU disponible, la latence réseau, ou une contrainte de priorité) et que tu veux rester agnostique du fournisseur cloud, Karmada est clairement le bon choix aujourd’hui — c’est littéralement le problème pour lequel il a été conçu. Si tu es mono-cloud Azure et que ton besoin se limite à synchroniser le même état sur trois clusters AKS, Fleet Manager ou même Argo CD ApplicationSets suffiront très bien, avec beaucoup moins de composants à opérer.

L’adoption, en chiffres

Le projet revendique plus de 1214 contributeurs issus de 292 organisations et 5600 étoiles sur GitHub. Côté production, Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, Kuaishou, SenseTime et Vivo figurent parmi les adoptants cités. C’est une base plus large que la plupart des projets qui sortent tout juste d’Incubating — et ça pèse dans la décision d’un audit de sécurité : plus il y a d’implémentations réelles qui remontent des bugs, plus vite les trous se bouchent.

La version 1.19, sortie en même temps que l’annonce de graduation, ajoute une amélioration de la planification multi-composants pensée pour les charges IA, et fait passer la planification basée sur les priorités en beta. Un signal cohérent avec ce qu’on voit ailleurs dans l’écosystème Kubernetes en ce moment — la pression des charges GPU/IA pousse tous les schedulers, y compris multi-cluster, à devenir plus fins sur la priorisation.

FAQ

Karmada a-t-il un intérêt pour deux clusters seulement ?

Rarement. La valeur de Karmada vient du scheduling dynamique et des politiques de répartition à l’échelle. Pour deux clusters, la complexité opérationnelle d’un control plane et d’un etcd dédiés supplémentaires dépasse probablement le bénéfice — un script ou de l’ApplicationSets Argo CD fera l’affaire.

Le control plane Karmada est-il un point de défaillance unique ?

Il faut le traiter comme tel et le durcir en conséquence — etcd dédié à sauvegarder, accès API à restreindre. Une panne du control plane Karmada n’arrête pas les workloads déjà déployés sur les clusters membres (ils continuent de tourner normalement), mais elle bloque toute nouvelle propagation ou mise à jour de policy tant qu’elle n’est pas résolue.

Quelle version de Kubernetes faut-il sur les clusters membres ?

Karmada s’appuie sur les API Kubernetes standard côté membres, donc toute version supportée en amont convient en pratique. Vérifie la matrice de compatibilité officielle avant une mise à niveau majeure, en particulier si tu mélanges des membres sur des versions très éloignées les unes des autres.

Et maintenant ?

Si tu gères déjà plusieurs clusters à la main et que tu sens que ça devient ingérable, la graduation CNCF est un bon moment pour retester Karmada sérieusement — le badge de maturité lève une bonne partie des objections classiques côté sécurité et gouvernance qu’on entend en revue d’architecture. Commence petit : un control plane Karmada avec deux clusters de test, une PropagationPolicy simple, et regarde comment ton équipe s’approprie le modèle avant de l’étendre à la prod.

Si le sujet qui te bloque aujourd’hui, c’est plutôt la sécurité d’un cluster unique avant même de penser au multi-cluster, notre guide complet pour sécuriser un cluster Kubernetes reste la base à poser en premier. Et si ta contrainte de placement concerne spécifiquement des GPU, notre article sur la Dynamic Resource Allocation se combine bien avec du scheduling multi-cluster Karmada pour répartir les charges IA là où la capacité existe réellement.

Si tu gères des nœuds GPU sur un cluster Kubernetes, tu connais sûrement la mécanique historique : déclarer nvidia.com/gpu comme ressource étendue, poser des labels et des taints sur les nœuds, et croiser les doigts pour que le scheduler place correctement les pods. Ça fonctionne, mais ça reste rigide — impossible d’exprimer finement « je veux un GPU avec au moins 20 Gio de VRAM » ou « je préfère telle référence, mais telle autre fera l’affaire ». C’est précisément ce que corrige la Dynamic Resource Allocation (DRA), passée en disponibilité générale avec Kubernetes 1.35. Voici ce qu’elle change concrètement pour toi.

Le problème avec l’ancien modèle

Le mécanisme des ressources étendues (resources.requests/resources.limits avec nvidia.com/gpu: 1) traite un GPU comme un simple compteur, sans notion de caractéristiques du matériel. Résultat : pour cibler un type de GPU précis, tu dois passer par des nodeSelector ou des règles d’affinité, ce qui t’oblige à colocaliser des types de matériel spécifiques sur des nœuds dédiés et à maintenir ce mapping à la main. Dès que ton parc GPU devient hétérogène (T4, A100, H100 mélangés), ça devient vite ingérable.

Dynamic Resource Allocation, en résumé

Introduite en alpha dès Kubernetes 1.30, la Dynamic Resource Allocation a atteint la disponibilité générale avec Kubernetes 1.35 : le feature gate DynamicResourceAllocation est désormais verrouillé et ne peut plus être désactivé, ce qui en fait un mécanisme désormais considéré comme stable et recommandé pour piloter du matériel spécialisé (GPU, TPU, FPGA…).

ResourceClaim et ResourceClaimTemplate

Un ResourceClaim représente une demande de ressource matérielle faite par un pod — l’équivalent d’un PersistentVolumeClaim, mais pour du matériel plutôt que du stockage. Un ResourceClaimTemplate permet de générer ces claims automatiquement à partir d’un modèle, exactement comme un PodTemplate génère des pods.

DeviceClass et ResourceSlice

Une DeviceClass définit les caractéristiques et sélecteurs d’une famille de matériels (par exemple, « tous les GPU NVIDIA de la classe compute 8.0+ »). Une ResourceSlice, elle, est publiée par le driver de ressource pour annoncer l’inventaire disponible sur chaque nœud — le scheduler s’appuie dessus pour prendre ses décisions de placement.

# Exemple simplifié : une DeviceClass ciblant des GPU avec au moins 20 Gio de VRAM
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu-20gb-minimum
spec:
  selectors:
    - cel:
        expression: "device.attributes['gpu.nvidia.com'].memory.compareTo(quantity('20Gi')) >= 0"
---
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim-template
spec:
  spec:
    devices:
      requests:
        - name: gpu
          deviceClassName: gpu-20gb-minimum

Ce que ça change concrètement pour toi

Une sélection fine, exprimée en CEL

Plutôt que de jongler avec des labels de nœuds, tu exprimes tes contraintes matérielles directement via des expressions CEL (Common Expression Language) qui examinent les attributs et la capacité des devices. Tu peux aussi exprimer des préférences classées (firstAvailable) : privilégier un GPU A5000, et accepter un T4 si aucun A5000 n’est disponible — sans avoir à écrire deux DeploymentSpec différents.

Le partage de GPU devient natif

DRA supporte plusieurs pods (ou plusieurs conteneurs d’un même pod) partageant un même GPU via ResourceClaim, ainsi que du time slicing pour faire tourner plusieurs charges sur une seule carte — utile pour des environnements de développement ou de test où monopoliser un GPU entier par pod serait du gaspillage.

Et sur AKS ?

À ce jour, les stratégies de partitionnement GPU documentées pour AKS reposent encore principalement sur le modèle historique : ressources étendues nvidia.com/gpu, combinées à du MIG (partitionnement matériel), du time-slicing ou du MPS via le NVIDIA GPU Operator. DRA étant un mécanisme du cœur de Kubernetes, sa disponibilité effective sur AKS dépend de la version de Kubernetes du cluster et du support du driver NVIDIA associé — vérifie les notes de version AKS avant de migrer une charge de production, et commence par un nodepool de test si tu veux évaluer DRA dès maintenant.

FAQ

DRA remplace-t-il complètement le device plugin NVIDIA ?

Pas immédiatement : les deux modèles peuvent coexister le temps de la transition. Mais DRA est désormais la direction recommandée par le projet Kubernetes pour tout nouveau déploiement ciblant du matériel spécialisé.

Ai-je besoin d’un driver de ressource spécifique pour utiliser DRA avec NVIDIA ?

Oui, le driver DRA NVIDIA (distribué avec le GPU Operator) doit être installé sur ton cluster pour que les ResourceSlice soient correctement publiées et que le scheduler puisse allouer les GPU dynamiquement.

DRA fonctionne-t-il aussi pour du matériel non-GPU ?

Oui, le mécanisme est générique : il s’applique à toute ressource matérielle nécessitant une allocation fine — FPGA, cartes réseau spécialisées (SmartNIC), ou futurs types d’accélérateurs.

En résumé

Si tu pilotes un cluster GPU hétérogène pour des charges IA, la Dynamic Resource Allocation vaut clairement le détour : elle remplace des contournements fragiles par un modèle d’allocation pensé pour ça, avec la maturité de la GA depuis Kubernetes 1.35. Pour aller plus loin sur la gestion de ton cluster, notre article sur les nouveautés de Kubernetes 1.37 et notre guide pour sécuriser un cluster Kubernetes en 2026 complètent bien ce sujet, tout comme notre article sur la migration vers la Gateway API si tu prépares une mise à niveau plus large de ton cluster.

Si tu gères un cluster Kubernetes en production, il y a de fortes chances que tu utilises encore ingress-nginx pour exposer tes services. Sauf que ce projet, qui équipait historiquement une large majorité des clusters, ne reçoit plus aucun correctif depuis mars 2026 — ni bugfix, ni patch de sécurité. Dans cet article, tu vas comprendre pourquoi ce retrait a eu lieu, ce que Kubernetes propose comme remplaçant officiel (la Gateway API), et comment migrer sans tout casser en prod — avec un cas particulier si tu es sur AKS.

Pourquoi Ingress-NGINX tire sa révérence

Le SIG Network de Kubernetes et le comité de réponse aux incidents de sécurité ont annoncé la retraite du projet ingress-nginx fin 2025, avec une fin de maintenance actée en mars 2026. Deux raisons principales ont motivé cette décision :

• Un risque de sécurité structurel : le mécanisme de « snippets » qui permet d’injecter de la configuration NGINX brute via des annotations a été à l’origine de plusieurs CVE critiques, car il ouvre la porte à de l’injection de configuration depuis des ressources Ingress non fiables.
• Un projet sous-staffé : malgré des millions de déploiements dans le monde, la maintenance reposait sur une ou deux personnes bénévoles, un rythme intenable face à la charge de sécurité d’un composant aussi exposé.

Concrètement, depuis mars 2026 : plus de nouvelles releases, plus de correctifs de bugs, et surtout plus de patch en cas de nouvelle faille découverte. Si tu tournes encore dessus, chaque jour qui passe sans plan de migration augmente ton exposition.

La Gateway API, le successeur « officiel »

La communauté Kubernetes pousse depuis plusieurs années la Gateway API comme évolution naturelle d’Ingress — certains parlent d’« Ingress 2.0 ». Contrairement à l’API Ingress, pensée comme un objet unique et assez rigide, la Gateway API sépare clairement les responsabilités :

• le GatewayClass, fourni par le vendeur d’infrastructure (le contrôleur) ;
• le Gateway, géré par l’équipe plateforme/infra (les points d’entrée réseau) ;
• les HTTPRoute / GRPCRoute / TCPRoute, gérés par les équipes applicatives (le routage vers leurs services).

Cette séparation évite justement le problème des snippets : plus besoin d’injecter du texte de config libre, chaque équipe agit dans son périmètre avec des ressources typées. Côté maturité, le canal « standard » de la Gateway API n’a plus connu de changement cassant depuis deux ans, et TCPRoute/UDPRoute ont atteint la disponibilité générale récemment (dernière version stable v1.6.x début septembre 2026), ce qui en fait un socle solide au-delà du simple HTTP/HTTPS.

Et si tu es sur Azure Kubernetes Service (AKS) ?

Microsoft aligne AKS sur cette bascule upstream. Si tu utilises le module complémentaire de routage applicatif (application routing add-on) avec NGINX, tu bénéficies de correctifs de sécurité critiques jusqu’en novembre 2026 — mais aucune migration n’est imposée dans l’urgence aujourd’hui. Selon ta configuration actuelle, la documentation officielle AKS recommande un chemin de migration parmi trois :

• basculer vers l’implémentation Gateway API du module de routage applicatif ;
• migrer vers Application Gateway for Containers, qui prend en charge à la fois Ingress et Gateway API en natif ;
• ou, si tu as des besoins avancés (limites de taille de requête, scripts Lua, rate limiting), passer par l’add-on de service mesh Istio avec Gateway API.

Exemple concret : convertir un Ingress en Gateway API

Voici la même route exposée d’abord en Ingress classique, puis en Gateway API :

<!-- Ingress classique -->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mon-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: monapp.exemple.fr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mon-app-svc
            port:
              number: 80

# Équivalent en Gateway API
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mon-app
spec:
  parentRefs:
  - name: gateway-principale
  hostnames:
  - "monapp.exemple.fr"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: mon-app-svc
      port: 80

Le Gateway (le point d’entrée réseau lui-même, avec ses listeners et son TLS) est créé une seule fois par l’équipe plateforme, et chaque équipe applicative ne gère plus que ses HTTPRoute.

Comment migrer sans tout casser

Une migration Ingress → Gateway API se prépare, elle ne s’improvise pas un vendredi après-midi :

• Fais l’inventaire de toutes tes ressources Ingress actuelles (annotations comprises — c’est souvent là que se cachent les comportements spécifiques à migrer).
• Utilise ingress2gateway, l’outil officiel du projet Kubernetes SIG Network qui génère automatiquement les Gateway et HTTPRoute équivalents à partir de tes Ingress existants (support NGINX, Istio, GKE et plusieurs autres contrôleurs).
• Teste en environnement de staging avant toute bascule en prod, en particulier les comportements liés aux annotations spécifiques à ton contrôleur actuel qui n’ont pas toujours d’équivalent direct.
• Bascule progressivement, service par service si possible, avec un plan de rollback clair (garder les Ingress en parallèle le temps de valider chaque route).

FAQ

Dois-je migrer dans l’urgence ?

Non, mais tu dois planifier. Si tu es sur AKS avec le module NGINX, tu as un filet de sécurité jusqu’à fin novembre 2026. Au-delà, plus aucun correctif ne sera publié pour ingress-nginx lui-même.

Qu’est-ce qui casse concrètement si je ne fais rien ?

Rien ne casse du jour au lendemain — mais toute nouvelle CVE découverte sur ingress-nginx restera non corrigée, ce qui devient vite un point bloquant en audit de sécurité ou en conformité.

La Gateway API fonctionne-t-elle avec Helm et ArgoCD ?

Oui, les ressources Gateway et HTTPRoute sont des CRD Kubernetes standard : elles se déploient et se versionnent exactement comme n’importe quelle autre ressource, via Helm, Kustomize ou GitOps (ArgoCD/Flux).

La bascule vers la Gateway API n’est pas qu’une contrainte de fin de vie à subir : c’est aussi l’occasion de clarifier qui possède quoi entre équipe plateforme et équipes applicatives. Si tu tournes encore sur une version ancienne de Kubernetes, c’est aussi le bon moment pour vérifier ta compatibilité — jette un œil à notre article sur les nouveautés de Kubernetes 1.37. Et si la sécurité de ton cluster en général mérite un tour de vérification, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base.

Kubernetes 1.37, nom de code « Garhwal », est sorti le 26 août 2026. Si tu gères des clusters en production, cette version mérite ton attention : elle fait passer en stable plusieurs fonctionnalités de sécurité qui traînaient en beta depuis des mois, et elle acte le début de la fin pour un composant que tu utilises peut-être encore sans le savoir. Dans cet article, tu retrouves les changements qui comptent vraiment pour l’exploitation quotidienne, sans passer par les 67 items de la release note officielle.

Ce qui passe en stable (GA) et que tu peux activer sans crainte

Une version stable, c’est une fonctionnalité que tu peux mettre en production sans attendre le prochain cycle. Sur les 67 améliorations de Kubernetes 1.37, 16 franchissent ce cap. Voici celles qui changent concrètement ta façon de gérer un cluster.

Montage de volumes SELinux accéléré

Si tes nœuds tournent avec SELinux en mode enforcing (RHEL, Fedora CoreOS…), tu as sûrement déjà vu un pod mettre de longues secondes, voire des minutes, à démarrer sur un volume contenant beaucoup de fichiers : c’est le relabeling SELinux fichier par fichier qui bloque. Kubernetes 1.37 généralise l’option de montage native -o context, qui applique le label au niveau du point de montage plutôt qu’à chaque fichier. Le gain de démarrage est immédiat, et ça ferme au passage certaines techniques d’exploitation basées sur les chemins hôte.

Certificats de pods (Pod Certificates) en GA

C’est la fonctionnalité qui va t’intéresser si tu cherches à sortir du tout-bearer-token pour l’authentification inter-services. Avec la source de volume projeté PodCertificate, chaque pod peut désormais recevoir automatiquement un certificat X.509 signé, avec rotation gérée par Kubernetes. Ça t’évite de déployer et maintenir cert-manager ou un sidecar dédié juste pour du mTLS basique entre services internes. À utiliser en complément d’un service mesh si tu en as un, ou en solution autonome si ton besoin est simple.

Ressources au niveau du pod

Pour les workloads composés de plusieurs conteneurs étroitement couplés (un conteneur principal + un sidecar de log shipping, par exemple), tu peux désormais définir un pool de ressources CPU/mémoire partagé au niveau du pod plutôt que de fixer des limites rigides conteneur par conteneur. Résultat : moins de sur-provisionnement « au cas où » sur chaque conteneur pris isolément.

DRA : les tolérances de dispositifs passent en GA

La Dynamic Resource Allocation (DRA), qui gère l’attribution de matériel spécialisé (GPU, TPU, cartes réseau dédiées), avait déjà atteint la GA en 1.34. En 1.37, les device taints/tolerations deviennent stables : un device défaillant ou en maintenance peut désormais être « tainté » exactement comme un nœud, et tes workloads peuvent choisir de tolérer ce taint ou non. Si tu opères des pools de GPU pour de l’inférence IA, c’est le genre de détail qui t’évite un incident silencieux le jour où une carte commence à dériver.

Ce qui arrive en beta : à tester avant la prochaine LTS

Les fonctionnalités en beta sont activées par défaut dans la plupart des cas, mais restent à valider en environnement de test avant une généralisation.

• ClusterTrustBundles : une API cluster-scoped pour distribuer des ancres de confiance X.509 à tes workloads, avec mise à jour automatique lors des rotations de certificats — le complément naturel des Pod Certificates ci-dessus.
• Préemption pour le redimensionnement de pods à chaud : le scheduler peut désormais préempter des pods de priorité plus basse pour libérer de la place quand une demande de resize « in-place » ne trouve pas de ressources disponibles sur un nœud saturé.
• Scoring de capacité de stockage : les nœuds peuvent être priorisés lors du provisionnement de volumes persistants selon leur capacité disponible, pour étaler la charge ou au contraire consolider selon ta stratégie.
• Autoscaling horizontal jusqu’à zéro réplique pour le HorizontalPodAutoscaler, utile pour des workloads événementiels qui n’ont pas besoin de tourner en continu.

La dépréciation à anticiper : la fin programmée d’IPVS

C’est le point qui mérite une ligne dans ton backlog d’infra dès maintenant. Le backend kube-proxy IPVS est officiellement déprécié à partir de la 1.37, avec une suppression prévue en 1.43. En parallèle, le nouveau backend NFTables (alpha en 1.37, avec un support de l’accès NodePort en localhost via proxy userspace) est sur une trajectoire pour devenir le backend par défaut dès la version 1.40, en remplacement progressif d’iptables.

Concrètement, si ton cluster tourne encore avec IPVS, tu as jusqu’à la 1.43 pour basculer, mais autant commencer à planifier la migration vers iptables (le mode le plus courant aujourd’hui) ou NFTables plutôt que d’attendre le dernier moment. Vérifie la configuration de ton kube-proxy avec kubectl get configmap kube-proxy -n kube-system -o yaml si tu as un doute sur le backend actuellement utilisé.

Comment préparer ta mise à jour vers Kubernetes 1.37

Avant de lancer la migration sur un cluster de production, quelques réflexes qui t’évitent les mauvaises surprises :

• Consulte la note de version officielle pour la liste complète des 67 changements, y compris ceux spécifiques à ta distribution (EKS, AKS, GKE ont chacune leur propre calendrier de disponibilité).
• Teste d’abord sur un cluster de non-production, en particulier si tu utilises SELinux en mode enforcing ou si tu as des CRD volumineuses (le décodage concurrent des watchs, en beta, cible justement ce cas).
• Si tu es sur IPVS, planifie ta bascule de backend kube-proxy indépendamment de la montée de version elle-même, pour isoler les deux changements.
• Documente-toi sur les guides de dépréciation officiels pour vérifier qu’aucune API que tu utilises n’arrive en fin de vie dans cette version.

Si tu veux revoir les fondamentaux du hardening d’un cluster avant de monter en version, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base, indépendamment de la version installée.

FAQ

Faut-il migrer vers Kubernetes 1.37 tout de suite ?

Pas dans l’urgence. Comme pour toute montée de version majeure, teste d’abord en environnement de non-production. Les fonctionnalités GA de cette version (SELinux, Pod Certificates, DRA taints) sont solides, mais rien n’oblige à migrer avant ta fenêtre de maintenance habituelle — sauf si tu es concerné par la dépréciation d’IPVS.

IPVS va-t-il disparaître immédiatement ?

Non. La dépréciation en 1.37 signifie que le composant est marqué pour suppression, prévue en 1.43 — tu as donc plusieurs cycles de release devant toi (généralement plusieurs mois par version) pour planifier la migration.

Les Pod Certificates remplacent-ils un service mesh ?

Pas forcément. Ils couvrent le besoin de base (certificat X.509 par pod, rotation automatique) mais un service mesh comme Istio ou Linkerd ajoute des couches supplémentaires (observabilité, retry, politiques de trafic). Pour un besoin de mTLS simple entre quelques services, les Pod Certificates peuvent suffire seuls.

En résumé

Kubernetes 1.37 consolide surtout des fondations de sécurité posées lors des versions précédentes : SELinux et certificats de pods passent enfin en stable, la DRA continue sa maturation pour les workloads GPU, et le compte à rebours démarre officiellement pour IPVS. Rien qui impose une migration en urgence, mais de quoi mettre à jour ta feuille de route infra pour les prochains mois. Si un point de cet article te concerne directement — bascule IPVS, adoption des Pod Certificates —, c’est le bon moment pour ouvrir le ticket avant que ça devienne urgent.

Ton cluster Kubernetes est-il vraiment sécurisé, ou juste « en prod depuis longtemps sans incident » ?

Il y a une différence entre un cluster Kubernetes qui tourne sans problème et un cluster réellement sécurisé. La première catégorie te donne un faux sentiment de tranquillité, jusqu’au jour où un pod compromis obtient des droits qu’il n’aurait jamais dû avoir. Avec la sortie de Kubernetes 1.34 puis la version 1.37, actuellement la dernière stable, c’est le bon moment pour faire un point complet sur les fondamentaux de sécurité de ton cluster — qu’il tourne en AKS, EKS, GKE ou on-premise.

Dans cet article, on passe en revue les couches de sécurité qui comptent vraiment : Pod Security Standards, RBAC, Network Policies et scan d’images. Pas de liste à cocher vague — des exemples concrets que tu peux appliquer cette semaine.

Pod Security Standards : la base que tu dois avoir

Depuis que PodSecurityPolicy a été retiré de Kubernetes, les Pod Security Standards (PSS) sont devenus la référence officielle pour encadrer ce qu’un pod a le droit de faire. Trois niveaux existent :

• Privileged : aucune restriction, réservé aux composants système ou aux clusters de test isolés
• Baseline : bloque les vulnérabilités connues et graves (pas de conteneurs privilégiés, pas d’accès root au host) tout en restant compatible avec la plupart des applications
• Restricted : le niveau le plus strict, pensé pour la production et les environnements multi-tenant

Appliquer un niveau via Pod Security Admission

Le plus simple, c’est d’étiqueter tes namespaces. Tu peux même combiner audit, warn et enforce pour une transition progressive sans tout casser d’un coup :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Un pod conforme au niveau Restricted ressemble à ça :

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: mon-registry/app:1.4.2
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Astuce pour l’adoption : commence toujours en mode audit sur un namespace existant avant de passer en enforce. Ça t’évite de bloquer des déploiements légitimes que tu n’avais pas anticipés.

RBAC : le principe du moindre privilège, pour de vrai

Le RBAC (Role-Based Access Control) est souvent configuré une fois au démarrage du cluster, puis plus jamais revisité — et c’est justement là que le risque s’accumule au fil du temps, à mesure que des ServiceAccounts et des rôles s’empilent.

Trois réflexes à adopter :

• Ne donne jamais cluster-admin à un ServiceAccount applicatif. Crée des Role et RoleBinding scopés au namespace plutôt que des ClusterRole par défaut.
• Audite régulièrement qui a accès à quoi avec kubectl auth can-i --list --as=system:serviceaccount:namespace:nom-du-sa
• Désactive le montage automatique du token ServiceAccount pour les pods qui n’ont pas besoin de parler à l’API Kubernetes : automountServiceAccountToken: false

Network Policies : ton cluster n’est pas un réseau plat par défaut… sauf si tu ne fais rien

Par défaut, sans Network Policy, tous les pods de ton cluster peuvent communiquer entre eux, quel que soit le namespace. C’est pratique au début, catastrophique une fois qu’un composant est compromis : l’attaquant peut se déplacer latéralement sans aucune friction.

La bonne pratique consiste à partir d’une politique « deny all » par namespace, puis à autoriser explicitement les flux nécessaires :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Puis tu ouvres au cas par cas, par exemple pour autoriser uniquement le trafic venant de ton ingress controller vers ton API. Ça demande un peu de rigueur au départ, mais ça te protège des mouvements latéraux qui transforment un incident mineur en compromission complète du cluster.

Scan d’images et supply chain : ne déploie pas ce que tu n’as pas vérifié

Une image de conteneur, c’est du code que tu exécutes en production, au même titre qu’un binaire. Pourtant, beaucoup d’équipes déploient encore des images sans jamais les scanner. Intègre le scan de vulnérabilités directement dans ta CI/CD, avant que l’image atteigne ton registre de production :

• Scanne chaque image au build (Trivy, Grype ou l’outil intégré à ton registre cloud)
• Bloque le pipeline si une vulnérabilité critique est détectée sans correctif disponible
• Utilise des images de base minimales (distroless ou Alpine) pour réduire la surface d’attaque
• Signe tes images avec Cosign et vérifie la signature à l’admission via une politique dédiée

Cette approche « shift left » te coûte quelques minutes de pipeline en plus, mais elle t’évite de découvrir une CVE critique une fois l’image déjà en production sur des dizaines de pods.

Les mêmes principes s’appliquent en amont, dans tes pipelines : les leçons des attaques supply chain CI/CD de mars 2026.

Surveille en continu, pas seulement au moment du déploiement

Toutes les protections précédentes réduisent la surface d’attaque, mais elles ne remplacent pas une vraie visibilité sur ce qui se passe dans ton cluster en temps réel. Active les audit logs de l’API Kubernetes pour savoir qui fait quoi, et pas seulement au moment de l’incident.

• Centralise les audit logs dans ta stack d’observabilité (au même titre que les logs applicatifs) pour pouvoir reconstituer une chronologie en cas d’incident
• Ajoute une détection runtime avec un outil comme Falco, qui repère les comportements anormaux à l’intérieur des conteneurs (exécution d’un shell inattendu, écriture dans un répertoire système)
• Mets en place des alertes sur les changements de RBAC eux-mêmes : un nouveau ClusterRoleBinding créé en dehors de ta CI est un signal fort à ne jamais ignorer

Cette couche de détection est ce qui te permet de réagir en minutes plutôt qu’en jours quand une des couches précédentes a été contournée. Aucune protection n’est infaillible à 100 % : c’est la combinaison prévention + détection qui fait la différence entre un incident contenu et une compromission complète.

FAQ

Par où commencer si mon cluster n’a aucune de ces protections aujourd’hui ?

Commence par les Network Policies en mode « deny all » sur tes namespaces les plus sensibles, puis les Pod Security Standards en mode audit. Ce sont les deux mesures qui limitent le plus l’impact d’une compromission, pour un effort de mise en place raisonnable.

Le niveau Restricted des Pod Security Standards casse-t-il les applications existantes ?

Souvent oui, si elles n’ont pas été conçues avec ces contraintes en tête (utilisateur root, écriture sur le système de fichiers racine). D’où l’intérêt du mode audit avant enforce : tu identifies les pods problématiques sans bloquer la production.

Faut-il un outil tiers (Falco, OPA Gatekeeper) en plus des fonctionnalités natives ?

Les fonctionnalités natives (PSS, RBAC, NetworkPolicy) couvrent une bonne base. Des outils comme OPA Gatekeeper ou Kyverno deviennent utiles quand tu as besoin de politiques plus fines que ce que Kubernetes propose nativement, ou d’une détection runtime avec Falco.

Comment savoir si mon cluster est déjà sur une version supportée ?

Kubernetes maintient les trois dernières versions mineures. Vérifie ta version avec kubectl version et compare-la aux versions actives sur la page officielle des releases. Une version hors support ne reçoit plus de correctifs de sécurité.

Les changements de la dernière version sont détaillés dans mon article sur Kubernetes 1.37.

Le scan d’images suffit-il à sécuriser ma supply chain ?

Non, c’est une couche parmi d’autres. Associe-le à la signature d’images et à une politique d’admission qui vérifie la provenance, sinon rien n’empêche une image non scannée de passer par un autre chemin de déploiement.

En résumé

La sécurité Kubernetes n’est pas un projet qu’on termine puis qu’on oublie : c’est une couche qui se construit progressivement, namespace par namespace, politique par politique. Commence par les fondamentaux — Pod Security Standards en mode audit, RBAC scopé, Network Policies deny-all, scan d’images en CI — et itère à partir de là. Chaque couche que tu ajoutes réduit concrètement ce qu’un attaquant peut faire s’il obtient un pied dans ton cluster.

Vérifie dès aujourd’hui l’état de tes Network Policies sur ton namespace de production : c’est souvent la première surprise, et la plus rapide à corriger.