Kubernetes 1.37: o que quebra e quando chega no EKS

Operei alguns clusters EKS de produção e desenvolvimento, em ambiente regulado, e não tive quebra nos upgrades que conduzi. Minha forma de aplicar era testar em homologação primeiro e deixar a madrugada para produção. Mesmo assim, já paguei suporte estendido do EKS por alguns dias: quando faltou disponibilidade do time para atualizar antes de vencer o suporte padrão.

Esse é o contexto em que olho para o Kubernetes 1.37, Garhwal, lançado em 26 de agosto de 2026. Antes de escolher uma funcionalidade nova, preciso entender o risco da atualização e reservar um tempo para executar.

O que muda: a versão inclui 67 melhorias, com 16 promoções a estável. Para preparar o upgrade, vale revisar SELinux, APIs alpha removidas, configuração do kubelet e compatibilidade da Metrics API com o HPA. Em 07/09/2026, o EKS ainda oferece a 1.36 como versão mais nova; o AKS prevê a 1.37 em GA para outubro.

Escopo e pré-requisitos Não executei estes comandos contra um cluster 1.37. A análise usa documentação oficial conferida em 07/09/2026 e minha experiência com upgrades anteriores de EKS. As consultas são de leitura, exigem kubectl, jq e permissões adequadas; no trecho de EKS, também AWS CLI. Disponibilidade de APIs e configuração variam por ambiente.

Checagens antes do upgrade para Kubernetes 1.37

Comece levantando os pontos abaixo no cluster atual. Eles ajudam a montar o plano de atualização, mas não substituem a revisão dos addons, do runtime, das aplicações e das notas da versão do provedor.

1. Descubra em que modo o kube-proxy está

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep -i 'mode:'

Se aparecer mode: ipvs, planeje a migração de backend descrita mais abaixo. mode: iptables indica que essa configuração não seleciona IPVS.

Saída vazia não aprova a checagem. Confirme se o ConfigMap existe, se a chave é config.conf e se o processo lê esse arquivo. No EKS, a chave pode ser config; consulte o ConfigMap completo e os argumentos do DaemonSet. Erro de permissão ou configuração em outro lugar deixa o resultado inconclusivo.

2. Descubra se o servidor oferece a API alpha removida

kubectl get --raw /apis/scheduling.k8s.io | jq -r '.versions[].groupVersion'

Essa consulta lista versões servidas pelo API server, não os objetos armazenados nem os clientes que as usam. A 1.37 remove scheduling.k8s.io/v1alpha2; se ela aparecer, inventarie os recursos dessa versão:

kubectl get --raw /apis/scheduling.k8s.io/v1alpha2 | jq -r '.resources[] | select(.name | contains("/") | not) | [.name, .namespaced] | @tsv'

Use os nomes retornados para listar as instâncias, respeitando o escopo de namespace, e revise os manifests e clientes que usam v1alpha2. A preparação deve seguir o changelog antes da atualização. Um endpoint inexistente não é o mesmo que erro de autorização; nenhum dos dois deve ser interpretado como inventário concluído.

3. Levante candidatos a revisão de SELinux

kubectl get pods -A -o json \
  | jq -r '.items[]
    | select(.spec.securityContext.seLinuxOptions != null
      or any(.spec.containers[]?, .spec.initContainers[]?, .spec.ephemeralContainers[]?;
        .securityContext.seLinuxOptions != null or .securityContext.privileged == true))
    | "\(.metadata.namespace)/\(.metadata.name)"'

A lista inclui contexto no Pod, nos containers e containers privilegiados, mas ainda é uma triagem. Cruze os resultados com os PVCs compartilhados, os nós e o suporte do driver de volume. Ela não cobre templates de workloads sem Pods ativos.

Verifique getenforce nos nós Linux afetados. Disabled indica SELinux desligado; Permissive mantém SELinux ativo, sem impor as negações da política, e não deve ser tratado como Disabled. Mais abaixo explico as condições do conflito e as verificações específicas recomendadas pelo projeto.

