Docs Menu
Docs Home
/ /
Implementar
Docs Home
/
Enterprise Kubernetes Operator
/
Implementar recursos de la base de datos
/
Implementar
Docs Home
/
Enterprise Kubernetes Operator
/
Implementar recursos de la base de datos
/
Implementar

Implementar un clúster particionado

Nota

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

Importante

  • Puede utilizar el operador de Kubernetes para implementar recursos de MongoDB con Cloud Manager y con Ops Manager versión 6.0.x o posterior.

  • Puede utilizar el operador Atlas para implementar recursos de MongoDB en Atlas.

Advertencia

El operador de Kubernetes no admite nodos árbitros.

Los clústeres fragmentados proporcionan escalamiento horizontal para grandes conjuntos de datos y permiten operaciones de alto rendimiento al distribuir el conjunto de datos en un grupo de servidores.

Para obtener más información sobre la fragmentación, consulte Introducción a la fragmentación en el manual de MongoDB.

Utilice este procedimiento para implementar un nuevo clúster fragmentado administrado por Ops Manager. Posteriormente, podrá usar Ops Manager para agregar fragmentos y realizar otras operaciones de mantenimiento en el clúster.

Considerations

No implemente agentes de monitoreo dentro y fuera de Kubernetes

Debido a la traducción de la red de Kubernetes, un agente de monitorización externo a Kubernetes no puede monitorizar instancias de MongoDB dentro de Kubernetes. Por este motivo, no se admiten implementaciones k8s y no k8s en el mismo proyecto. Utilice proyectos separados.

Elija si desea cifrar las conexiones

Cuando implementa su clúster fragmentado a través del operador de Kubernetes, debe elegir si desea cifrar las conexiones mediante Certificados TLS.

El siguiente procedimiento para TLS-Encrypted conexiones:

  • Establece conexiones cifradas con TLSentre fragmentos del clúster.

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

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento para Non-Encrypted Connections:

  • No cifra las conexiones entre fragmentos del clúster.

  • 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 con TLS.

Nota

No es posible proteger una instancia independiente de MongoDB en un clúster de Kubernetes.

Para configurar el cifrado TLS para un conjunto de réplicas, consulte Implementar un conjunto de réplicas.

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

Requisitos previos

Para implementar un clúster fragmentado usando un objeto, usted debe:

Nota

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

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

    • Cada fragmento de su clúster fragmentado. Asegúrese de agregar SANal certificado para cada pod de Kubernetes que aloje un miembro del fragmento.

      En sus certificados TLS, la SAN de cada pod de fragmento debe usar el siguiente formato:

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

    • Tus servidores de configuración. Asegúrate de agregar SANs para cada pod de Kubernetes que hospede tus servidores de configuración al certificado.

      En sus certificados TLS, la SAN para cada pod de servidor de configuración debe usar el siguiente formato:

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

    • Su mongosinstancias. Asegúrese de agregar SAN para cada pod de Kubernetes que aloje unmongosal certificado.

      En sus certificados TLS, la SAN de cada pod debe usar este mongos formato:

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

    • 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 y la unidad organizativa combinadas en cada certificado TLS difieren de la organización y la unidad organizativa en el certificado TLS de los miembros de su conjunto de réplicas.

  • Debe poseer el certificado CA y la clave que utilizó para firmar sus 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 clúster fragmentado usando un objeto, debe:

Nota

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

Implementar un clúster particionado

1

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los kubectl comandos en el espacio de nombres 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:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Crea el secreto para los certificados TLS de tus Shards.

Ejecute este kubectl comando para crear un nuevo secreto que almacene los certificados de los fragmentos del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
  --cert=<shard-0-tls-cert> \
  --key=<shard-0-tls-key>
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
  --cert=<shard-1-tls-cert> \
  --key=<shard-1-tls-key>

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

3

Crea el secreto para el certificado TLS de tus servidores de configuración.

Ejecute este comando kubectl para crear un nuevo secreto que almacene el certificado de los servidores de configuración del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
  --cert=<config-tls-cert> \
  --key=<config-tls-key>

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

4

Crea el secreto para el certificado TLS de tus servidores Mongos.

Ejecute este kubectl comando para crear un nuevo secreto que almacene el certificado mongos del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \
  --cert=<mongos-tls-cert> \
  --key=<mongos-tls-key>

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

5

Crea el secreto para el certificado TLS de tu agente.

Ejecute este kubectl comando 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.

6

Cree el ConfigMap para vincular su CA con su implementación.

Ejecute este kubectl comando para vincular su CA a su clúster fragmentado y especificar el archivo de certificado de CA que siempre debe nombrar ca-pem para el MongoDB recurso:

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

Copia el clúster recurso.

Cambie la configuración de este archivo YAML para que coincida con la configuración de clúster fragmentado deseada.

