Notas de versión para MongoDB Enterprise Kubernetes Operator

Nuevas características:

• Agrega soporte para Ops Manager y implementaciones de base de datos de la aplicación en múltiples clústeres de Kubernetes sin requerir una Service Mesh.

  • Añade el spec.applicationDatabase.externalAccess Configuración utilizada para la configuración de servicios comunes o para implementaciones de un solo clúster.

  • Agrega la spec.applicationDatabase.clusterSpecList.externalAccess configuración.

  • Admite anotaciones para servicios externos administrados por el operador, que contienen marcadores de posición que se reemplazan automáticamente con los valores adecuados:

    • Base de datos de aplicaciones: spec.applicationDatabase.externalAccess.externalService.annotations

    • MongoDBOpsManager: aún no compatible

Correcciones de errores

• Se corrige un error que provocaba que las cargas de trabajo en la arquitectura de contenedor static siguieran descargando binarios. Esto ocurría cuando el operador se ejecutaba con la arquitectura de contenedor predeterminada non-static, pero la carga de trabajo se implementaba con la arquitectura static mediante la anotación mongodb.com/v1.architecture: "static".

• Se corrige un error que impedía que el operador de Kubernetes aplicara correctamente la personalización de servicios externos según la configuración spec.externalAccess y spec.mongos.clusterSpecList.externalAccess. Anteriormente, se ignoraba, pero solo para clústeres fragmentados multiclúster.

• Se solucionó un problema por el cual los recursos de Ops Manager no se limpiaban correctamente al eliminarlos. El operador ahora garantiza que se eliminen todos los recursos al eliminar un recurso de Ops Manager.

• Se solucionó un problema con nombres de host de monitorización incorrectos para bases de datos de aplicaciones implementadas en modo multiclúster. Los agentes de monitorización deben detectar los nombres de host correctos y enviar los datos a Ops Manager. Los nombres de host utilizados para monitorizar AppDB en implementaciones multiclúster con una malla de servicios {resource_name}-db-{cluster_index}-{pod_index}-svc.{namespace}.svc.{cluster_domain} son. Se deben definir certificados TLS para estos nombres de host.

  Nota

  Esta corrección provocará la pérdida de datos históricos de monitorización de los miembros de AppDB multiclúster. Si conservar estos datos es crucial, realice una copia de seguridad antes de actualizar. Esto solo afecta a los datos de monitorización de las implementaciones de AppDB multiclúster. No afecta a las AppDB de un solo clúster ni a ninguna otra implementación de MongoDB administrada por Ops Manager.

  Para exportar datos de monitoreo de miembros de AppDB, consulte Obtener mediciones de host, proceso y sistema en la documentación de Ops Manager.

• Corrige un error en el que el operador de Kubernetes no usaba el spec.clusterSpecList.externalConnectivity campo, pero aparece documentation en.

• Corrige un error en el que siempre se esperaba una CA personalizada al configurar Ops Manager con TLS habilitado.

Cambios radicales

• Elimina todas las referencias a la imagen y al repositorio mongodb-enterprise-appdb-database-ubi, ya que están obsoletos desde el operador de Kubernetes 1.22.0.

Nuevas características:

• Disponibilidad general: clústeres fragmentados de varios clústeres: admite la configuración de clústeres fragmentados de MongoDB de alta disponibilidad en varios clústeres de Kubernetes.

  • MongoDB los recursos de tipo clúster ahora admiten tanto topologías de clúster único como múltiple.

  • La implementación es retrocompatible con implementaciones de clústeres individuales de MongoDB Sharded Clusters, estableciendo de spec.topology a SingleCluster como valor predeterminado. No es necesario modificar los recursos MongoDB existentes para actualizar a esta versión del operador de Kubernetes.

  • Presenta soporte para implementaciones fragmentadas en múltiples clústeres de Kubernetes sin requerir un Service Mesh, lo que se puede lograr al permitir que todos los componentes de dicha implementación (incluidos mongos, servidores de configuración y mongod) se expongan externamente a los clústeres de Kubernetes, lo que permite el enrutamiento a través de interfaces externas.

  • Para obtener más información, consulte la documentación pública.

