Kubernetes v1.37 : préparer la sortie du 26 août sans casser kube-proxy

Le « sneak peek » officiel de Kubernetes v1.37 a été publié le 31 juillet 2026, pour une sortie prévue le 26 août. Le calendrier n’est pas anodin : le 27 août, la 1.34 entre en maintenance. Beaucoup d’équipes qui pensaient avoir jusqu’à l’automne pour bouger découvrent que leur fenêtre de planification, c’est cette semaine.

Cet article se concentre sur ce qui casse — ou casse bientôt — plutôt que sur la liste exhaustive des nouveautés.

Calendrier : pourquoi la fenêtre est maintenant

La politique de support de Kubernetes accorde à chaque version mineure environ un an de correctifs, suivi d’une période de maintenance courte pendant laquelle seuls les correctifs critiques sont backportés. Concrètement, si vous êtes en 1.34, votre marge de manœuvre se réduit à quelques semaines avant de basculer sur une version qui ne recevra plus grand-chose.

L’erreur classique consiste à traiter l’upgrade comme un incrément de version. Ce n’est pas le cas ici : v1.37 amorce une trajectoire de dépréciation sur kube-proxy et durcit un comportement du kubelet qui, sur certains clusters, empêche purement et simplement des static pods de démarrer. Ces deux points méritent d’être traités avant de planifier la montée de version, pas pendant.

Le point chaud : la dépréciation du mode ipvs

C’est l’annonce la plus structurante. Le mode ipvs de kube-proxy est officiellement déprécié, avec une trajectoire annoncée en trois temps :

• v1.37 : kube-proxy émet un avertissement au démarrage lorsqu’il est configuré en mode ipvs. Rien ne casse.
• v1.40 (visé) : le mode est désactivé par défaut. Il faudra une opt-in explicite pour continuer à l’utiliser.
• v1.43 (visé) : retrait du code.

Ces jalons sont des cibles, pas des engagements contractuels — ils peuvent glisser. Mais le sens de la marche est clair : le mode nftables, passé GA en v1.33, devient le backend de référence, et iptables reste le mode par défaut historique pour des raisons de compatibilité.

Deux à trois versions mineures, cela ressemble à beaucoup de temps. En pratique, si votre cadence d’upgrade est semestrielle, vous avez trois ou quatre cycles pour migrer, tester et débugger. Ce n’est pas confortable pour un composant qui touche le chemin de données de tous vos Services.

Diagnostic en cinq minutes

Première question : quel mode tournent réellement vos clusters ? Ne vous fiez pas à la documentation interne, vérifiez.

# Le mode déclaré dans la configuration
kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep -E '^\s*mode:'

# Le mode effectivement appliqué, vu depuis les logs d'un pod
kubectl -n kube-system logs ds/kube-proxy --tail=50 | grep -i 'proxy mode'

Attention : un champ mode: "" signifie « mode par défaut », c’est-à-dire iptables sur Linux. Ce n’est pas une erreur de configuration, mais cela veut dire que votre cluster suivra silencieusement l’évolution des valeurs par défaut amont.

Vérification côté nœud, la seule qui ne ment pas :

# Sur un nœud worker
sudo ipvsadm -Ln | head -20            # non vide => ipvs actif
sudo nft list table ip kube-proxy      # existe => mode nftables
sudo iptables-save | grep -c 'KUBE-SVC' # nombre de chaînes de service

Cas particulier des offres managées : chez plusieurs cloud providers, kube-proxy est déployé comme un add-on géré, et le DaemonSet est réconcilié en permanence. Vos modifications au ConfigMap seront écrasées si vous ne passez pas par l’API du provider (configuration du node pool, add-on versionné, ou champ dédié dans la définition du cluster). Vérifiez également si votre CNI remplace kube-proxy — Cilium en mode kubeProxyReplacement, par exemple — auquel cas la dépréciation ne vous concerne tout simplement pas.

Plan de migration vers nftables

Le backend nftables a des prérequis noyau réels. Comptez un noyau Linux 5.13 ou supérieur et une version de nft suffisamment récente côté nœud. Les distributions « entreprise » avec noyaux backportés sont un terrain piégeux : le numéro de version affiché ne reflète pas toujours les fonctionnalités disponibles.

uname -r
nft --version

La bascule elle-même est un changement de champ, suivi d’un rolling restart du DaemonSet :

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: nftables

