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 y 9 sistemas operativos. MongoDB recompila las imágenes del operador de Kubernetes a diario para mantenerlas actualizadas con las últimas versiones del sistema operativo y de las librerías de soporte.
Nota
Las imágenes del agente MongoDB extraídas por contenedores estáticos siempre están en Red Hat UBI.9
Las imágenes oficiales ofrecen las siguientes ventajas:
Se reconstruyen diariamente para las últimas correcciones de vulnerabilidad ascendentes.
MongoDB los prueba, mantiene y respalda.
Para ver todas las versiones disponibles de cada imagen, consulta los siguientes enlaces.
Nombre de la imagen | Descripción | Arquitectura compatible |
|---|---|---|
Imagen del agente MongoDB creada en Red Hat UBI 9 y utilizada para contenedores estáticos, la base de datos de la aplicación y las implementaciones de MongoDB Community Edition. | Compatible con x86-64, ARM64, s390x y ppc64le. Admite contenedores estáticos y no estáticos para todas las versiones de MongoDB Controllers for Kubernetes Operator. | |
Imagen heredada del MongoDB Agent. | Soporte para x86-64 y ARM64. Admite contenedores no estáticos para todas las versiones de Controladores MongoDB para el Operador de Kubernetes. Admite contenedores estáticos solamente para los Controladores MongoDB para el Operador de Kubernetes 1.2.0 y versiones anteriores. | |
La imagen Enterprise MongoDB utilizada para contenedores estáticos y la base de datos de la aplicación. Para las arquitecturas IBM ZSeries (s390x) y Power (ppc64le), las imágenes se ejecutan únicamente en Red Hat UBI 9 y el soporte se limita a MongoDB 8.0.12+. | x86-64, ARM64, s390x, ppc64le | |
| x86-64, ARM64, s390x, ppc64le | |
Imagen del entorno de la base de datos MongoDB utilizada para contenedores no estáticos. | x86-64, ARM64, s390x, ppc64le | |
| x86-64, ARM64, s390x, ppc64le | |
Imagen de Ops Manager. | x86-64 sólo | |
| x86-64 sólo |
Contenedores estáticos (Vista previa pública)
Los contenedores estáticos son más simples y más seguros que los contenedores no estáticos. Los contenedores estáticos son inmutables en tiempo de ejecución, lo que significa que no cambian respecto a la imagen utilizada para crear el contenedor. 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.
Durante su ejecución, los contenedores estáticos no modifican ningún archivo excepto los puntos de montaje de volúmenes 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 se aloje el binario de MongoDB ni en Ops Manager ni en otro HTTPS servidor, que es especialmente útil si tienes un entorno aireado.
No puedes ejecutar scripts extensos de
CMDpara el contenedor estático.No puede copiar archivos entre contenedores estáticos utilizando
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.
Puedes usar la Vista previa pública de contenedores estáticos en lugar de los contenedores no estáticos existentes, que descargan el binario de MongoDB desde Cloud Manager u Ops Manager, o desde Internet en tiempo de ejecución. Puedes usar los procedimientos en esta página para habilitar o deshabilitar contenedores estáticos para todos o para implementaciones individuales de MongoDB.
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 contenedor no estático
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 contenedor estático
La arquitectura de contenedores estáticos utiliza la funcionalidad de namespace compartido de Kubernetes para ejecutar el MongoDB Agent como un proceso independiente, de manera que pueda controlar el ciclo de vida completo de mongod y evitar la descarga de archivos a través de una red.
Compatibilidad con modo local o remoto
Si utiliza contenedores estáticos, no es necesario que configure Ops Manager para que funcione en Modo local o Modo remoto, a menos que utilice respaldos consultables. En la arquitectura de contenedores estáticos, los binarios para el agente y mongod tienen sus propias imágenes de contenedores y estas no se descargan desde Ops Manager.
Los respaldos consultables son la excepción porque en la arquitectura de contenedor no estática, por defecto, el daemon de copias de seguridad descarga y ejecuta los binarios del MongoDB Server para todas las versiones que están respaldadas. Este comportamiento por defecto de MongoDB socava la naturaleza completamente estática de los contenedores utilizados para ejecutar el daemon de copias de seguridad. Si usas respaldos consultables, todavía debes alojar los binarios pertinentes del Servidor MongoDB utilizando el modo local o remoto. Para aprender más, consulta Configurar un recurso de Ops Manager para usar el modo local o Configurar un recurso de Ops Manager para usar el modo remoto.
Si has utilizado el modo Remoto o Local antes y no quieres usar respaldos consultables, haz lo siguiente para asegurarte de que mongodb-enterprise-server imágenes puedan ser descargadas en los nodos usados por los pods:
Limitaciones
Si habilita contenedores estáticos:
Las implementaciones en arquitecturas de hardware IBM ZSeries (s390x) o IBM POWER (ppc64le) permiten sólo contenedores estáticos para MongoDB 8.0.12 y posteriores.
Debes Desactivar copias de seguridad consultables para que el Servicio del daemon de copias 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 versiones 6.0.27+, 7.0.12+, y 8.0.0+ son compatibles. El Operador de Kubernetes utiliza automáticamente la versión correcta del contenedor de MongoDB Agent en función de la versión de Ops Manager que selecciones para gestionar 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 Image: 12.0.29.7785-1_1.24.0 Actualiza el operador de Kubernetes a la última versión, lo que actualiza automáticamente el agente de MongoDB.
Actualizar una versión de MongoDB desencadena un reinicio en secuencia de todos los Pods, en orden del último al primero, y podría causar más elecciones, hasta el número de Pods. Esto se aplica a cualquier actualización que active un reinicio en secuencia.
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
¿Admiten los contenedores estáticos el modo local o remoto?
No, si utiliza contenedores estáticos, no necesita configurar Ops Manager para ejecutarlo en Modo local o Modo remoto a menos que use respaldo consultable. Para saber más, consulte Modos Locales y Remotos.
¿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 ejecuta en modo estático?
Hay muchas maneras de determinar si su implementación utiliza un contenedor estático. Para obtener más información, consulte el 7 paso.
Migra a contenedores estáticos
Para migrar de contenedores no estáticos a contenedores estáticos, configura las variables de entorno del MongoDB Agent y activa los contenedores estáticos siguiendo los pasos a continuación. También puedes activar los contenedores estáticos durante la instalación o actualización.
Deshabilitar copias de seguridad consultables.
Sigue el procedimiento en Deshabilitar respaldos consultables.
Si deseas usar respaldos consultables, debes configurar el recurso de Ops Manager para usar Modo Local o Modo Remoto para que los binarios de todas las versiones en uso puedan obtenerse de Ops Manager.
Remueve las StatefulSet anulaciones de los contenedores de inicio, si las hay.
No se utilizan contenedores de inicio con la arquitectura de contenedores estáticos. Si se anula un contenedor de inicio, la migración de contenedores no estáticos a estáticos falla.
Remueve cualquier StatefulSet anulación para contenedores init en tu especificación de recursos de MongoDB o en la especificación de recursos de Ops Manager. Por ejemplo, asegúrate de que ninguna de las siguientes configuraciones haya sido establecida para initContainers:
Ops Manager:
spec.statefulSet.specBase de datos de la aplicación:
spec.applicationDatabase.podSpecDatabase: Configuración de StatefulSet
Multi-clúster: spec.statefulSet.spec
Establezca variables de entorno para la imagen del MongoDB Agent.
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 tu Helm chart del operador de Kubernetes, define registry.agent y agent.name para especificar el repositorio del que el operador de Kubernetes descarga la imagen del MongoDB Agent para contenedores estáticos.
Guarda y aplica el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si utilizas Kubernetes sin OpenShift, ejecuta:
kubectl apply -f mongodb-kubernetes.yaml
Si usa Kubernetes con OpenShift:
oc apply -f mongodb-kubernetes-openshift.yaml
helm upgrade mongodb-kubernetes-operator mongodb/mongodb-kubernetes \ --set registry.pullPolicy='IfNotPresent'
Esto inicia un reinicio continuo de todos los pods en su implementación.
Habilitar contenedores estáticos.
Selecciona la pestaña adecuada a continuación para habilitar contenedores estáticos para todas tus implementaciones de MongoDB a la vez, incluidas las implementaciones existentes, o una implementación a la vez.
En el archivo de configuración de tu Operador de Kubernetes, configura MDB_DEFAULT_ARCHITECTURE o operator.mdbDefaultArchitecture a static.
En la especificación del recurso MongoDB para una implementación específica, establece la anotación metadata.annotations.mongodb.com/v1.architecture en static.
Guarda y aplica el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si utilizas Kubernetes sin OpenShift, ejecuta:
kubectl apply -f <my-config-file>.yaml
Si usa Kubernetes con OpenShift:
oc apply -f <my-config-file>.yaml
helm upgrade mongodb-kubernetes-operator mongodb/mongodb-kubernetes \ --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"
El operador de Kubernetes actualiza las imágenes de StatefulSet para tu implementación de MongoDB, pasando de un único contenedor que gestionaba tanto el MongoDB Agent como la base de datos MongoDB, a una nueva configuración con dos contenedores separados: uno para el MongoDB Agent y otro para la base de datos MongoDB. Esta actualización inicia un reinicio en secuencia.
Cuando migres a contenedores estáticos, se aplicarán los siguientes cambios:
Los nodos de Kubernetes utilizan el 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.
Verifica el valor de una de las siguientes variables, que debes 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.
Migra a contenedores no estáticos
Para migrar de contenedores estáticos a no estáticos, deshabilita los contenedores estáticos siguiendo los pasos que se indican a continuación. También puedes desactivar los contenedores estáticos durante la instalación o actualización.
Deshabilitar los contenedores estáticos.
Selecciona la pestaña correspondiente de abajo para desactivar contenedores estáticos para todas tus implementaciones de MongoDB a la vez, incluidas las implementaciones existentes, o implementar uno por uno.
En el archivo de configuración de tu Operador de Kubernetes, configura MDB_DEFAULT_ARCHITECTURE o operator.mdbDefaultArchitecture a non-static.
En la especificación del recurso MongoDB para una implementación específica, establece la anotación metadata.annotations.mongodb.com/v1.architecture en non-static.
Guarda y aplica el archivo.
Después de guardar los cambios, vuelva a aplicar su configuración.
Si utilizas Kubernetes sin OpenShift, ejecuta:
kubectl apply -f <my-config-file>.yaml
Si usa Kubernetes con OpenShift:
oc apply -f <my-config-file>.yaml
helm upgrade mongodb-kubernetes-operator mongodb/mongodb-kubernetes \ --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.