Considerações

Implemente o número recomendado de conjuntos de réplicas do MongoDB

Recomendamos que você use uma única instância do Operador Kubernetes para implantar até 20 conjuntos de réplicas em paralelo.

Você pode aumentar esse número para 50 e esperar um aumento razoável no tempo que o Kubernetes Operator leva para baixar, instalar, implantar e reconciliar seus recursos.

Para 50 conjuntos de réplicas, o tempo de implementação varia e pode levar até 40 minutos. Esse tempo depende da largura de banda da rede do cluster Kubernetes e do tempo que cada MongoDB Agent leva para baixar binários de instalação do MongoDB da Internet para cada membro do MongoDB cluster.

Para implantar mais de 50 conjuntos de réplicas do MongoDB em paralelo, use várias instâncias do Kubernetes Operator.

Especificar os requisitos de recursos de memória e CPU

Em Kubernetes, cada Pod inclui parâmetros que permitem especificar recursos de CPU e recursos de memória para cada container no Pod.

Para indicar os limites de recursos, o Kubernetes usa as solicitações e limites parâmetros, onde:

• a solicitação indica um limite inferior de um recurso.

• limite indica um limite superior de um recurso.

As seções a seguir ilustram como:

• defina CPU e memória para o Pod do Operador.

• definir CPU e memória para Pods MongoDB.

Para os Pods que hospedam MongoDB Ops Manager o , use as configurações padrão de limites de recursos.

Usar Contêineres Estáticos (Pré-visualização Pública)

Os containers estáticos são mais seguros e simples do que os containers não estáticos. Os containers estáticos são imutáveis no tempo de execução. Além disso:

• Durante a execução, os containers estáticos não podem baixar binários ou executar scripts ou outros utilitários por meio de conexões de rede. Os containers estáticos só podem baixar arquivos de configuração de tempo de execução.

• Durante a execução, os containers estáticos não podem modificar nenhum arquivo, exceto as montagens do volume de armazenamento.

• Os containers estáticos não exigem que você verifique se há vulnerabilidades de segurança nos containers, ao contrário dos containers não estáticos que exigem verificação de segurança de containers. Se você usar containers estáticos, só poderá executar verificações de segurança nas próprias imagens de container, mas não em seus containers.

• Se você tiver um ambiente com lacuna de ar, os contêineres estáticos não exigem que você hospede o binário do MongoDB no servidor que hospeda o MongoDB Ops Manager ou em outro servidorHTTPS .

• Você não pode executar scripts CMD extensivos para o container estático.

• Você não pode copiar arquivos entre containers estáticos usando initContainer.

Para saber mais, consulte Contêineres estáticos (visualização pública).

Colocalize mongos Pods com Seus Aplicativos

Você pode executar a instância mongos leve no mesmo nó como seus aplicativos usando o MongoDB. O operador do Kubernetes oferece suporte aos nós de afinidade e antiafinidade padrão do Kubernetes funcionalidades. Usando esses recursos, você pode forçar a instalação do mongos no mesmo nó do seu aplicativo.

O exemplo abreviado a seguir mostra a configuração de afinidade e várias zonas de disponibilidade.

A chave podAffinity determina se deve instalar um aplicativo no mesmo Pod, nó ou centro de dados que outro aplicativo.

Para especificar a afinidade do Pod:

1. Adicione um rótulo e um valor na collection spec.podSpec.podTemplate.metadata.labels YAML para marcar o sistema. spec.podSpec.podTemplate.metadataConsulte e a API principal do Kubernetes v1 Core API.

2. Especifique qual rótulo o mongos utiliza na collection spec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector YAML . A collection matchExpressions define o label que o Kubernetes Operator utiliza para identificar o Pod para hospedar o mongos.

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

Veja o exemplo completo de configuração de múltiplas zonas de disponibilidade e afinidade de nó em replica-set-affinity.yaml nas Amostras de afinidade diretório.

Este diretório também contém amostras de afinidade e configurações de múltiplas zona para clusters fragmentados e sistemas autônomo do MongoDB.

Nomeie seu serviço MongoDB com sua finalidade

