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.

  • You must have the CA certificate file and name it 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 Ops Manager e MongoDB . A partir da versão do Kubernetes Operator 1.17.0, o Kubernetes Operator não permite 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 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.

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 de operadores, 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>.

For example, if you call your deployment my-deployment and you set the prefix to mdb, you must name the TLS secret for the client TLS communications mdb-my-deployment-cert. Also, you must name the TLS secret for internal cluster authentication (if enabled) 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: "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

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

8.0.0

spec
.opsManager
.configMapRef
.name

string

Name of the ConfigMap with the Ops Manager connection configuration. The spec.cloudManager.configMapRef.name setting is an alias for this setting and can be used in its place.

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.

O objeto Ops Manager Kubernetes Secret contendo as credenciais deve existir no mesmo namespace do 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.

Flag indicating if this MongoDB resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB resource is stopped or restarted.

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:

WARNING: Grant your containers permission to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000, runAsUser = 2000, and runAsNonRoot = true in securityContext. Kubernetes Operator sets fsgroup equal to runAsUser to make the volume writable for a user that runs the main process in the container. To learn more, see Configure a Security Context for a Pod or Container and the related discussion in the Kubernetes documentation. If redeploying the resource doesn't fix issues with your Persistent Volume, contact MongoDB Support.

If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.

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.

For example, if you call your deployment my-deployment and you set the prefix to mdb, you must name the TLS secret for the client TLS communications mdb-my-deployment-cert. Also, you must name the TLS secret for internal cluster authentication (if enabled) mdb-my-deployment-clusterfile.

devDb

9

Optional: Configure ACME based TLS certificates for your replica set resource.

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:

    • If you prefer to configure the hostname while creating your Kubernetes cluster, change the default domain from cluster.local to the external domain when creating or recreating your Kubernetes cluster. Then, set this domain in your MongoDB resource by using the spec.clusterDomain setting.

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

By default, each replica set member uses the Kubernetes Pod's FQDN (*.svc.cluster.local) as the default hostname. However, if you add an external domain to this setting, the replica set uses a hostname that is a subdomain of the specified domain instead. This hostname uses the following format:

<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

You must set spec.clusterDomain if your Kubernetes cluster has a default domain other than the default cluster.local. If you neither use the default nor set the spec.clusterDomain option, the Kubernetes Operator might not function as expected.

11

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

12

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

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

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 de operadores, 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.

Run this kubectl command to renew an existing secret that stores the replica set's certificates:

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 de operadores, 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: "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...
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 metadata.name e a documentação do Kubernetes 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.

8.0.0

spec
.opsManager
.configMapRef
.name

string

Name of the ConfigMap with the Ops Manager connection configuration. The spec.cloudManager.configMapRef.name setting is an alias for this setting and can be used in its place.

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.

O objeto Ops Manager Kubernetes Secret contendo as credenciais deve existir no mesmo namespace do 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.

Flag indicating if this MongoDB resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB resource is stopped or restarted.

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:

WARNING: Grant your containers permission to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000, runAsUser = 2000, and runAsNonRoot = true in securityContext. Kubernetes Operator sets fsgroup equal to runAsUser to make the volume writable for a user that runs the main process in the container. To learn more, see Configure a Security Context for a Pod or Container and the related discussion in the Kubernetes documentation. If redeploying the resource doesn't fix issues with your Persistent Volume, contact MongoDB Support.

If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.

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

You must set spec.clusterDomain if your Kubernetes cluster has a default domain other than the default cluster.local. If you neither use the default nor set the spec.clusterDomain option, the Kubernetes Operator might not function as expected.

6

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

7

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

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

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.

Voltar
Instância autônoma
Próximo
Cluster fragmentado
Avalie esta página

Nesta página