Kubernetes 1.33: O que Mudou de Verdade na Estrutura do Cluster

O Kubernetes v1.36 chegou com uma proposta clara: consolidar a plataforma para cenários mais exigentes, com mais controle de segurança, melhor observabilidade nativa e avanços concretos em scheduling, storage e gerenciamento de hardware. No total, são 70 melhorias, sendo 18 estáveis, 25 em beta e 25 em alpha. Na prática, isso significa uma versão que não apenas adiciona recursos, mas também reposiciona a experiência operacional do Kubernetes para clusters modernos, incluindo ambientes multi-tenant, workloads distribuídos e cargas de IA/HPC.

Se antes muita coisa dependia de integrações externas, webhooks, scripts e acesso privilegiado aos nós, o v1.36 dá mais um passo em direção a um modelo mais nativo, mais auditável e mais seguro. E isso importa especialmente para equipes de plataforma que precisam equilibrar agilidade, conformidade e resiliência operacional.

Entre os destaques desta versão, três eixos se sobressaem: segurança com menos privilégio, observabilidade nativa mais rica e infraestrutura mais preparada para workloads modernos. A seguir, os pontos que mais mudam a rotina de operação e desenvolvimento.

Segurança: menos privilégio, mais controle fino

Uma das mudanças mais relevantes do Kubernetes v1.36 é a autorização mais granular no kubelet. Na prática, isso reduz a necessidade de depender amplamente de permissões como nodes/proxy, permitindo um controle mais restrito sobre o que pode ser acessado no nó. Para times de segurança e plataforma, isso é importante porque diminui a superfície de ataque e melhora o alinhamento com políticas de acesso mínimo necessário.

Essa evolução faz diferença em ambientes com múltiplas equipes, clusters gerenciados e operações sujeitas a auditoria. Em vez de expor mais do que o necessário, o Kubernetes passa a oferecer uma abordagem mais refinada para interagir com o kubelet sem abrir mão de governança.

Outro avanço importante está no campo de políticas mutáveis de admission. Com MutatingAdmissionPolicies e o avanço de validation-gen, o ecossistema se move para um modelo mais declarativo, reduzindo dependências de lógica embarcada em webhooks customizados. Isso tende a simplificar manutenção, diminuir pontos de falha e tornar o comportamento mais previsível.

Também merece atenção o trabalho em SELinux volume labeling, que pode trazer ganhos de isolamento, mas exige cuidado operacional. Em ambientes com diferentes níveis de privilégio, uma auditoria mais atenta pode ser necessária para evitar conflitos entre Pods e políticas de segurança já existentes.

Observabilidade nativa mais forte para nós e componentes

O Kubernetes v1.36 amplia a capacidade de diagnóstico dentro da própria plataforma. Recursos como Node log query, ComponentStatusz e ComponentFlagz expandem a observabilidade nativa do plano de controle e dos nós, reduzindo a dependência de ferramentas auxiliares para entender o estado interno do cluster.

Para operadores, isso é valioso porque acelera a investigação de incidentes e melhora a visibilidade sobre componentes críticos. Em vez de recorrer imediatamente a SSH, buscas manuais em logs ou integrações externas, passa a existir mais contexto diretamente nas APIs do Kubernetes.

Esse movimento é especialmente útil em ambientes que exigem resposta rápida a falhas e maior padronização operacional. Também reforça uma tendência clara: o Kubernetes quer ser não só o orquestrador de workloads, mas também uma fonte mais rica de sinais operacionais confiáveis.

Health status de recursos alocados: diagnóstico mais inteligente

Outro destaque com impacto prático é o allocatedResourcesStatus, que passa a expor a saúde de recursos alocados no status do Pod. Isso melhora a capacidade de identificar problemas relacionados a hardware, especialmente em cenários com dispositivos especializados.

Na prática, isso ajuda a diagnosticar situações em que um Pod entra em crash loop não por erro de aplicação, mas por falha ou degradação do recurso alocado, como GPU, FPGA ou outro device. Esse tipo de visibilidade é extremamente útil para plataformas de IA, HPC e workloads sensíveis a hardware.

Quando a camada de orquestração consegue refletir melhor a saúde do recurso, o troubleshooting fica mais rápido e a operação menos reativa. Isso reduz tempo de indisponibilidade e facilita ações corretivas antes que o problema se espalhe.

Scheduling orientado a workload: um passo importante para cargas distribuídas

O avanço de Workload Aware Scheduling é outro ponto de peso no Kubernetes v1.36. A introdução de PodGroup e de avaliação atômica do grupo aproxima o agendamento do comportamento esperado por workloads distribuídos, especialmente aqueles que precisam ser tratados como uma unidade lógica.

Esse tipo de evolução faz diferença quando a aplicação não pode ser pensada apenas Pod a Pod. Em cargas distribuídas, o valor está na coordenação: o grupo precisa ser considerado como um todo para evitar fragmentação, desperdício de recursos ou alocação parcial que comprometa a execução.

Para clusters com GPU, HPC e modelos de IA, isso é particularmente relevante. O scheduling passa a caminhar em direção a uma experiência mais adequada para workloads complexos, que exigem precisão maior na alocação e melhor entendimento das dependências entre componentes.

DRA e hardware: maturidade crescente para IA e multi-tenancy

