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

Arquitetura de banco de dados do MongoDB no Kubernetes

Nesta página

  • A definição de recurso personalizada do MongoDB
  • Reconciliando o recurso personalizado do MongoDB
  • Reconciliando o recurso personalizado do MongoDBUser

Importante

Esta seção é somente para sistemas de cluster Kubernetes únicos. Para sistemas do MongoDB em clusters multi-Kubernetes, consulte Arquitetura, recursos e limitações.

Você pode usar o Kubernetes Operator and Cloud Manager ou o Ops Manager para implantar recursos de banco de dados do MongoDB em um cluster do Kubernetes. Você pode usar um Cloud Manager ou Ops Manager existente ou implementar o Ops Manager no Kubernetes para gerenciar seus bancos de dados.

O Kubernetes Operator usa o Cloud Manager ou o Ops Manager para gerenciar os seguintes recursos personalizados do banco de dados MongoDB:

  • MongoDB

  • MongoDBUser

Suas especificações de recurso personalizado definem estes recursos no Operador Kubernetes. O operador do Kubernetes monitora esses recursos. Quando você atualiza a especificação do recurso, o Operador do Kubernetes envia essas alterações para o Cloud Manager ou o Ops Manager, que fazem alterações na configuração da implantação do MongoDB .

A MongoDB definição de recurso personalizado

O Operador Kubernetes gerencia sistemas de banco de dados MongoDB que são definidas por recursos personalizados do MongoDB.

A especificação do banco de dados MongoDB recurso personalizado define os seguintes tipos de recursos personalizados do banco de dados MongoDB:

  • Standalone

  • ReplicaSet

  • ShardedCluster

O diagrama a seguir ilustra a composição de cada tipo do recurso MongoDB no Operador Kubernetes.

Diagrama mostrando a arquitetura de alto nível dos recursos do MongoDB no MongoDB Enterprise Kubernetes Operator
clique para ampliar

Aviso

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

Autônomo

Para o tipo Standalone do recurso de banco de dados MongoDB, o Operador Kubernetes implementa um conjunto de réplicas com um único membro no cluster Kubernetes como um StatefulSet.

O Operador Kubernetes cria o StatefulSet, que contém a especificação Pod com o número de Pods a criar. O Operador Kubernetes depende do Controlador StatefulSet do Kubernetes para criar um Pod para esta instância de banco de dados MongoDB independente.

Importante

Em Kubernetes, um recurso do Standalone é equivalente a um recurso do ReplicaSet com somente um membro. Recomendamos que você implemente um ReplicaSet com um membro em vez de um Standalone porque um conjunto de réplicas permite que você adicione membros a ele no futuro.

Conjunto de réplicas

Para o ReplicaSet tipo do recurso MongoDB, o Operador Kubernetes implementa um conjunto de réplicas no cluster Kubernetes como um StatefulSet, com um número de membros igual ao valor de spec.members.

O Operador Kubernetes depende do Controlador StatefulSet Kubernetes para criar um Pod no StatefulSet para cada membro do conjunto de réplicas.

Cada Pod no StatefulSet executa uma instância de Agente MongoDB.

Cluster fragmentado

O tipo ShardedCluster do recurso MongoDB consiste em um ou mais servidores de configuração, instâncias mongos e nós do shard.

Para o recurso ShardedCluster, o Operador Kubernetes implementa:

  • Um StatefulSet para todos os servidores de configuração

  • Um StatefulSet para todas as instâncias do mongos

  • Um StatefulSet para cada membro do Shard

O Operador Kubernetes depende do Controlador StatefulSet Kubernetes para criar um Pod em cada um dos StatefulSets criados para o cluster fragmentado.

Reconciliando o MongoDB recurso personalizado do

Quando você aplica uma especificação de recurso personalizada do MongoDB, o Kubernetes Operator implanta cada recurso como um StatefulSet no cluster Kubernetes.

O operador Kubernetes:

  • Observa a especificação do recurso personalizado e o ConfigMap associado ou segredos armazenados em sua ferramenta de armazenamento secreto.

  • Valida as alterações quando o arquivo de especificação, o ConfigMap ou a alteração secreta.

  • Cria as atualizações apropriadas para os recursos do banco de dados MongoDB no cluster Kubernetes.

  • Envia as alterações para o Cloud Manager ou o Ops Manager, que fazem alterações na configuração do sistema do MongoDB.

Diagrama de uma reconciliação de conjunto de réplicas

O diagrama a seguir descreve como o Kubernetes Operator se comporta se você fizer alterações em um conjunto de réplicas:

Diagrama descrevendo como o Operador Kubernetes do MongoDB Enterprise faz alterações na Definição de recursos personalizados do MongoDB para um conjunto de réplicas
clique para ampliar

Diagrama de uma conciliação de cluster fragmentado

O diagrama a seguir descreve como o Kubernetes Operator se comporta se você fizer alterações em um cluster fragmentado:

Diagrama que descreve como o Enterprise Kubernetes Operator faz alterações na definição de recurso personalizado do MongoDB para um cluster fragmentado
clique para ampliar

Fluxo de trabalho de reconciliação

Quando você cria ou altera uma especificação de recurso MongoDB, ou quando você faz alterações em um ConfigMap ou segredo associado, o Operador Kubernetes executa as seguintes ações para reconciliar as alterações:

  1. Lê a organização necessária e a configuração do projeto do ConfigMap que você usou para criar ou se conectar a um projeto no Kubernetes Operator.

    Se você alterar a especificação do recurso, o Kubernetes Operator identificará que a alteração ocorreu e verificará a especificação do ConfigMap especificado em spec.opsManager.configMapRef.name.

    Observação

    Ao configurar o Kubernetes Operator para recursos do MongoDB, você cria um ConfigMap para conectar ou criar seu projeto do Cloud Manager ou do Ops Manager. O MongoDB Agent usa esse ConfigMap para iniciar ou fazer alterações na implementação do recurso MongoDB.

  2. Lê a configuração de autenticação do Cloud Manager ou do Ops Manager a partir do segredo especificado em:

    Esse secret armazena as chaves da API do Cloud Manager ou as chaves da API do Ops Manager necessárias para que o Kubernetes Operator se autentique no Cloud Manager ou no Ops Manager.

    Observação

    Ao configurar o Kubernetes Operator para recursos do MongoDB, você cria esse segredo no Kubernetes ou o armazena em sua ferramenta de armazenamento de segredos.

  3. O Kubernetes Operator se conecta ao Cloud Manager ou Ops Manager e realiza as seguintes ações:

    • Lê a organização a partir do campo orgId no ConfigMap. Você deve fornecer um valor no campo orgId.

    • Lê um nome de projeto especificado no campo projectName no ConfigMap, ou, se você não especificou um valor para este campo opcional, criará este projeto no Cloud Manager ou Ops Manager se ele não existir.

    • Verifica se o segredo <project-id>-group-secret criado pelo Operador Kubernetes para o Agente MongoDB existe. O Kubernetes Operator lê o segredo de sua ferramenta de armazenamento de segredos ou o cria com chaves de API do Ops Manager ou chaves de API do Cloud Manager.

    • Registra-se como um observador do ConfigMap e este secret. Isso permite que o Kubernetes Operator reaja às alterações feitas no ConfigMap ou no secret.

  4. O Kubernetes Operator verifica quaisquer certificados TLS e X.509.

    • Se o TLS estiver habilitado para um conjunto de réplicas, o Kubernetes Operator procurará certificados fornecidos no secret do <prefix>-<resource-name>-cert ou na sua ferramenta de armazenamento de secret.

    • Se o TLS estiver ativado para um cluster fragmentado, o Kubernetes Operator procurará certificados nesses segredos:

      • <prefix>-<resource-name>-x-cert para cada membro do fragmento.

      • <prefix>-<resource-name>-config-cert para todos os servidores de configuração.

      • <prefix>-<resource-name>-mongos-cert para todas as instâncias do mongos .

      • Sua ferramenta de armazenamento secreta.

    • Se a autenticação X.509 ou interna com X.509 e TLS estiver ativada, o Kubernetes Operator verificará se seus certificados contêm a configuração necessária.

  5. O Kubernetes Operator localiza e atualiza os StatefulSets necessários, ou cria novos StatefulSets se não existirem. O número de StatefulSets depende do tipo do recurso MongoDB.

    • Para recursos do ReplicaSet ou Standalone, o Operador Kubernetes cria um StatefulSet único.

    • Para um recurso do ShardedCluster, o Operador Kubernetes cria:

      • Um StatefulSet para todos os servidores de configuração.

      • Um StatefulSet para todas as instâncias do mongos .

      • Um StatefulSet para cada membro do fragmento.

      Neste ponto, cada Pod executa pelo menos uma instância de MongoDB Agent , mas ainda não contém mongod instâncias.

    • Cada instância do MongoDB Agent começa a pesquisar o Cloud Manager ou o Ops Manager para receber a configuração de automação do MongoDB.

      Observação

      Contêineres não estáticos: quando o MongoDB Agent recebe a configuração pela primeira vez, ele baixa os binários do MongoDB com a versão especificada em spec.version da Internet ou do MongoDB Ops Manager se o MongoDB Agent estiver configurado no modo local.

      Contêineres estáticos: os contêineres estáticos não baixam binários no tempo de execução. Para saber mais, consulte Containers estáticos (visualização pública).

    • Após o MongoDB Agent receber a configuração de automação, ele inicia uma instância do mongod no Pod correspondente.

    • Para cada Pod de cada StatefulSet que o recurso personalizado do MongoDB cria, exceto para StatefulSets, o Operador mongos do Kubernetes gera uma Reivindicação de Volume Persistente. Você pode substituir este comportamento configurando spec.persistent para false na especificação do recurso.

  6. O Kubernetes Operator atualiza a configuração de automação que recebeu do MongoDB Agent com alterações das especificações e a enviar para o Cloud Manager ou Ops Manager.

    • Cada agente MongoDB para cada Pod pesquisa o Cloud Manager ou Ops Manager novamente e recebe a configuração de automação atualizada.

    • Se você alterar qualquer campo na especificação, o Operador Kubernetes executará uma atualização de rolagem do StatefulSets para iniciar novos Pods correspondentes à nova especificação.

    • O Kubernetes Operator espera que cada agente do MongoDB informe que ele chegou ao estado pronto.

    Observação

    Se você alterar a configuração de segurança de um recurso do banco de dados de dados ou reduzir um StatefulSet existente, o Operador Kubernetes executa a etapa 6 antes de executar a etapa 5.

  7. O Kubernetes Operator atualiza os serviços do Kubernetes, ou para um novo recurso do MongoDB, cria os serviços necessários para cada novo StatefulSet.

    Para o ServiceType ClusterIP, o Operador Kubernetes ClusterIP Nonedefine como e executa estas ações:

    • Cria este serviço se não existir.

    • Para recursos do ReplicaSet ou Standalone, o Kubernetes Operator nomeia o serviço com o nome do recurso personalizado com -svc anexado a ele.

    • Para um recurso ShardedCluster, o Operador Kubernetes usa estas convenções de nomenclatura:

      • Para instâncias do mongos , o Operador do Kubernetes utiliza o nome especificado no spec.service ou o nome do recurso com -svc anexado a ele.

      • Para os servidores de configuração, o Kubernetes Operator utiliza o nome do recurso com -cs anexado a ele.

      • Para cada shard, o Operador Kubernetes utiliza o nome do recurso com -sh anexado a ele.

    • Para a porta, o Kubernetes Operator usa a porta padrão 27017 ou o .net.port especificado em spec.additionalMongodConfig.