Defina o parâmetro spec.service para um valor que identifica a finalidade deste sistema, conforme ilustrado no exemplo a seguir.

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"

Use rótulos para diferenciar entre sistemas

Use a afinidade do Pod Recurso do Kubernetes para:

• Separe diferentes recursos do MongoDB, como ambientes test, staging e production .

• Coloca Pods em alguns nós específicos para aproveitar recursos como o suporte a 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

Personalizar as CustomResourceDefinitions que o operador do Kubernetes observa

Você pode especificar quais recursos personalizados deseja que o Operador Kubernetes observe. Isso permite que você instale o CustomResourceDefinition apenas para os recursos que deseja que o Kubernetes Operator managed.

Você deve usar o helm para configurar o Operador Kubernetes para monitorar somente os recursos personalizados que você especificar. Siga as instruções de instalação helm relevantes, mas faça os seguintes ajustes:

1. Decida quais CustomResourceDefinitions você deseja instalar. Você pode instalar qualquer número dos seguintes itens:

   Valor	Descrição
   mongodb	Instale o CustomResourceDefinitions para recursos de reconhecimento de data center e observe estes recursos.
   mongodbusers	Instale os recursos de usuário CustomResourceDefinitions para MongoDB e observe esses recursos.
   opsmanagers	Instale os recursos CustomResourceDefinitions para Ops Manager e observe esses recursos.

2. Instale o Helm Chart e especifique quais CustomResourceDefinitions você deseja que o Kubernetes Operator observe.

   Separe cada recurso personalizado com uma vírgula:

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

Garanta a configuração de persistência adequada

As implementações do Kubernetes orquestradas pelo Operador do Kubernetes são com estado. O container Kubernetes usa Volumes persistentes para manter o estado do cluster entre as reinicializações.

Para satisfazer o requisito de estado, o Kubernetes executa a seguinte ação:

• Cria volumes persistentes para sua implementação do MongoDB .

• Monta dispositivos de armazenamento em um ou mais diretórios chamados pontos de montagem.

• Cria um volume persistente para cada ponto de montagem MongoDB.

• Define o caminho padrão em cada container Kubernetes para /data.

Para atender às necessidades de armazenamento do cluster MongoDB, faça as seguintes alterações em sua configuração para cada conjunto de réplicas implementado com o Kubernetes Operator:

• Verifique se os volumes persistentes estão habilitados no spec.persistent. O padrão desta configuração é true.

• Especifique uma quantidade suficiente de armazenamento para o Operador Kubernetes alocar para cada um dos volumes. Os volumes armazenam os dados e os logs.

  • Para definir vários volumes, cada um para dados, registros e oplog, use spec.podSpec.persistence.multiple.data.

  • Para definir um único volume para armazenar dados, logs e o oplog, use spec.podSpec.persistence.single.

O exemplo abreviado a seguir mostra os tamanhos de armazenamento persistentes recomendados.

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 obter um exemplo completo da configuração de volumes persistentes, consulte replica-set-persistent-volumes.yaml nas Amostras de Volumes Persistentes diretório. Este diretório também contém exemplos de configurações de volumes persistentes para clusters fragmentados e sistemas autônomo .

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

Usar múltiplas zonas de disponibilidade

Definir o operador Kubernetes e o StatefulSets distribuir todos os membros de um conjunto de réplicas para diferentes nós para garantir alta disponibilidade.

O exemplo abreviado a seguir mostra a configuração de afinidade e várias zonas de disponibilidade.

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

Neste exemplo, o Operador Kubernetes agenda a implantação dos Pods para os nós que têm o rótulo kubernetes.io/e2e-az-name em zonas de disponibilidade e2e-az1 ou e2e-az2 . Altere nodeAffinity para agendar a implantação de Pods para as zonas de disponibilidade desejadas.

Veja o exemplo completo da configuração de múltiplas zonas de disponibilidade em replica-set-affinity.yaml nas Amostras de afinidade diretório.

Este diretório também contém amostras de afinidade e configurações de múltiplas zona para clusters fragmentados e sistemas autônomo do MongoDB.