Kubernetes 1.16 leva CRDs a GA e reforça extensibilidade

O Kubernetes 1.16 chega com CustomResourceDefinitions em General Availability, mudanças relevantes em métricas e novas capacidades de volume.¹ A versão também remove APIs depreciadas, o que torna o upgrade menos automático para clusters com manifests antigos.

CRDs em GA são o ponto central. Kubernetes já vinha sendo usado como plataforma extensível, onde operadores, controladores e produtos internos criam novos tipos de recurso. Ao estabilizar essa base, o projeto reconhece que extensibilidade não é acessório. É parte do modelo operacional.

CRDs viram contrato de plataforma

CustomResourceDefinitions permitem que equipes declarem recursos próprios no API Server e usem o padrão Kubernetes de reconciliação para operar domínios específicos. Isso viabiliza operadores de banco, filas, certificados, pipelines, políticas, ambientes e muitas outras abstrações.

Com GA, a expectativa de estabilidade aumenta. Equipes podem tratar CRDs como contrato de plataforma, não apenas como mecanismo experimental. Isso pressiona mantenedores a pensar em versionamento, validação de schema, compatibilidade e migração de recursos customizados.

Para empresas, o ganho é claro: a mesma superfície de API usada para Deployments e Services pode orquestrar capacidades internas. O risco também é claro: sem governança, cada time cria seus próprios tipos, controladores e convenções, transformando o cluster em coleção de extensões difíceis de auditar.

Métricas e volumes amadurecem a operação

O release também destaca revisão de métricas e extensões ligadas a volumes. Em clusters reais, observabilidade e armazenamento costumam ser fontes de incidente. Não basta iniciar pods. É preciso entender estado, saturação, latência, uso de recursos, expansão de volumes e comportamento de controladores.

Métricas mais consistentes ajudam SREs e times de plataforma a criar alertas menos frágeis. Recursos de volume avançam a capacidade de operar aplicações com estado, uma demanda constante de empresas que querem levar mais workloads para Kubernetes sem tratar tudo como stateless.

Esse amadurecimento mostra que o projeto está cada vez menos focado apenas em agendar containers. Kubernetes se consolida como plano de controle para aplicações distribuídas, extensões e infraestrutura ao redor delas.

Upgrade exige inventário de APIs

A parte menos confortável da versão é a remoção de APIs depreciadas. Clusters que ainda usam manifests antigos podem falhar no apply, em controladores ou em ferramentas de deploy. Esse é o tipo de mudança que separa uso experimental de operação profissional.

Antes de atualizar, equipes precisam inventariar recursos, revisar charts Helm, operadores, pipelines de CI/CD, templates internos e integrações com clientes Kubernetes. Também precisam testar em ambiente representativo, porque uma API removida pode estar escondida em dependência de terceiro.

Kubernetes 1.16 entrega avanço importante, mas cobra disciplina. CRDs em GA ampliam a confiança na extensibilidade; APIs removidas lembram que plataformas vivas têm ciclo de vida. Para quem opera clusters compartilhados, a mensagem é objetiva: trate a API do cluster como contrato versionado e faça upgrade com evidência, não com esperança.