4. Confira quais versões da Metrics API o cluster serve

kubectl get --raw /apis/metrics.k8s.io/ | jq -r '.versions[].groupVersion'

Guarde essa saída para comparar com a compatibilidade do HPA descrita mais abaixo. Se a API não existir ou a consulta retornar acesso negado, investigue a instalação do servidor de métricas e suas permissões antes de concluir.

5. No EKS, consulte os upgrade insights

É o que eu uso. O EKS roda cluster insights automaticamente em todo cluster, a cada 24 horas, e a categoria de upgrade insights existe exatamente para responder “o que me impede de subir de versão”. A AWS atualiza a lista de checagens a cada release do Kubernetes.

aws eks list-insights --cluster-name meu-cluster --region us-east-1

aws eks describe-insight --cluster-name meu-cluster --id ID_DO_INSIGHT --region us-east-1

Substitua meu-cluster, a região e ID_DO_INSIGHT pelos valores do seu ambiente. Leia o detalhe de cada insight e a versão de destino avaliada; a lista não certifica compatibilidade com uma versão que o provedor ainda não oferece.

Em um upgrade que conduzi, o insight apontou uma versão de addon gerenciado incompatível com a versão de destino antes da atualização do control plane. Esse caso me fez incluir a compatibilidade dos addons na preparação, junto da revisão das APIs e dos manifests.

Insights de rollback só existem por 7 dias Depois de subir a versão, o EKS passa a gerar também os rollback readiness insights, que avaliam se dá para voltar. Eles só são produzidos enquanto a janela de rollback de 7 dias estiver aberta. Escrevi sobre essa janela e o que ela cobre em rollback de versão no EKS.

Com esses resultados, você tem uma lista inicial de pontos a investigar. O próximo passo é entender quais mudanças se aplicam ao ambiente.

Mudanças que exigem atenção no Kubernetes 1.37

Os urgent upgrade notes do changelog destacam quatro ações. Elas incluem disponibilidade, volume de eventos e exposição de configuração; não são quatro quebras inevitáveis de workload.

SELinux: confira volumes compartilhados

O caminho de montagem com contexto evita a varredura recursiva de inodes, mas depende do contexto declarado, do PVC e do suporte do driver. Com CSI, confira spec.seLinuxMount no objeto CSIDriver.

No modelo recursivo, dois Pods com labels diferentes podem usar subPaths distintos de um mesmo volume. Essa condição faz diferença: não significa que qualquer compartilhamento com labels diferentes funcionava. Com montagem por contexto, esse cenário pode deixar um Pod em ContainerCreating. O compartilhamento entre Pod privilegiado e não privilegiado também exige atenção.

O comportamento depende do volume SELinuxMount era Beta e desabilitado por padrão na 1.36; na 1.37 é GA e vem habilitado. O caminho para volumes ReadWriteOncePod já tinha outra evolução. Não trate a versão do Kubernetes, sozinha, como prova de qual mecanismo seu volume usa.

Quando aplicável, spec.securityContext.seLinuxChangePolicy: Recursive permite optar pelo relabel recursivo. A mudança deve ser avaliada no template do workload, não apenas num Pod que será recriado. A orientação oficial de SELinux explica as condições e as métricas de conflito para planejar a migração.

Não habilite controladores nem altere políticas de SELinux em produção apenas para executar esta triagem. Valide o procedimento em homologação e, em serviço gerenciado, confirme o que o provedor permite observar e configurar.

API alpha removida e flag que inverteu

A mudança de DisruptionMode acompanha a passagem de scheduling.k8s.io/v1alpha2 para v1alpha3. A presença da versão no discovery é só o começo: o changelog exige tratar os objetos antigos antes de atualizar. Planeje também a adaptação dos clientes e manifests que ainda apontem para ela.

