Considerations

Implementar múltiples conjuntos de réplicas de MongoDB

Le recomendamos que utilice una única instancia del operador de Kubernetes para implementar y administrar sus conjuntos de réplicas de MongoDB.

Para implementar más de 10 conjuntos de réplicas de MongoDB en paralelo, puede Aumente el número de subprocesos de su instancia de operador de Kubernetes.

Que definir los requisitos de recursos de CPU y memoria

En Kubernetes, cada Pod incluye parámetros que le permiten especificar recursos de CPU y recursos de memoria para cada contenedor en el Pod.

Para indicar los límites de recursos, Kubernetes utiliza los parámetros solicitudes y límites, donde:

• solicitud indica un límite inferior de un recurso.

• límite indica un límite superior de un recurso.

Las siguientes secciones ilustran cómo:

• Configurar CPU y memoria para el pod del operador.

• Establecer CPU y memoria para pods MongoDB.

Para los Pods que alojan Ops Manager, utiliza las configuraciones de límites de recursos por defecto.

Considerar prácticas recomendadas para el almacenamiento

Las siguientes recomendaciones son aplicables a las implementaciones de MongoDB y a las implementaciones de la base de datos de la Aplicación Ops Manager gestionadas por el Operador de Kubernetes.

• Utiliza la clase de almacenamiento que proporcione el mejor rendimiento dado tus limitaciones. Ver escalar una implementación para aprender más.

• Provisiona volúmenes persistentes que admitan ReadWriteOnce para su clase de almacenamiento.

• En el nivel de nodo de trabajo, aplique las mejores prácticas de MongoDB en Linux.

• Asegúrese de utilizar una clase de almacenamiento que admita la expansión de volumen para permitir el cambio de tamaño del volumen de la base de datos.

Utiliza contenedores estáticos (Vista previa pública)

Los contenedores estáticos son más simples y más seguros que los contenedores no estáticos. Los contenedores estáticos son inmutables en tiempo de ejecución, lo que significa que no cambian respecto a la imagen utilizada para crear el contenedor. Además:

• Durante su ejecución, los contenedores estáticos no descargan binarios ni ejecutan scripts ni otras utilidades a través de conexiones de red. Solo descargan archivos de configuración en tiempo de ejecución.

• Durante su ejecución, los contenedores estáticos no modifican ningún archivo excepto los puntos de montaje de volúmenes de almacenamiento.

• Puede ejecutar análisis de seguridad en las imágenes del contenedor para determinar qué se ejecuta realmente como un contenedor activo, y el contenedor que se ejecuta no ejecutará binarios distintos de los que se definieron en la imagen.

• Los contenedores estáticos no requieren que se aloje el binario de MongoDB ni en Ops Manager ni en otro HTTPS servidor, que es especialmente útil si tienes un entorno aireado.

• No puedes ejecutar scripts extensos de CMD para el contenedor estático.

• No puede copiar archivos entre contenedores estáticos utilizando initContainer.

Para obtener más información, consulte Contenedores estáticos (versión preliminar pública).

Coloca los Pods mongos junto con tus aplicaciones

Puedes ejecutar la instancia ligerade mongos en el mismo nodo que tus aplicaciones utilizan MongoDB. El operador de Kubernetes admite afinidad y anti afinidad estándar de nodos funcionalidades de Kubernetes. Utilizando estas funcionalidades, puedes forzar la instalación del mongos en el mismo nodo que tu aplicación.

El siguiente ejemplo abreviado muestra la configuración de afinidad y zonas de disponibilidad múltiples.

La clave podAffinity determina si se debe instalar una aplicación en el mismo Pod, nodo o centro de datos que otra aplicación.

Para especificar la afinidad de pod:

1. Agregue una etiqueta y un valor en la spec.podSpec.podTemplate.metadata.labels colección YAML para etiquetar la implementación. spec.podSpec.podTemplate.metadata Consulte y la API principal de Kubernetes PodSpec v.1

2. Especifica qué etiqueta utiliza mongos en la colección spec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector YAML. La colección matchExpressions define los label que el Operador de Kubernetes utiliza para identificar el Pod que alojará los mongos.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 8.0.0
8
  service: my-service
9
10
  ...
11
    podTemplate:
12
      spec:
13
        affinity:
14
          podAffinity:
15
            requiredDuringSchedulingIgnoredDuringExecution:
