Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/
Implementar recursos do banco de dados
/
Distribuir

Implementar um cluster fragmentado

Nesta página

  • Considerações
  • Pré-requisitos
  • Implementar um cluster fragmentado

Observação

Em qualquer lugar nesta página que diz Gerente de Operações, você pode substituir o Gerenciador de Nuvem.

Importante

  • Você pode usar o Operador Kubernetes para implantar recursos do MongoDB com o Cloud Manager e o Ops Manager versão 6.0.x ou posterior.

  • Você pode utilizar o Operador do Atlas para distribuir recursos do MongoDB no Atlas.

Aviso

O Kubernetes Operator não oferece suporte a nós arbiter.

Clusters fragmentados oferecem dimensionamento horizontal para grandes conjuntos de dados e permitem operações de alta taxa de transferência, distribuindo o conjunto de dados em um grupo de servidores.

Para saber mais sobre fragmentação, consulte Introdução à fragmentação no manual do MongoDB.

Use esse procedimento para implantar um novo cluster fragmentado gerenciado pelo Ops Manager. Posteriormente, você pode usar o Ops Manager para adicionar fragmentos e realizar outras operações de manutenção no cluster.

Considerações

Não implante Agente de monitoramento dentro e fora do Kubernetes

Devido à tradução de rede do Kubernetes, um agente de monitoramento fora do Kubernetes não pode monitorar instâncias do MongoDB dentro do Kubernetes. Por esse motivo, sistemas k8se não k8s no mesmo projeto não são permitidos. Use projetos separados.

Escolha se deseja criptografar conexões

Ao implantar seu cluster fragmentado pelo Operador Kubernetes, você deve escolher se deseja criptografar conexões utilizando certificados TLS.

O procedimento a seguir para conexões TLS-Encrypted :

  • Estabelece conexões criptografadas por TLSentre shards de cluster.

  • Estabelece conexões criptografadas por TLSentre aplicativos clientes e implementações do MongoDB.

  • Exige certificados válidos para criptografia TLS.

O seguinte procedimento para Non-Encrypted Connections:

  • Não criptografa conexões entre shards de cluster.

  • Não criptografa conexões entre aplicativos cliente e MongoDB deployments.

  • Tem menos requisitos de configuração do que um sistema com conexões criptografadas TLS.

Observação

Você não pode proteger uma instância standalone do MongoDB em um cluster Kubernetes.

Para configurar a criptografia TLS para um conjunto de réplicas, consulte Implantar um conjunto de réplicas.

Selecione a guia apropriada com base no fato de você desejar criptografar as conexões do replica set com TLS.

Pré-requisitos

Para implantar um cluster fragmentado usando um objeto, você deve:

Observação

Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento secreta. As implantações em vários clusters do Kubernetes não oferecem suporte ao armazenamento de segredos em ferramentas de armazenamento de segredos, como o HashiCorp Vault.

  • Gere um certificado TLS para cada um dos seguintes componentes:

    • Cada shard em seu cluster fragmentado. Certifique-se de adicionar SANs para cada pod do Kubernetes que hospeda um membro de shard no certificado.

      Em seus certificados TLS , a SAN para cada pod de shard deve usar o seguinte formato:

      <pod-name>.<metadata.name>-sh.<namespace>.svc.cluster.local

    • Seus servidores de configuração. Certifique-se de adicionar SANs para cada pod do Kubernetes que hospeda seus servidores de configuração no certificado.

      Em seus certificados TLS , a SAN para cada pod do servidor de configuração deve usar o seguinte formato:

      <pod-name>.<metadata.name>-cs.<namespace>.svc.cluster.local

    • Suas instâncias mongos . Certifique-se de adicionar SANs para cada pod do Kubernetes que hospeda um mongos ao certificado.

      Em seus certificados TLS , a SAN para cada pod mongos deve usar este formato:

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local

    • O MongoDB Agent do seu projeto. Para o certificado do MongoDB Agent, certifique-se de atender aos seguintes requisitos:

      • O nome comum no certificado TLS não está vazio.

      • A Organização e a Unidade Organizacional combinadas em cada certificado TLS diferem da Organização e da Unidade Organizacional no certificado TLS para os membros do conjunto de réplicas.

  • Você deve possuir o certificado CA e a chave que usou para assinar seus certificados TLS .

