Considerações

Distribuir vários conjuntos de réplicas do MongoDB

Recomendamos que você use uma única instância do Operador Kubernetes para implantar e gerenciar seus conjuntos de réplicas do MongoDB.

Para implantar mais de 10 conjuntos de réplicas do MongoDB em paralelo, você pode aumentar a contagem de threads de sua instância do Kubernetes Operator.

Especificar os requisitos de recursos de memória e CPU

No Kubernetes, cada Pod inclui parâmetros que permitem especificar os recursos da CPU e recursos de memória para cada contêiner 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 o Ops Manager que hospeda os Pods, use as configurações padrão de limites de recursos.

Considere as práticas recomendadas para armazenamento

As recomendações a seguir são aplicáveis a sistemas do MongoDB e sistemas de banco de dados do aplicativo Ops Manager gerenciadas pelo Kubernetes Operator.

• Use a classe de armazenamento que oferece o melhor desempenho de acordo com suas restrições. Consulte dimensionar uma implantação para saber mais.

• Provisionar volumes persistentes que suportam ReadWriteOnce para sua classe de armazenamento.

• Em um nível de nó de trabalho, aplique as melhores práticas do MongoDB no Linux.

• Certifique-se de usar uma classe de armazenamento que ofereça suporte à expansão de volume para habilitar o redimensionamento do volume do banco de dados.

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

Os containers estáticos são mais simples e seguros do que os containers não estáticos. Os containers estáticos são imutáveis no tempo de execução, o que significa que eles não mudam da imagem usada para criar o container. Além disso:

• Durante a execução, os containers estáticos não baixam binários nem executam scripts ou outros utilitários por meio de conexões de rede. Os containers estáticos baixam apenas arquivos de configuração de tempo de execução.

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

• Você pode executar verificações de segurança nas imagens do contêiner para determinar o que está realmente sendo executado como um contêiner ativo, e o contêiner que é executado não executará binários diferentes do que foi definido na imagem.

• Os containers estáticos não exigem que você hospede o binário do MongoDB no Ops Manager ou em outro servidorHTTPS , o que é especialmente útil se você tiver um ambiente com lacunas de ar.

• 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 Containers 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 spec.podSpec.podTemplate.metadata.labels collection YAML para marcar o sistema. spec.podSpec.podTemplate.metadata Consulte e a API principal do Kubernetes PodSpec v .1

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: "6.0.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 standalone.

Definir limites de utilização de memória e CPU para o Pod do Operador Kubernetes

Quando você distribui conjuntos de réplicas do MongoDB com o Kubernetes Operator, o processo de reconciliação inicial aumenta o uso da CPU do Pod que executa o Kubernetes Operator. No entanto, quando o processo de implementação do conjunto de réplicas é concluído, o uso da CPU pelo operador Kubernetes é reduzido significativamente.

Para sistemas de produção, para satisfazer a implantação de até 50 conjuntos de réplicas do MongoDB ou clusters fragmentados em paralelo com o Kubernetes Operator, defina os recursos e os limites de CPU e memória para o Kubernetes Operator Pod da seguinte forma:

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

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

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

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

Se você usar o Helm para implantar recursos, defina esses valores no arquivo valores.yaml.

O exemplo abreviado a seguir mostra a configuração com limites de memória e CPU recomendados para o Pod do Kubernetes Operator em seu sistema de 50 conjuntos de réplicas ou clusters fragmentados. Se você estiver implantando menos de 50 clusters MongoDB, poderá usar números menores no arquivo de configuração do Pod do Kubernetes Operator.

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 obter um exemplo completo dos recursos e limites de utilização da CPU e da memória para o Pod do Kubernetes Operator que satisfazem a implantação paralela de até conjuntos de 50 réplicas do MongoDB, consulte mongodb-enterprise.yaml arquivo.

Definir limites de utilização de memória e CPU para Pods MongoDB

Os valores para Pods que hospedam conjuntos de réplicas ou clusters fragmentados mapeiam para o campo de solicitações para CPU e memória do Pod criado. Esses valores são consistentes com as considerações feitas para hosts MongoDB.

O Operador Kubernetes utiliza sua memória alocada para processamento, para o cache do WiredTiger e para armazenar pacotes durante os sistemas.

Para sistemas de produção, defina os recursos e limites de CPU e memória para o MongoDB Pod da seguinte maneira:

• spec.podSpec.podTemplate.spec.containers.resources.requests.cpu para 0.25

• spec.podSpec.podTemplate.spec.containers.resources.limits.cpu para 0.25

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

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

Se você usar o Helm para implantar recursos, defina esses valores no arquivo valores.yaml.

O exemplo abreviado a seguir mostra a configuração com limites de CPU e memória recomendados para cada Pod que hospeda um membro do conjunto de réplicas MongoDB em seu sistema.

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 obter um exemplo completo dos recursos e limites de utilização da CPU e da memória para Pods que hospedam membros do conjunto de réplicas do MongoDB,consulte replica-set-podspec.yaml nas amostras de amostras do Podspec do MongoDB diretório.

Este diretório também contém exemplos de configurações de limites de CPU e memória para Pods usados para:

• Um cluster fragmentado, no sharded-cluster-podspec.yaml.

• Sistemas standalone do MongoDB, no standalone-podspec.yaml.

Usar múltiplas zonas de disponibilidade

Defina 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.

Aumente a contagem de threads para executar vários processos de reconciliação em paralelo

Se você planeja implantar mais de 10 conjuntos de réplicas do MongoDB em paralelo, poderá configurar o Kubernetes Operator para executar vários processos de reconciliação em paralelo definindo a variável de ambiente MDB_MAX_CONCURRENT_RECONCILES em seu sistema do Kubernetes Operator ou ou por meio do campo operator.maxConcurrentReconciles em seu Helm values.yaml para configurar uma contagem de threads maior.

Aumentar a contagem de threads do Operador Kubernetes permite a você dimensionar verticalmente sua implantação do Operador Kubernetes para centenas de recursos do MongoDB executando dentro seu agrupamento Kubernetes e otimizar a utilização da CPU.

Monitore o servidor da API do Kubernetes e o uso de recursos do Operador do Kubernetes e ajuste sua respectiva alocação de recursos, se necessário.