16
              - labelSelector:
17
                  matchExpressions:
18
                    - key: security
19
                      operator: In
20
                      values:
21
                        - S1
22
                topologyKey: failure-domain.beta.kubernetes.io/zone
23
          nodeAffinity:
24
            requiredDuringSchedulingIgnoredDuringExecution:
25
              nodeSelectorTerms:
26
                - matchExpressions:
27
                    - key: kubernetes.io/e2e-az-name
28
                      operator: In
29
                      values:
30
                        - e2e-az1
31
                        - e2e-az2
32
          podAntiAffinity:
33
            requiredDuringSchedulingIgnoredDuringExecution:
34
            - podAffinityTerm:
35
                topologyKey: nodeId

Consulta el ejemplo completo de múltiples zonas de disponibilidad y la configuración de afinidad de nodos en replica-set-affinity.yaml en el directorio Muestras de afinidad.

Este directorio también contiene ejemplos de configuraciones de afinidad y zonas múltiples para clústeres fragmentados e implementaciones independientes de MongoDB.

Asigne un nombre a su servicio MongoDB con su propósito

Establece el parámetro spec.service en un valor que identifique el propósito de esta implementación, como se ilustra en el siguiente ejemplo.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: "8.0.0"
8
  service: drilling-pumps-geosensors
9
  featureCompatibilityVersion: "8.0"

Utiliza etiquetas para diferenciar entre implementaciones

Utilice la función de afinidad de pod de Kubernetes para:

• Separe diferentes recursos de MongoDB, como los entornos test, staging y production.

• Coloque Pods en algunos nodos específicos para aprovechar funcionalidades como el soporte para SSD.

1
mongosPodSpec:
2
  podAffinity:
3
    requiredDuringSchedulingIgnoredDuringExecution:
4
      - labelSelector:
5
        matchExpressions:
6
        - key: security
7
          operator: In
8
          values:
9
          - S1
10
        topologyKey: failure-domain.beta.kubernetes.io/zone

Personalice las CustomResourceDefinitions que supervisa el operador de Kubernetes

Puedes especificar qué recursos personalizados deseas que el Operador de Kubernetes supervise. Esto te permite instalar la CustomResourceDefinition solo para los recursos que desees que el Kubernetes Operator administre.

Debe usar helm para configurar el operador de Kubernetes para que supervise únicamente los recursos personalizados que especifique. Siga las helm instrucciones de instalación de correspondientes, pero realice los siguientes ajustes:

1. Decide qué CustomResourceDefinitions quieres instalar. Puedes instalar cualquier cantidad de los siguientes:

   Valor	Descripción
   mongodb	Instala los CustomResourceDefinitions para recursos de base de datos y monitorea esos recursos.
   mongodbusers	Instala las definiciones de recursos personalizados para los recursos de usuario de MongoDB y observa esos recursos.
   opsmanagers	Instale CustomResourceDefinitions para los recursos de Ops Manager y supervise esos recursos.

2. Instale el gráfico de Helm y especifique qué CustomResourceDefinitions desea que el operador de Kubernetes observe.

   Separe cada recurso personalizado con una coma:

   helm install <deployment-name> mongodb/mongodb-kubernetes \
     --set operator.watchedResources="{mongodb,mongodbusers}" \
        --skip-crds

Asegurar la configuración adecuada de la persistencia

Las implementaciones de Kubernetes orquestadas por el operador de Kubernetes son con estado. El contenedor de Kubernetes utiliza Volúmenes persistentes para mantener el estado del clúster entre reinicios.

Para satisfacer el requisito de estado, el operador de Kubernetes realiza las siguientes acciones:

• Crea volúmenes persistentes para su implementación de MongoDB.

• Monta dispositivos de almacenamiento en uno o más directorios llamados puntos de montaje.

• Crea un volumen persistente por cada punto de montaje de MongoDB.

• Establece la ruta por defecto en cada contenedor de Kubernetes a /data.

Para satisfacer las necesidades de almacenamiento de tu clúster de MongoDB, realiza los siguientes cambios en la configuración de cada set de réplicas desplegado con el operador de Kubernetes:

• Verifique que los volúmenes persistentes estén habilitados en. Esta configuración spec.persistent predeterminada true es.