Importante

O operador do Kubernetes usa kubernetes.io/tls segredos para armazenar certificados TLS e chaves privadas para recursos do MongoDB Ops Manager e MongoDB . A partir da versão 1 do operador Kubernetes .17.0, o Operador Kubernetes não suporta arquivos PEM concatenados armazenados como segredos Opaco.

Para implementar um cluster fragmentado usando um objeto, você deve:

Observação

Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento secreta. As implantações em vários clusters do Kubernetes não oferecem suporte ao armazenamento de segredos em ferramentas de armazenamento de segredos, como o HashiCorp Vault.

Implementar um cluster fragmentado

1

Configure kubectl como padrão para seu namespace.

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou.

Observação

Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:

  • Defina context como o nome do cluster central, como: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Defina --namespace para o mesmo escopo usado para sua implantação do MongoDB de vários clusters Kubernetes, como: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Crie o segredo para os certificados TLS dos seus Shards.

Execute este comando kubectl para criar um novo secreto que armazena os certificados de fragmento de cluster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
  --cert=<shard-0-tls-cert> \
  --key=<shard-0-tls-key>
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
  --cert=<shard-1-tls-cert> \
  --key=<shard-1-tls-key>

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

3

Crie o segredo para o certificado TLS dos seus servidores de configuração.

Execute este comando kubectl para criar um novo segredo que armazena o certificado dos servidores de configuração do cluster fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
  --cert=<config-tls-cert> \
  --key=<config-tls-key>

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

4

Crie o segredo para o certificado TLS dos seus servidores mongos.

Execute este comando kubectl para criar um novo segredo que armazena o cluster fragmentado mongos :

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \
  --cert=<mongos-tls-cert> \
  --key=<mongos-tls-key>

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

5

Crie o segredo para o certificado TLS do seu agente.

Execute este comando kubectl para criar um novo secret que armazena o certificado TLS do agente:

kubectl create secret tls <prefix>-<metadata.name>-agent-certs \
  --cert=<agent-tls-cert> \
  --key=<agent-tls-key>

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

6

Crie o ConfigMap para vincular sua CA com seu sistema.

Execute este comando kubectl para vincular seu CA ao seu cluster fragmentado e especifique o arquivo de certificado CA que você deve sempre nomear ca-pem para o recurso MongoDB :

kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>
7

Copie o recurso cluster fragmentado da amostra.

Altere as configurações desse arquivo YAML para corresponder à configuração de cluster fragmentado desejado.

Altere as configurações para corresponder à configuração de cluster fragmentado desejado.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
7  shardCount: 2
8  mongodsPerShardCount: 3
9  mongosCount: 2
10  configServerCount: 3
11  version: "4.2.2-ent"
12  opsManager:
13    configMapRef:
14      name: <configMap.metadata.name>
15            # Must match metadata.name in ConfigMap file
16  credentials: <mycredentials>
17  type: ShardedCluster
18  persistent: true
19...
19  security:
20    tls:
21      ca: <custom-ca>
22    certsSecretPrefix: <prefix>
23...
8

Cole o exemplo copiado para criar um novo cluster fragmentado .

Abra seu editor de texto preferido e cole a especificação do objeto em um novo arquivo de texto.

9

Defina as configurações destacadas na etapa anterior da seguinte maneira.

Chave
Tipo
Descrição
Exemplo

metadata.name

string

Etiqueta para este objeto de cluster fragmentado do Kubernetes .

Os nomes de recursos devem ter 44 caracteres ou menos.

Para saber mais, consulte e a documentação do Kubernetes metadata.name sobre nomes.

myproject

spec.shardCount

inteiro

Número de shards a implementar.

2

spec.mongodsPerShardCount

inteiro

Número de membros de shard por shard

3

spec.mongosCount

inteiro

Número de roteadores de shard a serem implementados.

2

spec.configServerCount

inteiro

Número de membros do conjunto de réplicas do servidor de configuração.

3

spec.version

string

Versão do MongoDB que esse cluster fragmentado deve executar.

O formato deve ser X.Y.Z para a edição Community e X.Y.Z-ent para a edição Enterprise.