• MongoDB: Añade la opción de exclusión voluntaria a la telemetría anonimizada para el operador de Kubernetes. Los datos recopilados por telemetría no contienen información de identificación personal (PII) ni datos que puedan vincularse a un cliente o empresa específicos. Consulte la documentación pública para obtener más información sobre:

  • Qué datos se incluyen en la telemetría

  • Cómo desactivar la telemetría

  • Qué RBACs se añaden y por qué son necesarios

• MongoDB: Se añade una nueva validación a las implementaciones de clústeres fragmentados para garantizar la corrección de las operaciones de escalado. Esta validación restringe el escalado simultáneo de diferentes componentes en dos direcciones con un solo cambio en el archivo YAML. Por ejemplo, no se permite añadir más nodos (escalado vertical) a los fragmentos mientras se eliminan simultáneamente (escalado vertical) servidores de configuración o MongoDB. Esta restricción también se aplica a las implementaciones multiclúster. Ahora se bloqueará un cambio simple que implique mover un nodo de un clúster a otro, sin modificar el número total de miembros. Es necesario realizar primero una operación de escalado vertical y luego ejecutar un cambio independiente para el escalado vertical.

Correcciones de errores

• Corrige el bug cuando el estado de MongoDBUser se establecía en Updated prematuramente. Por ejemplo, los usuarios nuevos no eran utilizables inmediatamente tras la creación de MongoDBUser a pesar de que el operador informaba del estado Updated.

• Se corrigió un error que causaba problemas de verificación del estado del clúster cuando el orden de los usuarios y los tokens era diferente en Kubeconfig.

• Se corrigió un error que ocurría cuando la implementación de un recurso fragmentado de varios clústeres con una configuración de acceso externo podía provocar que los pods no pudieran comunicarse entre sí.

• Se corrigió un error que ocurría cuando al configurar spec.fcv = AlwaysMatchVersion y agentAuth como SCRAM, el operador configuraba el valor de autenticación como SCRAM-SHA-1 en lugar de SCRAM-SHA-256.

Correcciones de errores

• Corregido el manejo de las variables de entorno del proxy en el Pod del Operador de Kubernetes. Cuando establezca las variables de entorno HTTP_PROXY, HTTPS_PROXY o NO_PROXY en el Pod del Operador de Kubernetes, podrá propagarlas a los Agentes de MongoDB estableciendo también la variable de entorno MDB_PROPAGATE_PROXY_ENV a true.

Nuevas características:

• MongoDB: corrige y mejora las implementaciones de clústeres fragmentados de múltiples clústeres (versión preliminar pública).

• MongoDB: Admite el campo para topologías de un solo clúster. Recomendamos usar este campo para personalizar la configuración de fragmentos spec.shardOverrides específicos.

• MongoDB: Se spec.shardSpecificPodSpec desestima. Use para personalizar fragmentos específicos para topologías de clúster único y múltiple. Para ver un ejemplo, consulte el spec.shardOverrides repositoriode GitHub mongodb-enterprise-kubernetes.

Correcciones de errores

• MongoDB: Se corrige el nombre del marcador de posición mongos en implementaciones fragmentadas de un solo clúster con un dominio externo definido. Esta corrección cambia mongodProcessDomain y mongodProcessFQDN a mongosProcessDomain y mongosProcessFQDN respectivamente.

• MongoDB, AppDB, MongoDBMultiCluster: Si pierde un clúster miembro, ya no recibirá errores de validación si el clúster fallido aún existe clusterSpecList en. Esto le permite reconfigurar sus implementaciones con mayor facilidad durante la recuperación ante desastres.

Nuevas características:

• AppDb: Añade compatibilidad con la expansión automática del almacenamiento al aumentar la capacidad de persistentVolumeClaims Kubernetes. Para obtener más información, consulte Aumentar el almacenamiento para volúmenes persistentes.

  La expansión automatizada de persistentVolumeClaims solo se admite si el Kubernetes storageClass subyacente admite la expansión de Kubernetes persistentVolume. Asegúrese de que su storageClass admita la expansión local sin pérdida de datos.

