El recurso MongoDBMultiCluster define la implementación de MongoDB en su clúster multi-Kubernetes y proporciona al operador de controladores de MongoDB para Kubernetes la información que necesita para crear o actualizar sus clústeres, la implementaciónde Ops Manager, los statefulSets, los servicios y otros recursos de Kubernetes.
Ejemplo
El siguiente ejemplo muestra una especificación de recursos para una implementación de MongoDB con múltiples clústeres de Kubernetes:
1 # This example provides statefulSet overrides per cluster. 2 3 apiVersion: mongodb.com/v1 4 kind: MongoDBMultiCluster 5 metadata: 6 name: multi-replica-set 7 spec: 8 version: 8.0.0 9 type: ReplicaSet 10 duplicateServiceObjects: false 11 credentials: my-credentials 12 opsManager: 13 configMapRef: 14 name: my-project 15 clusterSpecList: 16 - clusterName: cluster1.example.com 17 members: 2 18 statefulSet: 19 spec: 20 template: 21 spec: 22 containers: 23 # Example of custom sidecar containers. Remove it before using the file in production. 24 - name: sidecar1 25 image: busybox 26 command: [ "sleep" ] 27 args: [ "infinity" ] 28 # Use the following settings to override the default storage size of the "data" Persistent Volume. 29 volumeClaimTemplates: 30 - metadata: 31 name: data 32 spec: 33 resources: 34 requests: 35 storage: 1Gi 36 - clusterName: cluster2.example.com 37 members: 1 38 statefulSet: 39 spec: 40 template: 41 spec: 42 containers: 43 # Example of custom sidecar containers. Remove it before using the file in production. 44 - name: sidecar2 45 image: busybox 46 command: [ "sleep" ] 47 args: [ "infinity" ] 48 volumeClaimTemplates: 49 - metadata: 50 name: data 51 spec: 52 resources: 53 requests: 54 storage: 1Gi 55 - clusterName: cluster3.example.com 56 members: 1 57 statefulSet: 58 spec: 59 template: 60 spec: 61 containers: 62 # Example of custom sidecar containers. Remove it before using the file in production. 63 - name: sidecar3 64 image: busybox 65 command: [ "sleep" ] 66 args: [ "infinity" ] 67 volumeClaimTemplates: 68 - metadata: 69 name: data 70 spec: 71 resources: 72 requests: 73 storage: 1Gi 74 75 ...
Configuraciones de recurso requeridas de MongoDBMultiCluster
Esta sección describe ajustes que debes utilizar para tu recurso MongoDBMultiCluster.
apiVersionTipo: string
Versión del esquema de recursos de MongoDB Kubernetes.
kindTipo: string
Tipo de recurso de Kubernetes de MongoDB que se va a crear. Configurar esto en
MongoDBMultiCluster.
metadata.nameTipo: string
Nombre del recurso de MongoDB Kubernetes que está creando.
Los nombres de recursos deben tener 44 caracteres o menos.
spec.credentialsTipo: string
Nombre del secreto que creó como credenciales de autenticación de la API de Ops Manager para que el operador de Kubernetes se comunique con Ops Manager.
El objeto Ops Manager Kubernetes Secret que contiene las credenciales debe existir en el mismo espacio de nombres que el recurso que desea crear.
Importante
El operador gestiona los cambios en el secreto.
El operador de Kubernetes rastrea cualquier cambio en el Secreto y reconcilia el estado del recurso
MongoDB.
spec.typeTipo: string
Tipo de recurso de MongoDB Kubernetes a crear. El único valor aceptado para una implementación de MongoDB en un clúster de múltiples Kubernetes es ReplicaSet.
spec.versionTipo: string
Versión de MongoDB instalada para este recurso
MongoDBMultiCluster.Importante
Asegúrate de elegir una versión compatible de MongoDB Server.
Las versiones compatibles difieren según la imagen base que utiliza el recurso de base de datos de MongoDB.
Configuración de recursos MongoDBMultiCluster opcional
MongoDBMultiCluster los recursos pueden utilizar los siguientes ajustes:
spec.additionalMongodConfigtipo: colección
Opciones de configuración adicionales con las que desea iniciar los procesos de MongoDB.
El operador de Kubernetes admite todas las opciones de configuración que admite la versión de MongoDB que se implementa a través del MongoDB Agent, excepto que el operador de Kubernetes anula los valores que proporciona para cualquiera de las siguientes opciones:
net.portnet.tls.certificateKeyFilenet.tls.clusterFilereplication.replSetNamesecurity.clusterAuthModesharding.clusterRolestorage.dbPathsystemLog.destinationsystemLog.path
Para obtener más información sobre las opciones de configuración que gestiona el operador de Kubernetes, consulte Configuraciones exclusivas del operador de Kubernetes de MongoDB.
Para saber qué opciones de configuración puede utilizar, consulte Opciones avanzadas para implementaciones de MongoDB en la documentación de Ops Manager.
spec.agenttipo: colección
Configuración de MongoDB Agent para el recurso de base de datos de MongoDB.
spec.agent.startupOptionstipo: colección
Configuraciones de MongoDB Agent con las cuales deseas iniciar el recurso de la base de datos MongoDB.
Debe proporcionar la configuración de MongoDB Agent como pares clave-valor. Los valores deben ser cadenas de texto. Para obtener una lista de configuraciones admitidas del MongoDB Agent, consulta:
Configuración del agente de MongoDB para proyectos de Cloud Manager.
Configuración del agente de MongoDB para la versión de Ops Manager que implementó con el operador de Kubernetes.
spec.backuptipo: colección
El contenedor de recopilación para spec.backup.mode, que habilita copias de seguridad continuas para recursos de MongoDB en Kubernetes Operator.
spec.backup.assignmentLabelsTipo: arreglo
Lista de etiquetas de asignación para los procesos del servicio de demonio de copia de seguridad. Utilice las etiquetas de asignación para identificar que determinados procesos de demonio de copia de seguridad están asociados a proyectos específicos. Si configura las etiquetas de asignación mediante el operador de Kubernetes, los valores que establezca en el archivo de configuración de Kubernetes para las etiquetas de asignación anularán los valores definidos en la interfaz de usuario de Ops Manager. Las etiquetas de asignación que no configure mediante el operador de Kubernetes seguirán utilizando los valores establecidos en la interfaz de usuario de Ops Manager.
spec.backup.autoTerminateOnDeletionTipo: booleano
Indicador que especifica si el operador de Kubernetes detiene y finaliza la copia de seguridad al eliminar un recurso
MongoDBMultiCluster. El valor predeterminado esfalse. Establecer este indicador entrueresulta útil cuando se desea eliminar el recursoMongoDBMultiClustermientras que la configuración spec.backup.mode está establecida enenabled.
spec.backup.encryptionTipo: Objeto
Un objeto que contiene la configuración de cifrado de copias de seguridad.
spec.backup.encryption.kmipTipo: Objeto
Objeto que contiene la configuración de cifrado de copias de seguridad de KMIP. Para obtener más información, consulte Configurar el cifrado de copias de seguridad de KMIP para Ops Manager.
spec.backup.encryption.kmip.clientTipo: Objeto
Objeto que contiene la configuración del cliente de cifrado de copia de seguridad KMIP.
spec.backup.modeTipo: string
Habilita copias de seguridad continuas para un recurso
MongoDBMultiCluster. Los valores posibles sonenabled,disabledyterminated.Nota
La configuración spec.backup.mode depende de Backup que esté habilitado en Ops Manager y requiere que el valor
spec.backup.enableden la especificación de recursos de Ops Manager esté establecido entrue.Después de habilitar las copias de seguridad continuas para su recurso MongoDB con spec.backup.mode, puede comprobar el estado de la copia de seguridad.
spec.backup.snapshotScheduletipo: colección
Contenedor de colección para la configuración del cronograma de snapshot de copia de seguridad continuas para recursos de MongoDB en Kubernetes operador.
spec.backup.snapshotSchedule.dailySnapshotRetentionDaysTipo: número
Número de días para conservar las instantáneas diarias. Puede establecer un valor entre
1y365, inclusivo. Establecer el valor en0desactiva esta regla.
spec.backup.snapshotSchedule.fullIncrementalDayOfWeekTipo: string
Día de la semana en que Ops Manager toma una snapshot completa. Esta configuración garantiza una copia de seguridad completa reciente. Ops Manager establece el valor por defecto en
SUNDAY.
spec.backup.snapshotSchedule.monthlySnapshotRetentionMonthsTipo: número
Número de meses para conservar copias de seguridad mensuales. Puede establecer un valor entre
1y36, inclusivo. Establecer el valor en0desactiva esta regla.
spec.backup.snapshotSchedule.pointInTimeWindowHoursTipo: número
Número de horas en el pasado para las que puedes crear una snapshot puntual.
spec.backup.snapshotSchedule.referenceHourOfDayTipo: número
HoraUTC del día para programar instantáneas usando un reloj de 24 horas. Puede establecer un valor entre
0y23, ambos inclusive.
spec.backup.snapshotSchedule.referenceMinuteOfHourTipo: número
MinutoUTC de la hora para programar instantáneas. Puede establecer un valor entre
0y59, ambos inclusive.
spec.backup.snapshotSchedule.snapshotIntervalHoursTipo: número
Número de horas entre instantáneas. Puede establecer un valor de
6,8,12o24.
spec.backup.snapshotSchedule.snapshotRetentionDaysTipo: número
Número de días para mantener las snapshot recientes. Puedes establecer un valor entre
2y5, inclusive.
spec.backup.snapshotSchedule.weeklySnapshotRetentionWeeksTipo: número
Número de semanas para conservar los snapshots semanales. Puedes establecer un valor entre
1y52, inclusive. Configurar el valor a0deshabilita esta regla.
spec.cloudManager.configMapRef.nameTipo: string
Alias para spec.opsManager.configMapRef.name.
spec.clusterSpecListtipo: colección
Lista de especificaciones para cada clúster de Kubernetes en un recurso
MongoDBMultiCluster.
spec.clusterSpecList.clusterNameTipo: string
Nombre del clúster donde el operador de controladores de MongoDB para Kubernetes programa el StatefulSet. Cuando el operador de Kubernetes implementa este recurso
MongoDBMultiCluster, crea una cuenta de servicio. Este nombre es el que utiliza la cuenta de servicio en el clúster central para comunicarse con los clústeres de carga de trabajo.
spec.clusterSpecList.externalAccess.externalDomainTipo: string
Un dominio externo utilizado para exponer externamente su implementación de set de réplicas.
De forma predeterminada, cada miembro del conjunto de réplicas utiliza el FQDN del Pod de Kubernetes (
*.svc.cluster.local) como nombre de host predeterminado. Sin embargo, si agrega un dominio externo a esta configuración, el conjunto de réplicas utilizará un nombre de host que sea un subdominio del dominio especificado. Este nombre de host utiliza el siguiente formato:<replica-set-name>-<cluster-idx>-<pod-idx>.<externalDomain>Por ejemplo:
multi-replica-set-0-1.cluster-0.example.comDespués de implementar el conjunto de réplicas con esta configuración, el operador de Kubernetes utiliza el nombre de host con el dominio externo para sobrescribir el campo
processes[n].hostnameen la configuración de automatización de Ops Manager. A continuación, el agente de MongoDB utiliza este nombre de host para conectarse amongod.Para especificar otros nombres de host para conectarse al set de réplicas, puede utilizar el ajuste
spec.connectivity.replicaSetHorizons. Sin embargo, las siguientes conexiones aún utilizan el nombre de host con el dominio externo:El agente de MongoDB para conectarse a
mongod.
ADVERTENCIA: Especificar este campo modifica la forma en que Ops Manager registra los procesos
mongod. No puede cambiar el valor de este campo ni de ningún otro campoprocesses[n].hostnameen la configuración de automatización de Ops Manager para una implementación de conjunto de réplicas en ejecución.Importante
Utilice esta configuración solo al implementar un set de réplicas de implementación de MongoDB multi-Kubernetes sin una malla de servicios. Consulta Implementación en clústeres Multi-Kubernetes: Sin malla de servicios.
spec.clusterSpecList.externalAccess.externalServicetipo: colección
Configuración para exponer externamente un clúster específico en su implementación de MongoDB con múltiples clústeres de Kubernetes. Estos ajustes anulan la configuración global spec.externalAccess.externalService.
Al configurar el ajuste spec.externalAccess, el operador de Kubernetes crea automáticamente un servicio de balanceador de carga externo con valores predeterminados. Puede anular ciertos valores o agregar nuevos según sus necesidades. Por ejemplo, si desea crear servicios NodePort y no necesita un balanceador de carga, debe configurar anulaciones en su especificación de Kubernetes:
externalAccess: externalService: annotations: # cloud-specific annotations for the service spec: type: NodePort # default is LoadBalancer # you can specify other spec overrides if necessary Para obtener más información sobre la especificación de Kubernetes, consulte ServiceSpec en la documentación de Kubernetes.
spec.clusterSpecList.externalAccess.externalService.annotationstipo: colección
Pares clave-valor que permiten agregar configuraciones específicas del proveedor de nube a un clúster específico en su implementación de MongoDB en clústeres multi-Kubernetes. Esta configuración anula la configuración global, spec.externalAccess.externalService.annotations. Para obtener más información, consulte las anotaciones y la documentación de su proveedor de nube Kubernetes.
Puedes usar anotaciones para especificar valores de marcador de posición para los servicios externos que utilizan las implementaciones del Operador de Kubernetes. El Operador de Kubernetes reemplaza automáticamente estos valores con los correctos, tal como se describe en la siguiente tabla. El uso de marcadores de posición te permite proporcionar anotaciones específicas para cada servicio de un Pod concreto.
ValorDescripción{resourceName}Equal a
metadata.name.{namespace}Equal a
metadata.namespace.{podIndex}Índice del Pod asignado por el StatefulSet y al que apunta el servicio externo actual.
{podName}Igual a
{resourceName}-{clusterIndex}-{podIndex}.{clusterName}El nombre del clúster actual se establece en spec.clusterSpecList.clusterName.
{clusterIndex}El índice asignado inicialmente por el operador de Kubernetes para el nombre del clúster actual establecido en spec.clusterSpecList.clusterName.
Es posible que este valor no refleje el orden de los clústeres miembros definidos en spec.clusterSpecList. Si bien puede cambiar el orden de los clústeres miembros en spec.clusterSpecList, el operador de Kubernetes sigue utilizando el índice que asignó inicialmente para el nombre del clúster actual.
{statefulSetName}El StatefulSet. Igual a
{resourceName}-{clusterIndex}.{externalServiceName}Nombre generado del servicio externo, basado en los valores de los marcadores de posición que hayas especificado. Igual a
{resourceName}-{clusterIndex}-{podIndex}-svc-external.{mongodProcessDomain}El nombre de dominio del servidor que aloja el proceso mongod. Si se especifica, será igual a spec.externalAccess.externalDomain. De lo contrario, será igual al dominio utilizado para el FQDN del proceso
mongod.Por ejemplo, para el nombre de host del proceso
mdb-rs-1.example.com,example.comes el nombre de dominio.{mongodProcessFQDN}El nombre de host del proceso
mongodestablecido en la configuración de automatización.El nombre de host del proceso depende de la configuración de su implementación. Si ha configurado su implementación de MongoDB en un clúster multi-Kubernetes para usar dominios externos, como en el caso de una implementación sin malla de servicios, el nombre de host del proceso utiliza el siguiente formato:
{resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}Por ejemplo:
mdb-rs-0-1.example.comSi tu implementación no utiliza dominios externos, el nombre de host del proceso utiliza el siguiente formato:
{resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.localPor ejemplo:
mdb-rs-1-svc.ns.svc.cluster.localNota
Debes usar solo los valores de marcadores de posición conocidos, tal y como se especifica en la tabla, y asegurarte de que tus marcadores de posición no usen valores vacíos o nulos. De lo contrario, el operador de Kubernetes devuelve un error. Por ejemplo, puede que te encuentre con el siguiente mensaje de error:
error replacing placeholders in map with key=external-dns.alpha.kubernetes.io/hostname, value={resourceName}-{podIndex}-{unknownPlaceholder}.{clusterName}-{clusterIndex}.example.com: missing values for the following placeholders: {clusterName}, {clusterIndex}, {unknownPlaceholder}`` Ejemplo
El siguiente ejemplo especifica los marcadores de posición
{resourceName},{podIndex}y{namespace}:apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: mdb-rs namespace: ns spec: replicas: 3 externalAccess: externalService: annotations: external-dns.alpha.kubernetes.io/hostname: {resourceName}-{podIndex}-{namespace}.example.com El operador de Kubernetes completa automáticamente las anotaciones para los servicios externos en función del valor adecuado para cada marcador de posición. Por ejemplo:
mdb-rs-0-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-0-ns.example.com mdb-rs-1-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-1-ns.example.com mdb-rs-2-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-2-ns.example.com
spec.clusterSpecList.externalAccess.externalService.spectipo: colección
Configuración para ServiceSpec. Para obtener más información, consulte spec.clusterSpecList.externalAccess.externalService.
spec.clusterSpecList.memberConfigtipo: colección
Especificación para cada set de réplicas de MongoDB y sus nodos en su implementación de MongoDB en un clúster multi-Kubernetes.
El orden de los elementos en el objeto para cada set de réplicas debe reflejar el orden de los nodos en el set de réplicas. Por ejemplo, el primer elemento afecta al Pod en el índice
0, el segundo elemento afecta al índice1, y así sucesivamente.Ejemplo
Se debe considerar el siguiente ejemplo de especificación para una implementación de MongoDB en un clúster multi-Kubernetes con tres sets de réplicas:
apiVersion: mongodb.com/v1 kind: MongoDBMultiCluster metadata: name: multi-replica-set spec: version: 8.0.0 type: ReplicaSet duplicateServiceObjects: false credentials: my-credentials opsManager: configMapRef: name: my-project clusterSpecList: - clusterName: cluster1.example.com members: 2 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod" - votes: 1 priority: "1.5" tags: tag2: "value2" environment: "prod" - clusterName: cluster2.example.com members: 1 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod" - clusterName: cluster3.example.com members: 1 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod"
spec.clusterSpecList.memberConfig.priorityTipo: string
Número que indica la probabilidad relativa de que un miembro del conjunto de réplicas de MongoDB se convierta en el principal.
Para aumentar la probabilidad relativa de que un miembro del set de réplicas se convierta en el primario, es necesario especificar un valor de
prioritymás alto.Para disminuir la probabilidad relativa de que un miembro del set de réplicas se convierta en el primario, especifica un valor
prioritymás bajo.
Por ejemplo, un nodo con un
memberConfig.priorityde1.5es más probable que se convierta en primario que un nodo con unmemberConfig.priorityde0.5.Un miembro con un
memberConfig.priorityde0no puede ser elegido como miembro principal. Para obtener más información, consulte Prioridad de miembros.
spec.clusterSpecList.memberConfig.tagsTipo: mapa
Mapa de etiquetas de conjuntos de réplicas para dirigir las operaciones de lectura y escritura a miembros específicos de su conjunto de réplicas de MongoDB.
spec.clusterSpecList.memberConfig.votesTipo: número
Determina si un miembro del conjunto de réplicas de MongoDB puede votar en una elección. Establezca el valor en
1para permitir que el miembro vote. Establezca el valor en0para excluir al miembro de una elección.
spec.clusterSpecList.membersTipo: número
Número de miembros en el set de réplicas de MongoDB.
spec.clusterSpecList.serviceTipo: string
Por defecto: <resource_name>+"-service"
Nombre del servicio de Kubernetes que desea crear o usar para un StatefulSet. Si ya existe un servicio con este nombre, el operador de controladores de MongoDB para Kubernetes no lo elimina ni lo vuelve a crear. Esta configuración le permite crear sus propios servicios personalizados y que el operador de Kubernetes los reutilice.
spec.clusterSpecList.statefulSet.spectipo: colección
Proporciona la configuración para la anulación de StatefulSet para cada uno de los StatefulSets del clúster en una implementación de MongoDB con múltiples clústeres de Kubernetes. Para establecer la configuración global que se aplica a todos los clústeres en su implementación de MongoDB con múltiples clústeres de Kubernetes, consulte spec.statefulSet.spec.
Esta configuración se aplica solo a tipos de recursos de sets de réplicas en implementaciones de MongoDB multiclúster en Kubernetes.
spec.connectivity.replicaSetHorizonstipo: colección
Permite configurar diferentes ajustes DNS para las aplicaciones cliente y los agentes de MongoDB. El operador de Kubernetes utiliza DNS de horizonte dividido para los miembros del conjunto de réplicas. Esta función permite la comunicación tanto dentro del clúster de Kubernetes como desde fuera de él.
Puede añadir múltiples mapeos externos por host.
Nota
Asegúrese de que cada valor en este arreglo sea único.
Asegúrate de que el número de entradas en este arreglo coincida con el valor dado en spec.clusterSpecList.members.
Proporcione un valor para la configuración spec.security.certsSecretPrefix para habilitar TLS. Este método para usar horizontes divididos requiere la extensión Server Name Indication del protocolo TLS.
En este ejemplo, los clientes se comunican con el set de réplicas utilizando el horizonte
example-website.15 security: 16 tls: 17 enabled: true 18 connectivity: 19 replicaSetHorizons: 20 - "example-website": "web1.example.com:30907" 21 - "example-website": "web2.example.com:32350" 22 - "example-website": "web3.example.com:31185" 23 ...
spec.duplicateServiceObjectsTipo: booleano
Por defecto: true
Especifica si el operador de Kubernetes duplica el objeto de malla de servicios de un Pod en cada clúster para permitir la resolución DNS. Establézcalo en
falsesi configura un proxy DNS para su malla de servicios. Por ejemplo, consulte la sección sobre proxy DNS en la documentación de Istio.
spec.externalAccesstipo: colección
Especificación para exponer tu implementación de MongoDB en multi-Kubernetes para conexiones externas. Para aprender cómo conectarse a su implementación de MongoDB Multi-Kubernetes desde fuera del clúster de Kubernetes, consulte Conectarse al recurso multi-clúster desde fuera de Kubernetes.
Estos ajustes se aplican a los servicios de todos los clústeres. Para anular estos ajustes globales en un clúster específico, utilice spec.clusterSpecList.externalAccess.externalService.
Si agrega
spec.externalAccess, el operador de Kubernetes crea un servicio externo para cada Pod en un conjunto de réplicas. Los servicios externos proporcionan un punto de entrada externo para cada Pod de base de datos MongoDB en un clúster. Cada servicio externo tiene selectores que lo asocian a un Pod específico.Si agrega esta configuración sin ningún valor, el Operador de Kubernetes crea un servicio externo con los siguientes valores por defecto:
CampoValorDescripciónName<pod-name>-svc-externalNombre del Servicio externo. No puedes cambiar este valor.
TypeLoadBalancerCrea un servicio LoadBalancer externo.
Port<Port Number>Un puerto para
mongod.publishNotReadyAddresstrueEspecifica que los registros DNS se crean incluso si el Pod no está listo. No lo configure en
falsepara ningún Pod de base de datos.Nota
Si configura spec.clusterSpecList.externalAccess.externalDomain, el servicio externo agrega otro puerto (
Port Number + 1) para copias de seguridad.
spec.externalAccess.externalServicetipo: colección
Especificación para anular los valores por defecto en
spec.externalAccess.Al configurar el ajuste spec.externalAccess, el operador de Kubernetes crea automáticamente un servicio de balanceador de carga externo con valores predeterminados. Puede anular ciertos valores o agregar nuevos según sus necesidades. Por ejemplo, si desea crear servicios NodePort y no necesita un balanceador de carga, debe configurar anulaciones en su especificación de Kubernetes:
externalAccess: externalService: annotations: # cloud-specific annotations for the service spec: type: NodePort # default is LoadBalancer # you can specify other spec overrides if necessary Para obtener más información sobre la especificación de Kubernetes, consulte ServiceSpec en la documentación de Kubernetes.
spec.externalAccess.externalService.annotationstipo: colección
Pares clave-valor que permiten agregar configuraciones específicas del proveedor de la nube a todos los clústeres en su implementación de MongoDB con múltiples clústeres de Kubernetes. Para anulaciones específicas del clúster, consulte spec.clusterSpecList.externalAccess.externalService.annotations. Para obtener más información, consulte las anotaciones y la documentación del proveedor de la nube que utiliza para las implementaciones de Kubernetes.
Puedes usar anotaciones para especificar valores de marcador de posición para los servicios externos que utilizan las implementaciones del Operador de Kubernetes. El Operador de Kubernetes reemplaza automáticamente estos valores con los correctos, tal como se describe en la siguiente tabla. El uso de marcadores de posición te permite proporcionar anotaciones específicas para cada servicio de un Pod concreto.
ValorDescripción{resourceName}Equal a
metadata.name.{namespace}Equal a
metadata.namespace.{podIndex}Índice del Pod asignado por el StatefulSet y al que apunta el servicio externo actual.
{podName}Igual a
{resourceName}-{clusterIndex}-{podIndex}.{clusterName}El nombre del clúster actual se establece en spec.clusterSpecList.clusterName.
{clusterIndex}El índice asignado inicialmente por el operador de Kubernetes para el nombre del clúster actual establecido en spec.clusterSpecList.clusterName.
Es posible que este valor no refleje el orden de los clústeres miembros definidos en spec.clusterSpecList. Si bien puede cambiar el orden de los clústeres miembros en spec.clusterSpecList, el operador de Kubernetes sigue utilizando el índice que asignó inicialmente para el nombre del clúster actual.
{statefulSetName}El StatefulSet. Igual a
{resourceName}-{clusterIndex}.{externalServiceName}Nombre generado del servicio externo, basado en los valores de los marcadores de posición que hayas especificado. Igual a
{resourceName}-{clusterIndex}-{podIndex}-svc-external.{mongodProcessDomain}El nombre de dominio del servidor que aloja el proceso mongod. Si se especifica, será igual a spec.externalAccess.externalDomain. De lo contrario, será igual al dominio utilizado para el FQDN del proceso
mongod.Por ejemplo, para el nombre de host del proceso
mdb-rs-1.example.com,example.comes el nombre de dominio.{mongodProcessFQDN}El nombre de host del proceso
mongodestablecido en la configuración de automatización.El nombre de host del proceso depende de la configuración de su implementación. Si ha configurado su implementación de MongoDB en un clúster multi-Kubernetes para usar dominios externos, como en el caso de una implementación sin malla de servicios, el nombre de host del proceso utiliza el siguiente formato:
{resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}Por ejemplo:
mdb-rs-0-1.example.comSi tu implementación no utiliza dominios externos, el nombre de host del proceso utiliza el siguiente formato:
{resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.localPor ejemplo:
mdb-rs-1-svc.ns.svc.cluster.localNota
Debes usar solo los valores de marcadores de posición conocidos, tal y como se especifica en la tabla, y asegurarte de que tus marcadores de posición no usen valores vacíos o nulos. De lo contrario, el operador de Kubernetes devuelve un error. Por ejemplo, puede que te encuentre con el siguiente mensaje de error:
error replacing placeholders in map with key=external-dns.alpha.kubernetes.io/hostname, value={resourceName}-{podIndex}-{unknownPlaceholder}.{clusterName}-{clusterIndex}.example.com: missing values for the following placeholders: {clusterName}, {clusterIndex}, {unknownPlaceholder}`` Ejemplo
El siguiente ejemplo especifica los marcadores de posición
{resourceName},{podIndex}y{namespace}:apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: mdb-rs namespace: ns spec: replicas: 3 externalAccess: externalService: annotations: external-dns.alpha.kubernetes.io/hostname: {resourceName}-{podIndex}-{namespace}.example.com El operador de Kubernetes completa automáticamente las anotaciones para los servicios externos en función del valor adecuado para cada marcador de posición. Por ejemplo:
mdb-rs-0-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-0-ns.example.com mdb-rs-1-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-1-ns.example.com mdb-rs-2-svc-external: annotations: external-dns.alpha.kubernetes.io/hostname: mdb-rs-2-ns.example.com
spec.externalAccess.externalService.spectipo: colección
Configuración para ServiceSpec. Para obtener más información, consulte spec.externalAccess.externalService.
spec.featureCompatibilityVersionTipo: número
Limita los cambios en los datos que se producen al actualizar a una nueva versión principal. Esto permite volver a la versión principal anterior. Para obtener más información sobre la compatibilidad de las funciones, consulte
setFeatureCompatibilityVersionen el Manual de MongoDB.
spec.logLevelTipo: string
Configura el nivel de registro del Agente de automatización dentro del Pod. Los valores aceptados incluyen:
DEBUGINFOWARNERRORFATAL
spec.opsManager.configMapRef.nameTipo: string
Nombre del ConfigMap con la configuración de conexión de Cloud Manager u Ops Manager. El valor spec.cloudManager.configMapRef.name es un alias para este valor y puede utilizarse en su lugar.
Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.
Importante
El operador gestiona los cambios en el ConfigMap
El Operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso
MongoDB.
spec.persistentTipo: booleano
Por defecto: true
ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su Volumen Persistente. El Operador de Kubernetes establece
fsGroup = 2000,runAsUser = 2000yrunAsNonRoot = trueensecurityContext. El Operador de Kubernetes establecefsgroupigual arunAsUserpara que el volumen sea escribible para el usuario que ejecuta el proceso principal en el contenedor. Para obtener más información, consulte Configurar un Contexto de Seguridad para un Pod o Contenedor y la sección relacionada en la documentación de Kubernetes. Si la redistribución del recurso no soluciona los problemas con su Volumen Persistente, póngase en contacto con el Soporte de MongoDB.Si no utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en la pestaña Processes de la página Deployment ni en la página Metrics al revisar los datos de esta implementación.
spec.security.authenticationtipo: colección
Especificaciones de autenticación para tu implementación de MongoDB en un clúster múltiple de Kubernetes.
spec.security.authentication.agentstipo: colección
Configuración de autenticación del agente de MongoDB para el proyecto de Cloud Manager u Ops Manager.
spec.security.authentication.agents.automationLdapGroupDNTipo: string
El Nombre distinguido (DN) del grupo LDAP al que pertenece el usuario de MongoDB Agent.
Esta configuración es necesaria si:
spec.security.authentication.ldap.authzQueryTemplate está presente y
spec.security.authentication.agents.mode es
LDAPoX509.
spec.security.authentication.agents.automationPasswordSecretReftipo: colección
Detalles del secreto que contiene la contraseña para el usuario spec.security.authentication.agents.automationUserName.
Esta configuración es necesaria si spec.security.authentication.agents.mode es
LDAP.
spec.security.authentication.agents.automationPasswordSecretRef.keyTipo: string
Introduzca el secreto spec.security.authentication.agents.automationPasswordSecretRef.name que contiene la contraseña del usuario en spec.security.authentication.agents.automationUserName.
Esta configuración es necesaria si spec.security.authentication.agents.mode es
LDAP.
spec.security.authentication.agents.automationPasswordSecretRef.nameTipo: string
Nombre del secreto que contiene la contraseña del usuario spec.security.authentication.agents.automationUserName. Debe crear este secreto en el mismo espacio de nombres en el que implementa el operador de Kubernetes:
kubectl create secret generic ldap-agent-user \ --from-literal="password=<password>" -n <metadata.namespace> Este secreto debe contener una clave, cuyo valor coincida con la contraseña del usuario spec.security.authentication.agents.automationUserName en su implementación LDAP.
Esta configuración es necesaria si spec.security.authentication.agents.mode es
LDAP.
spec.security.authentication.agents.automationPasswordSecretRef.optionalTipo: booleano
Especifica si estas opciones son obligatorias u opcionales:
spec.security.authentication.agents.automationUserNameTipo: string
Nombre del usuario que los agentes de MongoDB utilizan para interactuar con la implementación de MongoDB en su clúster multi-Kubernetes. El nombre de usuario se asigna a un nombre distinguido (DN) de LDAP según spec.security.authentication.ldap.userToDNMapping. El DN resultante debe existir previamente en su implementación de LDAP.
Esta configuración es necesaria si spec.security.authentication.agents.mode es
LDAP.
spec.security.authentication.agents.clientCertificateSecretRef.nameTipo: string
Por defecto: agent-certs
Especifica el secreto que contiene el certificado TLS del agente de MongoDB.
Este secreto debe contener la clave
mms-automation-agent-pem. El valor de esta clave debe ser un certificado TLS que pueda ser validado por el servidor.Se debe crear este secreto en el mismo namespace al que se implemente el Operador Kubernetes:
kubectl create secret generic agent-certs \ --from-file=mms-automation-agent-pem=<automation-cert.pem> \ --namespace=<metadata.namespace>
spec.security.authentication.enabledTipo: booleano
Por defecto: false
Especifica si la autenticación está habilitada en el proyecto de Cloud Manager o Ops Manager. Si se establece en
true, debe configurar un mecanismo de autenticación en spec.security.authentication.modes.Importante
El operador de Kubernetes gestiona la autenticación para este recurso MongoDB si se incluye este ajuste, incluso si está configurado en
false. No puedes configurar la autenticación para este recurso usando la interfaz de usuario de Cloud Manager u Ops Manager, ni usar las API, mientras esta configuración exista en la especificación del recurso.Omite esta configuración si deseas gestionar la autenticación utilizando la interfaz de usuario de Cloud Manager u Ops Manager o las API.
spec.security.authentication.agents.modeTipo: string
Mecanismo de autenticación que utilizan los agentes de MongoDB para su implementación de MongoDB en clústeres multi-Kubernetes. Los valores válidos son
SCRAM,SCRAM-SHA-1,MONGODB-CR,X509yLDAP. El valor que especifique también debe estar presente en spec.security.authentication.modes. RecomendamosSCRAM-SHA-256 (SCRAM)en lugar deSCRAM-SHA-1. Si especificaSCRAM-SHA-1, también debe especificarMONGODB-CR.Esta configuración es necesaria si especificó más de un valor para spec.security.authentication.modes.
spec.security.authentication.ignoreUnknownUsersTipo: booleano
Por defecto: false
Determina si se pueden modificar los usuarios de la base de datos que no fueron configurados a través de Kubernetes operador, Cloud Manager u Ops Manager.
Para administrar los usuarios de la base de datos directamente a través de
mongodomongos, configure entrue.
spec.security.authentication.internalClusterTipo: string
Especifica si la autenticación interna del clúster X.509 está habilitada.
Para habilitar la autenticación interna del clúster X.509, configúrelo en
"X509". Requiere que se especifiquen los siguientes ajustes:spec.seguridad.autenticación.modos
: ["X509"]
El Operador de Kubernetes acepta los siguientes valores:
["X509"]: La autenticación interna de clúster X.509 está habilitada.""u omitido: la autenticación interna del clúster no está habilitada.
Importante
Después de habilitar la autenticación interna del clúster, no se puede deshabilitar.
spec.security.authentication.ldaptipo: colección
Requerido para la autenticación LDAP.
Configura la autenticación LDAP para el proyecto Cloud Manager u Ops Manager. Para habilitar la autenticación LDAP, establezca spec.security.authentication.modes en
["LDAP"].
spec.security.authentication.ldap.authzQueryTemplateTipo: string
Requerido para la autorizacion LDAP.
Plantilla de URL de consulta con formato LDAP RFC4515 y RFC4516 ejecutada por MongoDB para obtener los grupos LDAP a los que pertenece el usuario. La consulta es relativa al host o hosts especificados en
spec.security.authentication.ldap.servers. Puede utilizar los siguientes tokens en la plantilla:{USER}- Sustituye el nombre de usuario autenticado, o el nombre de usuario
transformed, en la consulta LDAP.
{PROVIDED_USER}- Sustituye el nombre de usuario proporcionado, antes de la autenticación o la transformación de LDAP, en la query LDAP. (Disponible a partir de la versión 4.2 de MongoDB).
Para obtener más detalles, consulte las plantillas de consulta LDAP en el manual de MongoDB.
spec.security.authentication.ldap.bindQueryPasswordSecretReftipo: colección
Requerido para la autenticación LDAP.
Especifica el secreto que contiene la contraseña con la que MongoDB se vincula al conectarse al servidor LDAP.
spec.security.authentication.ldap.bindQueryPasswordSecretRef.nameTipo: string
Requerido para la autenticación LDAP.
Nombre del secreto que contiene la contraseña con la que MongoDB se autentica al conectarse al servidor LDAP.
El secreto debe contener solo un campo
passwordque almacene la contraseña.
spec.security.authentication.ldap.bindQueryUserTipo: string
Requerido para la autenticación LDAP.
Nombre distintivoLDAP al que se vincula MongoDB al conectarse al servidor LDAP.
spec.security.authentication.ldap.caConfigMapReftipo: colección
Se requiere para la autenticación LDAP con TLS.
ConfigMap que contiene una CA que valida el certificado TLS del servidor LDAP.
spec.security.authentication.ldap.caConfigMapRef.keyTipo: string
Se requiere para la autenticación LDAP con TLS.
Nombre del campo que almacena la CA que valida el servidor LDAP del certificado TLS.
spec.security.authentication.ldap.caConfigMapRef.nameTipo: string
Se requiere para la autenticación LDAP con TLS.
Nombre del ConfigMap que contiene una CA que valida el certificado TLS del servidor LDAP.
spec.security.authentication.ldap.caConfigMapRef.optionalTipo: booleano
Especifica si estas opciones son obligatorias u opcionales:
spec.security.authentication.ldap.serversTipo: arreglo de cadenas
Requerido para la autenticación LDAP.
Lista de nombres de host y puertos de los servidores LDAP. Especifique los nombres de host con sus respectivos puertos en el siguiente formato:
spec: security: authentication: ldap: servers: - "<hostname1>:<port1>" - "<hostname2>:<port2>"
spec.security.authentication.ldap.timeoutMSTipo: entero
Especifica cuántos milisegundos debe esperar una solicitud de autenticación antes de agotar el tiempo de espera.
spec.security.authentication.ldap.transportSecurityTipo: string
Requerido para la autenticación LDAP.
Especifica si el servidor LDAP acepta TLS.
Si el servidor LDAP acepta TLS, establezca el valor en
tls. Si el servidor LDAP no acepta TLS, deje este valor en blanco o establezca el valor ennone.Nota
Si se especifica un string diferente de
noneotls, Kubernetes Operator aún establece la configuración entls.
spec.security.authentication.ldap.userCacheInvalidationIntervalTipo: entero
Especifica cuántos segundos espera MongoDB para vaciar la caché de usuarios LDAP. El valor predeterminado es 30 segundos.
spec.security.authentication.ldap.userToDNMappingTipo: string
Asigna el nombre de usuario proporcionado a
mongodomongospara la autenticación en un nombre distinguido (DN) de LDAP.Para obtener más detalles, consulte security.ldap.userToDNMapping en el Manual de MongoDB.
spec.security.authentication.modesTipo: arreglo
Especifica el mecanismo de autenticación que utiliza tu implementación de MongoDB en varios clústeres de Kubernetes. Los valores válidos son
SCRAM,SCRAM-SHA-1,MONGODB-CR,X509yLDAP. RecomendamosSCRAM-SHA-256 (SCRAM)en lugar deSCRAM-SHA-1. Si especificasSCRAM-SHA-1, también debes especificarMONGODB-CR.Nota
Para habilitar la autenticación interna del clúster X.509 para el proyecto Cloud Manager u Ops Manager, establezca este valor en
["X509"]y especifique la siguiente configuración:Proporcione un valor para la configuración spec.security.certsSecretPrefix.
Si proporciona más de un valor para
spec.security.authentication.modes, también debe especificar un valor para spec.security.authentication.agents.mode.
spec.security.authentication.requireClientTLSAuthenticationTipo: booleano
Por defecto: false
Especifica si el servidor de MongoDB requiere que los clientes se conecten mediante un certificado TLS. El valor predeterminado es
truesi se habilita la autenticación TLS.Para habilitar la autenticación TLS, proporcione un valor para la configuración spec.security.certsSecretPrefix.
spec.security.certsSecretPrefixTipo: string
Texto que se añadirá como prefijo a los secretos de Kubernetes que has creado y que contienen las claves TLS y los certificados de tu conjunto de réplicas.
Debe anteponer sus secretos con
<prefix>-<metadata.name>.Por ejemplo, si llama a su despliegue
my-deploymenty establece el prefijo enmdb, debe nombrar el secreto TLS para las comunicaciones TLS del cliente comomdb-my-deployment-cert. Además, debe nombrar el secreto TLS para la autenticación interna del clúster (si está habilitada) comomdb-my-deployment-clusterfile.Para obtener más información sobre cómo nombrar los secretos que contienen sus certificados TLS, consulte el tema correspondiente a su implementación en la Guía de inicio rápido para clústeres de Multi-Kubernetes.
spec.security.rolesTipo: arreglo
Matriz que define roles definidos por el usuario que le brindan un control de acceso granular sobre su implementación de MongoDB en clústeres multi-Kubernetes.
Para habilitar los roles definidos por el usuario,spec.security.authentication.enabled debe ser
true.Ejemplo
En este ejemplo, un rol definido por el usuario llamado
customRolepermite a los usuarios asignados a este rol:Inserte documentos en la colección
catsen la base de datospetsyBuscar e insertar documentos en la colección
dogsen la base de datospets.
1 security: 2 authentication: 3 enabled: true 4 modes: 5 - "SCRAM" 6 roles: 7 - role: "customRole" 8 db: admin 9 privileges: 10 - actions: 11 - insert 12 resource: 13 collection: cats 14 db: pets 15 - actions: 16 - insert 17 - find 18 resource: 19 collection: dogs 20 db: pets 21 ...
spec.security.roles.authenticationRestrictionsTipo: arreglo
Matriz que define la dirección IP desde y hacia la cual pueden conectarse los usuarios a los que se les ha asignado este spec.security.roles.role.
spec.security.roles.authenticationRestrictions.clientSourceTipo: arreglo
Conjunto de direcciones IP o bloques CIDR desde los que pueden conectarse los usuarios a los que se les ha asignado este rol de seguridad (spec.security.roles.role).
Los servidores de MongoDB rechazan las solicitudes de conexión de usuarios con este rol si estas solicitudes provienen de un cliente que no esté presente en este arreglo.
spec.security.roles.authenticationRestrictions.serverAddressTipo: arreglo
Conjunto de direcciones IP o bloques CIDR a los que pueden conectarse los usuarios a los que se les ha asignado este rol spec.security.roles.role.
Los servidores de MongoDB rechazan las solicitudes de conexión de usuarios con este rol si el cliente solicita conectarse a un servidor que no está presente en este arreglo.
spec.security.roles.dbTipo: string
La base de datos en la que almacenar el rol definido por el usuario.
Ejemplo
admin
spec.security.roles.privilegesTipo: arreglo
Arreglo que describe los privilegios que poseen los usuarios a quienes se les otorgó este rol.
spec.security.roles.privileges.actionsTipo: arreglo
Lista de acciones que pueden realizar los usuarios con este rol. Para ver la lista de valores aceptados, consulte Acciones de privilegio en el Manual de MongoDB para las versiones de MongoDB que implemente con el Operador de Kubernetes.
spec.security.roles.privileges.resourcetipo: colección
Recursos para los que se aplica el privilegio spec.security.roles.privileges.actions.
Esta colección debe incluir cualquiera de lo siguiente:
La configuración spec.security.roles.privileges.resource.cluster con un valor de
true.
spec.security.roles.privileges.resource.clusterTipo: booleano
Por defecto: false
Indicador que especifica que el privilegio spec.security.roles.privileges.actions se aplica a todas las bases de datos y colecciones en la implementación de MongoDB.
Si se establece en verdadero, no proporcione valores para spec.security.roles.privileges.resource.db y spec.security.roles.privileges.resource.collection.
spec.security.roles.privileges.resource.collectionTipo: string
Colección en spec.security.roles.privileges.resource.db para la cual se aplica el privilegio spec.security.roles.privileges.actions.
Si proporciona un valor para esta configuración, también debe proporcionar un valor para spec.security.roles.privileges.resource.db.
spec.security.roles.privileges.resource.dbTipo: string
Base de datos para la cual se aplica el privilegio spec.security.roles.privileges.actions.
Si proporciona un valor para esta configuración, también debe proporcionar un valor para spec.security.roles.privileges.resource.collection.
spec.security.roles.roleTipo: string
Nombre del rol definido por el usuario.
spec.security.tls.additionalCertificateDomainstipo: colección
Lista de todos los dominios que deben agregarse a los certificados TLS de cada Pod en este despliegue. Al configurar este parámetro, cada CSR que el Operador de Kubernetes transforma en un certificado TLS incluye un SAN con el formato
<pod name>.<additional cert domain>.Los recursos de conjuntos de réplicas no necesitan este parámetro. En su lugar, utilice spec.connectivity.replicaSetHorizons.
Nota
Si agrega este parámetro a un recurso habilitado para TLS, Kubernetes muestra un error cuando el recurso alcanza el estado
Pending. Este error muestra:Please manually remove the |csr| in order to proceed.Para solucionar este problema:Elimine cualquier CSR existentepara que Kubernetes pueda generar nuevos CSR. Para obtener información sobre cómo eliminar un recurso, consulte la sección "Eliminar recursos" en la documentación de Kubernetes.
Apruebe las solicitudes de servicio de cliente (CSR) después de que Kubernetes las genere.
spec.security.tls.caTipo: string
Proporcione el nombre del ConfigMap que almacena la CA.
Importante
Si utiliza una CA personalizada para firmar sus certificados TLS para el recurso
MongoDBMultiCluster, debe especificar este parámetro.El operador de Kubernetes requiere que se nombre el certificado para el recurso
MongoDBMultiClustercomoca-pemen el ConfigMap.
spec.security.tls.enabledTipo: booleano
Importante
spec.security.tls.enabledEsta función está obsoleta y se eliminará en una futura versión de Kubernetes Operator. Para habilitar TLS, proporcione un valor para la configuración spec.security.certsSecretPrefix.Cifra las comunicaciones utilizando certificados TLS entre:
Hosts de MongoDB en una configuración de set de réplicas o clúster fragmentado
Clientes (shell
mongo, controladores, MongoDB Compass y otros) y la implementación de MongoDB
spec.statefulSet.spectipo: colección
Especificación global para el StatefulSet que el operador de controladores de MongoDB para Kubernetes crea para su implementación de MongoDB en clústeres multi-Kubernetes.
Para revisar qué campos puede agregar a
spec.statefulSet.spec, consulte StatefulSetSpec v1 apps en la documentación de Kubernetes.