Kubernetes 1.37 active les histogrammes natifs Prometheus et réduit la cardinalité des métriques de 90 %
Le 11 septembre 2026, Kubernetes 1.37 fait passer les histogrammes natifs Prometheus en beta, activés par défaut. Les métriques de latence exposent désormais des buckets exponentiels dynamiques qui réduisent le nombre de séries temporelles jusqu’à 90 %, à condition de suivre la migration en quatre étapes.
11 septembre 2026. Richa Banker (Google) annonce sur le blog Kubernetes que le support des histogrammes natifs Prometheus passe en beta, activé par défaut dans Kubernetes 1.37. Introduit en alpha dans la 1.36 sous KEP-5808, il remplace les buckets statiques par des buckets exponentiels dynamiques. Pourquoi c’est important : les histogrammes de latence sont les métriques les plus coûteuses d’un cluster, et la réduction de cardinalité promise atteint 90 %.
Le problème : deviner les buckets avant de voir la distribution
Depuis les débuts de l’observabilité Kubernetes, les métriques de durée et de latence — apiserver_request_duration_seconds, durées d’ordonnancement — reposent sur les histogrammes classiques Prometheus. Leur principe est connu : l’auteur de la métrique définit une liste statique de bornes de buckets via le label le, par exemple 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10.
Cette approche engendre trois défauts structurels, détaillés dans le billet.
Le jeu de devinette des buckets. Si le profil de latence d’une charge change — passage en microsecondes, ou traîne de queue qui dépasse le bucket le plus haut — l’histogramme perd toute visibilité. Définir les bornes à l’avance exige de connaître la distribution avant de l’observer, ce qui est par définition impossible au premier déploiement.
La cardinalité et le coût de stockage. Chaque borne est exportée comme une série temporelle distincte (_bucket{le="…"}). Un histogramme à dix buckets multiplie donc le nombre de séries par dix, ce qui gonfle la mémoire de Prometheus et le coût du TSDB.
L’erreur d’interpolation des quantiles. Le calcul des percentiles via histogram_quantile() repose sur une interpolation linéaire entre bornes statiques. Quand les intervalles sont larges, l’estimation des quantiles peut souffrir d’une erreur importante.
Ce que changent les histogrammes natifs
Les histogrammes natifs Prometheus remplacent les buckets statiques définis par l’utilisateur par des buckets exponentiels dynamiques. Au lieu d’émettre une série par borne, un histogramme natif est stocké comme une seule série temporelle contenant un schéma riche : spans positifs et négatifs, seuil zéro, facteurs d’échelle exponentiels.
Trois gains en découlent directement.
- Haute résolution automatique : les buckets exponentiels s’ajustent à toute plage de valeurs, de la nanoseconde à l’heure, sans configuration préalable ;
- Jusqu’à 90 % de séries en moins : en consolidant les buckets en spans structurés dans une seule série, la surcharge de scraping et de stockage s’effondre ;
- Quantiles précis : le calcul offre des bornes d’erreur mathématiques, environ 5 % d’erreur relative au pire cas avec les réglages par défaut.
Dans Kubernetes, le support est implémenté directement dans le sous-système de métriques partagé k8s.io/component-base/metrics. Tous les composants majeurs en héritent donc automatiquement : kube-apiserver, kube-scheduler, kubelet, kube-controller-manager et kube-proxy.
La double exposition, pour ne rien casser
Une exigence de conception de KEP-5808 était la rupture zéro pour les piles d’observabilité existantes. Quand la feature gate NativeHistograms est active, les composants Kubernetes utilisent une double exposition : les buckets classiques (h.Bucket) continuent d’être émis, tandis que les spans natifs (h.Schema, h.PositiveSpan) sont inclus dans la même charge utile Protobuf pour les collecteurs qui les comprennent.
Deux réglages par défaut méritent l’attention. Le BucketFactor est fixé à 1.1 : chaque bucket est au plus 10 % plus large que le précédent, ce qui garantit une erreur relative bornée d’environ 5 % que l’opération dure 1 milliseconde ou 10 secondes. Le MaxBucketNumber est plafonné à 160, en suivant les recommandations du SDK OpenTelemetry pour l’agrégation exponentielle en base 2, afin de protéger la mémoire même face à des distributions aberrantes.
Comment scraper les histogrammes natifs
La réponse courte : passez à Kubernetes 1.37, et ça marche. Le cluster émet déjà des métriques en double exposition. La configuration côté Prometheus dépend de votre version.
Prometheus 3.0+ (recommandé) utilise une configuration par job dans scrape_configs, car le flag global --enable-feature=native-histograms est déprécié depuis Prometheus 3.9 :
scrape_configs:
- job_name: 'kubernetes-apiservers'
scrape_native_histograms: true
always_scrape_classic_histograms: true # recommandé pendant la transitionLe réglage always_scrape_classic_histograms: true est obligatoire pendant la migration. Sans lui, Prometheus n’ingère plus les séries classiques _bucket, _count et _sum, et vos dashboards histogram_quantile(…_bucket…) s’éteignent du jour au lendemain.
Prometheus 2.40 – 2.x active les histogrammes natifs globalement via prometheus --enable-feature=native-histograms. C’est un réglage tout-ou-rien pour toutes les cibles de scrape, nettement moins souple.
Côté exposition, le scraping texte standard ne transfère que les buckets classiques. Quand scrape_native_histograms est actif, Prometheus négocie automatiquement le format Protobuf avec les endpoints Kubernetes. Une fois les histogrammes natifs ingérés, la requête change de forme : histogram_quantile(0.99, rate(apiserver_request_duration_seconds[5m])) opère directement sur la métrique, sans suffixe _bucket ni regroupement sum by (le).
La migration en quatre étapes
Richa Banker recommande un workflow précis pour basculer sans casser alertes ni dashboards.
- Activer les deux formats — dans la config Prometheus 3.x, poser
scrape_native_histograms: trueetalways_scrape_classic_histograms: true; - Migrer les requêtes — remplacer les requêtes classiques par les natives, et les références
_count/_sumparhistogram_count(…)ethistogram_sum(…); - Vérifier en staging et production — valider que dashboards et alertes SLO tracent correctement ;
- Débloquer ~10× d’économie — une fois la migration terminée, passer
always_scrape_classic_histograms: falsepour réduire le nombre de séries d’histogramme jusqu’à 90 %.
Le retour arrière est simple. Côté collecteur, scrape_native_histograms: false suffit, sans redémarrage Kubernetes ni perte de données. Côté composant, --feature-gates=NativeHistograms=false désactive la gate après un redémarrage.
Verdict
Kubernetes 1.37 ne force personne : la double exposition rend les histogrammes natifs opt-in côté collecteur, et le basculement est réversible à chaque étape. C’est précisément ce qui rend la migration sûre, à condition de ne jamais brûler l’étape always_scrape_classic_histograms: true.
Si vous tournez sous Prometheus 3.x, activez la double exposition dès aujourd’hui, migrez vos dashboards et alertes quantile par quantile, puis coupez les buckets classiques pour récupérer jusqu’à 90 % de séries et environ dix fois moins de stockage sur vos métriques de latence.
Si vous êtes encore sous Prometheus 2.x, n’activez pas le flag global tout-ou-rien : le risque de casser des alertes non migrées l’emporte sur le gain. Planifiez plutôt la montée vers Prometheus 3.x, où la bascule par job est propre et graduelle.