O avanço em DRA (Dynamic Resource Allocation) reforça a direção do Kubernetes em direção a um gerenciamento mais inteligente de hardware. Isso é especialmente importante em cenários com dispositivos compartilhados, como GPUs, onde a coordenação entre scheduler, controllers e workloads precisa ser mais precisa para entregar valor real.

Na prática, a maturidade crescente de DRA beneficia ambientes de IA e HPC ao permitir uma alocação mais compatível com o uso real do recurso. Isso também abre espaço para novos modelos de multi-tenancy, onde o isolamento e a entrega de hardware precisam acontecer com mais previsibilidade.

O ganho estratégico aqui é claro: quanto mais o Kubernetes consegue tratar hardware como recurso de primeira classe, menos dependência existe de soluções paralelas ou proprietárias para administrar esse tipo de infraestrutura.

Storage: OCI como volume source amplia possibilidades

No campo de storage, uma das novidades mais interessantes é o suporte a OCI como volume source. Isso permite montar conteúdo diretamente de registries OCI, ampliando o uso de artefatos como dados de aplicação.

Esse movimento dialoga com padrões modernos de distribuição de conteúdo e pode simplificar pipelines em que imagens, artefatos e dados precisam ser consumidos de forma mais integrada. Para equipes de plataforma, isso pode representar mais flexibilidade e menos acoplamento com soluções externas.

Ao mesmo tempo, o ecossistema segue reforçando a adoção de padrões mais maduros e compatíveis com a arquitetura cloud native atual, especialmente em ambientes que já tratam OCI artifacts como parte natural do fluxo de entrega.

PSI, cgroup v2 e Memory QoS: sinais melhores para autoscaling e contenção

A inclusão de PSI em cgroup v2 e as melhorias em Memory QoS reforçam a base para decisões mais inteligentes de contenção e escalabilidade. Esses sinais ajudam a tornar o comportamento do sistema mais observável em situações de pressão de recursos.

Isso é relevante porque o autoscaling depende de sinais confiáveis, e a gestão de memória, em particular, continua sendo uma das áreas mais sensíveis em clusters de produção. Melhor visibilidade tende a se traduzir em decisões mais estáveis e em menos surpresas durante picos de carga.

GA para namespaces de usuário: um avanço importante para isolamento

O suporte GA para namespaces de usuário é outro marco importante do Kubernetes v1.36. Em ambientes multi-tenant, essa capacidade ajuda a fortalecer isolamento e a construir modelos mais seguros de execução, especialmente quando diferentes grupos compartilham infraestrutura.

Para provedores de nuvem e plataformas internas, isso significa mais uma peça nativa para ampliar governança sem depender exclusivamente de camadas adicionais de abstração.

O que muda para quem opera Kubernetes em produção

O impacto desta versão vai além da novidade técnica. Do ponto de vista operacional, o Kubernetes v1.36 reduz a dependência de ferramentas auxiliares em algumas frentes e melhora a qualidade dos sinais nativos da plataforma. Isso pode diminuir custo operacional, simplificar troubleshooting e elevar a segurança geral do ambiente.

Para times de plataforma, o ganho é direto:

• menos necessidade de acesso amplo a nós e de soluções baseadas em SSH;
• mais precisão para diagnosticar falhas de hardware e recursos especializados;
• melhor base para workloads distribuídos e cargas de IA/HPC;
• mais observabilidade nativa sobre componentes e nós;
• maior aderência a modelos declarativos de mutação e validação.

As mudanças que exigem atenção imediata

Nem tudo é avanço sem custo. O Kubernetes v1.36 também traz mudanças que exigem atenção em ambientes legados e em bases instaladas há mais tempo. A principal delas é a remoção definitiva de gitRepo, que pode quebrar workloads ainda dependentes desse plugin.

Além disso, externalIPs foi depreciado e já carrega um aviso claro de que será removido no futuro. Isso significa que organizações que ainda dependem desse modelo precisam iniciar a migração o quanto antes, tanto por motivos técnicos quanto por compliance e manutenção.

Outro ponto importante é que vários recursos desta versão ainda estão em alpha. Eles são promissores, mas não devem ser tratados como produção sem uma avaliação criteriosa. Em outras palavras: há inovação forte, mas nem tudo deve ser adotado imediatamente em ambientes críticos.

Conclusão: uma versão que amadurece a base do Kubernetes

O Kubernetes v1.36 marca uma virada importante de maturidade em três frentes: segurança, observabilidade e infraestrutura para workloads modernos. A combinação de autorização fina no kubelet, saúde nativa de recursos alocados, avanços em scheduling orientado a workload, novas capacidades de observabilidade e evolução em DRA mostra um ecossistema mais pronto para cenários complexos.

Para quem opera clusters em produção, a mensagem é objetiva: esta é uma versão que pode reduzir dependências legadas, melhorar o diagnóstico de falhas e preparar melhor a plataforma para demandas de IA, multi-tenancy e cargas distribuídas. Ao mesmo tempo, as remoções e depreciações reforçam a necessidade de planejamento de upgrade e migração.

Em resumo, o Kubernetes v1.36 não é apenas mais uma atualização. É um sinal claro de para onde a plataforma está indo: menos improviso, mais nativo; menos privilégio, mais controle; menos incerteza operacional, mais inteligência para orquestrar o que realmente importa.