Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
Empezar
Docs Home
/
Gestión
/
Operador de Atlas Kubernetes
/
Empezar
Docs Home
/
Gestión
/
Operador de Atlas Kubernetes
/
Empezar

Migrar parámetros a definiciones personalizadas de recursos

A partir de la versión 2.6 del Atlas Kubernetes Operator, varias configuraciones de recursos que antes se presentaban como parámetros han pasado a ser CRDs propias. El soporte para la configuración del recurso principal basada en parámetros está obsoleto. Las configuraciones existentes de recursos principales basadas en parámetros seguirán funcionando, pero el soporte para estas configuraciones se eliminará en una versión futura.

Para continuar administrando estos recursos a través de Atlas Kubernetes Operator en el futuro, migre al CRD apropiado.

Configuraciones afectadas

Las siguientes configuraciones se ven afectadas:

Parameter
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

Consideraciones específicas de los recursos

Antes de migrar parámetros a recursos, considera cualquier detalle de implementación específico de esos parámetros.

Emparejamiento de red

Las siguientes consideraciones se aplican a los recursos atlasNetworkPeering:

  • Un CRD atlasNetworkPeering puede referirse a su correspondiente atlasNetworkContainer mediante una referencia de nombre de Kubernetes o un ID.

  • Un CRD atlasNetworkPeering puede hacer referencia al atlasProject que lo aloja mediante un nombre o ID de Kubernetes.

  • El parámetro spec.networkPeers de un atlasProject CRD contiene detalles tanto de la conexión de emparejamiento en sí como del contenedor que la soporta. Cuando se migra de este parámetro a un atlasNetworkPeering CRD, es posible que tenga que crear un atlasNetworkContainer CRD para el contenedor que lo admite. Para aprender más, consulte Contenedor de red.

Contenedor de red

Las siguientes consideraciones se aplican a los recursos atlasNetworkContainer:

  • No necesitas crear un nuevo recurso atlasNetworkContainer cuando migres la conexión atlasNetworkPeering de un parámetro a un recurso si ocurre alguna de estas situaciones:

    • Administras el contenedor de red que admite una conexión atlasNetworkPeering fuera del Atlas Kubernetes Operator atlasProject en la que administras la conexión atlasNetworkPeering.

    • Ya existe un recurso atlasNetworkContainer para el contenedor de la conexión atlasNetworkPeering.

  • Un atlasNetworkContainer CRD puede referirse a su host atlasProject por referencia de nombre en Kubernetes o por ID.

Integraciones de terceros

Las siguientes consideraciones se aplican a los recursos AtlasThirdPartyIntegration:

  • Cada integración de terceros requiere su propio recurso AtlasThirdPartyIntegration. No se pueden definir múltiples integraciones en el mismo recurso.

  • Cada proyecto puede tener solo una instancia de un tipo particular de integración de terceros, ya sea configurada por una entrada de spec.integrations de ese tipo en tu recurso AtlasProject, o por un recurso AtlasThirdPartyIntegration con un spec.type de ese valor.

    Por ejemplo, si tienes un CRD de AtlasThirdPartyIntegration con spec.type DATADOG, no puedes declarar un spec.integrations.type de DATADOG en tu recurso AtlasProject.

Procedimiento de migración

Para migrar de la gestión de recursos a nivel de parámetro a la gestión de CRD:

1

Deshabilitar la conciliación de proyectos y editar las referencias de subrecursos.

  1. Agrega la anotación mongodb.com/atlas-reconciliation-policy: "skip" a la metadata del recurso principal. Esto impide que el Operador Kubernetes de Atlas intente conciliar el recurso principal y sus subrecursos.

  2. Para evitar conflictos con el nuevo CRD que cree, debe borrar los parámetros correspondientes al recurso que desea migrar del recurso principal.

Considera el siguiente ejemplo de un atlasProject con una configuración 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"

Asegúrate de que has agregado el bloque annotations en las líneas 5 y 6 y removiste el bloque customRoles mostrado en el ejemplo 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"

Advertencia

Si no aplicas esta anotación, el Atlas Kubernetes Operator continuará intentando la reconciliación a medida que modifiques tus otros recursos. Para los usuarios con New Default: Deletion Protection in Atlas Kubernetes Operator 2.0 deshabilitado, esto puede resultar en que el Atlas Kubernetes Operator remueva el proyecto Atlas cuando usted remueve el recurso atlasProject, o entrar en un estado bloqueado al intentar remover un proyecto con subrecursos activos como usuarios de base de datos o implementaciones.

2

Borre los parámetros del CRD principal.

Para evitar conflictos con el nuevo CRD que crees, primero debes borrar los parámetros correspondientes al recurso que deseas migrar del recurso principal. Por ejemplo, remover el parámetro customRoles del 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"
3

Crear la nueva CRD.

Crea un CRD del kind adecuado para el parámetro que deseas migrar, de acuerdo con su sintaxis. Por ejemplo, para migrar el parámetro customRoles del CRD atlasProject mostrado previamente, crea un 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
4

Espera a que Atlas Kubernetes Operator sincronice el nuevo estado del recurso.

5

Remueve la anotación atlas-reconciliation-policy: "skip".

Además, ahora puedes configurar este recurso como un CRD independiente.

Next

Overview

En esta página