• Especifique una cantidad suficiente de almacenamiento para que el Operador de Kubernetes asigne a cada uno de los volúmenes. Los volúmenes almacenan los datos y los registros.

  • Para configurar múltiples volúmenes, uno para datos, otro para registros y otro para el oplog, utiliza spec.podSpec.persistence.multiple.data.

  • Para configurar un solo volumen para almacenar datos, registros y,oplog spec.podSpec.persistence.singleutilice.

El siguiente ejemplo abreviado muestra los tamaños recomendados de almacenamiento persistente.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-cluster
5
spec:
6
7
  ...
8
  persistent: true
9
10
11
  shardPodSpec:
12
  ...
13
    persistence:
14
      multiple:
15
        data:
16
          storage: "20Gi"
17
        logs:
18
          storage: "4Gi"
19
          storageClass: standard

Para obtener un ejemplo completo de la configuración de volúmenes persistentes, consulta set de réplicas-persistent-volumes.yaml en el directorio Muestras de volúmenes persistentes. Este directorio también contiene configuraciones de volúmenes persistentes de muestra para clústeres fragmentados e implementaciones autónomas.

Establecer límites de utilización de CPU y memoria para el pod del operador de Kubernetes

Al implementar conjuntos de réplicas de MongoDB con el operador de Kubernetes, el proceso de conciliación inicial aumenta el uso de CPU del pod que ejecuta dicho operador. Sin embargo, una vez finalizado el proceso de implementación del conjunto de réplicas, el uso de CPU del operador de Kubernetes se reduce considerablemente.

Para implementaciones de producción, para satisfacer la implementación de hasta 50 conjuntos de réplicas de MongoDB o clústeres fragmentados en paralelo con el operador de Kubernetes, configure los recursos de CPU y memoria y los límites para el pod del operador de Kubernetes de la siguiente manera:

• spec.template.spec.containers.resources.requests.cpu hasta 500m

• spec.template.spec.containers.resources.limits.cpu hasta 1100 m

• spec.template.spec.containers.resources.requests.memory hasta 200 millas

• spec.template.spec.containers.resources.limits.memory a 1Gi

Si usa Helm para implementar recursos, defina estos valores en el archivo values.yaml.

El siguiente ejemplo abreviado muestra la configuración con los límites de CPU y memoria recomendados para el pod de operador de Kubernetes en su implementación de 50 conjuntos de réplicas o clústeres fragmentados. Si va a implementar menos de 50 clústeres de MongoDB, puede usar números menores en el archivo de configuración del pod de operador de Kubernetes.

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
 name: mongodb-kubernetes-operator
5
 namespace: mongodb
6
spec:
7
 replicas: 1
8
 selector:
9
  matchLabels:
10
     app.kubernetes.io/component: controller
11
     app.kubernetes.io/name: mongodb-kubernetes-operator
12
     app.kubernetes.io/instance: mongodb-kubernetes-operator
13
 template:
14
  metadata:
15
   labels:
16
     app.kubernetes.io/component: controller
17
     app.kubernetes.io/name: mongodb-kubernetes-operator
18
     app.kubernetes.io/instance: mongodb-kubernetes-operator
19
   spec:
20
     serviceAccountName: mongodb-kubernetes-operator
21
     securityContext:
22
       runAsNonRoot: true
23
       runAsUser: 2000
24
     containers:
25
     - name: mongodb-kubernetes-operator
26
       image: quay.io/mongodb/mongodb-kubernetes-operator:1.9.2
27
       imagePullPolicy: Always
28
       args:
29
        - "-watch-resource=mongodb"
30
        - "-watch-resource=opsmanagers"
31
        - "-watch-resource=mongodbusers"
32
       command:
33
        - "/usr/local/bin/mongodb-kubernetes-operator"
34
       resources:
35
         limits:
36
           cpu: 1100m
37
           memory: 1Gi
38
         requests:
39
           cpu: 500m
40
           memory: 200Mi

Para un ejemplo completo de los recursos y límites de utilización de CPU y memoria para el Kubernetes Operator Pod que satisfaga la implementación en paralelo de hasta 50 sets de réplicas de MongoDB, consulta el archivo mongodb-kubernetes.yaml.

Establecer límites de utilización de CPU y memoria para Pods de MongoDB

Los valores para los Pods que alojan sets de réplicas o clústeres se asignan al campo de solicitudes para CPU y memoria para el Pod creado. Estos valores son consistentes con las consideraciones establecidas para los hosts de MongoDB.

