---
title: "O Kubernetes 1.37 habilita histogramas nativos em versão Beta"
author: "Lígia Lemos Maia"
date: "2026-09-13 07:30:00-03"
category: "Tecnologia & Desenvolvimento"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/13/o-kubernetes-137-habilita-histogramas-nativos-em-versao-beta/md"
---

## Resumo
- O Kubernetes v1.37 promoveu os histogramas nativos ao estágio Beta e os habilitou por padrão.
- A implementação utiliza buckets exponenciais dinâmicos em vez de intervalos estáticos.
- O recurso pode reduzir em até 90% o número de séries temporais usadas pelas métricas.
- O mecanismo de dual exposition mantém métricas clássicas e nativas disponíveis ao mesmo tempo.
- O Kubernetes aplica BucketFactor de 1.1 e MaxBucketNumber de 160 como parâmetros padrão.
- O Prometheus v3.0 ou posterior suporta a transição com scrape_native_histograms habilitado.
- A recomendação é migrar dashboards e alertas gradualmente, mantendo a coleta clássica durante a adaptação.

---

Kubernetes v1.37, lançado em 26 de agosto de 2026, elevou o suporte a histogramas nativos para o estágio Beta e deixou o recurso habilitado por padrão. A mudança altera a forma como métricas de duração e latência podem ser organizadas e acompanhadas em clusters, justamente em uma área na qual cada observação precisa caber em uma linguagem compreensível para sistemas e pessoas. O anúncio não pede uma troca imediata de dashboards, nem transforma a operação em uma cerimônia de migração instantânea: ele apresenta uma transição compatível entre o formato clássico e o novo formato. O que está em jogo, portanto, é entender o que muda na coleta, onde o Kubernetes aplica a capacidade e quais passos reduzem o risco de uma adoção apressada. Este texto desbuga esses pontos e traduz a novidade para quem administra métricas no dia a dia.

## O que mudou na versão Beta

A promoção faz parte do KEP-5808, proposta de melhoria que orienta a implementação dos histogramas nativos no projeto. Em vez de organizar as observações apenas em intervalos definidos previamente, o recurso utiliza buckets exponenciais dinâmicos, isto é, faixas que acompanham a escala dos valores observados com uma progressão exponencial. Essa diferença ajuda a explicar por que o anúncio trata a novidade como uma alteração na estrutura das métricas, e não como uma simples opção de visualização. A implementação fica no subsistema k8s.io/component-base/metrics, o que leva o suporte automaticamente a componentes do Kubernetes, como o **kube-apiserver** e o kubelet. Para quem olha de fora, o detalhe parece interno; para quem acompanha um cluster, ele define onde a mudança começa a aparecer.

Essa base técnica também estabelece os limites usados pelo Kubernetes para controlar a representação dos dados. A configuração padrão aplica um **BucketFactor de 1.1**, associado a um erro relativo máximo de aproximadamente 5%, e um **MaxBucketNumber de 160**, que limita a quantidade de buckets para proteger a memória dos componentes. Um bucket é uma faixa usada para agrupar valores de uma métrica, como tempos de resposta; em um histograma, a distribuição dessas faixas ajuda a observar como os valores se espalham. A lógica é parecida com separar milhares de páginas em caixas, mas permitindo que as caixas mudem de tamanho conforme a escala, em vez de exigir divisões idênticas. Assim, a novidade combina flexibilidade de medição com limites explícitos, e esses limites conduzem a discussão sobre armazenamento.

## Menos séries sem abandonar o formato clássico

O principal efeito anunciado está na quantidade de séries temporais necessárias para registrar as métricas. A adoção dos histogramas nativos promete uma redução de até **90% no número de séries temporais**, o que conecta a alteração do formato ao trabalho de armazenamento e acompanhamento dos dados. Séries temporais são sequências de valores associadas a momentos sucessivos, como medições de duração observadas ao longo do tempo; quanto mais séries precisam ser mantidas, mais elementos entram na coleta e na consulta. O número divulgado não significa que toda instalação terá exatamente a mesma redução, porque o anúncio apresenta um limite de até 90%, mas deixa clara a dimensão da mudança pretendida. A pergunta prática passa a ser outra: como obter essa nova forma de representação sem romper o que já está funcionando?