IMPORTANTE: Certifique-se de escolher uma versão compatível do MongoDB Server. Versões compatíveis diferem dependendo da imagem base que o recurso do banco de banco de dados MongoDB utiliza.

Para saber mais sobre a versão MongoDB, consulte Versões do MongoDB no Manual MongoDB.

Para obter melhores resultados, use a versão mais recente disponível do MongoDB empresarial que seja compatível com sua versão do Ops Manager.

spec.opsManager.configMapRef.name

string

Nome do ConfigMap com a configuração de conexão MongoDB Ops Manager do . A configuração spec.cloudManager.configMapRef.name é um nome alternativo para essa configuração e pode ser usada como substituto.

Esse valor deve existir no mesmo namespace que o recurso que você deseja criar.

IMPORTANTE: o operador Kubernetes rastreia quaisquer alterações no ConfigMap e reconcilia o estado do recurso MongoDB.

<myproject>

spec.credentials

string

Nome do secret que você criou como credenciais de autenticação da API do Ops Manager para o Kubernetes Operator se comunicar com o Ops Manager.

No Ops Manager, o secret do Kubernetes que contém as credenciais precisa existir no mesmo namespace que o recurso que você deseja criar.

IMPORTANTE: o operador do Kubernetes rastreia quaisquer alterações no Secret e reconcilia o estado do recurso MongoDB .

<mycredentials>

spec.type

string

Tipo de recurso MongoDB a ser criado.

ShardedCluster

spec.persistent

string

Opcional.

Sinalizador que indica se esse MongoDB recurso deve usar Volumes persistentes para armazenamento. Os Volumes persistentes não são excluídos quando o recurso MongoDB é interrompido ou reiniciado.

Se este valor for true, os seguintes valores serão definidos para o valor padrão de 16Gi:

Para alterar a configuração de Declarações de volume persistente, configure as seguintes coleções para atender aos requisitos de sua implantação:

AVISO: conceda aos contêineres permissão para gravar no Volume Persistente. O Operador Kubernetes define fsGroup = 2000, runAsUser = 2000 e runAsNonRoot = true em securityContext. O Kubernetes Operator define fsgroup como runAsUser para tornar o volume gravável para um usuário que executa o processo principal no container. Para saber mais, consulte Configurar um contexto de segurança para um pod ou contêiner e a discussão relacionada na documentação do Kubernetes. Se a reimplementação do recurso não corrigir os problemas com o Volume Persistente, entre em contato com o Suporte do MongoDB.

Se você não usar Volumes persistentes, os Disk Usage e Disk IOPS Atlas Charts não poderão ser exibidos na Processes guia da Deployment página ou na Metrics página ao revisar os dados dessa implementação.

true

10

Configure as configurações de TLS para seu cluster fragmentado usando uma autoridade de certificação personalizada (CA).

Para habilitar o TLS em sua implantação, configure as seguintes configurações em seu objeto Kubernetes:

Chave
Tipo
necessidade
Descrição
Exemplo
spec.security
.tls.ca

string

Obrigatório

Adicione o nome do ConfigMap que armazena a CA personalizada que você usou para assinar os certificados TLS da sua implantação.

<custom-ca>

spec.security
.certsSecretPrefix

string

Obrigatório

Adicione o <prefix> do nome secreto que contém os certificados TLS da implantação do MongoDB.

Por exemplo, se você chamar sua implantação my-deployment de e definir o prefixo como mdb, deverá nomear o segredo TLS para as comunicações TLS do cliente mdb-my-deployment-cert. Além disso, você deve nomear o segredo TLS para autenticação interna do cluster (se ativado) como mdb-my-deployment-clusterfile.

devDb

11

Adicione quaisquer configurações aceitas adicionais para uma implementação de cluster fragmentado .

Você também pode adicionar qualquer uma das seguintes configurações opcionais ao arquivo de especificação do objeto para uma implantação de cluster compartilhado:

Aviso

Você deve definir se o seu spec.clusterDomain cluster Kubernetes tiver um domínio padrão diferente do cluster.local padrão. Se você não usar o padrão nem definir a opção spec.clusterDomain , o operador Kubernetes pode não funcionar conforme o esperado.

For config server

Para roteadores de shard

Para membros de shard

12

