Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/ /

Considerações

Nesta página

  • Distribuir vários conjuntos de réplicas do MongoDB
  • Especificar os requisitos de recursos de memória e CPU
  • Considere as práticas recomendadas para armazenamento
  • Usar Contêineres Estáticos (Pré-visualização Pública)
  • Colete mongos Pods com seus aplicativos
  • Nomeie seu serviço MongoDB com sua finalidade
  • Use rótulos para diferenciar entre sistemas
  • Personalizar as CustomResourceDefinitions que o operador do Kubernetes observa
  • Garanta a configuração de persistência adequada
  • Definir limites de utilização de memória e CPU para o Pod do Operador Kubernetes
  • Definir limites de utilização de memória e CPU para Pods MongoDB
  • Usar múltiplas zonas de disponibilidade
  • Aumente a contagem de threads para executar vários processos de reconciliação em paralelo

Esta página detalha as melhores práticas e recomendações de configuração do sistema para o MongoDB Enterprise Kubernetes Operator ao executar em produção.

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.

Observação

As seguintes considerações se aplicam:

  • Todas as recomendações de dimensionamento e desempenho para sistemas comuns do MongoDB por meio do Kubernetes Operator nesta seção estão sujeitas a alterações. Não trate estas recomendações como garantias ou limitações de qualquer tipo.

  • Essas recomendações refletem as descobertas dos testes de desempenho e representam nossas sugestões para sistemas de produção. Executamos os testes em um cluster composto por sete instâncias do Amazon Web Services EC2 do tipo t2.2xlarge e um nó mestre do tipo t2.medium.

  • As recomendações nesta seção não discutem as características de nenhuma implantação específica. As características da sua implementação podem ser diferentes das suposições feitas para criar essas recomendações. Entre em contato com o suporte do MongoDB para obter mais ajuda com os dimensionamentos.

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:

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

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

Observação

  • A redundância na classe de armazenamento não é necessária porque o MongoDB replica automaticamente os dados entre os membros de um conjunto de réplicas ou shard.

  • Você não pode compartilhar armazenamento entre membros de um conjunto de réplicas ou shard.

  • 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 de dados.

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

Observação

Quando implantado como containers estáticos, um sistema do Kubernetes Operator consiste em dois containers - um container mongodb-agent e um container mongodb-enterprise-server. O recurso personalizado do banco de dados de dados MongoDB herda as definições de limite de recursos do contêiner mongodb-agent, que executa o processo mongod em um sistema de contêiner estático. Para modificar os limites de recursos do banco de banco de dados MongoDB , você deve especificar os limites de recursos desejados no mongodb-agent contêiner.

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

Você pode executar a instância mongos leve no mesmo 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.

Exemplo

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

Dica

Veja também:

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

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

Dica

Veja também:

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 .

1mongosPodSpec:
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

Dica

Veja também:

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

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.

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

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: my-replica-cluster
5spec:
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 .

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.

Observação

A gravidade dos picos de uso da CPU no Operador Kubernetes é diretamente afetada pela contagem de threads do Operador Kubernetes, pois a contagem de threads (definida pelo valor MDB_MAX_CONCURRENT_RECONCILES ) é igual ao número de processos de reconciliação que podem ser executados em paralelo a qualquer momento tempo.

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.

Exemplo

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4 name: mongodb-enterprise-operator
5 namespace: mongodb
6spec:
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.

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.

Exemplo

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

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.

Exemplo

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

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 operador.maxConcurrentReconciles em seu arquivo 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.

Observação

  • Tenha cuidado ao aumentar o MDB_MAX_CONCURRENT_RECONCILES além 10. Em particular, você deve monitorar o Operador Kubernetes e a API Kubernetes de perto para evitar o tempo de inatividade resultante do aumento da carga nesses componentes.

    Para determinar a contagem de threads que atende às necessidades do seu sistema, use as seguintes diretrizes:

    • Seus requisitos de capacidade de resposta do operador Kubernetes ao reconciliar muitos recursos

    • Os recursos de computação disponíveis em seu ambiente Kubernetes e a carga total de processamento à qual seus recursos de computação Kubernetes estão sujeitos, incluindo recursos que podem não estar relacionados ao MongoDB

  • Uma alternativa para aumentar a contagem de threads de uma única instância do Kubernetes Operator e, ao mesmo tempo, aumentar o número de recursos MongoDB que você pode suportar no cluster do Kubernetes, é implantar várias instâncias do Kubernetes Operator no cluster do Kubernetes. No entanto, a implantação de várias instâncias do Operador Kubernetes requer que você garanta que nenhuma instância do Operador Kubernetes esteja monitorando os mesmos recursos MongoDB .

    A execução de mais de uma instância do Operador Kubernetes deve ser feita com cuidado, pois mais instâncias do Operador Kubernetes (especialmente com a reconciliação paralela ativada) colocam o servidor API em maior risco de ser sobrecarregado.

  • O dimensionamento do servidor de API do Kubernetes não é um motivo válido para executar mais de uma instância do Operador do Kubernetes. Se você observar que o desempenho do servidor de API foi afetado, adicionar mais instâncias do Operador Kubernetes provavelmente aumentará o problema.

Voltar

Definir o escopo do sistema