Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
/ / /

Implementar un set de réplicas

Nota

En cualquier lugar de esta página donde diga Ops Manager, puedes sustituir Cloud Manager.

Importante

  • Puedes usar el Operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.

  • Puedes utilizar el Atlas Operator para implementar recursos de MongoDB en Atlas.

Advertencia

El operador de Kubernetes no es compatible con nodos árbitros.

Un conjunto de réplicas es un grupo de implementaciones de MongoDB que mantienen el mismo conjunto de datos. Los conjuntos de réplicas proporcionan redundancia y alta disponibilidad, y son la base de todas las implementaciones de producción.

Para obtener más información sobre los conjuntos de réplicas, consulte Introducción a la replicación en el manual de MongoDB.

Utilice este procedimiento para implementar un nuevo conjunto de réplicas administrado por Ops Manager. Tras la implementación, utilice Ops Manager para administrar el conjunto de réplicas, incluyendo operaciones como agregar, eliminar y reconfigurar miembros.

Cuando implementa su conjunto de réplicas a través del operador de Kubernetes, debe elegir si desea cifrar las conexiones mediante TLS certificados.

El siguiente procedimiento para TLS-Encrypted Conexiones:

  • Establece conexiones cifradas con TLSentre los hosts MongoDB en el conjunto de réplicas.

  • Establece conexiones cifradas mediante TLSentre aplicaciones cliente y implementaciones de MongoDB.

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento para Non-Encrypted Connections:

  • No cifra las conexiones entre los hosts MongoDB en el conjunto de réplicas.

  • No cifra las conexiones entre las aplicaciones cliente y las implementaciones de MongoDB.

  • Tiene menos requisitos de configuración que una implementación con conexiones cifradas TLS.

Nota

No puedes asegurar una instancia autónoma de MongoDB en un clúster de Kubernetes.

Para configurar el cifrado TLS para un cluster sharded, consulta Implementa un clúster particionado.

Seleccione la pestaña adecuada dependiendo de si desea cifrar las conexiones de su set de réplicas con TLS.

Para implementar un conjunto de réplicas utilizando un objeto, debe:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

  • Genera un certificado TLS para cada uno de los siguientes componentes:

    • Tu set de réplicas. Asegúrate de añadir SANs para cada pod de Kubernetes que hostee un nodo de tu set de réplicas al certificado.

      En tu certificado TLS, el SAN de cada pod debe utilizar el siguiente formato:

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local

      Importante

      Si utilizas un proveedor de servicios basado en ACME, como Let's Encrypt para emitir certificados TLS, el proveedor podría prohibirte añadir los FQDNpredeterminados del Pod (*.svc.cluster.local) a SANs en el certificado.

      Para usar un certificado basado en ACME, debe configurarlo para el recurso del conjunto de réplicas. Para obtener más información, consulte el paso sobre certificados TLS basados ​​en ACME en el procedimiento.

    • El agente de MongoDB de su proyecto. Para el certificado del agente de MongoDB, asegúrese de cumplir los siguientes requisitos:

      • El Nombre común en el certificado TLS no está vacío.

      • La Organización combinada y la Unidad Organizativa en cada certificado TLS difiere de la Organización y Unidad Organizativa en el certificado TLS para los miembros del set de réplicas.

  • Debes tener el archivo de certificado CA y nombrarlo ca-pem.

  • Debes tener la clave que usaste para firmar tus certificados TLS.

Importante

El operador de Kubernetes utiliza kubernetes.io/tls secretos para almacenar TLS certificados y llaves privadas para Ops Manager y recursos de MongoDB. A partir de la versión 1.17.0 del operador de Kubernetes, el operador de Kubernetes no admite archivos PEM concatenados almacenados como secretos opacos.

Para implementar un conjunto de réplicas utilizando un objeto, debe:

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Ejecute este kubectl comando para crear un nuevo secreto que almacene el certificado del conjunto de réplicas:

kubectl create secret tls <prefix>-<metadata.name>-cert \
--cert=<replica-set-tls-cert> \
--key=<replica-set-tls-key>

Nota

Debes anteponer a tus secretos el prefijo <prefix>-<metadata.name>.

