Kubernetes v1.33 introduit les réponses de liste en streaming pour réduire l'utilisation mémoire du serveur API

Dans un article publié sur le blog Kubernetes en mai 2025, les mainteneurs Marek Siarkowicz et Wei Fu ont décrit une modification architecturale majeure dans Kubernetes v1.33. Cette mise à jour introduit un encodage en streaming pour les réponses List, une fonctionnalité conçue pour réduire drastiquement la consommation mémoire du serveur API lors du traitement de grands jeux de données. Cette amélioration répond aux problèmes de stabilité persistants dans les clusters à grande échelle, où la récupération de listes de ressources étendues risquait auparavant de provoquer des erreurs de manque de mémoire (out-of-memory).

Ce qui s'est passé

L'exploitation de grands clusters Kubernetes a toujours impliqué de gérer le compromis entre l'accessibilité des données et la consommation de ressources. L'un des défis les plus persistants a été le traitement des requêtes List, qui récupèrent des jeux de données substantiels depuis l'état du cluster. Dans les versions précédentes, le serveur API sérialisait l'intégralité d'une réponse dans un seul bloc contigu de mémoire avant de l'envoyer au client. Bien que HTTP/2 puisse diviser les réponses en trames plus petites pour la transmission, le serveur sous-jacent conservait le tampon de données complet en mémoire jusqu'à la fin du transfert entier. Cela signifiait que si la congestion réseau ralentissait le transfert, des centaines de mégaoctets de mémoire restaient verrouillés pendant des secondes ou des minutes.

Cette inefficacité est devenue critique à grande échelle. Lorsque plusieurs grandes requêtes List se produisaient simultanément, l'utilisation cumulative de la mémoire pouvait augmenter rapidement, entraînant des situations de manque de mémoire (OOM) qui compromettaient la stabilité du cluster. Le problème était aggravé par la gestion de la mémoire par le package encoding/json de Go. Il utilise sync.Pool pour réutiliser les tampons, ce qui est efficace pour les charges de travail stables mais problématique pour les réponses volumineuses sporadiques. Une fois qu'une grande réponse avait agrandi le pool de mémoire, ces tampons surdimensionnés restaient réservés pour les requêtes suivantes de petite taille, empêchant le ramassage des ordures (garbage collection) et maintenant une utilisation de la mémoire artificiellement élevée bien après la fin de la charge lourde.

Comment cela fonctionne

Le nouvel encodeur en streaming modifie la façon dont le serveur API traite les réponses List en se concentrant sur le champ Items, qui contient la majeure partie des données dans les structures de collection. Au lieu d'encoder l'ensemble du tableau comme un bloc monolithique, le serveur traite et transmet désormais chaque élément individuellement. À mesure que chaque fragment est envoyé au client, la mémoire associée est libérée immédiatement. Cette approche incrémentale garantit que l'empreinte mémoire du serveur API reste prévisible et gérable, quel que soit le nombre total d'objets dans la liste.

Comme les objets Kubernetes sont généralement limités à 1,5 MiB dans etcd, le streaming maintient les allocations mémoire individuelles petites. Le système maintient une compatibilité ascendante stricte en validant les balises de structure Go avant l'activation, garantissant que la sortie est identique octet par octet à celle de l'encodeur original. L'encodage standard continue de traiter tous les champs sauf Items, de sorte que les clients n'ont pas besoin de modifier leur code ni même d'être conscients que le mécanisme sous-jacent a changé. Cette intégration transparente prend en charge tous les types de listes Kubernetes, y compris les listes intégrées et les UnstructuredLists de ressources personnalisées.

Détails clés

• Version : La fonctionnalité a été introduite dans Kubernetes v1.33, annoncée en mai 2025.
• Réduction mémoire : Les benchmarks ont montré une amélioration de 20 fois de l'utilisation mémoire pour les opérations de listes volumineuses, passant de 70-80 Go à seulement 3 Go.
• Mécanisme : L'encodeur diffuse les éléments individuels dans le champ Items plutôt que de sérialiser tout le tableau d'un coup.
• Compatibilité : Aucun changement côté client n'est requis ; la sortie reste cohérente octet par octet avec les versions précédentes.
• Déclencheur : L'encodeur en streaming ne s'active qu'après une validation rigoureuse des balises de structure pour garantir la sécurité.
• Portée : Elle s'applique à tous les types de listes Kubernetes, y compris les ressources standard et les ressources personnalisées.

Pourquoi c'est important

Pour les ingénieurs qui construisent et maintiennent des infrastructures Kubernetes à grande échelle, cette mise à jour impacte directement la fiabilité et l'efficacité des coûts. Une utilisation élevée de la mémoire dans kube-apiserver oblige souvent les équipes à surprovisionner le matériel pour gérer les pics de charge, augmentant ainsi les coûts opérationnels. En réduisant l'empreinte mémoire des grandes requêtes List dans une telle mesure, les organisations peuvent exécuter des plans de contrôle plus légers sans sacrifier les performances. Cela réduit également le risque de tueries OOM inattendues, qui peuvent causer des perturbations de service et compliquer les efforts de débogage lors de la réponse aux incidents.

De plus, ce changement améliore la prévisibilité du comportement du cluster sous charge. Dans les environnements où les outils de surveillance, les contrôleurs ou les pipelines CI/CD listent fréquemment un grand nombre de ressources, les pics de mémoire précédents pouvaient créer des défaillances en cascade. Avec l'encodage en streaming, ces opérations ne retiennent plus une mémoire excessive pendant les retards de transmission. Cela permet au serveur API de gérer plus de requêtes concurrentes et des jeux de données plus importants sans heurts, facilitant la montée en charge des clusters pour prendre en charge des milliers de nœuds et des dizaines de milliers de pods.

Ce que vous pouvez faire

• Mettez à niveau votre plan de contrôle vers Kubernetes v1.33 ou une version ultérieure pour bénéficier de l'encodeur en streaming.
• Surveillez l'utilisation mémoire de kube-apiserver lors des grandes opérations List pour observer la réduction de la consommation maximale.
• Examinez les contrôleurs ou opérateurs personnalisés qui effectuent de grandes appels List pour vous assurer qu'ils gèrent correctement les réponses en streaming, bien qu'aucun changement de code ne soit strictement nécessaire.
• Vérifiez les paramètres de l'horizontal pod autoscaler de votre cluster, car une charge réduite du serveur API peut permettre des seuils de mise à l'échelle plus serrés.
• Validez que votre pile de surveillance ne dépend pas de tailles de tampon fixes pour l'analyse des réponses API, bien que la compatibilité octet par octet devrait prévenir les problèmes.
• Envisagez d'ajuster les demandes et limites de ressources pour kube-apiserver si vous avez précédemment surprovisionné la mémoire pour atténuer les risques d'OOM.