“A maioria dos CTOs pensa que upgrade de infraestrutura é fácil — até uma API ficar depreciada e ser necessário refazer várias esteiras de CI/CD.”

Esse início de 2026 está provando o ponto. O Kubernetes está empurrando a depreciação do Ingress NGINX, a obrigatoriedade de cgroups v2, mudanças de sintaxe em manifests que rodavam há anos sem ninguém mexer. Costumo dizer na minha roda de amigos que “todo software vai ser reescrito” — e o que parecia provocação virou rotina. Está acontecendo agora, em silêncio, em janelas de madrugada, em centenas de componentes internos na cloud que não podem cair.

Ontem terminamos uma dessas operações: o upgrade do cluster Kubernetes de um cliente do setor de saúde corporativa, da versão 1.31 para a 1.35 no OKE (Oracle Kubernetes Engine). Quatro saltos de versão, ambiente em produção, janela total de 3 horas fora do horário comercial. Esse artigo é o relato técnico — e estratégico — dessa operação.

O contexto: saúde corporativa rodando em containers

O cliente em questão opera serviços de saúde dentro de prédios de grandes empresas — atendimento ocupacional, agendamento de exames, ergonomia, prontuário. Toda a camada de software que sustenta essa operação (sistemas de atendimento e agendamento de pacientes) foi desenvolvida pela Audaz e roda em Kubernetes na Oracle Cloud Infrastructure.

Na prática: se o cluster cai, o atendimento de saúde para. E quando o cliente final do nosso cliente é uma multinacional com SLA contratual, “ficar fora do ar pra atualizar” não é decisão técnica — é decisão comercial.

Por que sair da 1.31 era inadiável

A 1.31 ainda funcionava. Mas funcionar não é critério em ambiente crítico. Os fatos que pesaram na decisão:

1. Janela de suporte do OKE é curta. O OKE geralmente mantém só três versões minor de Kubernetes ativas para novos clusters. Quando uma nova entra, a mais antiga sai. Ficar pra trás significa rodar um cluster sem patches de segurança — inaceitável para uma operação que lida com dados de saúde.

2. A 1.35 é uma quebra estrutural, não cosmética. A versão 1.35, apelidada de “Timbernetes” (The World Tree Release), exige cgroups v2 — ou seja, na prática, worker nodes têm que rodar Oracle Linux 8 ou superior. Não dá pra fazer upgrade in-place do sistema operacional dos nodes. Quem só descobre isso na hora do upgrade descobre tarde demais.

3. NGINX Ingress está em fim de vida. A comunidade Kubernetes anunciou que o Ingress NGINX deixa de receber manutenção em março de 2026 — sem mais releases, sem correções de bug, sem patch de segurança. Quem não planejou migração pra Gateway API ou alternativa suportada vai descobrir o problema do pior jeito possível: em produção, com vulnerabilidade conhecida e sem patch.

4. Ganhos operacionais reais. A 1.35 traz in-place Pod resource updates — dá pra ajustar requests e limits de CPU e memória sem reiniciar pods. Pra workloads stateful como sistemas de agendamento, isso reduz disrupção e acelera tuning de performance.

O desafio que não estava no roteiro: sintaxe

Quando se planeja um upgrade de Kubernetes, geralmente o pessoal foca nas peças óbvias — control plane, node pools, CNI, storage. O que mais consumiu engenharia nessa operação foi outra coisa: mudanças de sintaxe nos manifests.

Entre a 1.31 e a 1.35, vários campos de API mudaram de comportamento ou foram movidos. Declarações de imagem de container, especificações de recursos, configurações que rodavam há anos sem ninguém tocar — tudo precisou ser revisitado. Não é uma reescrita conceitual; é reescrita mesmo, manifest por manifest, pipeline por pipeline.

E é aqui que a frase do começo do artigo cobra seu preço:

“…é necessário refazer várias esteiras de CI/CD.”

É geralmente o que acontece. Cada pipeline que constrói imagem, cada chart Helm, cada template de deploy precisou ser validado contra a nova sintaxe. Não tem atalho. Não tem IA que faça isso de forma confiável sem revisão humana de quem entende o ambiente.

Como executamos: a engenharia por trás do “deu tudo certo”

Quando o cliente final só percebe o upgrade pelo grupo de WhatsApp, é porque a engenharia foi feita certo. O roteiro real:

1. Inventário e leitura de campo

Antes de qualquer kubectl, mapeamos cada node: imagem base, versão de kubelet, dependências de CNI, workloads stateful, jobs cron, integrações externas. Identificamos os pontos de risco — em especial qualquer node em OL7, que precisava sair antes da 1.35 chegar perto.

2. Skew policy respeitada, sem atalho

