etcd v3.7.0 est sorti début juillet 2026, annoncé sur le blog Kubernetes le 8 juillet, et c'est le genre de version qui compte davantage pour ceux qui exploitent des clusters que pour ceux qui lisent un changelog par plaisir. La fonction phare, RangeStream, permet au magasin de renvoyer les gros résultats de requête par fragments plutôt qu'en une réponse gigantesque, exactement le motif qui fait piquer un plan de contrôle chargé. Les utilisateurs de Kubernetes devraient voir la charge CPU globale de leurs membres etcd baisser par rapport à 3.6. Il y a une réserve à poser d'emblée, pour que personne ne migre en espérant un repas gratuit : le gain le plus important nécessite une version de Kubernetes qui n'est pas encore sortie.
The short answer
etcd v3.7.0 est sorti début juillet 2026, annoncé sur le blog Kubernetes le 8 juillet. Sa fonction phare, RangeStream, renvoie les grosses requêtes de plage par fragments au lieu d'une réponse géante, ce qui atténue les pics de mémoire et de CPU que ces requêtes provoquent. Les utilisateurs de Kubernetes devraient voir la charge CPU globale de leurs membres etcd baisser par rapport à 3.6. La version ajoute aussi les requêtes de plage clés seules, un renouvellement de bail plus rapide, un démarrage uniquement sur le magasin v3 et des points de terminaison sur socket Unix. Le plein bénéfice de RangeStream nécessite la future version Kubernetes v1.37 avec le feature gate EtcdRangeStream.
etcd fait rarement les gros titres, ce qui est bon signe : il fait son travail. C'est le magasin discret sous chaque cluster Kubernetes, qui contient tout l'état désiré, et il ne devient visible que lorsqu'un plan de contrôle commence à peiner. C'est ce qui rend cette version digne d'attention : les changements visent exactement les moments où etcd cesse d'être invisible.
Ce qui est sorti
etcd v3.7.0 est sorti début juillet 2026 et a été annoncé sur le blog Kubernetes le 8 juillet, après des versions bêta et candidates au fil du printemps. C'est une version mineure par le nom et significative par l'effet, car l'essentiel du travail porte sur le comportement d'etcd sous la charge qu'un grand cluster génère réellement.
La fonction vedette est RangeStream. Une requête de plage demande à etcd un ensemble de clés, et dans un grand cluster cet ensemble peut être énorme, pensez à lister tous les pods ou tous les secrets d'un namespace comptant des milliers d'objets. Traditionnellement, etcd assemble toute cette réponse et la renvoie d'un bloc, ce qui fait piquer la mémoire et monter la latence pour tout le reste au même instant. RangeStream renvoie plutôt le résultat sous forme d'une série de petits fragments. La mémoire de pointe reste plus plate, et la charge que ces grosses listes créent se répartit au lieu de se concentrer.
À ses côtés, etcd prend désormais en charge les requêtes de plage clés seules, si bien qu'un appelant qui a besoin des clés mais pas de leurs valeurs peut éviter complètement de transférer les valeurs. Les deux fonctions s'attaquent au même problème de fond : les grosses lectures sont la chose la plus coûteuse qu'un plan de contrôle fasse en routine.
Les autres améliorations, plus discrètes
Le reste de la version est le genre de maintenance qui paie pendant des années. FastLeaseKeepAlive accélère le renouvellement de bail en évitant d'attendre l'index appliqué, ce qui aide les nombreux baux à courte durée de vie qu'un cluster brasse. Le serveur démarre maintenant entièrement depuis le magasin v3 et ne dépend plus du magasin v2 hérité au démarrage, éliminant un vieux bagage historique. On trouve la prise en charge des points de terminaison sur socket Unix, si bien que des composants locaux peuvent parler à etcd sans aucun port TCP. Et une passe de nettoyage remplace plusieurs bibliothèques protobuf obsolètes par des versions maintenues, invisible au quotidien mais décisif la prochaine fois qu'un correctif de sécurité devra arriver en amont.
Mis bout à bout, les utilisateurs de Kubernetes devraient voir la charge CPU globale de leurs membres etcd baisser par rapport à 3.6, avant même d'activer la moindre fonction.
La réserve, et quoi en faire
Voici la partie à garder en tête avant que quiconque ne dépose une demande de changement promettant un soulagement immédiat. Les gains d'efficacité généraux arrivent dès que vous passez en 3.7. Le bénéfice de RangeStream, précisément, n'apparaît qu'une fois que le serveur d'API demande des plages en flux, et cette prise en charge arrive avec la future version Kubernetes v1.37, derrière le feature gate EtcdRangeStream. Sur le Kubernetes d'aujourd'hui, vous obtenez les améliorations larges mais pas le chemin de diffusion. Ce n'est pas une raison d'attendre, mais une raison d'être précis sur ce qui change et quand.
La discipline de migration est la discipline etcd habituelle, en plus stricte encore, car etcd est sous tout ce que vous faites tourner. Lisez les notes de version pour votre saut de version exact. Prenez un instantané vérifié et confirmez que vous savez réellement le restaurer. Passez d'abord un cluster hors production en 3.7 et laissez-le porter du vrai trafic un moment. Rejouez votre exercice de sauvegarde et de restauration face à 3.7 précisément, car une procédure de restauration qui marchait sur 3.6 reste une hypothèse tant que vous ne l'avez pas reprouvée. C'est seulement là que la production a du sens.
Rien de tout cela n'est palpitant, et c'est bien l'idée. etcd est le composant où la bonne posture est patiente et ennuyeuse, et cette version récompense les exploitants qui la traitent ainsi, tout en rendant discrètement un plan de contrôle chargé moins cher à faire tourner.
Sources et pour aller plus loin
- Blog Kubernetes : Announcing etcd v3.7.0
- Blog etcd : etcd v3.7.0-rc.0 now available for testing
- Versions d'etcd sur GitHub
Questions fréquentes
Qu'est-ce qu'etcd et pourquoi la version compte-t-elle ?
etcd est un magasin clé-valeur distribué qui contient tout l'état désiré d'un cluster Kubernetes, si bien que chaque objet créé y transite. C'est le composant le plus sensible à la latence et au CPU d'un plan de contrôle. Une nouvelle version d'etcd change la charge que votre plan de contrôle peut encaisser avant de faiblir, ce qui explique pourquoi les exploitants de clusters suivent ces versions de près.
Qu'est-ce que RangeStream et en quoi cela aide-t-il ?
RangeStream permet à etcd de renvoyer une requête de plage volumineuse sous forme de flux de petits fragments, au lieu d'assembler une énorme réponse en mémoire. Les grosses requêtes de liste, comme lister tous les pods d'un grand cluster, sont une cause classique de pics de mémoire et de latence sur le serveur d'API et sur etcd. Diffuser le résultat garde la mémoire de pointe plus plate et lisse la charge que ces requêtes créent.
Migrer vers 3.7 réduira-t-il immédiatement ma charge CPU ?
En partie. etcd v3.7.0 apporte des gains d'efficacité généraux que les utilisateurs de Kubernetes devraient ressentir comme une baisse de la charge CPU globale de leurs membres etcd par rapport à 3.6. Le bénéfice propre à RangeStream ne devient disponible qu'avec la future version Kubernetes v1.37, avec le feature gate EtcdRangeStream activé, puisque le serveur d'API doit demander des plages en flux. D'ici là, vous obtenez les autres améliorations mais pas celle-là.
Qu'a-t-on changé d'autre dans etcd 3.7 ?
Plusieurs éléments plus discrets mais utiles. Les requêtes de plage clés seules permettent de récupérer seulement les clés sans leurs valeurs. FastLeaseKeepAlive accélère le renouvellement de bail en évitant d'attendre l'index appliqué. Le serveur démarre désormais entièrement depuis le magasin v3 et abandonne sa dépendance au magasin v2 hérité au démarrage. On trouve aussi la prise en charge des points de terminaison sur socket Unix pour une communication locale sans port TCP, et un nettoyage qui remplace des bibliothèques protobuf obsolètes par des versions maintenues.
Faut-il précipiter cette migration en production ?
Traitez-la comme toute migration d'etcd, c'est-à-dire avec soin. etcd est sous tout le reste, donc le chemin raisonnable est de lire les notes de version, prendre un instantané vérifié, migrer d'abord un cluster hors production, et confirmer que votre exercice de sauvegarde et de restauration fonctionne toujours sur 3.7 avant de toucher à la production. Les gains sont réels, mais etcd est le dernier endroit où avancer vite en espérant que ça passe.