Kubernetes 1.21 estabiliza CronJob e prepara troca de políticas

Kubernetes 1.21 chegou como a primeira versão do ano e reforça a imagem de uma plataforma que amadurece pela disciplina operacional. O release inclui 51 enhancements: 13 graduados para stable, 16 em beta, 20 em alpha e duas depreciações.¹

A lista é ampla, mas três temas merecem atenção imediata de quem mantém clusters: CronJob finalmente estável, dual-stack IPv4/IPv6 em beta e a depreciação de PodSecurityPolicy. Juntos, eles mostram o Kubernetes avançando em duas frentes: consolidar APIs usadas todos os dias e retirar mecanismos que já não acompanham a forma como a plataforma é operada em produção.

CronJob deixa de ser aposta beta

CronJob está em beta desde o Kubernetes 1.8 e é uma das APIs mais comuns fora do caminho principal de Deployments e Services. Backups, relatórios, rotinas de limpeza, reconciliações periódicas e tarefas administrativas dependem desse modelo de execução agendada.¹

A graduação para stable reduz incerteza em ambientes que já usam CronJob como peça de operação. Em Kubernetes, estabilidade de API não é apenas rótulo; ela afeta expectativas de compatibilidade, documentação, suporte de ferramentas e confiança para padronizar workloads em produção.

O ganho também é cultural. Muitos clusters cresceram com scripts externos, crontabs em servidores administrativos ou automações acopladas a pipelines. CronJob estável reforça a ideia de que tarefas recorrentes podem ser declaradas dentro do mesmo plano de controle que governa o restante da aplicação, com observabilidade, histórico e políticas consistentes.

Segurança muda de mecanismo

A depreciação de PodSecurityPolicy exige mais cautela. PSP sempre foi uma peça importante para restringir o que Pods podiam fazer: privilégios, capabilities, volumes, execução como root e outras propriedades sensíveis. Ao mesmo tempo, era uma API difícil de operar, com comportamento que podia surpreender equipes e integrações.

Kubernetes 1.21 não remove PSP de imediato, mas a depreciação é aviso claro. Organizações precisam revisar como aplicam controles de admissão e política de segurança. Isso inclui alternativas como admission controllers, OPA Gatekeeper, Kyverno e políticas gerenciadas por distribuições ou provedores cloud.

O ponto não é apenas trocar YAML. Políticas de Pod são parte do modelo de ameaça do cluster. Uma revisão séria precisa responder quais namespaces podem executar containers privilegiados, como imagens são restringidas, que workloads acessam hostPath, quem pode criar ServiceAccounts e quais exceções são aceitáveis para observabilidade, storage ou rede.

Maturidade aparece nos detalhes

O release também torna Secrets e ConfigMaps imutáveis em stable, permitindo rejeitar alterações depois da criação. Isso ajuda em aplicações que exigem configuração previsível e reduz pressão sobre o servidor de API em escala, já que controladores não precisam observar mudanças nesses objetos da mesma forma.¹

Dual-stack IPv4/IPv6 avançou para beta e passa a ficar habilitado por padrão, um passo importante para operadores que lidam com escassez de IPv4, redes híbridas e requisitos de conectividade mais modernos.¹ Ainda é uma área que demanda testes de CNI, balanceadores, políticas de rede e observabilidade antes de adoção ampla.

Para equipes de plataforma, Kubernetes 1.21 pede um plano simples e concreto. Inventariar CronJobs existentes, padronizar templates, validar controllers, revisar políticas de segurança e acompanhar a substituição de PSP devem entrar no ciclo de upgrade. A versão traz novidades, mas o trabalho principal é reduzir surpresa.

Kubernetes continua a evoluir como infraestrutura compartilhada. O que diferencia clusters maduros não é adotar cada feature no dia do lançamento; é entender quais APIs viraram contrato de produção e quais precisam sair antes que a próxima janela de upgrade transforme depreciação em bloqueio.