Considerations

Implementar múltiples conjuntos de réplicas de MongoDB

Recomendamos que uses una única instancia del Operador de Kubernetes para implementar y gestionar tus sets de réplicas de MongoDB.

Para implementar más de 10 sets de réplicas de MongoDB en paralelo, puedes aumenta el recuento de hilos de tu instancia del 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:

• configura la CPU y la memoria para el pod del operador.

• establezca CPU y memoria para los pods de 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.

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

• Asegúrese de usar una clase de almacenamiento que admita expansión de volumen para habilitar el cambio de tamaño de 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:

• Mientas se ejecutan, los contenedores estáticos no descargan binarios ni ejecutan scripts u otros utilitarios a través de conexiones de red. Los contenedores estáticos solo descargan archivos de configuración 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.

• Puedes aplicar evaluaciones de seguridad a las imágenes de contenedores para determinar lo que realmente se ejecuta como un contenedor activo, y el contenedor que se ejecuta no ejecutará binarios diferentes a los definidos 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. Agrega una etiqueta y un valor en la colección spec.podSpec.podTemplate.metadata.labels YAML para etiquetar la implementación. Consulta spec.podSpec.podTemplate.metadata, y el Kubernetes PodSpec v1 Core API.

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 muestras de configuraciones de afinidad y múltiples zonas para clústeres y implementaciones autónomas 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 funcionalidad 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

Personaliza las CustomResourceDefinitions que el Operador de Kubernetes supervisa

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 utilizar helm para configurar el Kubernetes operador que solo observe los recursos personalizados que usted especifique. Sigue las helm instrucciones de instalación pertinentes, pero realiza 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	Instala los CustomResourceDefinitions para los recursos de Ops Manager y observa esos recursos.

2. Instale la Helm gráfica y especifique qué CustomResourceDefinitions quiere que el Kubernetes Operator vigile.

   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 tu 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:

• Verifica que los volúmenes persistentes estén habilitados en spec.persistent. Esta configuración tiene un valor por defecto de true.

• 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 establecer un solo volumen para almacenar datos, registros y el oplog, utiliza spec.podSpec.persistence.single.

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

Cuando implementas sets de réplicas de MongoDB con el Operador de Kubernetes, el proceso inicial de reconciliación aumenta el uso de CPU para el Pod que ejecuta el Operador de Kubernetes. Sin embargo, cuando se completa el proceso de implementación del set de réplicas, el uso de CPU por parte del Operador de Kubernetes se reduce considerablemente.

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

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

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

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

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

Si utilizas Helm para implementar recursos, define 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 el pod del operador de Kubernetes en su implementación de 50 sets de réplicas o clústeres. Si despliega menos de 50 clústeres de MongoDB, puede usar números más bajos en el archivo de configuración para el Kubernetes operador Pod.

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 utilizas Helm para implementar recursos, define 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.

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

Este directorio también contiene muestras de configuraciones de afinidad y múltiples zonas para clústeres y implementaciones autónomas 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.