Correcciones de errores

• MongoDB, AppDB, MongoDBMultiCluster: corrige un error en el que al especificar un número fraccionario para el tamaño de un volumen de almacenamiento,1.7Gi como, se interrumpe el ciclo de conciliación para ese recurso con un error Can't execute update on forbidden fields incluso si el reclamo de volumen persistente subyacente se implementa correctamente.

• MongoDB, MongoDBMultiCluster, OpsManager, AppDB: Se mejora la estabilidad de las implementaciones durante las rotaciones TLS. En escenarios donde el StatefulSet de la implementación se estaba reconciliando y se producía una rotación TLS, la implementación alcanzaba un estado erróneo. Las implementaciones ahora almacenarán el certificado TLS anterior junto con el nuevo.

Nuevas características:

• (Vista previa pública) Recurso MongoDB: Se introduce la compatibilidad con clústeres fragmentados en implementaciones MongoDB de clústeres multi-Kubernetes mediante la configuración de al crear un recurso spec.topology=MultiCluster MongoDB spec.type=ShardedCluster con. Para obtener más información, consulte Clúster fragmentado multi-clúster.

• Recursos MongoDB y MongoDBMultiCluster: Se añade soporte para la expansión automática del almacenamiento aumentando la capacidad del Kubernetes persistentVolumeClaims. Para aprender más, consulta Aumentar almacenamiento para volúmenes persistentes.

  • La expansión automatizada de persistentVolumeClaims solo se admite si el Kubernetes storageClass subyacente admite la expansión de Kubernetes persistentVolume. Asegúrese de que su storageClass admita la expansión local sin pérdida de datos.

• Recurso de OpsManager: introduce soporte para Ops Manager 8.0.0.

• Recursos deMongoDB y MongoDBMultiCluster: introduce soporte para MongoDB.8.0.0

• MongoDB y los recursos de base de datos de la aplicación MongoDBMultiCluster: Cambia el comportamiento por defecto de spec.featureCompatibilityVersion para la base de datos:

  • Cuando actualiza su versión de MongoDB, el operador de Kubernetes establece spec.featureCompatibilityVersion en la versión desde la que está actualizando para brindarle la opción de cambiar a una versión inferior si es necesario.

  • Si desea que la versión de compatibilidad de funciones coincida con la nueva versión de MongoDB, debe configurar manualmente featureCompatibilityVersion en la nueva versión de MongoDB o AlwaysMatchVersion.

• Actualiza las imágenes de contenedor para que utilicen Red Hat UBI 9 como imagen base, excepto mongodb-enterprise-database-ubi, que permanece en UBI8 para dar soporte a cargas de trabajo que se ejecutan en MongoDB 6.0.4 y anteriores.

  • La8 imagen UBI solo se usa para la arquitectura no estática predeterminada. Para una configuración completa de9 UBI, use contenedores estáticos. Para obtener más información, consulte Contenedores estáticos (versión preliminar pública).

Correcciones de errores

• RecursosMongoDB, AppDB y MongoDBMultiCluster: corrige un error en el que el init contenedor no obtenía el contexto de seguridad predeterminado, que luego era marcado por las políticas de seguridad.

• Recurso MongoDBMultiCluster: Corrige un error donde no se realizaban validaciones de recursos como parte del ciclo de reconciliación.

Nuevas características:

• Recurso deMongoDB: Se ha añadido compatibilidad para habilitar la rotación de registros para procesos de MongoDB, agentes de monitorización y agentes de backup. Para obtener más información, consulte Configuración de rotación de registros de CRD de MongoDB.

  Utilice las siguientes configuraciones para configurar la rotación de registros por componente:

  • spec.agent.mongod.logRotate para los procesos mongoDB.

  • spec.agent.mongod.auditlogRotate para los registros de auditoría de los procesos de MongoDB.

  • spec.agent.backupAgent.logRotate para el agente de respaldo.

  • spec.agent.monitoringAgent.logRotate para el agente de monitoreo.

  • spec.agent.readinessProbe.environmentVariables para las variables de entorno con las que se ejecuta la prueba de preparación. Esta configuración también se aplica a los ajustes relacionados con la rotación de registros. Para obtener más información sobre la configuración de entorno compatible, consulte Prueba de preparación.

  • spec.applicationDatabase.agent.<component>.logRotate para la base de datos de la aplicación.

  Para los clústeres fragmentados, el operador de Kubernetes admite la configuración de la rotación de registros solo en la configuración spec.Agent y no por tipo de proceso, como mongos o configsrv.