Kubernetes não permite saltos arbitrários entre versões. A partir da 1.28, worker nodes podem ficar até três versões atrás do control plane, mas não podem ir além disso, nem rodar versão mais nova que o control plane. Sair da 1.31 pra 1.35 é, na prática, uma sequência coreografada: control plane sobe, valida, worker nodes acompanham, valida, repete.

3. Migração de OS antes de tocar na 1.35

Como não dá pra fazer upgrade in-place do sistema operacional dos nodes, criamos node pools novos com imagem OKE OL8 (com cgroups v2 ativo), migramos workloads via cordon e drain, e só então retiramos os pools antigos. Esse trabalho preliminar é o que separa um upgrade tranquilo de um upgrade que vira incidente.

4. Refatoração de manifests e pipelines

Sintaxe nova, validação manifest por manifest, ajuste das esteiras de CI/CD que constroem e publicam as imagens. Sem isso, o cluster sobe — mas os deploys depois quebram.

5. Janela de 3 horas, fora do horário, com plano de rollback

A operação levou 3 horas porque o trabalho preliminar foi feito antes. Sem o inventário, sem a migração de OS prévia, sem a refatoração dos manifests testada em ambiente espelhado, essa mesma operação seria uma madrugada inteira — ou pior, um rollback às pressas com sistema de agendamento fora do ar no dia seguinte.

A reflexão estratégica: o ciclo não vai parar

O que aconteceu nessa operação vai acontecer em todo cluster Kubernetes em produção no Brasil nos próximos 12 meses. Quem está em 1.30, 1.31, 1.32 vai precisar mover. Quem usa NGINX Ingress vai precisar migrar. Quem ainda tem workers em OL7 vai precisar trocar a frota.

E essa é só a parte visível. Por baixo, tem uma fila de componentes internos da cloud que estão sendo reescritos em silêncio — operadores, CRDs, controllers, plugins de CNI, integrações de observabilidade. É por isso que insisto com meus pares: todo software vai ser reescrito. Costumo brincar que até o Notepad vai ser reescrito — e quando você olha pro Notepad do Windows hoje (abas, autosave, integração com IA), percebe que a piada já não é mais piada. Não é metáfora futurista; é o que está rolando geralmente, nos bastidores da infraestrutura cloud-native.

A pergunta pro CIO ou CTO não é se o upgrade vai ser necessário. É:

• Quem vai mapear o impacto de cada depreciação no nosso ambiente?
• Quem vai refatorar as pipelines quando a sintaxe mudar?
• Quem vai garantir que a janela seja de 3 horas e não de 3 dias?
• Quem vai sustentar essa cadência de upgrades — três por ano, pra sempre?

Empresas com time interno robusto fazem isso por dentro. Empresas que dependem de poucos especialistas, ou cujo time de TI já está sobrecarregado com a operação do dia a dia, acumulam dívida técnica em silêncio até o dia em que a dívida vence de uma vez só.

Como nossos clientes se beneficiam disso

Pros clientes da Audaz, esse ciclo não é problema. É rotina operacional.

Não dependem de um único especialista. Quem entende de Kubernetes, OKE, OL8, cgroups v2 e refatoração de manifests é um time — não uma pessoa que pode pedir demissão na semana errada.

Não pagam o custo de aprender errando. A primeira vez que uma equipe interna faz upgrade de Kubernetes em produção, ela aprende caro. Nossos clientes herdam o aprendizado de operações como essa, em ambientes financeiros e de saúde, sem absorver o custo da curva.

Janela curta, plano de rollback, zero surpresa. A operação descrita levou 3 horas porque o trabalho de preparação — inventário, migração de OS, refatoração de pipelines, ambiente espelhado — foi feito antes. É geralmente esse o padrão que entregamos.

Visão completa do stack. Rede, segurança, pipeline, aplicação. Não é o time de Kubernetes apontando pro time de rede que aponta pro time de aplicação. É um único parceiro técnico, responsável de ponta a ponta.

Onde está o seu cluster?

Se sua empresa roda Kubernetes em produção e você não tem certeza absoluta de em qual versão está, quando expira o suporte dela, ou se as suas pipelines vão sobreviver à próxima depreciação — esse é o momento de olhar com calma, antes de virar urgência.

A Audaz oferece avaliação de maturidade DevOps e Cloud Native: um diagnóstico técnico do seu ambiente Kubernetes, das suas pipelines e do seu plano de upgrades, com um roadmap concreto de modernização e mitigação de risco.

Se faz sentido conversar, fala com a gente.

Audaz Tecnologia — engenharia de precisão para infraestrutura crítica. DevOps, segurança e Cloud Native em ambientes que não podem parar.