/ /

Começar

Página inicial do Docs

/ /

Atlas Kubernetes Operator

Começar

Página inicial do Docs

Gestão

Atlas Kubernetes Operator

Começar

Migrar parâmetros para definições de recursos personalizados

Começando com o Atlas Kubernetes Operator versão 2.6, várias configurações de recursos que anteriormente assumiam a forma de parâmetros fizeram a transição para CRDs próprios. O suporte para a configuração do recurso pai baseado em parâmetros está obsoleto. As configurações existentes de recursos pai baseados em parâmetros continuarão funcionando, mas o suporte para essas configurações será removido em uma versão futura.

Para continuar gerenciando estes recursos pelo Atlas Kubernetes Operator no futuro, migre para o CRD apropriado.

Configurações afetadas

As seguintes configurações são afetadas:

Parâmetro	CRD
`spec.customRoles`	`AtlasCustomRole` Recurso personalizado
`spec.privateEndpoints`	`AtlasPrivateEndpoint` Recurso personalizado
`spec.projectIpAccessList`	`AtlasIPAccessList` Recurso personalizado
`spec.networkPeers`	`AtlasNetworkPeering` Recurso personalizado
`spec.networkPeers.containerId`	`AtlasNetworkContainer` Recurso personalizado
`spec.integrations`	`AtlasThirdPartyIntegration` Recurso personalizado

Considerações específicas do recurso

Antes de migrar parâmetros para recursos, considere quaisquer detalhes de implementação específicos para esses parâmetros.

Emparelhamento de rede

As seguintes considerações se aplicam a recursos do atlasNetworkPeering:

Um atlasNetworkPeering CRD pode se referir ao seu atlasNetworkContainer correspondente por uma referência de nome ou ID do Kubernetes.
Um CRD do atlasNetworkPeering pode referir-se ao atlasProject que o hospeda por uma referência de nome ou ID do Kubernetes.
O parâmetro spec.networkPeers de um atlasProject CRD contém detalhes da própria conexão de emparelhamento e do contêiner que a suporta. Ao migrar desse parâmetro para um CRD atlasNetworkPeering, talvez seja necessário criar um CRD atlasNetworkContainer para o container compatível. Para saber mais, consulte Contêiner de rede.

Container de rede

As seguintes considerações se aplicam a recursos do atlasNetworkContainer:

Você não precisa criar um novo recurso atlasNetworkContainer ao migrar a conexão atlasNetworkPeering de um parâmetro para um recurso se:
- Você gerencia o container de rede suportando uma conexão atlasNetworkPeering fora do Atlas Kubernetes Operator atlasProject no qual você gerencia a conexão atlasNetworkPeering
- Já existe um recurso atlasNetworkContainer para o contêiner da conexão atlasNetworkPeering.
Um atlasNetworkContainer CRD pode se referir a seu host atlasProject por uma referência de nome ou ID do Kubernetes.

Integrações de terceiros

As seguintes considerações se aplicam a recursos do AtlasThirdPartyIntegration:

Cada integração de terceiros requer seu próprio recurso AtlasThirdPartyIntegration. Não é possível definir várias integrações no mesmo recurso.
Cada projeto pode ter apenas uma instância de um tipo específico de integração de terceiros, seja configurada por uma entrada spec.integrations desse tipo em seu recurso AtlasProject ou por um recurso AtlasThirdPartyIntegration com spec.type desse valor .
Por exemplo, se você tiver um AtlasThirdPartyIntegration CRD de spec.type DATADOG, não poderá declarar um spec.integrations.type de DATADOG em seu recurso AtlasProject.

Procedimento de migração

Para migrar do gerenciamento de recursos em nível de parâmetros para o gerenciamento CRD:

Desative a reconciliação do projeto e edite as referências do subrecurso.

Adicione a anotação mongodb.com/atlas-reconciliation-policy: "skip" ao metadata do recurso pai. Isto impede que o Atlas Kubernetes Operator tente reconciliar o recurso principal e os seus sub-recursos.
Para evitar conflitos com o novo CRD criado, você deve excluir os parâmetros correspondentes ao recurso que deseja migrar do recurso pai.

Considere o seguinte exemplo de um atlasProject com uma configuração customRoles:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  customRoles:
    role:
      name: my-role
      actions:
        - name: getShardMap
          resources:
            cluster: true
        - name: shardingState
          resources:
            cluster: true
        - name: connPoolStats
          resources:
            cluster: true
        - name: getLog
          resources:
            cluster: true
        inheritedRoles:
          - name: operator-role-1
            role: backup
   projectIpAccessList:
     - cidrBlock: "203.0.113.0/24"
       comment: "CIDR block for Application Server B - D"

Certifique-se de ter adicionado o bloco annotations nas linhas 5 e 6 e removido o bloco customRoles mostrado no exemplo anterior.

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
annotations:
  mongodb.com/atlas-reconciliation-policy: "skip"
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "203.0.113.0/24"
      comment: "CIDR block for Application Server B - D"

Aviso

Se você não aplicar esta anotação, o Atlas Kubernetes Operator continuará tentando tentar a reconciliação à medida que você modifica seus outros recursos. Para usuários com Novo Padrão: Proteção Contra Exclusão no Atlas Kubernetes Operator 2.0 desabilitado, isso pode fazer com que o Atlas Kubernetes Operator remova o projeto do Atlas quando você remover o atlasProject recurso ou insira um estado bloqueado tentando remover um projeto com subrecursos ativos como usuários ou sistemas de banco de dados de dados.

Exclua os parâmetros do CRD principal.

Para evitar conflitos com o novo CRD criado, você deve primeiro excluir os parâmetros correspondentes ao recurso que deseja migrar do recurso pai. Por exemplo, remova o parâmetro customRoles do CRD atlasProject mostrado anteriormente:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
 name: my-project
 annotations:
   mongodb.com/atlas-reconciliation-policy: "skip"
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "203.0.113.0/24"
  comment: "CIDR block for Application Server B - D"

Crie o novo CRD.

Crie um CRD do kind apropriado para o parâmetro que você deseja migrar, de acordo com sua sintaxe. Por exemplo, para migrar o customRoles parâmetro do atlasProject CRD mostrado anteriormente, crie um AtlasCustomRole Recurso Personalizado.

apiVersion: atlas.mongodb.com/v1
kind: AtlasCustomRole
metadata:
  name: shard-operator-role
  namespace: mongodb-atlas-system
labels:
  mongodb.com/atlas-reconciliation-policy: keep
spec:
  projectRef:
    name: my-project
    namespace: my-operator-namespace
role:
  name: my-role
  actions:
    - name: getShardMap
      resources:
        cluster: true
    - name: shardingState
      resources:
        cluster: true
    - name: connPoolStats
      resources:
        cluster: true
    - name: getLog
      resources:
        cluster: true
  inheritedRoles:
    - name: operator-role-1
      role: backup

Aguarde o Atlas Kubernetes Operator sincronizar o novo status do recurso.

Remova a `atlas-reconciliation-policy: "skip"` anotação.

Além disso, agora você pode configurar este recurso como um CRD independente.

Voltar

Definições de Recurso Personalizadas Independentes

Compatibilidade

Configurações afetadas

Considerações específicas do recurso

Emparelhamento de rede

Container de rede

Integrações de terceiros

Procedimento de migração

Aviso

Exclua os parâmetros do CRD principal.

Crie o novo CRD.

Aguarde o Atlas Kubernetes Operator sincronizar o novo status do recurso.

Remova a atlas-reconciliation-policy: "skip" anotação.

Remova a `atlas-reconciliation-policy: "skip"` anotação.