kubectl -n kube-system rollout restart daemonset/kube-proxy
kubectl -n kube-system rollout status daemonset/kube-proxy

Deux précautions non négociables :

1. Nettoyage des règles résiduelles. kube-proxy ne supprime pas systématiquement les artefacts de l’ancien backend. Sur un nœud fraîchement migré, contrôlez qu’il ne reste pas de chaînes KUBE-* iptables orphelines ou de services IPVS actifs qui continueraient à intercepter du trafic. Le plus sûr reste de recycler les nœuds plutôt que de les convertir en place.
2. Vos règles maison. Toute règle iptables écrite à la main, tout opérateur qui insère des chaînes personnalisées, tout agent de sécurité qui filtre en PREROUTING doit être audité. Le passage à nftables ne casse pas iptables (grâce à iptables-nft), mais l’ordre d’évaluation et les priorités de hook changent, et c’est exactement là que se logent les régressions silencieuses.

Côté validation, un test de conformité minimal doit couvrir : ClusterIP, NodePort, LoadBalancer, externalTrafficPolicy: Local (préservation de l’IP source), les Services headless, les Services sans endpoint (rejet vs. drop), et les sessions affines. Si vous avez un environnement de préproduction représentatif, la suite de tests sig-network de Kubernetes reste la référence.

Static pods : la fin des références API

v1.37 supprime le feature gate PreventStaticPodAPIReferences et rend le comportement inconditionnel : un static pod ne peut plus référencer d’objets de l’API — Secrets, ConfigMaps, ServiceAccounts. C’est logique, le kubelet démarre ces pods sans garantie de disponibilité de l’API server, et ces références n’ont jamais été correctement supportées. Mais si un de vos manifestes en contenait une, il était toléré jusqu’ici ; il ne le sera plus.

Les static pods installés par kubeadm (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) montent tout via hostPath et ne sont pas concernés. Le risque vient des ajouts maison : agents de monitoring déployés en static pod, proxies d’authentification, sidecars de bootstrap.

# Sur chaque nœud control-plane et chaque nœud portant des static pods
sudo grep -rlE 'secretKeyRef|configMapKeyRef|secretRef|configMapRef|serviceAccountName|serviceAccountToken' \
  /etc/kubernetes/manifests/

La réécriture consiste à basculer sur des fichiers présents sur le nœud (hostPath) provisionnés par votre outil de configuration, ou — meilleure option dans la majorité des cas — à sortir la charge du mode static pod pour la déployer en DaemonSet avec un nodeSelector ou une tolération adaptée. Un static pod n’a de sens que pour ce qui doit démarrer avant l’API server.

Metrics API en GA

La Metrics API (metrics.k8s.io) passe en GA. En pratique, cela signifie une version stable v1 aux côtés de v1beta1, et un contrat d’API désormais figé.

Ce que ça change concrètement :

• HPA : le comportement ne change pas, mais le chemin resource metrics repose désormais sur une API stable. C’est une bonne nouvelle pour la prévisibilité de l’autoscaling.
• kubectl top : idem, transparent côté utilisateur.
• Vos implémentations : si vous exposez un APIService qui sert metrics.k8s.io — metrics-server, ou un adaptateur maison —, vérifiez qu’il annonce bien la nouvelle version. Un metrics-server trop ancien continuera à fonctionner via v1beta1, mais vous accumulez de la dette.

Le piège habituel reste inchangé : la Metrics API n’est pas une API de monitoring. Elle ne conserve pas d’historique et ne remplace pas Prometheus. Si vous avez des dashboards qui l’interrogent, ils sont mal conçus.

DRA : taints et tolerations sur les devices

Le Dynamic Resource Allocation gagne un mécanisme de taints/tolerations appliqué aux devices eux-mêmes, sur le modèle de ce qui existe pour les nœuds. Un driver DRA — ou un opérateur externe via un objet DeviceTaintRule — peut marquer un device individuel comme dégradé, et les workloads qui ne tolèrent pas ce taint sont évincés en cas d’effet NoExecute.

Le cas d’usage canonique est le GPU : erreur ECC non corrigible, throttling thermique persistant, device tombé en mode dégradé. Aujourd’hui, la seule granularité disponible est le nœud entier — on cordon le nœud et on évacue huit GPU pour en isoler un. Le taint au niveau device permet de retirer précisément l’accélérateur défaillant.