Salve este arquivo com uma extensão de arquivo .yaml.

13

Inicie sua implementação de cluster fragmentado .

Invoque o seguinte comando do Kubernetes para criar seu cluster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Verifique o log após executar este comando. Se a criação tiver sido bem-sucedida, você deverá ver uma mensagem semelhante à seguinte:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
14

Monitore o status de sua implantação de cluster fragmentado .

Para verificar o status do seu recurso MongoDB, utilize o seguinte comando:

kubectl get mdb <resource-name> -o yaml -w

Com o sinalizador -w (inspeção) definido, quando a configuração muda, o resultado é atualizado imediatamente até que a fase de status atinja o estado Running . Para saber mais sobre os status de distribuição de recursos, consulte Solucionar problemas do operador Kubernetes.

Depois de criptografar seu recurso de banco de dados com TLS, você pode proteger o seguinte:

Renovar certificados TLS para um cluster fragmentado

Renove periodicamente seus certificados TLS usando o seguinte procedimento:

1

Configure kubectl como padrão para seu namespace.

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou.

Observação

Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:

  • Defina context como o nome do cluster central, como: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Defina --namespace para o mesmo escopo usado para sua implantação do MongoDB de vários clusters Kubernetes, como: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Renove o segredo para os certificados TLS dos seus shards.

Execute este comando kubectl para renovar um segredo existente que armazena os certificados dos fragmentos de cluster fragmentados:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \
  --cert=<shard-0-tls-cert> \
  --key=<shard-0-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \
  --cert=<shard-1-tls-cert> \
  --key=<shard-1-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
3

Renove o segredo para os certificados TLS do seu servidor de configuração.

Execute este comando do kubectl para renovar um segredo existente que armazena os certificados do servidor de configuração do agrupamento fragmentado:

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
  --cert=<config-tls-cert> \
  --key=<config-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
4

Renove o segredo para os certificados TLS do seu servidor mongos.

Execute este kubectl comando para renovar um segredo existente que armazena os certificados do cluster fragmentado :mongos

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \
  --cert=<mongos-tls-cert> \
  --key=<mongos-tls-key> \
  --dry-run=client \
  -o yaml |
kubectl apply -f -
1

Configure kubectl como padrão para seu namespace.

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou.

Observação

Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:

  • Defina context como o nome do cluster central, como: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Defina --namespace para o mesmo escopo usado para sua implantação do MongoDB de vários clusters Kubernetes, como: kubectl config --namespace "mongodb".

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Copie o recurso cluster fragmentado da amostra.

Altere as configurações desse arquivo YAML para corresponder à configuração de cluster fragmentado desejado.

Este é um arquivo YAML que você pode modificar para atender à configuração desejada. Altere as configurações para corresponder à configuração de cluster fragmentado desejado.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
7  shardCount: 2
8  mongodsPerShardCount: 3
9  mongosCount: 2
10  configServerCount: 3
11  version: "4.2.2-ent"
12  opsManager:
13    configMapRef:
14      name: <configMap.metadata.name>
15            # Must match metadata.name in ConfigMap file
16  credentials: <mycredentials>
17  type: ShardedCluster
18  persistent: true
19...
3

Cole o exemplo copiado para criar um novo cluster fragmentado .

Abra seu editor de texto preferido e cole a especificação do objeto em um novo arquivo de texto.

4

Defina as configurações destacadas na etapa anterior da seguinte maneira.

Chave
Tipo
Descrição
Exemplo

metadata.name

string

Etiqueta para este objeto de cluster fragmentado do Kubernetes .

Os nomes de recursos devem ter 44 caracteres ou menos.

Para saber mais, consulte e a documentação do Kubernetes metadata.name sobre nomes.

myproject

spec.shardCount

inteiro

Número de shards a implementar.

2

spec.mongodsPerShardCount

inteiro

Número de membros de shard por shard

3

spec.mongosCount

inteiro

Número de roteadores de shard a serem implementados.

2

spec.configServerCount

inteiro

Número de membros do conjunto de réplicas do servidor de configuração.

3

spec.version

string

Versão do MongoDB que esse cluster fragmentado deve executar.

O formato deve ser X.Y.Z para a edição Community e X.Y.Z-ent para a edição Enterprise.