A resposta do Kubernetes está no mecanismo chamado **dual exposition**, ou dupla exposição. Com ele, métricas clássicas e métricas nativas podem coexistir durante o período de transição, evitando que dashboards e alertas existentes deixem de funcionar de imediato. A escolha tem uma consequência operacional direta: a equipe pode observar o novo formato enquanto preserva o caminho conhecido para as ferramentas que ainda dependem das métricas clássicas. Em linguagem simples, é como manter duas legendas para o mesmo mapa enquanto os leitores aprendem uma nova convenção, sem obrigar todos a reaprenderem no mesmo dia. O anúncio oficial detalha essa convivência na [explicação sobre a promoção dos histogramas nativos](https://kubernetes.io/blog/2026/09/11/kubernetes-v1-37-native-histograms-beta), e essa compatibilidade prepara o próximo passo, que depende da ferramenta de coleta.

## O que muda para a coleta de métricas

Para interpretar o formato nativo, a coleta precisa estar preparada para recebê-lo. A transição é suportada pelo **Prometheus v3.0 ou posterior**, desde que a configuração scrape_native_histograms esteja habilitada. Raspagem, neste contexto, é o processo pelo qual uma ferramenta consulta os componentes e recolhe os valores publicados por eles; habilitar a opção significa permitir que essa coleta reconheça os histogramas nativos. O requisito não elimina a convivência com o formato clássico, pois o próprio Kubernetes mantém a dupla exposição para evitar que dashboards e alertas sejam interrompidos. A ordem das ações, portanto, importa: primeiro a equipe verifica a capacidade do coletor, depois decide onde acompanhar o formato nativo e só então avalia a substituição gradual de consultas específicas.

Essa dependência da coleta impede que a atualização seja tratada como uma troca meramente estética nos painéis. Uma métrica pode parecer familiar na tela, mas a forma como seus valores são agrupados influencia a leitura da distribuição, a consulta e a persistência dos dados. Por isso, a recomendação oficial é fazer uma **migração gradual dos dashboards e alertas**, mantendo a raspagem do formato clássico durante a transição. O caminho preserva uma referência conhecida enquanto a equipe aprende como os histogramas nativos aparecem nas ferramentas utilizadas. Em vez de imaginar uma porta que se fecha atrás da instalação, o operador deve pensar em duas portas abertas por um período controlado: uma conduz ao formato legado e outra ao formato nativo. Esse cuidado leva ao contexto mais amplo da versão Garhwal.

## Uma mudança inserida em uma atualização maior

Os histogramas nativos chegaram ao Beta dentro do Kubernetes v1.37, também chamado de **Garhwal**, que trouxe outras alterações para as interfaces de operação. A API metrics.k8s.io, usada para disponibilizar métricas relacionadas aos recursos do cluster, foi estabilizada depois de nove anos em Beta. A versão também promoveu para Beta o suporte a scale to zero no HorizontalPodAutoscaler, mecanismo que ajusta a quantidade de réplicas de uma aplicação, e introduziu o etcd RangeStream em Beta para otimizar o uso de memória em grandes coletas de dados. Esses itens não substituem a pauta dos histogramas, mas ajudam a localizar a novidade: a atualização mexe tanto na observabilidade quanto em partes da infraestrutura que sustentam a administração do cluster. É nesse conjunto que a decisão de migrar precisa ser tomada.

O próximo passo para uma equipe que usa o Kubernetes v1.37 é verificar se o coletor está no **Prometheus v3.0 ou posterior**, habilitar scrape_native_histograms quando a ferramenta estiver preparada e acompanhar os resultados ao lado da raspagem clássica. Dashboards e alertas não precisam ser convertidos em bloco, porque a dual exposition foi criada para manter os dois formatos disponíveis durante a adaptação. A redução anunciada de até 90% nas séries temporais explica por que a mudança merece ser testada, enquanto o BucketFactor de 1.1 e o MaxBucketNumber de 160 mostram que a medição segue parâmetros definidos. A pergunta que fica para o operador não é se deve apagar o passado, mas quais painéis podem aprender primeiro a nova linguagem sem perder a leitura que já orienta o trabalho.