# Schéma indicatif — vérifiez la version d'API dans les release notes
apiVersion: resource.k8s.io/v1beta1
kind: DeviceTaintRule
metadata:
  name: gpu-node42-ecc
spec:
  deviceSelector:
    driver: gpu.nvidia.com
    pool: node-42
    device: gpu-3
  taint:
    key: hardware.example.com/unhealthy
    value: "ecc-uncorrectable"
    effect: NoExecute

Côté consommateur, un job de training tolérant peut demander à survivre quelques minutes pour checkpointer :

tolerations:
- key: hardware.example.com/unhealthy
  operator: Exists
  effect: NoExecute
  tolerationSeconds: 300

C’est une fonctionnalité à intégrer dans votre boucle de remédiation matérielle, pas à activer pour le plaisir : sans automatisation qui pose et retire les taints, elle n’apporte rien.

ulimits par conteneur

v1.37 introduit la possibilité de définir des ulimits au niveau du conteneur plutôt que d’hériter des limites du runtime. Le cas d’usage réel est étroit : nofile principalement, pour des workloads qui ouvrent massivement des descripteurs (proxies, brokers, bases de données) et pour lesquels la valeur par défaut du runtime est soit trop basse, soit — depuis que containerd a relevé sa valeur par défaut — beaucoup trop haute pour de vieilles applications qui itèrent naïvement sur tous les FD au démarrage.

Le piège : les ulimits ne sont pas des cgroups. Ils ne remplacent ni resources.limits, ni les PodSecurity standards, et ils ne protègent pas le nœud. Fixer nproc par conteneur dans un pod avec plusieurs conteneurs partageant un même namespace utilisateur produit des effets contre-intuitifs. Considérez cette fonctionnalité comme un correctif ciblé pour un problème identifié, pas comme un levier de tuning générique.

Checklist d’upgrade

1. Inventorier le mode kube-proxy de chaque cluster, y compris les clusters de test oubliés.
2. Vérifier si un CNI remplace kube-proxy (auquel cas la dépréciation est sans objet).
3. Contrôler les versions de noyau et de nft sur tous les node pools.
4. Auditer les static pods pour les références API et planifier leur réécriture.
5. Vérifier la version de metrics-server et sa compatibilité avec la Metrics API stable.
6. Passer les API dépréciées au crible avec kubectl-convert, pluto ou kubent.
7. Valider les webhooks admission tiers contre la version cible (cause n°1 de blocage d’upgrade).
8. Tester la migration nftables sur un node pool isolé, pas sur l’ensemble du cluster.
9. Dérouler une suite de conformité réseau : ClusterIP, NodePort, externalTrafficPolicy: Local, sessions affines.
10. Documenter la procédure de rollback avant de commencer.

Sur le rollback, soyez lucide : Kubernetes ne supporte pas le downgrade du control plane d’une version mineure. La stratégie réaliste est un cluster de remplacement (blue/green) ou, à défaut, une restauration etcd testée. Pour kube-proxy en revanche, le retour d’nftables vers iptables est un simple changement de ConfigMap plus un rolling restart — à condition d’avoir nettoyé les règles résiduelles. Gardez cette bascule scriptée et prête à l’emploi.

Ce qui peut attendre v1.38

Tout ce qui n’est pas sur le chemin critique. Les ulimits par conteneur relèvent de l’optimisation, pas de l’upgrade. Les taints DRA n’ont de valeur que couplés à une automatisation de remédiation que vous n’écrirez pas en une itération. La Metrics API en GA ne demande aucune action immédiate si votre metrics-server est à jour.

Les deux sujets à traiter maintenant sont les static pods — parce que c’est un blocage dur au démarrage du kubelet — et l’inventaire kube-proxy. Ce dernier ne casse rien en v1.37, mais c’est précisément le moment de le faire : vous avez encore le luxe de migrer sans pression, avec un chemin de retour trivial. En v1.40, ce ne sera plus le cas.

La véritable difficulté de cet upgrade n’est pas technique, elle est organisationnelle : un avertissement dans les logs de kube-proxy ne déclenche aucune alerte, ne crée aucun ticket, et sera oublié dans trois semaines. Transformez-le en tâche planifiée dès maintenant, sinon vous le redécouvrirez en 1.40, un vendredi soir.