Crossplane: Infraestrutura como Código com Kubernetes — Construindo Plataformas Internas Modernas

A Evolução da Infraestrutura como Código

Nos últimos anos, a infraestrutura como código (IaC) evoluiu de scripts shell para ferramentas declarativas como Terraform e Pulumi. Mas mesmo essas soluções modernas têm limitações: cada equipe gerencia seus próprios estados, a governança é fragmentada e a experiência do desenvolvedor varia entre diferentes provedores de nuvem.

O Crossplane surge como uma alternativa radical: em vez de gerenciar infraestrutura com ferramentas externas, ele estende a API do Kubernetes para que qualquer recurso de nuvem — bancos de dados, filas, buckets S3, redes VPC — seja tratado como um objeto Kubernetes nativo. Isso significa que você usa o mesmo kubectl apply tanto para deployar uma aplicação quanto para provisionar um banco PostgreSQL gerenciado na AWS.

Desde que se tornou um projeto incubado da CNCF em 2021, o Crossplane tem sido adotado por empresas como Adidas, Ticketmaster e Upbound para construir plataformas internas de desenvolvedor que abstraem a complexidade da nuvem.

Como o Crossplane Funciona

Diferente de ferramentas tradicionais de IaC, o Crossplane não é um binário executado em pipelines de CI/CD. Ele é executado como um controlador dentro do cluster Kubernetes, monitorando constantemente o estado desejado e reconciliando os recursos externos.

Arquitetura em Três Camadas

• Providers: conectam o Crossplane a APIs externas — AWS, Azure, GCP, GitHub, Datadog, e muitos outros. Cada provider traduz objetos Kubernetes em chamadas de API para o serviço correspondente.
• Managed Resources (MRs): representam recursos reais de infraestrutura, como um Bucket S3, um Instance RDS ou um Database Cloud SQL. São objetos Kubernetes completos, com spec, status e condições.
• Compositions e Claims: a camada mais poderosa. Compositions permitem criar templates de infraestrutura que combinam múltiplos recursos. Claims são interfaces simplificadas que os desenvolvedores usam para solicitar infraestrutura — eles pedem um XPostgreSQL e recebem um banco completo com replicação, backup e monitoramento.

Exemplo Prático: Provisionando um Bucket S3

Com o Crossplane, criar um bucket S3 é tão simples quanto aplicar este manifesto Kubernetes:

apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
  name: meu-bucket-cron
spec:
  forProvider:
    region: us-east-1
    tags:
      Environment: production
      ManagedBy: Crossplane

Execute kubectl apply -f bucket.yaml e o Crossplane cuida do resto — cria o bucket na AWS, configura as políticas de acesso e atualiza o status do objeto com o endpoint e ARN.

Plataformas Internas com Compositions

O verdadeiro poder do Crossplane está nas Compositions. Elas permitem que a equipe de plataforma crie abstrações de alto nível que escondem a complexidade da infraestrutura subjacente.

Imagine que sua organização precisa de um padrão para bancos de dados PostgreSQL: instância RDS, bucket S3 para backups, secreto no Vault para credenciais, e alarmes no CloudWatch. Em vez de cada equipe criar isso manualmente, a plataforma define uma Composition que orquestra todos esses recursos:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgresql-composition
spec:
  resources:
    - name: database
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            engine: postgres
            engineVersion: "16"
            instanceClass: db.t3.medium
    - name: backup-bucket
      base:
        apiVersion: s3.aws.upbound.io/v1beta1
        kind: Bucket

Depois, os desenvolvedores solicitam um banco com um manifesto simples de 10 linhas, sem precisar saber detalhes de configuração RDS, VPC ou IAM.

Crossplane vs. Terraform

A comparação mais comum é com o Terraform, e cada ferramenta tem seus pontos fortes:

• Estado: Terraform mantém um arquivo de estado local ou remoto. Crossplane usa o etcd do Kubernetes como fonte da verdade, eliminando conflitos de estado.
• Operação: Terraform executa em pipelines — apply, destroy, refresh. Crossplane opera continuamente como um controlador, reconciliando divergências automaticamente.
• Multi-cloud: Ambos suportam múltiplos provedores, mas no Crossplane todos os recursos seguem o mesmo formato Kubernetes, independente do provedor.
• Governança: Crossplane se integra nativamente com RBAC do Kubernetes, políticas OPA/Gatekeeper e controllers de admissão.

Isso não significa que Crossplane substitui Terraform — em muitos casos, eles são complementares. Terraform é excelente para provisionamento inicial de infraestrutura base (VPCs, clusters), enquanto Crossplane brilha no dia-a-dia de autosserviço para equipes de desenvolvimento.

Instalando e Começando

Para experimentar o Crossplane, você precisa de um cluster Kubernetes (local com Kind ou Minikube já serve):

1. Instale o Crossplane: helm repo add crossplane-stable https://charts.crossplane.io/stable && helm install crossplane crossplane-stable/crossplane --namespace crossplane-system --create-namespace
2. Instale um provider: kubectl apply -f https://raw.githubusercontent.com/upbound/provider-aws/main/package/crds/provider.yaml
3. Crie credenciais: configure as chaves de API do provedor como uma Kubernetes Secret referenciada pelo ProviderConfig.
4. Provisione: aplique seus primeiros Managed Resources com kubectl apply.

Conclusão

O Crossplane representa uma mudança de paradigma na forma como pensamos infraestrutura como código. Ao integrar o provisionamento de recursos ao ecossistema Kubernetes, ele unifica a experiência de desenvolvedores e operadores em uma única plataforma.

Para organizações que já investem em Kubernetes, o Crossplane é o próximo passo natural na jornada de plataforma interna. Ele reduz o atrito entre times, padroniza a entrega de infraestrutura e permite que desenvolvedores se concentrem no que realmente importa: o produto.

Com o suporte da CNCF, uma comunidade ativa e casos de uso reais em empresas de grande porte, o Crossplane não é apenas mais uma ferramenta de IaC — é a base sobre a qual as plataformas internas do futuro serão construídas.