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, 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.