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.

  • Agrega el spec.applicationDatabase.externalAccess configuración utilizada para la configuración de servicios comunes o para implementaciones de clúster único.

  • añade la configuración spec.applicationDatabase.clusterSpecList.externalAccess.

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

    • AppDB: spec.applicationDatabase.externalAccess.externalService.annotations

    • MongoDBOpsManager: Aún no se admite

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 supervisión de nodos de AppDB, consulta Obtener host, Proceso, Medidas del 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 repositorio de mongodb-enterprise-appdb-database-ubi, ya que está obsoleta desde Kubernetes operador 1.22.0.

Nuevas características:

• Disponibilidad general - clústeres fragmentados multi-clúster: 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 compatible con versiones anteriores para implementaciones de clústeres sharded de MongoDB de un solo clúster, al establecer por defecto spec.topology en SingleCluster. Los recursos existentes MongoDB no necesitan ser modificados para actualizar a esta versión del Kubernetes operador.

  • 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 aprender más, 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: Agrega una nueva validación a los despliegues de clústeres fragmentados para garantizar la corrección de las operaciones de escalado. Esta validación restringe el escalado de diferentes componentes en dos direcciones simultáneamente dentro de un solo cambio en el archivo YAML. Por ejemplo, no se permite añadir más nodos (escalar hacia arriba) a las particiones mientras se remueven simultáneamente (escalar hacia abajo) servidores de configuración o mongos. Esta restricción también se aplica a implementaciones con múltiples clústeres. Un cambio sencillo que implica "mover" un nodo de un clúster a otro—sin modificar el número total de miembros—ahora será bloqueado. Es necesario realizar primero una operación de escalado y luego ejecutar un cambio separado para reducir el escalado.

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.

• Corregido un error que causaba problemas con la verificación de estado del clúster cuando el orden de los usuarios y tokens difería en Kubeconfig.

• Se ha corregido un error que, al implementar un recurso particionado en varios clústeres con una configuración de acceso externo, podía impedir que los pods se comunicaran entre sí.

• Se soluciona un error al configurar spec.fcv = AlwaysMatchVersion y agentAuth como SCRAM, lo que hace que el operador establezca el valor de autorizació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: Soluciona e introduce mejoras en las implementaciones de Clústeres Fragmentados Multiclúster (Vista Previa Pública).

• MongoDB: Compatible con el campo spec.shardOverrides para topologías de clúster único. Recomendamos usar este campo para personalizar los ajustes de particiones específicos.

• MongoDB: desaprueba spec.shardSpecificPodSpec. Use spec.shardOverrides to customize specific particiones for both single-clúster and multi-clúster topologías. Para obtener un ejemplo, consulta el repositorio de GitHub mongodb-enterprise-kubernetes.

Correcciones de errores

• MongoDB: Corrige el nombre del marcador de posición para mongos en implementaciones sharded de clúster único con un dominio externo configurado. Esta corrección cambia mongodProcessDomain y mongodProcessFQDN a mongosProcessDomain y mongosProcessFQDN respectivamente.

• MongoDB, AppDB, MongoDBMultiCluster: si pierdes un clúster de nodos, ya no recibirás errores de validación si el clúster fallido aún existe en clusterSpecList. Esto te permite reconfigurar más fácilmente tus implementaciones durante la recuperación ante desastres.

Nuevas características:

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

  La expansión automática de persistentVolumeClaims solo es compatible si el storageClass de Kubernetes subyacente admite la expansión de Kubernetes persistentVolume. Asegúrate de que tu storageClass admita la expansión en el lugar sin pérdida de datos.

Correcciones de errores

• MongoDB, AppDB, MongoDBMultiCluster: Corrige un error donde, al especificar un número fraccionario para el tamaño de un volumen de almacenamiento, como 1.7Gi, se rompe el ciclo de conciliación para ese recurso con un error Can't execute update on forbidden fields, incluso si la reclamación de volumen persistente subyacente se implementa con éxito.

• MongoDB, MongoDBMultiCluster, OpsManager, AppDB: Mejora la estabilidad de las implementaciones durante las rotaciones de TLS. En los casos en los que el StatefulSet de la implementación se estaba conciliando y se producía una rotación TLS, la implementación llegaría a un estado fallido. Ahora, las implementaciones almacenarán el certificado TLS anterior junto al nuevo.