Já eventRecordQPS: 0 passa a significar ausência de limite. É uma correção para alinhar o comportamento à documentação, não uma nova intenção do campo. Para preservar o comportamento anterior de quem usava zero, o changelog indica definir um valor não zero, por exemplo 50.

O kubelet também passa a registrar a configuração efetiva ao iniciar. Revise quem pode ler logs de nó, incluindo permissões associadas a nodes/logs. O post sobre RBAC no Kubernetes ajuda a revisar essa autorização.

Static Pods e referências à API

Essa mudança não está nas urgent upgrade notes. O changelog registra a remoção do feature gate PreventStaticPodAPIReferences: static Pods deixam de referenciar recursos da API, e o comportamento não pode mais ser desligado. O aviso prévio da 1.37 detalha o recorte de configMapRef e secretRef.

Vale principalmente em cluster self-managed ou kubeadm, onde o control plane ainda usa static Pods. No EKS gerenciado, o control plane não é o seu; a checagem só entra se você mesmo mantém static Pods nos nós.

Funcionalidades estáveis e o que ainda está em Beta

Foram 16 promoções a estável. A seleção abaixo separa a maturidade das funcionalidades para não confundir disponibilidade com estabilidade.

O anúncio da release detalha os estágios. Ter uma API nativa para certificados não elimina a necessidade de implementar e operar a emissão.

A pegadinha da Metrics API

A metrics.k8s.io graduou para v1. Os tipos e os campos são idênticos ao v1beta1, é só a promoção de versão. Parece o item mais chato da lista e é justamente onde mora a armadilha.

O kubectl top já sabe conversar com as duas: prefere v1 e cai para v1beta1 se precisar. O HorizontalPodAutoscaler, não. Na 1.37 o HPA ainda fala apenas v1beta1. A seleção por discovery está planejada, mas não chegou.

Não migre o metrics-server só para v1 Se você trocar a implementação do metrics-server para servir exclusivamente v1.metrics.k8s.io, o kubectl top continua funcionando e o seu HPA para de escalar. A recomendação oficial é servir as duas versões durante a transição. Não tive esse problema em upgrades anteriores; aqui, a recomendação vem da documentação da 1.37.

Se você quiser entender de onde essas métricas realmente vêm antes de mexer nessa camada, escrevi sobre cAdvisor, kubelet e CRI.

Como seu cliente trata HTTP 429

O watch cache agora inicializa de forma resiliente. Quando ele está aquecendo, o API server delega o que consegue e recusa o excedente com HTTP 429, em vez de servir devagar e derrubar o etcd junto. É uma melhoria real de disponibilidade do control plane.

Revise como controllers, operators e integrações tratam HTTP 429, Retry-After e backoff. Usar bibliotecas oficiais ajuda, mas não comprova o comportamento da aplicação: confira versão, configuração e tratamento de erro. O mesmo vale para scripts próprios.

Teste contra um API server que recusa Vale mais simular a recusa num cluster de laboratório do que descobrir o comportamento em produção. Se você não tem onde brincar, subir um cluster local com o Kind resolve em poucos minutos.

Depreciação com relógio: IPVS

O modo IPVS do kube-proxy foi formalmente depreciado pelo KEP-5495, e o aviso de deprecações e remoções da 1.37 publicou o calendário:

• 1.37: o kube-proxy passa a logar aviso de depreciação no startup.
• 1.40: desabilitado por padrão, ainda selecionável por feature gate.
• 1.43: removido.

O argumento é honesto: a API de IPVS do kernel nunca deu conta de implementar Services sozinha, e o modo IPVS sempre continuou usando iptables por baixo. O destino é o backend nftables.

Quando a 1.37 chega no cluster que você opera

A disponibilidade depende do provedor. Os dados abaixo foram conferidos em 07/09/2026 e cobrem EKS e AKS; confirme novamente antes de agendar uma atualização.

Amazon EKS