Reconciliando o MongoDBUser recurso personalizado do

Se o método de autenticação do usuário estiver definido como SCRAM, a Especificação de Recursos do Usuário do MongoDB dependerá da ferramenta de armazenamento secreto que armazena as credenciais do usuário. Se você estiver usando um segredo do Kubernetes , você especifica o segredo spec.passwordSecretKeyRef nas MongoDBUser configurações na especificação do recurso .

O Operador Kubernetes observa o segredo em busca de mudanças. Se você fizer alterações na configuração do segredo, o Operador Kubernetes reconciliará as alterações. São necessárias as seguintes ações:

  1. Determina o recurso do usuário MongoDB baseado no valor especificado na configuração spec.MongoDBResourceRef.name na Especificação do recurso do usuário MongoDB.

  2. Conecta-se ao Cloud Manager ou Ops Manager:

  3. Atualiza as credenciais do usuário no Cloud Manager ou Ops Manager, ou cria um novo usuário se não existir.

    • Se o método de autenticação do usuário for SCRAM, leia a senha do segredo.

    • Lê o nome de usuário. Se o nome de usuário tiver sido alterado, o Kubernetes Operator removerá o nome antigo e adicionará um novo.

    • Garante que o usuário exista no Cloud Manager ou Ops Manager.

O diagrama a seguir descreve como o Kubernetes Operator se comporta se você fizer alterações no secret do usuário ou na Especificação de recursos do usuário do MongoDB.

Diagrama que descreve como o operador do MongoDB Enterprise Kubernetes reconcilia as alterações na definição de recurso personalizado do MongoDBUser
clique para ampliar

Voltar

Implementar recursos do banco de dados

Próximo

Configurar