Plataforma SQL corporativa no Kubernetes com Crossplane e Azure PostgreSQL

O Crossplane v2.2, lançado em março de 2026, é o verdadeiro alicerce técnico dessa plataforma SQL corporativa, não só por suportar o Azure PostgreSQL Flexible Server, mas por permitir que equipes definam servidores de banco de dados como recursos Kubernetes nativos: com composite resources (XRs), composition pipelines e validação de esquema em tempo de execução. Isso transforma um processo manual de configuração de 20, 25 parâmetros no provedor azurerm em um único manifesto YAML, alinhado ao GitOps. A arquitetura ativo-passivo descrita não depende de ferramentas externas para orquestração de failover: o Crossplane sincroniza estado entre regiões via Azure Resource Manager, enquanto o Fleet Manager com Cilium cross-cluster (prévia pública desde 25/05) garante que os serviços de aplicação se conectem ao endpoint primário ou secundário sem alterações de código, basta ajustar o DNS com Azure Traffic Manager.

A segurança não fica no nível do serviço isolado: private endpoints são provisionados como objetos Kubernetes gerenciados pelo Crossplane, e a autenticação via Azure AD é injetada diretamente no ConnectionSecret gerado automaticamente, eliminando credenciais estáticas em segredos do cluster. Essa camada de abstração também permite impor políticas de conformidade (ex: exigir zone-redundant HA em todas as instâncias de produção) diretamente no XRD (CompositeResourceDefinition), antes mesmo do deploy.

Em comparação com a cobertura anterior sobre múltiplas assinaturas Azure com Terraform (25/05), essa implantação troca o modelo imperativo de 'definir e aplicar' por um declarativo de 'observar e reconciliar'. O Terraform ainda exige scripts para lidar com falhas de rede ou atualizações de estado, enquanto o Crossplane opera continuamente no cluster, reagindo a drifts na infraestrutura real. Também há evolução frente à abordagem tradicional de operadores de banco de dados: aqui o PostgreSQL não roda *dentro* do Kubernetes, mas é gerenciado *como parte* dele, com SLA garantido pelo provedor nuvem, não pela equipe de plataforma.

Isso reduz o tempo médio de provisionamento de uma nova instância de PostgreSQL de horas para menos de 90 segundos, e, mais importante, elimina a necessidade de times de infraestrutura aprovar manualmente cada pedido de banco de dados. Desenvolvedores solicitam recursos via Pull Request em um repositório Git com um XR personalizado (ex: CorporatePostgreSQL), e o Crossplane lida com tudo: rede privada, firewall, backup geo-redundante, réplica DR e até rotulagem automática para auditoria. Em ambientes com dezenas de equipes e centenas de bancos de dados, essa padronização corta custos operacionais em até 40%, segundo relatos de empresas que migraram do Terraform + Jenkins para esse fluxo baseado em Kubernetes API e GitOps.