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 de recursos personalizadas

A partir de la versión 2.6 de Atlas Kubernetes Operator, varias configuraciones de recursos que antes se configuraban como parámetros se han convertido en sus propias CRD. La compatibilidad con la configuración de recursos principales basada en parámetros ha quedado obsoleta. Las configuraciones de recursos principales basadas en parámetros existentes seguirán funcionando, pero se eliminará la compatibilidad con estas configuraciones en una próxima versión.

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

especificaciones.roles personalizados

AtlasCustomRole Recurso personalizado

spec.privateEndpoints

AtlasPrivateEndpoint Recurso personalizado

especificación.proyectoIpAccessList

AtlasIPAccessList Recurso personalizado

especificación.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, considere los detalles de implementación específicos de esos parámetros.

Emparejamiento de red

Las siguientes consideraciones se aplican a los recursos atlasNetworkPeering:

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

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

  • El parámetro spec.networkPeers de un atlasProject CRD contiene detalles tanto de la conexión de peering como del contenedor que la soporta. Al migrar de este parámetro a un atlasNetworkPeering CRD, es posible que deba crear un atlasNetworkContainer CRD para el contenedor que lo soporta. Para obtener más información, consulte Contenedor de red.

Contenedor de red

Las siguientes consideraciones se aplican a los recursos atlasNetworkContainer:

  • No es necesario crear un nuevo recurso atlasNetworkContainer cuando migra la conexión atlasNetworkPeering de un parámetro a un recurso si:

    • Administra el contenedor de red que admite una conexión atlasNetworkPeering fuera del operador Atlas Kubernetes atlasProject en el que administra 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 varias integraciones en el mismo recurso.

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

    Por ejemplo, si tiene un CRD AtlasThirdPartyIntegration de spec.type DATADOG, no puede declarar un spec.integrations.type de DATADOG en su recurso AtlasProject.

Procedimiento de migración

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

1

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

  1. Agregue la anotación mongodb.com/atlas-reconciliation-policy: "skip" al metadata ​​del recurso principal. Esto evita que Atlas Kubernetes Operator intente conciliar el recurso principal y sus subrecursos.

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

Considere 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úrese de haber agregado el bloque annotations en las líneas 5 y 6 y eliminar el bloque customRoles que se muestra 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 aplica esta anotación, Atlas Kubernetes Operator seguirá intentando la conciliación mientras modifica sus otros recursos. Para los usuarios con la opción "Nuevo valor predeterminado: Protección contra eliminación en Atlas Kubernetes Operator "2.0 deshabilitada, esto puede provocar que Atlas Kubernetes Operator elimine el proyecto Atlas al eliminar el atlasProject recurso, o que entre en estado de bloqueo al intentar eliminar un proyecto con subrecursos activos, como usuarios de bases de datos o implementaciones.

2

Eliminar los parámetros del CRD principal.

Para evitar conflictos con el nuevo CRD que cree, primero debe eliminar los parámetros correspondientes al recurso que desea migrar del recurso principal. Por ejemplo, elimine 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 el nuevo CRD.

Cree un CRD del apropiado kind para el parámetro que desea migrar, según su sintaxis. Por ejemplo, para migrar el customRoles parámetro del atlasProject CRD mostrado anteriormente, cree 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

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

5

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

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

Volver

Definiciones de recursos personalizados independientes

Next

Compatibilidad

En esta página