O seu control plane está pronto para o Crossplane v2?

O Crossplane v2 não é só uma atualização de versão: é uma reescrita estrutural do modelo de abstração. Enquanto a v1 tratava infraestrutura como um domínio isolado, a v2 funde aplicações e infra em uma única camada de composição, agora qualquer recurso Kubernetes pode ser incluído em uma Composition, desde Secrets até Deployments. Isso elimina a necessidade de orquestradores paralelos (como Argo CD + Crossplane) para entregar pilhas completas. A mudança para recursos namespaced por padrão também não é só técnica: reduz drasticamente o risco de conflito entre equipes em ambientes multi-tenant, já que XRs e MRs passam a obedecer ao mesmo modelo de RBAC e escopo que os recursos nativos.

As Operations são o novo ponto de entrada para lógica operacional contínua, não mais apenas 'criar e esquecer'. Elas transformam tarefas como renovação de certificados ou rotação de chaves em pipelines observáveis, executados como Jobs com saída estruturada. Isso alinha o Crossplane diretamente com práticas modernas de SRE, onde a confiabilidade depende menos de estado estático e mais de capacidade de resposta a eventos. O comando crossplane beta upgrade check, lançado na v1.20.9, é a primeira peça concreta dessa transição: ele não apenas lista incompatibilidades, mas mapeia cada recurso problemático (ex: um Composition usando patch-and-transform) para a alternativa equivalente na v2 (ex: uma função de pipeline com o novo runtime de funções).

A cobertura anterior do CEVIU sobre o Kubernetes v1.36 (5/2026) mostrou a consolidação da validação declarativa como GA, um movimento paralelo ao do Crossplane v2, que agora leva essa ideia além dos tipos nativos: as Compositions v2 passam a suportar validação declarativa integrada via OpenAPI v3, com erros reportados diretamente no status do recurso composto. Também há evolução direta em relação à cobertura sobre o Claude Code na AWS (6/2026): enquanto aquele artigo destacou auditorias paralelas em IaC, o upgrade check do Crossplane é a primeira ferramenta de análise estática *específica para control planes*, com foco em compatibilidade semântica, não só sintática, ela entende o impacto de remover o ControllerConfig ou external secret stores no fluxo real de provisionamento.

Equipes que usam Crossplane para construir plataformas internas precisam entender que migrar para a v2 não é um 'upgrade' técnico, mas uma mudança de contrato operacional. A remoção do patch-and-transform composition exige reescrita de lógicas de personalização; a adoção de namespaces padrão força revisão de políticas de rede e RBAC; e as Operations exigem novos padrões de observabilidade, não basta monitorar o estado do XR, agora é preciso rastrear execuções de pipelines. Ignorar isso gera dívida técnica acumulada em abstrações que deixam de ser mantidas, aumentando o custo de operação em vez de reduzi-lo.