Cambie la configuración para que coincida con la configuración de clúster fragmentado deseada.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
7  shardCount: 2
8  mongodsPerShardCount: 3
9  mongosCount: 2
10  configServerCount: 3
11  version: "4.2.2-ent"
12  opsManager:
13    configMapRef:
14      name: <configMap.metadata.name>
15            # Must match metadata.name in ConfigMap file
16  credentials: <mycredentials>
17  type: ShardedCluster
18  persistent: true
19...
19  security:
20    tls:
21      ca: <custom-ca>
22    certsSecretPrefix: <prefix>
23...
8

Pegue el ejemplo copiado para crear un nuevo recurso de clúster fragmentado.

Abra su editor de texto preferido y pegue la especificación del objeto en un nuevo archivo de texto.

9

Configure los ajustes resaltados en el paso anterior de la siguiente manera.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

Etiqueta para este objeto de clúster fragmentado de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para obtener más información, consulte y la documentación de Kubernetes metadata.name sobre nombres.

myproject

spec.shardCount

entero

Número de fragmentos a implementar.

2

spec.mongodsPerShardCount

entero

Número de miembros por fragmento.

3

spec.mongosCount

entero

Número de enrutadores de fragmentos a implementar.

2

spec.configServerCount

entero

Número de miembros del conjunto de réplicas del servidor de configuración.

3

spec.version

string

Versión de MongoDB que debe ejecutar este clúster fragmentado.

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

IMPORTANTE: Asegúrese de elegir una versión compatible de MongoDB Server. Las versiones compatibles varían según la imagen base que utilice el recurso de base de datos MongoDB.

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

Para obtener mejores resultados, utilice la última versión disponible de MongoDB empresarial que sea compatible con su versión de Ops Manager.

spec.opsManager.configMapRef.name

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. El parámetro es un alias de este parámetro y puede utilizarse en su spec.cloudManager.configMapRef.name 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.

<myproject>

spec.credentials

string

Nombre del secreto que creó como credenciales de autenticación de API de Ops Manager para que el operador de 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>

spec.type

string

Tipo de recurso MongoDB a crear.

ShardedCluster

spec.persistent

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 es true, los siguientes valores se establecen en su valor predeterminado de 16Gi:

Para cambiar la configuración de sus reclamaciones de volumen persistente, configure las siguientes colecciones para cumplir con sus 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 utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se podrán mostrar ni en Processes la pestaña de la Deployment página ni en la Metrics página al revisar los datos de esta implementación.

true

10

Configure los ajustes de TLS para su recurso de clúster fragmentado utilizando una autoridad de certificación (CA) personalizada.

Para habilitar TLS en su implementación, configure las siguientes opciones en su objeto de Kubernetes:

Clave
Tipo
Necesidad
Descripción
Ejemplo
spec.security
.tls.ca

string

Requerido

Agregue el nombre de ConfigMap que almacena la CA personalizada que utilizó para firmar los certificados TLS de su implementación.

<custom-ca>

spec.security
.certsSecretPrefix

string

Requerido

Agregue el <prefix> del nombre secreto que contiene los certificados TLS de su 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

11

Agregue cualquier configuración adicional aceptada para una implementación de clúster fragmentado.

También puede agregar cualquiera de las siguientes configuraciones opcionales al archivo de especificación de objeto para una implementación de clúster fragmentado:

Advertencia

Debe configurar si su clúster spec.clusterDomain de Kubernetes tiene un dominio predeterminado distinto del cluster.local predeterminado. Si no usa el dominio predeterminado ni configura la spec.clusterDomain opción, es posible que el operador de Kubernetes no funcione correctamente.

For config server

Para enrutadores de fragmentos

Para miembros del fragmento

12

Guarde este archivo con una .yaml extensión de archivo.

13

Inicie su implementación de clúster particionado.

Invoque el siguiente comando de Kubernetes para crear su clúster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Revise el registro después de ejecutar este comando. Si la creación se realizó correctamente, debería ver un mensaje similar al siguiente:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
14

Realice un seguimiento del estado de la implementación de su clúster fragmentado.

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

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

Con el -w indicador (observación) activado, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el Running estado. Para obtener más información sobre los estados de implementación de recursos, consulte Solucionar problemas del operador de Kubernetes.

Después de cifrar su recurso de base de datos con TLS, puede proteger lo siguiente:

Renovar certificados TLS para un clúster fragmentado

Renueve sus certificados TLS periódicamente mediante el siguiente procedimiento:

1

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los kubectl comandos en el espacio de nombres 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:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Renueve el secreto de los certificados TLS de sus Shards.

Ejecute este kubectl comando para renovar un secreto existente que almacena los certificados de los fragmentos del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
  --cert=<shard-0-tls-cert> \
  --key=<shard-0-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
  --cert=<shard-1-tls-cert> \
  --key=<shard-1-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
3

Renueve el secreto de los certificados TLS de su servidor de configuración.