• RecursoOpsManager: agrega soporte para reemplazar el archivo de configuración logback.xml, que configura ajustes de registro generales, como la rotación de registros para Ops Manager y las copias de seguridad de Ops Manager.

  Utilice la siguiente configuración:

  • spec.logging.logBackAccessRef para el ConfigMap y la clave de acceso con el archivo de configuración logback de acceso para montarlo en el pod de Ops Manager. Asigne a la clave de acceso del ConfigMap el logback-access.xml nombre. Este archivo configura el acceso al archivo de configuración de registro de Ops Manager.

  • spec.logging.logBackRef para el ConfigMap y la clave de acceso con el logback archivo de configuración para montarlo en el pod de Ops Manager. Este archivo configura el comportamiento general de registro de Ops Manager, incluyendo las políticas de rotación de registros, los niveles de registro y otros parámetros de registro. Asigne a la clave de acceso del ConfigMap el logback.xml nombre.

  • spec.backup.logging.logBackAccessRef para el ConfigMap y la clave de acceso con el archivo de configuración logback de acceso para montarlo en el pod de Ops Manager. Asigne a la clave de acceso del ConfigMap el logback-access.xml nombre. Este archivo configura el acceso al archivo de configuración de registro para las copias de seguridad de Ops Manager.

  • spec.backup.logging.logBackRef para el ConfigMap y la clave de acceso con el logback archivo de configuración para montarlo en el pod de Ops Manager. Este archivo configura el comportamiento general de registro para las copias de seguridad de Ops Manager, incluyendo las políticas de rotación de registros, los niveles de registro y otros parámetros de registro. Asigne a la clave de acceso del ConfigMap el logback.xml nombre.

Obsolescencias

• La spec.applicationDatabase.agent.logRotate configuración para la base de datos de la aplicación ha quedado obsoleta. Utilice en su spec.applicationDatabase.agent.mongod.logRotate lugar.

Correcciones de errores

• Lanzador del agente: Se solucionó un problema que, en algunos casos de resincronización, podía provocar que los datos del diario en /journal se corrompieran. El agente ahora garantiza que no existan datos de diario conflictivos y prioriza los datos /data/journal de. Para desactivar este comportamiento, configure la variable de entorno MDB_CLEAN_JOURNAL en el operador de Kubernetes con un valor distinto 1 de.

• Recursos MongoDB, AppDB, MongoDBMulti: corrige un problema que garantiza que se utilicen dominios externos connectionString en, si lo configura.

• Recurso MongoDB: Se elimina la respuesta de pánico si se proporciona una configuración de Horizon con un número inferior al de miembros. El operador de Kubernetes ahora emite un error descriptivo en el estado del recurso MongoDB en estos casos.

• RecursoMongoDB: corrige un problema por el cual, al crear un recurso en un nuevo proyecto nombrado como prefijo de otro proyecto, fallaba, lo que impedía la creación del recurso MongoDB.

Nuevas características:

• Mejora la utilización de la CPU y el escalamiento vertical del operador de Kubernetes y logra una conciliación más rápida de todos los recursos administrados al permitirle controlar la cantidad de conciliaciones que el operador de Kubernetes puede realizar en paralelo.

  Puede establecer MDB_MAX_CONCURRENT_RECONCILES para la implementación del Operador de Kubernetes o operator.maxConcurrentReconciles en el diagrama de Helm de la instalación del Operador de Kubernetes. Si no se proporciona, el valor predeterminado 1 es. La posibilidad de controlar el número de conciliaciones podría aumentar la carga en Ops Manager y el servidor de la API de Kubernetes en el mismo período. Observe el uso de recursos del Operador de Kubernetes y ajuste operator.resources.requests y operator.resources.limits si es necesario. Para obtener más información,consulte "Administración de recursos para pods y contenedores" en la documentación de Kubernetes.