El Operador de Kubernetes utiliza su memoria asignada para procesamiento, para la caché de WiredTiger y para almacenar paquetes durante las implementaciones.

Para implementaciones de producción, configura los recursos y límites de CPU y memoria para el Pod de MongoDB de la siguiente manera:

• spec.podSpec.podTemplate.spec.containers.resources.requests.cpu a 0,25

• spec.podSpec.podTemplate.spec.containers.resources.limits.cpu a 0,25

• spec.podSpec.podTemplate.spec.containers.resources.requests.memory a 512M

• spec.podSpec.podTemplate.spec.containers.resources.limits.memory a 512M

Si usa Helm para implementar recursos, defina estos valores en el archivo values.yaml.

El siguiente ejemplo abreviado muestra la configuración con los límites recomendados de CPU y memoria para cada Pod que aloja un miembro del set de réplicas de MongoDB en tu implementación.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
name: my-replica-set
5
spec:
6
  members: 3
7
  version: 8.0.0
8
  service: my-service
9
  ...
10
11
  persistent: true
12
  podSpec:
13
    podTemplate:
14
      spec:
15
        containers:
16
        - name: mongodb-enterprise-database
17
          resources:
18
            limits:
19
              cpu: "0.25"
20
              memory: 512M

Para obtener un ejemplo completo de los recursos y límites de uso de CPU y memoria para Pods que alojan miembros del set de réplicas de MongoDB, véase el archivo replica-set-podspec.yaml en el directorio Muestras de Podspec de MongoDB.

Este directorio también contiene muestras de configuraciones de límites de CPU y memoria para Pods utilizados en:

• Un clúster particionado, en el sharded-cluster-podspec.yaml.

• Implementaciones autónomos de MongoDB, en el standalone-podspec.yaml.

Utiliza zonas de disponibilidad múltiple

Configura el Kubernetes Operator y los statefulSets para distribuir todos los miembros de un set de réplicas a diferentes nodos para garantizar alta disponibilidad.

El siguiente ejemplo abreviado muestra la configuración de afinidad y zonas de disponibilidad múltiples.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 8.0.0
8
  service: my-service
9
  ...
10
    podAntiAffinityTopologyKey: nodeId
11
    podAffinity:
12
      requiredDuringSchedulingIgnoredDuringExecution:
13
      - labelSelector:
14
        matchExpressions:
15
        - key: security
16
          operator: In
17
          values:
18
          - S1
19
        topologyKey: failure-domain.beta.kubernetes.io/zone
20
21
    nodeAffinity:
22
       requiredDuringSchedulingIgnoredDuringExecution:
23
         nodeSelectorTerms:
24
         - matchExpressions:
25
           - key: kubernetes.io/e2e-az-name
26
           operator: In
27
           values:
28
           - e2e-az1
29
           - e2e-az2

En este ejemplo, el Operador de Kubernetes programa la implementación de Pods en los nodos que tienen la etiqueta kubernetes.io/e2e-az-name en e2e-az1 o e2e-az2 zonas de disponibilidad. Cambia nodeAffinity para programar la implementación de Pods en las zonas de disponibilidad deseadas.

Consulte el ejemplo completo de configuración de múltiples zonas de disponibilidad en replica-set-affinity.yaml en el directorio Affinity Samples.

Este directorio también contiene ejemplos de configuraciones de afinidad y zonas múltiples para clústeres fragmentados e implementaciones independientes de MongoDB.

Aumente el número de hilos para ejecutar múltiples procesos de reconciliación en paralelo

Si planea implementar más de 10 sets de réplicas de MongoDB en paralelo, puede configurar el operador de Kubernetes para ejecutar múltiples procesos de conciliación en paralelo estableciendo la variable de entorno MDB_MAX_CONCURRENT_RECONCILES en su implementación del operador de Kubernetes o mediante el parámetro operator.maxConcurrentReconciles. campo en tu archivo Helm values.yaml para configurar un mayor número de hilos.

Aumentar el conteo de hilos del operador de Kubernetes permite escalar verticalmente tu implementación del operador de Kubernetes a cientos de recursos MongoDB que se ejecutan en tu clúster de Kubernetes y optimizar el uso de la CPU.

Supervise el uso de recursos del servidor de API de Kubernetes y de los recursos del Operador de Kubernetes y ajuste su respectiva asignación de recursos si es necesario.