Nuevas características:

• (Vista previa pública) Recurso MongoDB: Introduce soporte para clústeres fragmentados en implementaciones de MongoDB multinodo en Kubernetes configurando spec.topology=MultiCluster al crear un recurso MongoDB con spec.type=ShardedCluster. Para obtener más información, consulta Clúster fragmentado Multiclú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 automática de persistentVolumeClaims solo es compatible si el storageClass de Kubernetes subyacente admite la expansión de Kubernetes persistentVolume. Asegúrate de que tu storageClass admita la expansión en el lugar sin pérdida de datos.

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

• Recursos MongoDB y MongoDBMultiCluster: Presenta 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 actualices tu versión de MongoDB, el Administrador del operador de Kubernetes configurará el spec.featureCompatibilityVersion con la versión desde la que estás actualizando para darte la opción de revertir si fuese 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

• MongoDB, recursos AppDB y MongoDBMultiCluster: Se corrige un error donde el contenedor init no recibía el contexto de seguridad por defecto, y esto 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.

  Utiliza la siguiente configuración para configurar la rotación de registros por componente:

  • spec.agent.mongod.logRotate para los procesos de 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.

• Recurso de OpsManager: añade soporte para reemplazar el archivo de configuración logback.xml, que configura la configuración general de registro, como la rotación de registros para Ops Manager y las copias de seguridad de Ops Manager.

  Utiliza las siguientes configuraciones:

  • spec.logging.logBackAccessRef para el ConfigMap y la clave de acceso con el logback archivo de configuración de acceso para montar en el Pod de Ops Manager. Nombra la clave de acceso del ConfigMap logback-access.xml. Este archivo configura el acceso al archivo de configuración de registros para el Ops Manager.

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

  • 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 configuración spec.applicationDatabase.agent.logRotate para la base de datos de la aplicación ha quedado obsoleta. En su lugar, utiliza spec.applicationDatabase.agent.mongod.logRotate.

Correcciones de errores

• Lanzador de agente: corrige un problema por el cual, en algunos escenarios de resincronización, los datos del diario en /journal se corrompían. Ahora el agente se asegura de que no existan datos de registro en conflicto y prioriza los datos de /data/journal. Para desactivar este comportamiento, establece la variable de entorno MDB_CLEAN_JOURNAL en el Operador de Kubernetes a cualquier valor diferente de 1.

• Recursos de MongoDB, AppDB, MongoDBMulti: Corrige un problema que garantiza que se usen dominios externos en el connectionString, si lo configuras.

• Recurso MongoDB: se elimina la respuesta de pánico si se proporciona una configuración de Horizon más corta que el número de nodos. El Operador de Kubernetes ahora emite un error descriptivo en el estado del recurso MongoDB en tales 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 escalado vertical del Kubernetes Operator y logra una reconciliación más rápida de todos los recursos gestionados al permitir controlar el número de reconciliaciones que el Kubernetes Operator puede realizar en paralelo.

  Puede establecer MDB_MAX_CONCURRENT_RECONCILES para la implementación del operador de Kubernetes o operator.maxConcurrentReconciles en la gráfica de Helm de instalación del operador de Kubernetes. Si no se proporciona, el valor por defecto es 1. La capacidad de controlar el número de conciliaciones podría generar una mayor carga en el Ops Manager y en el servidor API de Kubernetes dentro de la misma ventana de tiempo. Observe el uso de los recursos de Kubernetes Operator y ajuste operator.resources.requests y operator.resources.limits si es necesario. Para obtener más información, consulte Gestión de recursos para pods y contenedores en la documentación de Kubernetes.

• Agrega soporte para OpenShift 4.15. Para obtener más información, consulta Compatibilidad de MongoDB Enterprise Kubernetes Operator.

Cambios en la instalación de la Helm gráfica

• Agrega un parámetro operator.maxConcurrentReconciles que permite controlar la cantidad de reconciliaciones que el Operador de Kubernetes puede realizar en paralelo. El valor por defecto 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 MongoDB, MongoDBMultiCluster: Soluciona un error en el que el operador de Kubernetes no supervisaba los cambios en los certificados X-509 configurados para la autenticación del MongoDB Agent.