• Añade compatibilidad con OpenShift.4.15 Para obtener más información, consulte Compatibilidad de operadores de MongoDB Enterprise y Kubernetes.

Cambios en la instalación del gráfico de Helm

• Añade un parámetro operator.maxConcurrentReconciles que permite controlar el número de conciliaciones que el operador de Kubernetes puede realizar en paralelo. El valor predeterminado es 1.

• Añade el parámetro operator.webhook.installClusterRole que controla si se instala el rol de clúster, lo que permite al operador de Kubernetes configurar webhooks de admisión. Establezca este parámetro en false cuando no se permitan los roles de clúster. El valor predeterminado true es.

Correcciones de errores

• MongoDB recurso: corrige un error donde configurar un recurso MongoDB con múltiples entradas en spec.agent.startupOptions provocaba una reconciliación innecesaria adicional del subyacente StatefulSet.

• Recursos de MongoDB, MongoDBMultiCluster: corrige un error en el que el operador de Kubernetes no observaba los cambios en los509 certificados X- configurados para la autenticación del agente de MongoDB.

• Recurso MongoDB: corrige un error en el que los indicadores booleanos pasados ​​al Agente MongoDB no se pueden establecer en false si su valor predeterminado true es.

Cambio decisivo

• RecursoMongoDBOpsManager. El operador de Kubernetes ya no es compatible con Ops Manager. 5.0 Actualice a una versión posterior de Ops Manager. Si bien Ops Manager 5.0 puede seguir funcionando con el operador de Kubernetes, MongoDB no probará el operador de Kubernetes con Ops 5.0 Manager.

Nuevas características:

• RecursoMongoDBOpsManager: Añade compatibilidad para implementar la aplicación Ops Manager en varios clústeres de Kubernetes. Para obtener más información, consulte Implementar recursos de Ops Manager en varios clústeres de Kubernetes.

• (Vista previa pública) MongoDB, recursos deOpsManager: presenta contenedores estáticos opcionales (vista previa pública) para todo tipo de implementaciones.

  • En esta versión, use contenedores estáticos solo para pruebas. Es posible que se conviertan en la opción predeterminada en una versión posterior.

  • Para activar el modo de contenedores estáticos, configure la variable de entorno MDB_DEFAULT_ARCHITECTURE en el nivel de operador de Kubernetes como static. Como alternativa, anote un recurso personalizado MongoDB o OpsManager específico con mongodb.com/v1.architecture: "static".

  • El operador de Kubernetes facilita la migración fluida entre las arquitecturas estáticas y no estáticas. Para obtener más información, consulte:

    • Utilice contenedores estáticos

    • Migrar a contenedores estáticos

• Recurso OpsManager: agrega el spec.internalConnectivity campo para permitir anulaciones del servicio utilizado por el operador de Kubernetes para garantizar la conectividad interna con los OpsManager pods que alojan el recurso.

• Recurso deMongoDB: Puede recuperar un recurso debido a una configuración de automatización defectuosa en clústeres fragmentados. En versiones anteriores, se podían recuperar otros tipos de recursos, pero no clústeres fragmentados. Para obtener más información, consulte Recuperar un recurso debido a una configuración de automatización defectuosa.

• Recursos MongoDB, MongoDBMultiCluster: estos recursos ahora le permiten agregar marcadores de posición en servicios externos.

  • Puede definir anotaciones para servicios externos administrados por el operador de Kubernetes que contengan marcadores de posición que se reemplazarán automáticamente con los valores adecuados. Anteriormente, el operador de Kubernetes configuraba las mismas anotaciones para todos los servicios externos creados para cada pod. A partir de esta versión, puede agregar marcadores de posición para que el operador de Kubernetes pueda personalizar las anotaciones en cada servicio con valores relevantes y únicos para cada pod. Para obtener más información, consulte:

    • MongoDB resource: spec.externalAccess.externalService.annotations

    • MongoDBMultiCluster especificación de recurso.acceso externo.servicio externo.anotaciones