IMPORTANTE: Certifique-se de escolher uma versão compatível do MongoDB Server. Versões compatíveis diferem dependendo da imagem base que o recurso do banco de banco de dados MongoDB utiliza.

Para saber mais sobre a versão MongoDB, consulte Versões do MongoDB no Manual MongoDB.

Para obter melhores resultados, use a versão mais recente disponível do MongoDB empresarial que seja compatível com sua versão do Ops Manager.

spec.opsManager.configMapRef.name

string

Nome do ConfigMap com a configuração de conexão MongoDB Ops Manager do . A configuração spec.cloudManager.configMapRef.name é um nome alternativo para essa configuração e pode ser usada como substituto.

Esse valor deve existir no mesmo namespace que o recurso que você deseja criar.

IMPORTANTE: o operador Kubernetes rastreia quaisquer alterações no ConfigMap e reconcilia o estado do recurso MongoDB.

<myproject>

spec.credentials

string

Nome do secret que você criou como credenciais de autenticação da API do Ops Manager para o Kubernetes Operator se comunicar com o Ops Manager.

No Ops Manager, o secret do Kubernetes que contém as credenciais precisa existir no mesmo namespace que o recurso que você deseja criar.

IMPORTANTE: o operador do Kubernetes rastreia quaisquer alterações no Secret e reconcilia o estado do recurso MongoDB .

<mycredentials>

spec.type

string

Tipo de recurso MongoDB a ser criado.

ShardedCluster

spec.persistent

string

Opcional.

Sinalizador que indica se esse MongoDB recurso deve usar Volumes persistentes para armazenamento. Os Volumes persistentes não são excluídos quando o recurso MongoDB é interrompido ou reiniciado.

Se este valor for true, os seguintes valores serão definidos para o valor padrão de 16Gi:

Para alterar a configuração de Declarações de volume persistente, configure as seguintes coleções para atender aos requisitos de sua implantação:

AVISO: conceda aos contêineres permissão para gravar no Volume Persistente. O Operador Kubernetes define fsGroup = 2000, runAsUser = 2000 e runAsNonRoot = true em securityContext. O Kubernetes Operator define fsgroup como runAsUser para tornar o volume gravável para um usuário que executa o processo principal no container. Para saber mais, consulte Configurar um contexto de segurança para um pod ou contêiner e a discussão relacionada na documentação do Kubernetes. Se a reimplementação do recurso não corrigir os problemas com o Volume Persistente, entre em contato com o Suporte do MongoDB.

Se você não usar Volumes persistentes, os Disk Usage e Disk IOPS Atlas Charts não poderão ser exibidos na Processes guia da Deployment página ou na Metrics página ao revisar os dados dessa implementação.

true

5

Adicione quaisquer configurações aceitas adicionais para uma implementação de cluster fragmentado .

Você também pode adicionar qualquer uma das seguintes configurações opcionais ao arquivo de especificação do objeto para uma implantação de cluster compartilhado:

Aviso

Você deve definir se o seu spec.clusterDomain cluster Kubernetes tiver um domínio padrão diferente do cluster.local padrão. Se você não usar o padrão nem definir a opção spec.clusterDomain , o operador Kubernetes pode não funcionar conforme o esperado.

For config server

Para roteadores de shard

Para membros de shard

6

Salve este arquivo com uma extensão de arquivo .yaml.

7

Inicie sua implementação de cluster fragmentado .

Invoque o seguinte comando do Kubernetes para criar seu cluster fragmentado:

kubectl apply -f <sharded-cluster-conf>.yaml

Verifique o log após executar este comando. Se a criação tiver sido bem-sucedida, você deverá ver uma mensagem semelhante à seguinte:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
8

Monitore o status de sua implantação de cluster fragmentado .

Para verificar o status do seu recurso MongoDB, utilize o seguinte comando:

kubectl get mdb <resource-name> -o yaml -w

Com o sinalizador -w (inspeção) definido, quando a configuração muda, o resultado é atualizado imediatamente até que a fase de status atinja o estado Running . Para saber mais sobre os status de distribuição de recursos, consulte Solucionar problemas do operador Kubernetes.

Voltar

Conjunto de réplicas

Próximo

Usar com Prometeus