• Recurso MongoDB: Corrige un error en el que los indicadores booleanos enviados al Agente MongoDB no pueden establecerse en false si su valor por defecto es true.

Cambio decisivo

• MongoDBOpsManager recurso. El operador de Kubernetes ya no es compatible con Ops Manager 5.0. Actualiza 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 en Ops Manager 5.0.

Nuevas características:

• MongoDBOpsManager recurso: añade soporte para implementar la aplicación Ops Manager en múltiples 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) Recursos de MongoDB, OpsManager: Introduce el uso optativo de contenedores estáticos (vista previa pública) para todos los tipos de implementaciones.

  • En esta versión, use contenedores estáticos solo con fines de prueba. Los contenedores estáticos podrían convertirse por defecto 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 Kubernetes admite la migración sin interrupciones entre arquitecturas estáticas y no estáticas. Para obtener más información, consulta:

    • Utiliza contenedores estáticos

    • Migra 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 de MongoDB: puedes recuperar un recurso por una configuración de automatización defectuosa en clústeres particionados. En versiones anteriores, se podían recuperar otros tipos de recursos pero no clústeres fragmentados. Para obtener más información, consulta Recuperar recurso debido a configuración de automatización rota.

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

  • Puede definir anotaciones para servicios externos gestionados por el operador de Kubernetes que contienen marcadores de posición que serán automáticamente reemplazados por 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 añadir marcadores de posición para que el Operador de Kubernetes personalice las anotaciones en cada servicio con valores que sean relevantes y únicos para cada pod en particular. Para obtener más información, consulta:

    • MongoDB resource: spec.externalAccess.externalService.annotations

    • MongoDBMultiCluster recurso spec.externalAccess.externalService.annotations

• 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 la gestión de las configuraciones cuando el Operador de Kubernetes supervisa más de un namespace y cuando se instala el Operador de Kubernetes en un namespace que difiere del namespace 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.

• Agrega una variable de entorno opcional MDB_WEBHOOK_REGISTER_CONFIGURATION para el Operador de Kubernetes. La variable controla si el Operador de Kubernetes debe realizar la configuración automática del webhook de admisión. El valor por defecto es true. La variable está configurada en false para implementaciones de OLM y OpenShift.

Cambios en la instalación de la Helm gráfica

• Cambia el valor agent.version por 107.0.0.8502-1 por defecto. Esto cambia el agente por defecto utilizado en los despliegues del operador de Kubernetes que se instalan utilizando un Helm chart.

• Agrega la variable operator.additionalArguments con el valor por defecto de [] para permitirte pasar argumentos adicionales al binario del Operador de Kubernetes.

• Agrega la variable operator.createResourcesServiceAccountsAndRoles con true por defecto para controlar si se instalan roles y cuentas de servicio para los recursos MongoDB y OpsManager. Cuando utilices el plugin kubectl mongodb para configurar el operador de Kubernetes para una implementación multinodo de clústeres de Kubernetes, el plugin instala todos los roles y cuentas de servicio necesarios. Por lo tanto, para evitar conflictos, en algunos casos no instale esos roles utilizando la gráfica 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.

• Prueba de preparación de MongoDB: Corrige un mensaje de error confuso para la prueba 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 Kubectl: Los binarios del plugin kubectl mongodb ahora están firmados y las firmas se publican junto con los activos de la versión. La clave pública está disponible en esta dirección. Los binarios del plugin kubectl mongodb liberados también están notariados 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, consulta MongoDB Enterprise Kubernetes Operator kubectl y oc Configuraciones de instalación y Configuraciones de instalación de Helm para MongoDB Enterprise Kubernetes Operator.

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

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 de los registros de auditoría del agente de automatización y de MongoDB, se enviaran a los registros del pod de Kubernetes. A partir de Kubernetes Operator 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

• Se 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 utiliza el estado Reconciling para todos los recursos personalizados. En la mayoría de los casos, este estado se ha reemplazado por Pending y un mensaje correspondiente. Si utilizas herramientas de supervisión con los recursos personalizados de MongoDB implementados con el Operador de Kubernetes, es posible que debas ajustar tus tableros y reglas de alerta para utilizar 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 donde las etiquetas de anulación StatefulSet no lograron anular el/la StatefulSet.

Mejoras

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

• Agrega documentación para configurar una implementación de recursos MongoDBMultiCluster en un entorno 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