Por ejemplo, si llama a su implementación my-deployment y establece el prefijo,mdb debe asignarle al secreto TLS para las comunicaciones TLS del cliente el mdb-my-deployment-cert nombre. Además, debe asignarle al secreto TLS para la autenticación interna del clúster (si está habilitada) el mdb-my-deployment-clusterfile nombre.

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

Para conocer sus opciones para el almacenamiento de secretos, consulte Configurar almacenamiento de secretos.

3

Ejecute este comando kubectl para crear un nuevo secreto que almacene el certificado TLS del agente:

kubectl create secret tls <prefix>-<metadata.name>-agent-certs \
--cert=<agent-tls-cert> \
--key=<agent-tls-key>

Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

4

Ejecuta este comando kubectl para vincular tu CA a tu set de réplicas y especificar el archivo del certificado CA.

Importante

El Operador de Kubernetes requiere que el certificado para el recurso MongoDB se llame ca-pem en el ConfigMap.

kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>
5

Cambie la configuración de este archivo YAML para que coincida con la configuración del conjunto de réplicas deseada.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5 name: <my-replica-set>
6spec:
7 members: 3
8 version: "8.0.0"
9 opsManager:
10 configMapRef:
11 # Must match metadata.name in ConfigMap file
12 name: <configMap.metadata.name>
13 credentials: <mycredentials>
14 type: ReplicaSet
15 persistent: true
16...
16 security:
17 tls:
18 ca: <custom-ca>
19 certsSecretPrefix: <prefix>
20...
6

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

7
Clave
Tipo
Descripción
Ejemplo

string

Etiqueta para este objeto de conjunto de réplicas de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

entero

Número de nodos del set de réplicas.

3

string

Versión de MongoDB que este set de réplicas debería ejecutar.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

8.0.0

spec
.opsManager
.configMapRef

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La configuración spec.cloudManager.configMapRef.name es un alias de esta configuración y se puede usar en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myconfigmap>

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el Operador Kubernetes se comunique con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager que contiene las credenciales debe existir en el mismo espacio de nombres que el recurso que desea crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

string

Tipo de recurso MongoDB que se va a crear.

ReplicaSet

string

Opcional.

Indicador que indica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan al MongoDB detener o reiniciar el recurso.

Si este valor true es, entonces se establece en su valor spec.podSpec.persistence.single predeterminado 16Gi de.

Para cambiar la <a class=\" \" target=\" \"href=\" \" rel=\"noopener noreferrer\"> Solicitud de volumen persistente <svg class=\" \" height=\" \" width=\" \" role=\" \" aria-hidden=\" \" alt=\" \" viewbox=\" \"><path d=\" \" fill=\" \"> <path d=\" \" fill=\" \"> configuración, configura las siguientes colecciones para cumplir con tus requisitos de implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su volumen persistente. El operador de Kubernetes fsGroup = 2000 establece, runAsUser = 2000 y runAsNonRoot = true en. El securityContext operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen pueda ser escrito por un 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 información relacionada en la documentación de Kubernetes. Si volver a implementar el recurso no soluciona los problemas con su volumen persistente, póngase en contacto con el soporte técnico de MongoDB.

Si no usas Volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en la pestaña Processes en la página Deployment, ni en la página Metrics al revisar los datos de esta implementación.

true

8

Para habilitar TLS en tu implementación, configura los siguientes ajustes en tu objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
Ejemplo
spec.security

string

Requerido

Agregar el nombre del ConfigMap que almacena la CA personalizada que usaste para firmar los certificados TLS de tu implementación.

<custom-ca>

spec.security

string

Requerido

Agrega el <prefix> del nombre secreto que contiene los certificados TLS de tu implementación de MongoDB.

Por ejemplo, si llama a su implementación my-deployment y establece el prefijo,mdb debe asignarle al secreto TLS para las comunicaciones TLS del cliente el mdb-my-deployment-cert nombre. Además, debe asignarle al secreto TLS para la autenticación interna del clúster (si está habilitada) el mdb-my-deployment-clusterfile nombre.

devDb

9

Si utilizas un proveedor de servicios basado en ACME, como Let's Encrypt para emitir certificados TLS, el proveedor podría prohibirte añadir los FQDNpredeterminados del Pod (*.svc.cluster.local) a los SANdel certificado.