O calendário oficial do EKS lista a 1.36 como versão mais nova, liberada em 02 de junho de 2026. A 1.37 ainda não tem data anunciada. O padrão histórico de atraso entre o lançamento upstream e a chegada no EKS foi de 36 dias na 1.34, 41 dias na 1.35 e 41 dias na 1.36. Aplicando isso à 1.37, o palpite razoável é outubro de 2026. É projeção minha a partir do histórico, não compromisso da AWS.

São 14 meses de suporte padrão mais 12 de estendido, 26 meses no total. O estendido vem ligado por padrão e cobra a mais por hora de cluster. É onde eu caí: não por não saber, mas por não ter gente disponível na janela certa.

Depois dos 26 meses a AWS atualiza sozinha No fim do suporte estendido, o control plane é atualizado automaticamente, sem aviso prévio e sem horário definido, e para a versão mais antiga ainda em suporte, não para a mais nova. O auto-upgrade toca só o control plane: managed node groups e nós self-managed continuam onde estavam, o que é uma receita pronta para version skew. Em cluster com EKS Auto Mode, os nós podem se atualizar sozinhos, o que muda o cenário mas não te devolve o controle da data.

Platform version não é versão do Kubernetes Se você viu eks.6 em algum lugar e ficou na dúvida: isso é a platform version, que descreve as capacidades do control plane gerenciado (quais flags do API server estão ligadas, qual patch está rodando). A AWS atualiza essa plataforma automaticamente; isso não dispensa acompanhar a saúde do cluster. aws eks describe-cluster --name meu-cluster --query cluster.platformVersion mostra a sua.

Azure AKS

O calendário oficial do AKS prevê as seguintes datas. Meses futuros são planejamento, sujeito a atualização:

A política do AKS é diferente da AWS: 12 meses de suporte comunitário para versão GA, seguindo a regra N-2 (a versão atual e as duas anteriores), mais um ano opcional de long-term support que você precisa habilitar. Fora disso existe ainda o platform support em N-3, que cobre problemas do Azure mas não cobre componentes do Kubernetes.

No AKS, a atualização entre versões menores suportadas não-LTS é sequencial: de 1.34 para 1.36, passe pela 1.35. Não interprete isso como autorização para pular versões no EKS; siga o procedimento de atualização do provedor.

O que eu faria hoje

Na minha rotina, a preparação do upgrade precisa disputar espaço no calendário antes de o suporte vencer. Foi isso que faltou quando fiquei alguns dias no suporte estendido. Para esta versão, eu começaria pelas dependências e condições que podem impedir a atualização.

O que eu faria, nesta ordem:

1. Executar as consultas iniciais e registrar resultados inconclusivos, permissões ausentes e APIs não disponíveis.
2. No EKS, revisar os insights e a compatibilidade dos addons com a versão de destino.
3. Reservar tempo antes do fim do suporte padrão da versão atual.
4. Testar em homologação com aplicações e condições representativas.
5. Em produção, seguir uma janela com equipe disponível e capacidade para o rollout. Nos ambientes que operei, eram poucas horas de madrugada, com a aplicação servindo e a meta de evitar downtime.
6. Conferir PodDisruptionBudgets, drain, capacidade e o procedimento de recuperação. No EKS, entender as condições da janela de rollback de sete dias antes de começar.

Minha preferência continua sendo manter uma cadência de atualização. A cada versão adiada, cresce o conjunto de APIs, addons e comportamentos que preciso revisar de uma vez. Os poucos dias de suporte estendido não pesaram na fatura, mas mostraram que o planejamento tinha ficado para trás. O caso do addon pego pelo insight reforçou o outro lado: revisar dependências antes da janela evita levar uma incompatibilidade conhecida para o upgrade.

Além disto, vale configurar um lembrete e alarmes para lembrar sobre a nova versão, quando ela ficar disponível dependendo do caso(por exemplo, AWS onde a versão 1.37 ainda não está disponível). Importante é não perder a mão e deixar no radar!