• El complemento kubectl mongodb: le permite imprimir información de compilación al usar el complemento.

• El setup comando del kubectl mongodb complemento: Agrega la configuración registry.imagePullSecrets. Si se especifica, las cuentas de servicio creadas hacen referencia al secreto especificado en el imagePullSecrets campo.

• Mejora el manejo de las configuraciones cuando el operador de Kubernetes supervisa más de un espacio de nombres y cuando se instala el operador de Kubernetes en un espacio de nombres que difiere del espacio de nombres en el que el operador de Kubernetes supervisa los recursos.

• Optimiza la configuración de roles y permisos en los clústeres de Kubernetes miembro mediante una única cuenta de servicio por clúster de Kubernetes con roles y enlaces de roles configurados correctamente (no se necesitan roles de clúster) para cada espacio de nombres supervisado.

• Amplía el proceso de conciliación basado en eventos existente con una conciliación basada en tiempo que se activa cada 24 horas. Esto garantiza que todos los agentes de monitorización se actualicen siempre de forma oportuna.

• Operador de OpenShift y OLM: Se elimina el requisito de permisos para todo el clúster. Anteriormente, el operador de Kubernetes necesitaba estos permisos para configurar los webhooks de admisión. A partir de esta versión,OLM configura automáticamente los webhooks.

• Añade una variable de entorno MDB_WEBHOOK_REGISTER_CONFIGURATION opcional para el operador de Kubernetes. Esta variable controla si el operador de Kubernetes debe configurar automáticamente el webhook de admisión. El valor predeterminado es true. La variable se establece en false para las implementaciones de OLM y OpenShift.

Cambios en la instalación del gráfico de Helm

• Cambia el valor predeterminado agent.version a 107.0.0.8502-1. Esto cambia el agente predeterminado que se usa en las implementaciones de Kubernetes Operator que se instalan mediante un gráfico de Helm.

• Agrega la variable operator.additionalArguments con el valor predeterminado de [] para permitirle pasar argumentos adicionales para el binario del operador de Kubernetes.

• Añade la variable operator.createResourcesServiceAccountsAndRoles con el valor predeterminado true para controlar si se instalan roles y cuentas de servicio para los recursos MongoDB y OpsManager. Al usar el complemento kubectl mongodb para configurar el operador de Kubernetes en una implementación de varios clústeres de Kubernetes, el complemento instala todos los roles y cuentas de servicio necesarios. Por lo tanto, para evitar conflictos, en algunos casos no instale esos roles mediante el gráfico Helm del operador de Kubernetes.

Correcciones de errores

• Recurso MongoDBMultiCluster: Se solucionó un problema por el cual el operador de Kubernetes informaba que spec.externalAccess.externalDomain spec.clusterSpecList[*].externalAccess.externalDomains los campos y eran obligatorios aunque no se utilizaban. El operador de Kubernetes activaba prematuramente una validación para estos campos cuando los recursos personalizados contenían una spec.externalAccess estructura definida. A partir de esta versión, el operador de Kubernetes comprueba la unicidad de los dominios externos solo cuando se definen en las configuraciones spec.externalAccess.externalDomain spec.clusterSpecList[*].externalAccess.externalDomains o.

• RecursoMongoDB: corrige un error en el cual, al eliminar un MongoDB recurso, las controlledFeature políticas permanecían establecidas en la instancia relacionada de Ops Manager o Cloud Manager, lo que hacía imposible la limpieza en la interfaz de usuario en caso de perder el operador de Kubernetes.

• Recurso deOpsManager: Se solucionó un problema por el cual admin-key se eliminaba el secreto al eliminar el recurso OpsManager personalizado. La corrección de la admin-key eliminación del secreto facilita la reinstalación de Ops Manager.

• Sonda de preparación de MongoDB: Corrige un mensaje de error engañoso para la sonda de preparación:. "... kubelet Readiness probe failed:..." Esto afecta a todas las implementaciones de MongoDB.

• Operador: corrige casos en los que, en algunas instancias, al comunicarse con el OpsManager recurso personalizado, el operador de Kubernetes omitió la verificación de TLS, incluso si habilitó TLS.