Ejecute este kubectl comando para renovar un secreto existente que almacena los certificados del servidor de configuración del clúster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
  --cert=<config-tls-cert> \
  --key=<config-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
4

Renueva el secreto para los certificados TLS del servidor mongos.

Ejecute este comando kubectl para renovar un secret existente que almacene los certificados de mongos del clúster sharded:

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

Configure para kubectl que el valor predeterminado sea su espacio de nombres.

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los kubectl comandos en el espacio de nombres 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:

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

  • Establezca --namespace en el mismo ámbito que utilizó para su implementación de MongoDB en un clúster de Kubernetes múltiple, como porkubectl config --namespace "mongodb" ejemplo:.

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

Copia el clúster recurso.

Cambie la configuración de este archivo YAML para que coincida con la configuración de clúster fragmentado deseada.

Este es un archivo YAML que puedes modificar para cumplir con la configuración deseada. Cambia los ajustes para que coincidan con la configuración de clústeres fragmentados que deseas.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
7  shardCount: 2
8  mongodsPerShardCount: 3
9  mongosCount: 2
10  configServerCount: 3
11  version: "4.2.2-ent"
12  opsManager:
13    configMapRef:
14      name: <configMap.metadata.name>
15            # Must match metadata.name in ConfigMap file
16  credentials: <mycredentials>
17  type: ShardedCluster
18  persistent: true
19...
3

Pegue el ejemplo copiado para crear un nuevo recurso de clúster fragmentado.

Abra su editor de texto preferido y pegue la especificación del objeto en un nuevo archivo de texto.

4

Configure los ajustes resaltados en el paso anterior de la siguiente manera.

Clave
Tipo
Descripción
Ejemplo

metadata.name

string

Etiqueta para este objeto de clúster fragmentado de Kubernetes.

Los nombres de recursos deben tener 44 caracteres o menos.

Para obtener más información, consulte y la documentación de Kubernetes metadata.name sobre nombres.

myproject

spec.shardCount

entero

Número de fragmentos a implementar.

2

spec.mongodsPerShardCount

entero

Número de miembros por fragmento.

3

spec.mongosCount

entero

Número de enrutadores de fragmentos a implementar.

2

spec.configServerCount

entero

Número de miembros del conjunto de réplicas del servidor de configuración.

3

spec.version

string

Versión de MongoDB que debe ejecutar este clúster fragmentado.

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

IMPORTANTE: Asegúrese de elegir una versión compatible de MongoDB Server. Las versiones compatibles varían según la imagen base que utilice el recurso de base de datos MongoDB.

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

Para obtener mejores resultados, utilice la última versión disponible de MongoDB empresarial que sea compatible con su versión de Ops Manager.

spec.opsManager.configMapRef.name

string

Nombre del ConfigMap con la configuración de conexión de Ops Manager. El parámetro es un alias de este parámetro y puede utilizarse en su spec.cloudManager.configMapRef.name 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.

<myproject>

spec.credentials

string

Nombre del secreto que creó como credenciales de autenticación de API de Ops Manager para que el operador de 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>

spec.type

string

Tipo de recurso MongoDB a crear.

ShardedCluster

spec.persistent

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 es true, los siguientes valores se establecen en su valor predeterminado de 16Gi:

Para cambiar la configuración de sus reclamaciones de volumen persistente, configure las siguientes colecciones para cumplir con sus 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 utiliza volúmenes persistentes, los gráficos Disk Usage y Disk IOPS no se podrán mostrar ni en Processes la pestaña de la Deployment página ni en la Metrics página al revisar los datos de esta implementación.

true

5

Agregue cualquier configuración adicional aceptada para una implementación de clúster fragmentado.

También puede agregar cualquiera de las siguientes configuraciones opcionales al archivo de especificación de objeto para una implementación de clúster fragmentado:

Advertencia

Debe configurar si su clúster spec.clusterDomain de Kubernetes tiene un dominio predeterminado distinto del cluster.local predeterminado. Si no usa el dominio predeterminado ni configura la spec.clusterDomain opción, es posible que el operador de Kubernetes no funcione correctamente.

For config server

Para enrutadores de fragmentos

Para miembros del fragmento

6

Guarde este archivo con una .yaml extensión de archivo.

7

Inicie su implementación de clúster particionado.

Invoque el siguiente comando de Kubernetes para crear su clúster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Revise el registro después de ejecutar este comando. Si la creación se realizó correctamente, debería ver un mensaje similar al siguiente:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
8

Realice un seguimiento del estado de la implementación de su clúster fragmentado.

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

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

Con el -w indicador (observación) activado, cuando la configuración cambia, la salida se actualiza inmediatamente hasta que la fase de estado alcanza el Running estado. Para obtener más información sobre los estados de implementación de recursos, consulte Solucionar problemas del operador de Kubernetes.

Volver

Set de réplicas

Next

Usar con Prometheus

En esta página