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

Distribuir um conjunto de réplicas

Nesta página

  • Considerações
  • Pré-requisitos
  • Distribuir um conjunto de réplicas

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.

Um conjunto de réplica é um grupo de implantações do MongoDB que mantém o mesmo conjunto de dados. Os conjuntos de réplicas oferecem redundância e alta disponibilidade e são a base para todas as implantações de produção.

Para saber mais sobre conjuntos de réplicas, consulte a Introdução à replicação no manual do MongoDB.

Use este procedimento para implantar um novo conjunto de réplicas que o Ops Manager gerencia. Após a implantação, use o Ops Manager para gerenciar o conjunto de réplicas, incluindo operações como adicionar, remover e reconfigurar membros.

Considerações

Ao definir seu conjunto de réplicas por meio do Operador de Kubernetes, você deve escolher se deseja criptografar as conexões usando certificados TLS.

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

  • Estabelece conexões criptografadas TLSentre hosts MongoDB no conjunto de réplicas.

  • 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 hosts MongoDB no conjunto de réplicas.

  • 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 cluster fragmentado, consulte Distribuir um cluster fragmentado.

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

Pré-requisitos

Para implementar um conjunto de réplicas 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:

    • Seu conjunto de réplicas. Certifique-se de adicionar SANspara cada pod Kubernetes que hospeda um membro do seu conjunto de réplicas no certificado.

      No certificado TLS , a SAN para cada pod deve usar o seguinte formato:

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

      Importante

      Se você estiver usando um provedor de serviços baseado em ACME , como Vamos Criptografar para emitir certificados TLS , o fornecedor pode proibi-lo de adicionar o FQDNs padrão do Pod (*.svc.cluster.local) ao s SAN no certificado.

      Para usar um certificado baseado em ACME , você deve configurar o certificado para o recurso do conjunto de réplicas. Para saber mais, consulte a etapa sobre certificados TLS baseados em ACME no procedimento.

    • 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 ter o arquivo de certificado da CA e nomeá-lo ca-pem.

  • Você deve ter a chave usada 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 conjunto de réplicas 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.

Distribuir um conjunto de réplicas

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 o certificado TLS de seu conjunto de réplicas.

Execute este comando kubectl para criar um novo secreto que armazena o certificado do conjunto de réplica:

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-tls-key>

Observação

É necessário prefixar os segredos com <prefix>-<metadata.name>.

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.

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

Para saber mais sobre suas opções de armazenamento secreto, consulte Configurar armazenamento secreto.

3

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 .

4

Crie o ConfigMap para vincular sua CA com seu sistema.

Execute este comando kubectl para vincular a CA ao seu conjunto de réplicas e especificar o arquivo de certificado da CA.

Importante

O Operador Kubernetes exige que o certificado do recurso MongoDB seja denominado ca-pem no ConfigMap.

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

Copie o recurso definir de exemplo.

Altere as configurações desse arquivo YAML para corresponder à configuração desejada do definir .

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

Cole o exemplo copiado para criar um novo recurso de conjunto de réplica.

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

7

Altere as configurações para seus valores preferidos.

Chave
Tipo
Descrição
Exemplo

metadata.name

string

Etiqueta para este conjunto de réplica objeto 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.members

inteiro

Número de membros do conjunto de réplicas.

3

spec.version

string

Versão do MongoDB que este conjunto de réplica 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.

6.0.0-ent

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.

<myconfigmap>

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.

ReplicaSet

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, então spec.podSpec.persistence.single está definido para seu 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

8

Configure as configurações de TLS para seu recurso de conjunto de réplica 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

9

Opcional: configure certificados TLS baseados em ACME para o recurso do conjunto de réplicas.

Se você estiver usando um provedor de serviços baseado em ACME , como Vamos Criptografar para emitir certificados TLS , o fornecedor pode proibi-lo de adicionar o FQDNs padrão do Pod (*.svc.cluster.local) ao SANs no certificado.

Para configurar um certificado que não contém os FQDNs do podcast:

  1. Emita o certificado para um domínio externo. Para obter mais informações, consulte a documentação do Let's Encrypt ou a documentação do seu provedor.

  2. Certifique-se de que seu certificado contenha todos os nomes de host que você planeja implementar no replica set. Alternativamente, você pode emitir um certificado curinga para *.<externalDomain>.

  3. Para usar um certificado que contenha apenas domínios externos para a implantação do replica set, você deve alterar o nome de host padrão usado pelo replica set:

    • Se você preferir configurar o nome de host ao criar seu cluster Kubernetes, altere o domínio padrão do cluster.local para o domínio externo ao criar ou recriar seu cluster Kubernetes. Em seguida, defina esse domínio no recurso do MongoDB usando a configuração spec.clusterDomain .

    • Caso contrário, crie sua MongoDB deployment com as seguintes configurações definidas no objeto Kubernetes:

Chave
Tipo
necessidade
Descrição
spec.externalAccess
.externalDomain

string

Obrigatório

Um domínio externo usado para expor externamente seu sistema de conjunto de réplicas.

Por padrão, cada nó do conjunto de réplicas utiliza o FQDN (*.svc.cluster.local) do Pod do Kubernetes como o nome de host padrão. No entanto, se você adicionar um domínio externo a esta configuração, o conjunto de réplicas usará um nome de host que é um subdomínio do domínio especificado. Este nome de host tem o seguinte formato:

<replica-set-name>-<pod-idx>.<externalDomain>

Por exemplo:

replica-set-1.example.com

Depois de implantar o conjunto de réplicas com essa configuração, o Kubernetes Operator usa o nome do host com domínio externo para substituir o processes[n].hostname campo na MongoDB Ops Manager configuração de automação do . Em seguida, o MongoDB Agent utiliza este nome de host para se conectar ao mongod.

Para especificar outros nomes de host para conectar ao conjunto de réplica, você pode utilizar a configuração do spec.connectivity.replicaSetHorizons. No entanto, as seguintes conexões ainda usam o nome de host com o domínio externo:

  • O MongoDB Agent para se conectar ao mongod.

  • mongod para conectar a outras mongod instâncias.

AVISO: a especificação desse campo altera a forma como o MongoDB Ops Manager registra os processos mongod . Você pode especificar esse campo somente para novas implantações de conjunto de réplicas começando no Kubernetes Operator versão 1.19. Você não pode alterar o valor desse campo ou de qualquer processes[n].hostname campo na MongoDB Ops Manager automation configuration do para uma implantação de replica set em execução.

spec.externalAccess
.externalService.spec

collection

Opcional

Configuração do ServiceSpec.

Quando você configura a configuração do spec.externalAccess, o Operador Kubernetes cria automaticamente um serviço de balanceador de carga externo com valores padrão. Você pode substituir determinados valores ou adicionar novos valores dependendo de suas necessidades. Por exemplo, se você pretende criar serviços do NodePort e não precisa de um balanceador de carga, você deve configurar substituições na especificação do Kubernetes:

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      # you can specify other spec overrides if necessary

Para obter mais informações sobre a especificação do Kubernetes, consulte ServiceSpec na documentação do Kubernetes.

spec.externalAccess
.externalService.annotations

collection

Opcional

Pares de valores-chave que permitem adicionar configurações específicas do fornecedor de nuvem a todos os clusters em seu sistema. Para saber mais,consulte anotações e a documentação do seu fornecedor de nuvem Kubernetes.

Você pode especificar valores de espaço reservado para personalizar suas anotações. Para saber mais, consulte spec.externalAccess.externalService.annotations.

10

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

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

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.

11

Salve este arquivo de configuração de conjunto de réplicas com uma .yaml extensão.

12

Inicie o seu sistema de conjunto de réplicas.

Em qualquer diretório, invoque o seguinte comando do Kubernetes para criar seu conjunto de réplicas:

kubectl apply -f <replica-set-conf>.yaml
13

Monitore o status da implantação do conjunto de réplicas.

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 conjunto de réplicas

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 seus certificados TLS.

Execute este kubectl comando para renovar um segredo existente que armazena os certificados do conjunto de réplicas:

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-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 definir de exemplo.

Altere as configurações desse arquivo YAML para corresponder à configuração desejada do definir .

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-replica-set>
6spec:
7  members: 3
8  version: "4.2.2-ent"
9  opsManager:
10    configMapRef:
11           # Must match metadata.name in ConfigMap file
12      name: <configMap.metadata.name>
13  credentials: <mycredentials>
14  type: ReplicaSet
15  persistent: true
16...
3

Cole o exemplo copiado para criar um novo recurso de conjunto de réplica.

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

4

Altere as configurações para seus valores preferidos.

Chave
Tipo
Descrição
Exemplo

metadata.name

string

Etiqueta para este conjunto de réplica objeto 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.members

inteiro

Número de membros do conjunto de réplicas.

3

spec.version

string

Versão do MongoDB que este conjunto de réplica 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.

6.0.0-ent

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.

<myconfigmap>

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.

ReplicaSet

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, então spec.podSpec.persistence.single está definido para seu 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 adicionais aceitas para uma implementação de definir.

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

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.

6

Salve este arquivo de configuração de conjunto de réplicas com uma .yaml extensão.

7

Inicie o seu sistema de conjunto de réplicas.

Em qualquer diretório, invoque o seguinte comando do Kubernetes para criar seu conjunto de réplicas:

kubectl apply -f <replica-set-conf>.yaml
8

Monitore o status da implantação do conjunto de réplicas.

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

Instância autônoma

Próximo

Cluster fragmentado