Kubernetes 1.37 enterre les Services ExternalIPs et muscle la supervision réseau

31 juillet 2026. L’équipe release de Kubernetes a publié le sneak peek de la version 1.37, dont la sortie est attendue pour mi-septembre 2026. Au menu : le début de la suppression des Services ExternalIPs, la graduation du Mixed Version Proxy en beta, de nouvelles métriques réseau dans le Cloud Controller Manager et la sortie d’etcd 3.7.0. Trois changements structurels qui concernent directement tout administrateur de cluster en production.

Ce n’est pas une release de fonctionnalités tape-à-l’œil. C’est une release de dette technique qu’on rembourse et de sécurité qu’on solidifie.

Services ExternalIPs : la fin d’un vecteur d’attaque

Les ExternalIPs existent depuis les premières versions de Kubernetes. Le principe : attacher une adresse IP externe directement à un Service, sans passer par un LoadBalancer provisionné par le cloud provider. Pratique en apparence, dangereux en pratique.

Le problème est documenté depuis 2019 (CVE-2019-11253 et suivants) : un attaquant capable de créer ou modifier un Service peut détourner du trafic destiné à n’importe quelle IP du réseau. En substance, les ExternalIPs permettent de recevoir du trafic qui ne vous est pas destiné — un man-in-the-middle architectural.

Kubernetes 1.36 a introduit la dépréciation officielle de la fonctionnalité, masquée derrière une feature gate. La version 1.37 va plus loin :

• La feature gate ServiceExternalIPs passe en off par défaut pour les nouveaux clusters.
• Un mécanisme de migration automatique est proposé : l’API convertit silencieusement les ExternalIPs en adresses de type LoadBalancer là où un contrôleur le supporte, ou en NodePort à défaut.
• Les clusters existants reçoivent un warning formel dans kube-apiserver à chaque utilisation d’ExternalIPs.

Pour les équipes ops, deux actions immédiates :

1. Auditer tous les Services utilisant externalIPs dans le champ spec — la commande kubectl get svc -A -o json | jq ’.items[] | select(.spec.externalIPs != null) | {name: .metadata.name, namespace: .metadata.namespace, ips: .spec.externalIPs}’ vous donne la liste exhaustive.
2. Migrer vers des solutions légitimes : LoadBalancer (MetalLB en on-prem), Ingress standardisé via Gateway API, ou, pour les cas de hairpin NAT, une sonde externe pilotée par un DaemonSet.

La suppression définitive est planifiée pour Kubernetes 1.39, soit environ six mois après la 1.37. Le compte à rebours est lancé.

Mixed Version Proxy : les montées de version sans interruption

Le Mixed Version Proxy (MVP) a été introduit en alpha dans Kubernetes 1.35. En 1.37, il passe en beta et devient activable en production.

Le problème qu’il résout est connu de tous ceux qui ont déjà fait une mise à niveau de cluster : pendant la fenêtre où le plan de contrôle tourne en version N+1 tandis que les kubelets sont encore en version N, les requêtes API peuvent cibler des ressources qui n’existent pas encore dans l’ancienne version. Résultat : erreurs 404 intempestives, reconcilers qui plantent, interruptions de service.

Le MVP introduit un proxy de compatibilité entre les kube-apiserver de versions différentes. Concrètement :

• Les requêtes arrivant sur un apiserver en version N+1 pour une ressource qui n’existe que depuis N+1 sont automatiquement routées vers le nœud de contrôle qui la comprend.
• Les réponses sont normalisées : un champ ajouté en N+1 est filtré (stripped) avant d’être renvoyé à un client en version N.
• Le kube-scheduler et le controller-manager utilisent le MVP pour garantir qu’ils ne planifient pas de Pods avec des champs incompris par les anciens kubelets.

En beta, le MVP est activé par défaut sur les nouveaux clusters créés avec kubeadm en version 1.37. Pour les clusters existants, une feature gate MixedVersionProxy contrôle l’activation.

Le gain est massif pour les clusters multi-tenant ou critiques où les fenêtres de maintenance sont réduites : une mise à niveau qui nécessitait une heure de coupure partielle peut désormais s’effectuer sans interruption observable.

Cloud Controller Manager : nouvelle métrique de synchronisation

Le Cloud Controller Manager (CCM) gère la synchronisation des routes réseau entre le cluster Kubernetes et le réseau sous-jacent du fournisseur cloud. Jusqu’à la 1.36, cette synchronisation était une boîte noire : impossible de savoir si une route était bloquée, en retard, ou en échec sans plonger dans les logs bruts.

Kubernetes 1.37 introduit la métrique route_sync_duration_seconds, exposée au format Prometheus par le CCM. Elle se décline en trois labels :

• cloud_provider : identifie le fournisseur (AWS, GCP, Azure, OpenStack…).
• operation : distingue create, update et delete.
• status : success, timeout ou error.

Couplée à un alerting Prometheus standard, cette métrique permet de détecter une désynchronisation réseau avant qu’elle ne provoque une panne. Pour un cluster de plus de 100 nœuds, c’est la différence entre une alerte à 2 h du matin et un incident manager convoqué à 3 h.

etcd 3.7.0 : plus rapide, plus stable, plus sûr

Le 31 juillet 2026, la sortie d’etcd 3.7.0 a été annoncée, et Kubernetes 1.37 recommande cette version comme baseline pour le stockage du cluster.

Les avancées notables :

• Compaction parallélisée. La compaction, opération historique d’etcd qui purge les anciennes révisions et réduit l’espace disque, ne bloque plus les écritures pendant son exécution. Sur un cluster de 50 nœuds, le temps de compaction passe de 15 secondes à moins de 2 secondes.
• Chiffrement TLS 1.3 obligatoire pour les communications inter-nœuds. Fini les compatibilités descendantes avec TLS 1.2 qui introduisaient des downgrades silencieux.
• Watch progressives (watch progress notify). Les clients etcd reçoivent désormais une notification périodique même en l’absence de changement — ce qui élimine les timeouts inexpliqués sur les longues sessions watch.

La migration depuis etcd 3.6 est transparente pour un cluster Kubernetes standard : un rolling upgrade des pods etcd suffit. Le stockage reste compatible, aucun dump/restore n’est nécessaire.

Verdict

Kubernetes 1.37 ne fera pas les gros titres de la presse tech — mais c’est précisément la release que les SRE et administrateurs de clusters attendent. Elle nettoie une fonctionnalité dangereuse (ExternalIPs), fluidifie les mises à niveau (Mixed Version Proxy), donne de la visibilité sur le réseau cloud (CCM) et durcit le stockage (etcd 3.7).

Si vous gérez des clusters en production, votre plan d’action pour septembre tient en trois lignes : auditez vos ExternalIPs maintenant, activez le Mixed Version Proxy sur vos clusters de staging cette semaine, et prévoyez un rolling upgrade etcd pendant une fenêtre de maintenance standard. Le reste suivra.

Références

• Kubernetes Blog, « Kubernetes v1.37 Sneak Peek », 31 juillet 2026.
• Kubernetes Enhancement Proposal KEP-2340, « Mixed Version Proxy », 2025.
• etcd GitHub Releases, « etcd v3.7.0 Release Notes », 31 juillet 2026.