Al instalar el operador de Kubernetes, este extrae las imágenes del registro de contenedores de Quay.io. Las imágenes del operador de Kubernetes se basan en Red Hat UBI.8 Sistema operativo. MongoDB reconstruye imágenes del operador de Kubernetes diariamente para el último sistema operativo y las actualizaciones de bibliotecas compatibles.
Las imágenes oficiales ofrecen las siguientes ventajas:
Se reconstruyen diariamente para incluir las últimas correcciones de vulnerabilidades ascendentes.
MongoDB los prueba, los mantiene y los soporta.
Para ver todas las versiones disponibles de cada imagen, consulte los siguientes enlaces.
Nombre de la imagen | Descripción |
|---|---|
Imagen del agente MongoDB. | |
La imagen Enterprise MongoDB utilizada para contenedores estáticos y la base de datos de la aplicación. | |
| |
Imagen del entorno de base de datos MongoDB utilizada para contenedores no estáticos. Para obtener más información sobre contenedores estáticos y no estáticos, consulte Contenedores estáticos (versión preliminar pública). | |
| |
Imagen de Ops Manager. | |
|
Contenedores estáticos (Vista previa pública)
Los contenedores estáticos son más sencillos y seguros que los no estáticos. Son inmutables en tiempo de ejecución, lo que significa que no cambian con respecto a la imagen utilizada para crearlos. Además:
Durante su ejecución, los contenedores estáticos no descargan binarios ni ejecutan scripts ni otras utilidades a través de conexiones de red. Solo descargan archivos de configuración en tiempo de ejecución.
Mientras se ejecutan, los contenedores estáticos no modifican ningún archivo excepto los montajes del volumen de almacenamiento.
Puede ejecutar análisis de seguridad en las imágenes del contenedor para determinar qué se ejecuta realmente como un contenedor activo, y el contenedor que se ejecuta no ejecutará binarios distintos de los que se definieron en la imagen.
Los contenedores estáticos no requieren que alojes el binario de MongoDB en Ops Manager ni en otro ServidorHTTPS, que es especialmente útil si tienes un entorno con espacio de aire.
No se pueden ejecutar scripts
CMDextensos 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.
A partir del Operador de Kubernetes de MongoDB Enterprise 1.25, puede usar la versión preliminar pública de contenedores estáticos en lugar de los contenedores no estáticos existentes, lo que descarga el binario de MongoDB desde Cloud Manager, Ops Manager o Internet durante la ejecución. Puede usar los procedimientos de esta página para habilitar o deshabilitar los contenedores estáticos para todas las implementaciones de MongoDB o para implementaciones individuales.
Los contenedores estáticos usan la imagen del repositorio Quay.io de mongodb-enterprise-server de manera predeterminada, pero puedes usar tu propio registro si lo configuraste para tus nodos de Kubernetes.
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.
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.
Compatibilidad con modo local o remoto
Si usa contenedores estáticos, no necesita configurar Ops Manager para que se ejecute en modo local o remoto, a menos que use copias de seguridad consultables. En la arquitectura de contenedores estáticos, los binarios del agente y mongod tienen sus propias imágenes de contenedor y estas no se descargan de Ops Manager.
Las copias de seguridad consultables son la excepción, ya que, en la arquitectura de contenedores no estáticos, el demonio de copia de seguridad descarga y ejecuta los binarios de MongoDB Server de todas las versiones respaldadas por defecto. Este comportamiento predeterminado de MongoDB socava la naturaleza completamente estática de los contenedores utilizados para ejecutar el demonio de copia de seguridad. Si utiliza copias de seguridad consultables, deberá alojar los binarios de MongoDB Server relevantes en modo local o remoto. Para obtener más información, consulte Configurar un recurso de Ops Manager para usar el modo local o Configurar un recurso de Ops Manager para usar el modo remoto.
Si utilizó el modo remoto o local anteriormente y no desea utilizar copias de seguridad consultables, haga lo siguiente para asegurarse de que mongodb-enterprise-server se puedan descargar imágenes en los nodos utilizados por los pods:
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
agentVersionen 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.
Preguntas frecuentes
¿Los contenedores estáticos admiten el modo local o remoto?
No, si usa contenedores estáticos, no necesita configurar Ops Manager para que se ejecute en modo local o remoto, a menos que use copias de seguridad consultables. Para obtener más información,consulte Modos local y remoto.
¿Cuáles son los cambios para los contenedores estáticos?
Los contenedores estáticos no descargan el binario de MongoDB durante la ejecución. En su lugar, utilizan las imágenes del repositorio mongodb-enterprise-server de Quay.io. Para obtener más información sobre los cambios, consulte el 6 paso.
¿Cómo puedo verificar si mi implementación se está ejecutando de forma estática?
Hay muchas maneras de determinar si su implementación utiliza un contenedor estático. Para obtener más información, consulte el 7 paso.
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.
Deshabilitar copias de seguridad consultables.
Siga el procedimiento que se describe en Deshabilitar copias de seguridad consultables.
Si desea utilizar copias de seguridad consultables, debe configurar el recurso Ops Manager para usar el modo local o el modo remoto para que los binarios de todas las versiones en uso se puedan extraer de Ops Manager.
Establecer variables de entorno para la imagen del Agente MongoDB.
En el archivo de configuración del operador de Kubernetes, defina la variable de entorno MDB_AGENT_IMAGE_REPOSITORY para especificar el repositorio desde el cual el operador de Kubernetes descarga la imagen del agente MongoDB para contenedores estáticos.
En el gráfico Helm del operador de Kubernetes, defina registry.agent y agent.name para especificar el repositorio desde el cual el operador de Kubernetes descarga la imagen del agente de MongoDB para contenedores estáticos.
Guarde y aplique el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si usa Kubernetes sin OpenShift, ejecute:
kubectl apply -f mongodb-enterprise.yaml
Si usa Kubernetes con OpenShift:
oc apply -f mongodb-enterprise-openshift.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set registry.pullPolicy='IfNotPresent'
Esto inicia un reinicio continuo de todos los pods en su implementación.
Habilitar contenedores estáticos.
Seleccione la pestaña adecuada a continuación para habilitar contenedores estáticos para todas sus implementaciones de MongoDB a la vez, incluidas las implementaciones existentes, o una implementación a la vez.
En el archivo de configuración del operador de Kubernetes, establezca MDB_DEFAULT_ARCHITECTURE o operator.mdbDefaultArchitecture staticen.
En la especificación de recursos de MongoDB para una implementación específica, establezca la metadata.annotations.mongodb.com/v1.architecture anotación static en.
Guarde y aplique el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si usa Kubernetes sin OpenShift, ejecute:
kubectl apply -f <my-config-file>.yaml
Si usa Kubernetes con OpenShift:
oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"
El operador de Kubernetes actualiza las imágenes de StatefulSet para su implementación de MongoDB, pasando de un único contenedor que anteriormente gestionaba tanto el agente como la base de datos de MongoDB a una nueva configuración con dos contenedores independientes: uno para el agente y otro para la base de datos de MongoDB. Esta actualización inicia un reinicio continuo.
Al migrar a contenedores estáticos, se aplican los siguientes cambios:
Los nodos de Kubernetes utilizan su registro de contenedores configurado para realizar las descargas.
La versión del agente de supervisión y la versión del agente de automatización están alineadas.
El operador de Kubernetes, en lugar del agente, maneja las actualizaciones de MongoDB.
Kubernetes operador reemplaza las imágenes existentes, lo que provocará un reinicio en secuencia.
Verifique que la implementación se esté ejecutando de forma estática.
Verifique el valor de una de las siguientes variables, que debe haber establecido en
static:MDB_DEFAULT_ARCHITECTUREVariable para todas las implementaciones.
metadata.annotations[mongodb.com/v1.architecture]Variable por implementación.
Verifique la implementación de la base de datos para verificar el uso de dos imágenes separadas, una para el agente y otra para MongoDB, y asegúrese de que no se implementen contenedores de inicio.
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.
Deshabilitar contenedores estáticos.
Seleccione la pestaña adecuada a continuación para deshabilitar los contenedores estáticos para todas sus implementaciones de MongoDB a la vez, incluidas las implementaciones existentes, o una implementación a la vez.
En el archivo de configuración del operador de Kubernetes, establezca MDB_DEFAULT_ARCHITECTURE o operator.mdbDefaultArchitecture non-staticen.
En la especificación de recursos de MongoDB para una implementación específica, establezca la metadata.annotations.mongodb.com/v1.architecture anotación non-static en.
Guarde y aplique el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si usa Kubernetes sin OpenShift, ejecute:
kubectl apply -f <my-config-file>.yaml
Si usa Kubernetes con OpenShift:
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"
El operador de Kubernetes reemplaza las imágenes StatefulSet de su implementación de MongoDB e inicia un reinicio continuo de todos los pods en su implementación.