Imágenes de contenedores

Arquitectura

La arquitectura de los contenedores estáticos y no estáticos difiere significativamente y requiere varios pasos para migrar de uno a otro. Para obtener más información, consulte Migrar a contenedores estáticos y Migrar a contenedores no estáticos.

Arquitectura de contenedores no estáticos

La arquitectura predeterminada de contenedor no estática asume que inicializas un contenedor vacío, descargas e inicias el MongoDB Agent, el cual luego descarga los binarios para mongod y mongosh desde Cloud Manager u Ops Manager.

haga clic para ampliar

Arquitectura de contenedores estáticos

La arquitectura de contenedor estático utiliza lafunción de espacio de nombres compartido de Kubernetes para ejecutar el Agente MongoDB como un proceso separado, de modo que pueda controlar el ciclo de mongod vida completo y evitar la descarga de archivos a través de una red.

Los contenedores estáticos son más seguros y sencillos que los no estáticos. Son inmutables en tiempo de ejecución. Además:

• Durante su ejecución, los contenedores estáticos no pueden descargar binarios ni ejecutar scripts ni otras utilidades a través de conexiones de red. Solo pueden descargar archivos de configuración en tiempo de ejecución.

• Mientras se ejecutan, los contenedores estáticos no pueden modificar ningún archivo, excepto los montajes de volumen de almacenamiento.

• Los contenedores estáticos no requieren análisis de seguridad, a diferencia de los contenedores no estáticos, que sí lo requieren. Si se utilizan contenedores estáticos, solo se pueden ejecutar análisis de seguridad en las imágenes, pero no en los contenedores.

• Si tiene un entorno sin conexión, los contenedores estáticos no requieren que aloje el binario de MongoDB en el servidor que aloja Ops Manager u otro servidor HTTPS.

• No se pueden ejecutar scripts CMD extensos para el contenedor estático.

• No se pueden copiar archivos entre contenedores estáticos usando initContainer.

Nota

Cuando se implementa como contenedores estáticos, una implementación de operador de Kubernetes consta de dos contenedores: un contenedor mongodb-agent y un contenedor mongodb-enterprise-server. El recurso personalizado de la base de datos MongoDB hereda las definiciones de límites de recursos del contenedor mongodb-agent, que ejecuta el proceso mongod en una implementación de contenedor estático. Para modificar los límites de recursos del recurso de la base de datos MongoDB, debe especificar los límites de recursos deseados en el contenedor mongodb-agent.

haga clic para ampliar

Limitaciones

Si habilita contenedores estáticos:

• Debe deshabilitar las copias de seguridad consultables para que el servicio de demonio de copia de seguridad no intente descargar los binarios de MongoDB desde Ops Manager, lo que socava la naturaleza inmutable de los contenedores estáticos.

• Con Ops Manager, solo son compatibles las versiones 6.0.24, 7.0.5 o posteriores. El operador de Kubernetes utiliza automáticamente la versión correcta del contenedor del agente de MongoDB según la versión de Ops Manager que seleccione para administrar una implementación específica.

• Con MongoDB Cloud Manager, la versión de su agente MongoDB podría ser incompatible con la última versión de MongoDB Cloud Manager porque el operador de Kubernetes no puede llamar al punto de conexión agentVersion en MongoDB Cloud Manager. Para asegurarse de que su agente MongoDB esté actualizado con MongoDB Cloud Manager, puede realizar una de las siguientes acciones:

  • Especifique una versión compatible del Agente MongoDB en la especificación de recursos de MongoDB sobrescribiendo la imagen del contenedor StatefulSet para el Agente MongoDB. Por ejemplo:

    podSpec:
      podTemplate:
        spec:
          containers:
            - name: mongodb-agent-ubi
              Image: 12.0.29.7785-1_1.24.0

  • Actualice el operador de Kubernetes a la última versión, que actualiza automáticamente el agente de MongoDB.

• Actualizar una versión de MongoDB activa un reinicio progresivo de todos los pods, en orden del último al primero, y podría generar más elecciones, hasta el número de pods. Esto aplica a cualquier actualización que active un reinicio progresivo.

• No podrá determinar si se realizó una actualización de la base de datos MongoDB a partir del estado del Agente MongoDB. Cuando Kubernetes rota los pods después de una actualización, el Agente MongoDB reemplaza el archivo de estado, por lo que no podrá determinar si se realizó un cambio de versión a partir de este, solo el estado actual.

Migrar a contenedores estáticos

Para migrar de contenedores no estáticos a estáticos, configure las variables de entorno del Agente MongoDB y habilite los contenedores estáticos siguiendo los pasos a continuación. También puede habilitar los contenedores estáticos durante la instalación o actualización.

kubectl apply -f mongodb-enterprise.yaml

oc apply -f mongodb-enterprise-openshift.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
  --set registry.pullPolicy='IfNotPresent'

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

Migrar a contenedores no estáticos

Para migrar de contenedores estáticos a no estáticos, deshabilite los contenedores estáticos siguiendo los pasos a continuación. También puede deshabilitarlos durante la instalación o actualización.

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"