Mejoras

• Plugin de Kubectl: Los kubectl mongodb binarios del plugin ya están firmados y las firmas se publican con los recursos de la versión. La clave pública está disponible en esta dirección. Los kubectl mongodb binarios del plugin también están notarizados para macOS.

• Imágenes publicadas firmadas: Todas las imágenes de contenedor publicadas para el operador de Kubernetes están firmadas criptográficamente. Esto es visible en el registro de MongoDB Quay. Puede verificar las firmas con la clave pública de MongoDB. Las imágenes publicadas están disponibles en esta dirección.

MongoDBOpsManager Resource

Correcciones de errores

• Corrige un problema que impedía finalizar una copia de seguridad correctamente.

Advertencias y cambios importantes

• Alinea los números de versión de las imágenes de componentes con la etiqueta de lanzamiento del operador de Kubernetes para que quede claro qué imágenes corresponden a cada versión del operador de Kubernetes. Esto afecta a las siguientes imágenes:

  • quay.io/mongodb/mongodb-enterprise-database-ubi

  • quay.io/mongodb/mongodb-enterprise-init-database-ubi

  • quay.io/mongodb/mongodb-enterprise-init-appdb-ubi

  • quay.io/mongodb/mongodb-enterprise-init-ops-manager-ubi

  Para obtener más información, consulte Configuración de instalación de MongoDB Enterprise Kubernetes Operator kubectl y oc y Configuración de instalación de MongoDB Enterprise Kubernetes Operator Helm.

• Reemplaza spec.exposedExternally (obsoleto en el operador de 1.19 Kubernetes) spec.externalAccess con.

Correcciones de errores

• Soluciona un problema con el escalado de un set de réplicas en una implementación de MongoDB de varios clústeres de Kubernetes cuando un clúster nodo ha perdido la conectividad. La solución aborda ambos procedimientos de recuperación manual y automatizada.

• Se solucionó un problema que impedía que, al cambiar los nombres del agente de automatización y los registros de auditoría de MongoDB, se enviaran a los registros del pod de Kubernetes. A partir del operador de Kubernetes 1.22, no hay restricciones en los nombres de archivo de los registros de auditoría de MongoDB.

• Permite que los siguientes nuevos tipos de registros del contenedor mongodb-enterprise-database se transmitan directamente a los registros de Kubernetes:

  • agent-launcher-script

  • monitoring-agent

  • backup-agent

• Corrige un problema que impedía almacenar el recurso MongoDBUser en el espacio de nombres establecido en spec.mongodbResourceRef.namespace.

Cambios radicales

El operador de Kubernetes ya no usa el estado Reconciling para todos los recursos personalizados. En la mayoría de los casos, este estado se ha reemplazado por Pending y su mensaje correspondiente. Si usa herramientas de monitorización con los recursos personalizados de MongoDB implementados con el operador de Kubernetes, es posible que deba ajustar sus paneles y reglas de alerta para usar el nombre de estado Pending.

MongoDBOpsManager Resource

MongoDB Resource

Cambios radicales

• Cambia el nombre de la variable de entorno CURRENT_NAMESPACE NAMESPACEa. Esta variable rastrea el espacio de nombres del operador de Kubernetes. Si configuró esta variable editando los MongoDB recursos, actualice CURRENT_NAMESPACE a NAMESPACE al actualizar el operador de Kubernetes.

Correcciones de errores

• Corrige un problema en el que las etiquetas de anulación StatefulSet no podían anular StatefulSet.

Mejoras

• Admite la configuración de copias de seguridad de la base de datos de la aplicación y MongoDB para el recurso MongoDBMultiCluster.

• Añade documentación para configurar una implementación de MongoDBMultiCluster recursos en un entorno de GitOps. Para obtener más información, consulta Configurar recursos para GitOps.

• Añade MetadataWrapper, un contenedor de etiquetas y anotaciones, a los recursos MongoDB, MongoDBMultiCluster y MongoDBOpsManager. Este contenedor permite anular metadata.Labels y metadata.Annotations.

MongoDBOpsManager Resource