Kubernetes lança versões novas várias vezes por ano e mantém cada uma por pouco mais de um ano. É um ritmo que não permite ficar parado: um cluster que passa dois ciclos sem atualizar já está fora de suporte, e voltar exige atravessar várias versões em sequência, sem pular nenhuma.
O resultado previsível é o cluster de quatro versões atrás que ninguém quer tocar — e que agora precisa de um projeto, não de uma janela.
A boa notícia: upgrade planejado é rotina chata. O que o torna arriscado é a falta de método, e o método cabe em um artigo.
O que quebra de verdade
Upgrade de Kubernetes raramente quebra o cluster. Quebra as aplicações, e quase sempre por um motivo: API removida.
O ciclo de vida de uma API é conhecido: ela é marcada como depreciada, continua funcionando por várias versões com aviso, e então é removida. No dia da remoção, qualquer manifesto que ainda a usa simplesmente falha — e o que falha não é só a sua aplicação: é qualquer componente instalado no cluster que não acompanhou.
As outras causas, em ordem:
- Componentes de terceiros incompatíveis com a versão nova: driver de rede, driver de storage, controlador de entrada, operadores, ferramenta de monitoramento.
- Mudança de comportamento padrão entre versões.
- Recurso que era experimental e mudou de forma ao se estabilizar.
- Incompatibilidade de versão entre plano de controle e nós além do permitido.
Antes do upgrade: encontrar o que vai quebrar
Esta é a fase que decide o resultado, e ela acontece semanas antes.
1. Varrer os manifestos em busca de API depreciada. Existem ferramentas dedicadas que analisam tanto os arquivos do repositório quanto o que está efetivamente rodando no cluster. Rode as duas análises — o repositório mostra o que você mantém; o cluster mostra o que terceiros instalaram.
Esse segundo ponto é onde mora a surpresa: os gráficos de implantação que você instalou meses atrás trazem manifestos próprios, e eles envelhecem sem ninguém olhar.
2. Ler as notas da versão, especificamente a seção de mudanças que exigem ação. É leitura tediosa e é onde estão os avisos que importam.
3. Inventariar os componentes de infraestrutura com a versão de cada um, e verificar a matriz de compatibilidade de cada fornecedor com a versão de destino. Normalmente, alguns deles precisam ser atualizados antes do cluster, não depois.
4. Verificar a distância de versão entre plano de controle e nós. Há um limite de quantas versões eles podem divergir, e ele determina a ordem e o ritmo.
5. Confirmar backup dos objetos do cluster, dos volumes e — em cluster autogerenciado — do armazenamento de estado do plano de controle. Sem isso, não há caminho de volta.
A ordem dos componentes
A sequência importa e não é intuitiva:
- Componentes de infraestrutura que exigem versão mais nova, atualizados antes do cluster.
- Plano de controle, um nó por vez em cluster com múltiplos.
- Componentes que acompanham a versão do plano de controle.
- Nós de trabalho, em lotes.
- Componentes que exigiam a versão nova do cluster, atualizados depois.
- Aplicações, se houve mudança de API.
O plano de controle sempre vai primeiro entre os dois planos. Nó mais novo que o plano de controle não é suportado.
Atualizar os nós: duas estratégias
No lugar. O nó é drenado, atualizado e devolvido ao cluster. Menos recursos, mais rápido, e o rollback de um nó com problema é trabalhoso.
Substituição. Nós novos com a versão nova entram no cluster, as cargas migram, os antigos são removidos. Exige capacidade extra temporária e oferece o melhor rollback possível: os nós antigos ainda estão lá.
Em ambiente com capacidade disponível, substituição é a estratégia preferível, especialmente para o primeiro upgrade de uma versão maior. É também o desenho natural quando o cluster roda sobre virtualização — criar VMs novas e descartar as antigas é barato.
Em qualquer das duas, a drenagem correta é o que evita indisponibilidade:
- Orçamento de disrupção definido em todas as aplicações importantes, garantindo um mínimo de réplicas disponíveis durante o processo.
- Mais de uma réplica nas aplicações críticas. Réplica única com orçamento de disrupção configurado trava a drenagem — ou o nó não esvazia, ou a aplicação cai.
- Encerramento gracioso, para as conexões em andamento terminarem.
- Um lote por vez, com validação entre eles.
- Atenção aos pods com estado, que precisam de volume acessível no destino.
O ensaio
O upgrade acontece primeiro em um cluster que não é produção. Não é opcional — é o que transforma o processo em rotina.
O ambiente de ensaio precisa ter a mesma versão de origem, os mesmos componentes de infraestrutura e cargas representativas. Um cluster de teste vazio não ensina nada, porque o que quebra são as aplicações e os operadores.
Durante o ensaio, cronometre cada etapa e anote cada surpresa. O roteiro de produção sai daí.
A janela e a observação
O upgrade em si costuma ser tranquilo. O que exige atenção é o período depois:
- Janela com equipe disponível, não na sexta à noite.
- Validação por etapa, não só ao final.
- Fumaça nas aplicações críticas após cada lote de nós.
- Observação reforçada por alguns dias — mudanças de comportamento sutis aparecem sob carga real, não no teste.
- Comparar métricas com a linha de base anterior: latência, uso de recurso, taxa de erro.
O plano de volta
Honestidade necessária: downgrade de plano de controle não é um caminho suportado. Isso muda a natureza do plano de volta.
O que existe de verdade:
- Nós antigos preservados, se a estratégia foi substituição. É o rollback real e o motivo principal para preferi-la.
- Backup do estado do cluster, restaurável em cluster novo. É recuperação de desastre, não rollback rápido — mas é o que existe quando nada mais funciona.
- Rollback de aplicação, que é quase sempre suficiente, porque o problema costuma ser da aplicação e não do cluster.
- Critério de abortar escrito antes: o que caracteriza falha, quem decide.
A consequência prática: o esforço se concentra na preparação, porque a reversão é limitada. É o inverso de um deploy de aplicação, onde se pode arriscar mais contando com o botão de voltar.
A cadência que evita o projeto
O erro estrutural é tratar upgrade como evento excepcional. A correção é transformá-lo em rotina:
- Uma versão a cada poucos meses, acompanhando o ritmo do projeto.
- Nunca mais de duas versões atrasado, para não sair do suporte.
- Nunca pular versão maior. Não é suportado; é preciso passar por cada uma.
- Verificação contínua de API depreciada no pipeline, falhando o build quando alguém introduz uma versão de API prestes a sumir. É o controle que mais economiza trabalho — ele impede a dívida de se formar.
- Inventário de versões dos componentes de infraestrutura, revisado a cada ciclo.
O item da verificação no pipeline merece destaque: ele muda o problema de "descobrir o que vai quebrar antes do upgrade" para "nunca deixar entrar o que vai quebrar". É a diferença entre arqueologia e prevenção.
Gerenciado é diferente, mas não é automático
Em Kubernetes gerenciado, o provedor cuida do plano de controle. Isso remove uma parte do trabalho e não remove:
- Encontrar e corrigir API depreciada nos seus manifestos e nos de terceiros.
- Atualizar os componentes de infraestrutura que você instalou.
- Gerenciar a atualização dos nós de trabalho.
- Testar as aplicações.
E adiciona uma restrição própria: o provedor tem calendário de fim de suporte e pode forçar a atualização. Vale conhecer as datas e planejar antes de ser surpreendido por uma janela que você não escolheu.
Erros comuns
- Deixar o cluster atrasar várias versões e transformar o upgrade em projeto.
- Não varrer API depreciada, nem no repositório nem no que está rodando.
- Esquecer os manifestos trazidos por gráficos de terceiros.
- Não verificar a matriz de compatibilidade dos componentes de infraestrutura.
- Atualizar nós antes do plano de controle.
- Ultrapassar o limite de divergência de versão entre planos.
- Aplicações com réplica única travando a drenagem.
- Nenhum orçamento de disrupção definido.
- Ensaiar em cluster vazio, sem cargas representativas.
- Contar com downgrade do plano de controle, que não existe.
- Não preservar os nós antigos quando a estratégia permitiria.
- Upgrade na sexta à noite, sem equipe.
- Não comparar métricas com a linha de base depois.
- Em cluster gerenciado, achar que o provedor cuida de tudo.
Onde a Solvefy/Cloud entra
Conduzimos upgrades de cluster com o método completo: varredura de API depreciada no repositório e no cluster em execução, inventário e matriz de compatibilidade dos componentes de infraestrutura, ensaio em ambiente com cargas representativas e tempos cronometrados, estratégia de nós por substituição quando há capacidade, orçamentos de disrupção corrigidos antes, janela com validação por etapa e observação pós-upgrade. E implantamos a verificação contínua no pipeline, que é o que impede o cluster de voltar a atrasar.
Há quantas versões o seu cluster está atrasado? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.