Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs
Página inicial do Docs
/ /
Distribuir
Página inicial do Docs
/ /
Implementar recursos do banco de dados
/
Distribuir
Página inicial do Docs
/
Gestão
/
Controladores para o Operador do Kubernetes
/
Implementar recursos do banco de dados
/
Distribuir

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 usar o Atlas Operator para implantar recursos do MongoDB no Atlas.

Aviso

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

Um conjunto de réplicas é um grupo de sistemas do MongoDB que mantém o mesmo conjunto de dados. Os conjuntos de réplicas fornecem redundância e alta disponibilidade e são a base para todos os sistemas de produção.

Para saber mais sobre conjuntos de réplicas, consulte a Introdução à replicação no manual 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 replica set por meio do Kubernetes Operator, você deve escolher se deseja criptografar conexões usando certificados TLS.

O seguinte procedimento para conexões do 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 Implementar 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 de segredos. As implantações em vários clusters do Kubernetes não suportam o armazenamento de segredos no armazenamento de segredos FERRAMENTAS, 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

      If you're using an ACME based service provider such as Let's Encrypt to issue TLS certificates, the provider might prohibit you from adding the Pod's default FQDNs (*.svc.cluster.local) to SANs in the certificate.

      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 CA e nomeá-lo ca-pem.

  • Você deve ter a chave usada para assinar seus certificados TLS .

Importante

O operador Kubernetes usa kubernetes.io/tls segredos para armazenar certificados TLS e chaves privadas para o MongoDB Ops Manager e recursos do MongoDB. A partir da versão 1.17.0 do operador Kubernetes, ele não oferece suporte a arquivos PEM concatenados armazenados como Opaque secrets.

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 e definir o prefixo como mdb, deverá nomear o segredo TLS para as comunicações TLS do cliente como 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.

Change the settings of this YAML file to match your desired replica set configuration.

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

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 metadata.name e a documentação do Kubernetes sobre nomes.

myproject

inteiro

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

3

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.

8.0.0

spec
.opsManager
.configMapRef
.name

string

Nome do ConfigMap com a configuração de conexão do Ops Manager. 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>

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.

The Ops Manager Kubernetes Secret object holding the Credentials must exist on the same Namespace as the resource you want to create.

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

<mycredentials>

string

Tipo de recurso MongoDB a ser criado.

ReplicaSet

string

Opcional.

Sinalizador que indica se esse recurso MongoDB 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 collections para atender aos requisitos do seu sistema:

AVISO: conceda aos seus 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 igual a 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 utilizar Volumes Persistentes, os gráficos Disk Usage e Disk IOPS não poderão ser exibidos na guia Processes na página Deployment ou na página Metrics ao revisar os dados para este sistema.

true

8

Configure the TLS settings for your replica set resource using a custom certificate authority (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 e definir o prefixo como mdb, deverá nomear o segredo TLS para as comunicações TLS do cliente como 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.

If you're using an ACME based service provider such as Let's Encrypt to issue TLS certificates, the provider might prohibit you from adding the Pod's default FQDNs (*.svc.cluster.local) to SANs in the certificate.

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 agrupamento Kubernetes, altere o domínio padrão do cluster.local para o domínio externo ao criar ou recriar seu agrupamento 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 membro do conjunto de réplica utiliza o FQDN (*.svc.cluster.local) do Kubernetes Pode 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 usa o seguinte formato:

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

Por exemplo:

replica-set-1.example.com

After you deploy the replica set with this setting, the Kubernetes Operator uses the hostname with the external domain to override the processes[n].hostname field in the Ops Manager automation configuration. Then, the MongoDB Agent uses this hostname to connect to 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:

WARNING: Specifying this field changes how Ops Manager registers mongod processes. You can't change the value of this field or any processes[n].hostname fields in the Ops Manager automation configuration for a running replica set deployment.

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 provedor de nuvem a todos os clusters em seu sistema. Para saber mais, consulte as anotações e a documentação do seu provedor 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 spec.clusterDomain se o seu cluster Kubernetes tiver um domínio padrão diferente do padrão cluster.local. 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

Save this replica set config file with a .yaml extension.

12

Inicie o seu conjunto de réplicas implantação.

In any directory, invoke the following Kubernetes command to create your replica set:

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

Acompanhe 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 comando kubectl 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 -
Voltar
Instância autônoma
Próximo
Cluster fragmentado
Avalie esta página

Nesta página