Para configurar un certificado que no contenga los FQDNdel pod:

  1. Emitir el certificado para un dominio externo. Para obtener más información, consulte la documentación de Let's Encrypt o la documentación de su proveedor.

  2. Asegúrate de que tu certificado contenga todos los nombres de host que planeas implementar en el set de réplicas. Alternativamente, puedes emitir un certificado comodín para *.<externalDomain>.

  3. Para usar un certificado que contenga solo dominios externos para tu implementación del set de réplicas, deberás cambiar el hostname por defecto que usa el set de réplicas:

    • Si prefieres configurar el nombre de host al crear tu clúster de Kubernetes, cambia el dominio por defecto de cluster.local al dominio externo al crear o recrear tu clúster de Kubernetes. Luego, establece este dominio en tu recurso de MongoDB usando la configuración spec.clusterDomain.

    • De lo contrario, cree su implementación de MongoDB con las siguientes configuraciones configuradas en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
spec.externalAccess

string

Requerido

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 usa el FQDN del pod de Kubernetes*.svc.cluster.local () como nombre de host predeterminado. Sin embargo, si se agrega un dominio externo a esta configuración, el conjunto de réplicas usa un nombre de host que es un subdominio del dominio especificado. Este nombre de host tiene el siguiente formato:

<replica-set-name>-<pod-idx>.<externalDomain>

Por ejemplo:

replica-set-1.example.com

Después de implementar el set de réplicas con esta configuración, el Operador de Kubernetes utiliza el nombre de host con el dominio externo para anular el campo processes[n].hostname en el configuración de automatización de Ops Manager. Luego, el agente de MongoDB utiliza este nombre de host para conectarse a mongod.

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 se conecta a mongod.

  • mongod para conectar con otras mongod instancias.

ADVERTENCIA: Especificar este campo cambia la forma en que Ops Manager registra los procesos mongod. No puedes cambiar el valor de este campo ni de ninguno de los campos processes[n].hostname en la configuración de automatización de Ops Manager para una implementación activa de un set de réplicas.

spec.externalAccess

Colección

Opcional

Configuración para el ServiceSpec.

Al configurar el ajuste spec.externalAccess, el operador de Kubernetes crea automáticamente un servicio de balanceador de carga externo con valores por defecto. Puedes anular ciertos valores o agregar nuevos valores dependiendo de tus necesidades. Por ejemplo, si tiene la intención de crear servicios NodePort y no necesita un balanceador de cargas, debe configurar las 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, consulta ServiceSpec en la documentación de Kubernetes.

spec.externalAccess

Colección

Opcional

Pares clave-valor que le permiten agregar configuraciones específicas del proveedor de nube a todos los clústeres de su implementación. Para obtener más información, consulte anotaciones y la documentación de su proveedor de nube de Kubernetes.

Puedes especificar valores de marcador de posición para personalizar tus anotaciones. Para obtener más información, consulta spec.externalAccess.externalService.annotations.

10

También puede añadir cualquiera de los siguientes ajustes opcionales al archivo de especificaciones del objeto para el set de réplicas implementación:

Advertencia

Debe establecer spec.clusterDomain si su clúster Kubernetes tiene un dominio por defecto diferente al por defecto cluster.local. Si no utilizas la opción por defecto ni estableces la opción spec.clusterDomain, el Operador Kubernetes podría no funcionar como se espera.

11
12

En cualquier directorio, ejecuta el siguiente comando de Kubernetes para crear tu set de réplicas:

kubectl apply -f <replica-set-conf>.yaml
13

Para comprobar el estado de su recurso MongoDB, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.

Después de encriptar el recurso de base de datos con TLS, puedes proteger lo siguiente:

Renueva tus certificados TLS periódicamente utilizando el siguiente procedimiento:

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Ejecute este kubectl comando para renovar un secreto existente que almacena los certificados del conjunto de réplicas:

kubectl create secret tls <prefix>-<metadata.name>-cert \
--cert=<replica-set-tls-cert> \
--key=<replica-set-tls-key> \
--dry-run=client \
-o yaml |
kubectl apply -f -
1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si está implementando un recurso de Ops Manager en una implementación de MongoDB de un clúster de Kubernetes múltiple:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Cambie la configuración de este archivo YAML para que coincida con la configuración del conjunto de réplicas deseada.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5 name: <my-replica-set>
6spec:
7 members: 3
8 version: "8.0.0"
9 opsManager:
10 configMapRef:
11 # Must match metadata.name in ConfigMap file
12 name: <configMap.metadata.name>
13 credentials: <mycredentials>
14 type: ReplicaSet
15 persistent: true
16...
3

Abre tu editor de texto preferido y pega la especificación del objeto en un nuevo archivo de texto.

4
Clave
Tipo
Descripción
Ejemplo

string

Etiqueta para este objeto de conjunto de réplicas de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, consulta metadata.name y la documentación de Kubernetes sobre nombres.

myproject

entero

Número de nodos del set de réplicas.

3

string

Versión de MongoDB que este set de réplicas debería ejecutar.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ent para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

8.0.0

spec
.opsManager
.configMapRef

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. La configuración spec.cloudManager.configMapRef.name es un alias de esta configuración y se puede usar en su lugar.

Este valor debe existir en el mismo espacio de nombres que el recurso que quieres crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio en el ConfigMap y reconcilia el estado del recurso MongoDB.

<myconfigmap>

string

Nombre del secreto que creaste como Ops Manager API credenciales de autenticación para que el Operador Kubernetes se comunique con Ops Manager.

El objeto secreto de Kubernetes de Ops Manager que contiene las credenciales debe existir en el mismo espacio de nombres que el recurso que desea crear.

IMPORTANTE: El operador de Kubernetes rastrea cualquier cambio realizado en el Secreto y reconcilia el estado del recurso MongoDB.

<mycredentials>

string

Tipo de recurso MongoDB que se va a crear.

ReplicaSet

string

Opcional.

Indicador que indica si este MongoDB recurso debe usar volúmenes persistentes para el almacenamiento. Los volúmenes persistentes no se eliminan al MongoDB detener o reiniciar el recurso.

Si este valor true es, entonces se establece en su valor spec.podSpec.persistence.single predeterminado 16Gi de.

Para cambiar la <a class=\" \" target=\" \"href=\" \" rel=\"noopener noreferrer\"> Solicitud de volumen persistente <svg class=\" \" height=\" \" width=\" \" role=\" \" aria-hidden=\" \" alt=\" \" viewbox=\" \"><path d=\" \" fill=\" \"> <path d=\" \" fill=\" \"> configuración, configura las siguientes colecciones para cumplir con tus requisitos de implementación:

ADVERTENCIA: Otorgue a sus contenedores permiso para escribir en su volumen persistente. El operador de Kubernetes fsGroup = 2000 establece, runAsUser = 2000 y runAsNonRoot = true en. El securityContext operador de Kubernetes establece fsgroup igual a runAsUser para que el volumen pueda ser escrito por un 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 información relacionada en la documentación de Kubernetes. Si volver a implementar el recurso no soluciona los problemas con su volumen persistente, póngase en contacto con el soporte técnico de MongoDB.

Si no usas Volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se pueden mostrar ni en la pestaña Processes en la página Deployment, ni en la página Metrics al revisar los datos de esta implementación.

true

5

También puede añadir cualquiera de los siguientes ajustes opcionales al archivo de especificaciones del objeto para el set de réplicas implementación:

Advertencia

Debe establecer spec.clusterDomain si su clúster Kubernetes tiene un dominio por defecto diferente al por defecto cluster.local. Si no utilizas la opción por defecto ni estableces la opción spec.clusterDomain, el Operador Kubernetes podría no funcionar como se espera.

6
7

En cualquier directorio, ejecuta el siguiente comando de Kubernetes para crear tu set de réplicas:

kubectl apply -f <replica-set-conf>.yaml
8

Para comprobar el estado de su recurso MongoDB, utilice el siguiente comando:

kubectl get mdb <resource-name> -o yaml -w

Con la bandera -w (observar) activada, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el estado Running. Para obtener más información sobre el estado de implementación de recursos, consulta Solucionar problemas con el operador de Kubernetes.

Volver

Instancia autónoma

En esta página