Crossplane Provider for OCI agora suporta Crossplane v2: impacto para plataformas Kubernetes no Brasil

Crossplane Provider for OCI agora suporta Crossplane v2: impacto para plataformas Kubernetes no Brasil

TL;DR: O Crossplane Provider for OCI foi atualizado para suportar o Crossplane v2, introduzindo recursos gerenciados namespaced, políticas de observação sem mutação e controle granular de reconciliação. Para empresas brasileiras que gerenciam infraestrutura multi-cloud com Kubernetes, isso significa possibilitar que times de aplicação provisionem recursos OCI de forma isolada, enquanto o time de plataforma mantém controle centralizado. A principal conclusão é que a migração planejada e testes em não-produção são essenciais devido a breaking changes.

Por que o Crossplane é relevante para quem opera OCI?

Aplicativos modernos frequentemente cruzam fronteiras entre recursos Kubernetes e serviços de cloud. Quando desenvolvedores precisam alternar entre manifests do Kubernetes e ferramentas de infrastructure-as-code, os workflows se fragmentam. O Crossplane é um framework open-source que estende o Kubernetes para gerenciar infraestrutura cloud via APIs nativas do K8s. Com o Provider for OCI, times podem usar um único control plane baseado em Kubernetes tanto para aplicações quanto para infraestrutura na Oracle Cloud.

Por que esta release importa?

O Crossplane v2 introduz recursos namespaced como padrão de primeira classe. Isso muda o jogo para platform teams: em vez de escolher entre uma configuração centralizada ou workflows isolados, agora é possível combinar configuração cluster-level com definições de recursos e credenciais em nível de namespace. O resultado é uma forma mais Kubernetes-nativa de oferecer recursos OCI para times de aplicação.

O que há de novo?

• Suporte ao Crossplane v2: Provider alinhado com os novos padrões de plataforma.
• Recursos gerenciados dual-scope: Podem ser usados tanto no formato legado cluster-scoped quanto no novo namespaced.
• Isolamento por namespace: Cada time pode criar recursos em seu próprio namespace, com ProviderConfig separado para credenciais.
• Management policies: Recursos podem ser observados sem serem alterados ou deletados pelo Crossplane.
• Reconciliação configurável: Intervalos de polling e taxa de reconciliação ajustáveis.
• Exemplos e quickstarts atualizados: Incluem guias de migração.

Como começar?

A arquitetura de family provider permite instalar apenas os providers OCI necessários. O exemplo abaixo instala o family provider e o provider de Object Storage:

CopiarapiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: oracle-provider-family-oci
spec:
  package: ghcr.io/oracle/provider-family-oci:v1.0.1
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-oci-objectstorage
spec:
  package: ghcr.io/oracle/provider-oci-objectstorage:v1.0.1

Verifique se os providers estão instalados e saudáveis com kubectl get providers.

Exemplo 1: Recurso namespaced para isolamento de time

CopiarapiVersion: objectstorage.oci.m.upbound.io/v1alpha1
kind: Bucket
metadata:
  name: app-team-a-bucket
  namespace: app-team-a
spec:
  forProvider:
    compartmentId: <compartment-ocid>
    name: app-team-a-crossplane
    namespace: <oci-object-storage-namespace>
  providerConfigRef:
    kind: ProviderConfig
    name: app-team-a

Se providerConfigRef for omitido, o recurso usará o ClusterProviderConfig padrão.

Exemplo 2: Observar recursos OCI existentes sem assumir ownership

CopiarapiVersion: kms.oci.m.upbound.io/v1alpha1
kind: Vault
metadata:
  name: shared-vault
  namespace: app-team-a
  annotations:
    crossplane.io/external-name: <existing-vault-external-name>
spec:
  managementPolicies:
  - Observe
  forProvider:
    compartmentId: <compartment-ocid>
    displayName: shared-vault
  providerConfigRef:
    kind: ProviderConfig
    name: app-team-a

Com managementPolicies: Observe, o Crossplane apenas lê o estado do recurso externo e reporta via Kubernetes, sem corrigir drift ou deletar.

Exemplo 3: Ajustar comportamento de reconciliação

Ambientes grandes podem precisar equilibrar velocidade de reconciliação com consumo de API e recursos do controller. O release adiciona suporte para configurar poll interval e max reconcile rate:

CopiarapiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
  name: oci-provider-runtime
spec:
  deploymentTemplate:
    spec:
      selector: {}
      template:
        spec:
          containers:
          - name: package-runtime
            args:
            - --poll=10m
            - --max-reconcile-rate=4
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-oci-objectstorage
spec:
  package: ghcr.io/oracle/provider-oci-objectstorage:v1.0.1
  runtimeConfigRef:
    name: oci-provider-runtime

Use intervalos menores para detectar drift mais rápido; intervalos maiores para reduzir atividade do controller em estado estável.

Considerações sobre upgrade

Como esta release inclui a migração para Crossplane v2, planeje upgrades com cuidado:

• Teste em ambiente não-produção primeiro.
• Claims do Crossplane v1 não são suportados no novo padrão; use composite resources namespaced.
• Use o grupo de API namespaced (ex.: objectstorage.oci.m.upbound.io) para novos recursos.
• Recursos cluster-scoped legados podem continuar usando o grupo de API antigo enquanto planeja a migração.
• Revise nomes de providers, ProviderConfig, secrets e managed resources antes de fazer alterações.

Próximos passos

Experimente o quickstart atualizado em um cluster de teste, crie um bucket namespaced e avalie onde as management policies observe-only podem ajudar a trazer recursos OCI existentes para seu workflow de plataforma. Compartilhe feedback no GitHub e acompanhe as releases para se manter atualizado.

Perguntas Frequentes

• Quais são os principais benefícios do suporte ao Crossplane v2 no Provider OCI?

  • O benefício central é a adoção de recursos gerenciados namespaced, permitindo que diferentes times de aplicação provisionem recursos OCI isoladamente em seus próprios namespaces, com credenciais e limites de acesso separados. Além disso, as management policies permitem observar recursos existentes sem alterá-los, e o controle de reconciliação possibilita ajustar taxa de polling para balancear uso de API e consumo de recursos do controller.

• Como funciona o recurso de observação sem gerenciamento (Observe management policy)?

  • Ao definir managementPolicies: [Observe] no recurso gerenciado, o Crossplane apenas lê o estado do recurso OCI existente e o expõe via APIs Kubernetes, sem corrigir drift, alterar configurações ou deletar o recurso. É útil para trazer infraestrutura legada (criada por Terraform ou Console) para visibilidade Kubernetes sem risco de modificação acidental.

• Quais cuidados devo tomar ao atualizar para a nova versão?

  • A migração para Crossplane v2 inclui breaking changes. As claims do Crossplane v1 não são suportadas no novo padrão; é preciso usar composite resources namespaced. Recomenda-se testar em ambiente não-produção, revisar ProviderConfig, secrets e managed resources antes da migração, e usar o grupo de API namespaced (ex.: objectstorage.oci.m.upbound.io) para novos recursos.

• O que significa um recurso gerenciado namespaced e como ele difere do cluster-scoped?

  • Um recurso namespaced existe dentro de um namespace específico do Kubernetes, permitindo que times de aplicação gerenciem recursos OCI de forma isolada e self-service. Já o cluster-scoped é global ao cluster, geralmente usado por platform teams para infraestrutura compartilhada. O novo provider suporta ambos os escopos, facilitando a adoção gradual.

---

Artigo originalmente publicado por Jeetendra Kukreja em cloud-infrastructure.