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 aumentar el número de subprocesos de su instancia de operador de Kubernetes.

Especificar los requisitos de recursos de CPU y memoria

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

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

• Lasolicitud 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, utilice las configuraciones de límites de recursos predeterminadas.

Considere las prácticas recomendadas para el almacenamiento

Las siguientes recomendaciones se aplican a las implementaciones de MongoDB y a las implementaciones de bases de datos de aplicaciones Ops Manager administradas por el operador de Kubernetes.

• Utilice la clase de almacenamiento que ofrezca el mejor rendimiento según sus limitaciones. Consulte "Escalar una implementación" para obtener más información.

• Aprovisione 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.

Usar contenedores estáticos (versión preliminar pública)

Los contenedores estáticos son más sencillos y seguros que los no estáticos. Son inmutables en tiempo de ejecución, lo que significa que no cambian con respecto a la imagen utilizada para crearlos. 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.

• Mientras se ejecutan, los contenedores estáticos no modifican ningún archivo excepto los montajes del volumen 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 alojes el binario de MongoDB en Ops Manager ni en otro ServidorHTTPS, que es especialmente útil si tienes un entorno con espacio de aire.

• No se pueden ejecutar scripts CMD extensos para el contenedor estático.

• No se pueden copiar archivos entre contenedores estáticos usando initContainer.

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

Ubica mongos pods junto con tus aplicaciones

Puedes ejecutar la mongos instancia ligera en el mismo nodo que tus aplicaciones usando MongoDB. El operador de Kubernetes admite las funciones estándar de afinidad y antiafinidad de nodos de Kubernetes. Con estas funciones, puedes forzar la instalación de mongos en el mismo nodo que tu aplicación.

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

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. Especifique la mongos etiqueta que usa en la spec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector colección YAML. La matchExpressions colección define el label que el operador de Kubernetes usa para identificar el pod que aloja mongos el.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.2.1-ent
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

Vea el ejemplo completo de múltiples zonas de disponibilidad y configuración de afinidad de nodos 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.

Nombre su servicio MongoDB con su propósito

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

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

Utilice etiquetas para diferenciar entre implementaciones

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

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

• Coloque Pods en algunos nodos específicos para aprovechar características como la compatibilidad con 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

Puede especificar qué recursos personalizados desea que el operador de Kubernetes supervise. Esto le permite instalar CustomResourceDefinition solo para los recursos que desea que el operador de Kubernetes 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	Instale CustomResourceDefinitions para los recursos de la base de datos y observe dichos recursos.
   mongodbusers	Instale CustomResourceDefinitions para los recursos de usuario de MongoDB y observe 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/enterprise-operator \
     --set operator.watchedResources="{mongodb,mongodbusers}" \
        --skip-crds

Asegúrese de que la configuración de persistencia sea adecuada

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 para cada punto de montaje de MongoDB.

• Establece la ruta predeterminada en cada contenedor de Kubernetes en /data.

Para satisfacer las necesidades de almacenamiento de su clúster MongoDB, realice los siguientes cambios en su configuración para cada conjunto de réplicas implementado 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 la asigne a cada volumen. Los volúmenes almacenan los datos y los registros.

  • Para configurar varios volúmenes, cada uno para datos, registros oplog y,spec.podSpec.persistence.multiple.data utilice.

  • 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 ver un ejemplo completo de configuración de volúmenes persistentes, consulte replica-set-persistent-volumes.yaml en el directorio de ejemplos de volúmenes persistentes. Este directorio también contiene ejemplos de configuraciones de volúmenes persistentes para clústeres fragmentados e implementaciones independientes.

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 a 500m

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

• spec.template.spec.containers.resources.requests.memory a 200Mi

• 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 está implementando 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-enterprise-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-enterprise-operator
12
     app.kubernetes.io/instance: mongodb-enterprise-operator
13
 template:
14
  metadata:
15
   labels:
16
     app.kubernetes.io/component: controller
17
     app.kubernetes.io/name: mongodb-enterprise-operator
18
     app.kubernetes.io/instance: mongodb-enterprise-operator
19
   spec:
20
     serviceAccountName: mongodb-enterprise-operator
21
     securityContext:
22
       runAsNonRoot: true
23
       runAsUser: 2000
24
     containers:
25
     - name: mongodb-enterprise-operator
26
       image: quay.io/mongodb/mongodb-enterprise-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-enterprise-operator"
34
       resources:
35
         limits:
36
           cpu: 1100m
37
           memory: 1Gi
38
         requests:
39
           cpu: 500m
40
           memory: 200Mi

Para obtener un ejemplo completo de los recursos y límites de utilización de CPU y memoria para el pod del operador de Kubernetes que satisfacen la implementación paralela de hasta 50 conjuntos de réplicas de MongoDB, consulte el archivo mongodb-enterprise.yaml.

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

Los valores de los pods que alojan conjuntos de réplicas o clústeres fragmentados se asignan al campo de solicitudes de CPU y memoria del pod creado. Estos valores son coherentes con las consideraciones establecidas para los hosts de MongoDB.

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

Para las implementaciones de producción, configure los recursos de CPU y memoria y los límites para el MongoDB Pod 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 de memoria y CPU recomendados para cada Pod que aloja un miembro del conjunto de réplicas de MongoDB en su implementación.

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.0.0-ent
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 utilización de CPU y memoria para pods que alojan miembros del conjunto de réplicas de MongoDB, consulte el archivo replica-set-podspec.yaml en el directorio MongoDB Podspec Samples.

Este directorio también contiene ejemplos de configuraciones de límites de memoria y CPU para los pods utilizados para:

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

• Implementaciones independientes de MongoDB, en standalone-podspec.yaml.

Utilice múltiples zonas de disponibilidad

Configure el operador de Kubernetes y statefulSets para distribuir todos los miembros de un conjunto de réplicas a diferentes nodos para garantizar una alta disponibilidad.

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

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.2.1-ent
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 con la etiqueta kubernetes.io/e2e-az-name en las zonas de disponibilidad e2e-az1 o e2e-az2. Cambie 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 subprocesos para ejecutar múltiples procesos de conciliación en paralelo

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

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 API de Kubernetes y del operador de Kubernetes y ajuste su respectiva asignación de recursos si es necesario.