Considerations

Implementar la cantidad recomendada de conjuntos de réplicas de MongoDB

Le recomendamos que utilice una sola instancia del operador de Kubernetes para implementar hasta 20 conjuntos de réplicas en paralelo.

Puede aumentar este número a 50 y esperar un aumento razonable en el tiempo que el operador de Kubernetes tarda en descargar, instalar, implementar y conciliar sus recursos.

Para 50 sets de réplicas, el tiempo de despliegue varía y puede tomar hasta 40 minutos. Este tiempo depende del ancho de banda de red del clúster de Kubernetes y del tiempo que tarda cada MongoDB Agent en descargar los binarios de instalación de MongoDB desde Internet para cada nodo del clúster de MongoDB.

Para implementar más de 50 conjuntos de réplicas de MongoDB en paralelo, utilice varias instancias del 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.

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

Los contenedores estáticos son más seguros y sencillos que los no estáticos. Son inmutables en tiempo de ejecución. Además:

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

• Mientras se ejecutan, los contenedores estáticos no pueden modificar ningún archivo, excepto los montajes de volumen de almacenamiento.

• Los contenedores estáticos no requieren análisis de seguridad, a diferencia de los contenedores no estáticos, que sí lo requieren. Si se utilizan contenedores estáticos, solo se pueden ejecutar análisis de seguridad en las imágenes, pero no en los contenedores.

• Si tiene un entorno con espacio de aire, los contenedores estáticos no requieren que aloje el binario de MongoDB en el servidor que aloja Ops Manager u otro Servidor HTTPS.

• 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 (vista previa 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: "4.4.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.

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

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

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.