Se a sua operação utiliza containers sobre Oracle Linux 7 (OL7), janeiro de 2025 marcou uma transição silenciosa, mas crítica. A versão x86_64 do OL7 entrou oficialmente em Extended Support (ES), com previsão de término em junho de 2028.
Embora correções críticas e de segurança continuem sendo enviadas via RPMs de suporte estendido, as imagens oficiais de OL7 deixaram de ser atualizadas em dezembro de 2024. Para empresas brasileiras que buscam previsibilidade operacional e conformidade, esse movimento exige uma revisão imediata dos pipelines de infraestrutura.
Somado a isso, o lançamento do Kubernetes 1.35 em dezembro de 2025 trouxe a padronização do cgroup v2 — uma tecnologia que o OL7 não suporta nativamente. Com a iminente chegada da versão 1.35 ao Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE), a modernização do sistema operacional deixa de ser opcional.
Vamos analisar os impactos práticos dessa mudança para o seu ambiente.
O impacto direto no OKE e no ciclo de vida de patches
Ainda é possível utilizar OL7 no OKE, mas a entrada no Extended Support altera a dinâmica de manutenção. As imagens estão "congeladas". Isso significa que a responsabilidade pela aplicação de patches mudou: em vez de simplesmente fazer o pull de uma nova imagem atualizada, o time de engenharia deve garantir que os RPMs de ES sejam aplicados durante o processo de build ou na inicialização do node.
A partir do Kubernetes 1.35, o OKE exigirá imagens Oracle Linux 8 (OL8) ou superiores. O OL7 não terá suporte na versão 1.35 e posteriores. Além disso, as Platform Images (tanto OL7 quanto OL8 padrão) não serão suportadas a partir desta versão.
Quanto ao cgroup v2, há uma mudança crítica de usabilidade: o kubelet não será inicializado em sistemas que não ofereçam suporte a essa versão dos cgroups. Para evitar falhas em upgrades e downtimes não planejados, a transição do OS deve ser planejada antes da migração para o Kubernetes 1.35.
Nota: Este post reflete o estado do suporte no momento da publicação. Para o ciclo de vida atualizado do Oracle Linux e versões suportadas do OKE, consulte a documentação oficial da Oracle antes de realizar alterações.
Plano de Ação: Do Inventário à Migração
O primeiro passo para gestores de TI é realizar um inventário rigoroso: onde o OL7 ainda aparece? Verifique imagens em pipelines de CI/CD e node pools em clusters ativos.
Se a sua empresa pretende se manter nas versões 1.33 ou 1.34 por enquanto, é fundamental fixar as imagens de OL7 de dezembro de 2024 e integrar os updates de ES ao seu fluxo. Isso inclui habilitar os repositórios de Extended Support para que scanners de vulnerabilidades e gerenciadores de pacotes identifiquem as correções, além de realizar o deploy via digest para garantir paridade entre o que foi escaneado e o que está rodando.
Ao planejar a subida para o Kubernetes 1.35, a migração de imagens OKE OL7 para OL8 deve ser tratada como um pré-requisito. Como não existe upgrade de OS in-place para nodes, o caminho recomendado é a estratégia de Blue/Green em nível de pool:
- Provisione um novo node pool pequeno com OL8.
- Migre serviços menos críticos para validar configurações de
containerd,systemd, flags dekubelet, e compatibilidade de CNI/CSI. - Após a validação, escale os pools OL8 e utilize
cordonedrainnos nodes OL7. - O OKE só permitirá o upgrade para a versão 1.35 quando todos os node pools estiverem em conformidade (OL8+).
Cronograma Estratégico
- Dezembro de 2024: Última atualização de imagem OL7.
- Janeiro de 2025: Início do Extended Support do OL7; atualizações trimestrais para K8s 1.33 e 1.34 continuam.
- Dezembro de 2025: Lançamento do Kubernetes 1.35 com exigência de cgroup v2.
- Até Junho de 2028: Janela final de suporte estendido para o OL7.
Por que essa mudança gera valor?
Embora exija esforço de engenharia, a transição fortalece a postura de segurança e eficiência operacional:
- Times de Plataforma: Maior controle, já que o OKE bloqueia upgrades arriscados, garantindo que o 1.35 rode em uma base estável.
- Times de Aplicação: Ganham um caminho de migração com salvaguardas, testando em OL8 antes do switch final.
- Segurança e Compliance: Patches de ES integrados ao build garantem auditoria simplificada. O uso de Cloud Guard e Vulnerability Scanning permite comprovar a integridade do ambiente mesmo durante a transição.
Em resumo: se o Kubernetes 1.35 está no seu roadmap, inicie o piloto com OL8 agora. Se a prioridade é a estabilidade nas versões atuais, refine seus processos de correção via Extended Support.
Artigo originalmente publicado por Jordan Spore em cloud-infrastructure.
