Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/ /

Reconciliando o MongoDBOpsManager Recurso Personalizado

O diagrama a seguir descreve como o Operador Kubernetes reconcilia as alterações no MongoDBOpsManager CustomResourceDefinition em cada cluster Kubernetes de membros.

Diagrama que descreve como o Operador do MongoDB Enterprise Kubernetes Operator reconcilia as alterações na Definição de recurso personalizado do MongoDBOpsManager em cada cluster do Kubernetes de membros.
clique para ampliar
  1. O Operador Kubernetes cria ou atualiza o segredo <om_resource_name>-db-config . Este segredo contém as configurações que o MongoDB Agent usa para iniciar o conjunto de réplicas do banco de dados de aplicativo.

  2. O Operador Kubernetes cria ou atualiza o aplicativo de banco de dados <om_resource_name>-db StatefulSet. Este StatefulSet contém pelo menos três Pods.

    • Cada Pod executa uma instância de MongoDB Agent . Cada MongoDB Agent inicia uma instância mongod em seu Pod.

    • O Operador Kubernetes monta o segredo <om_resource_name>-db-config para cada Pod. O MongoDB Agent usa esse segredo para configurar o conjunto de réplicas do aplicativo de banco de dados.

      Em sistemas de vários clusters, o Operador Kubernetes atribui o sufixo de índice do cluster de membros a cada StatefulSet do banco de dados de aplicativos, na forma de <om_resource_name>-db-<cluster-idx>, por exemplo: om-db-1.

  3. O Operador Kubernetes cria ou atualiza o <om_resource_name> StatefulSet. Em sistemas de vários clusters, o Operador Kubernetes atribui o sufixo de índice do cluster de membros a cada StatefulSet, na forma de <om_resource_name>-<cluster-idx>, por exemplo: om-1.

    O StatefulSet contém um Pod para cada réplica MongoDB Ops Manager . Cada réplica MongoDB Ops Manager se conecta ao banco de dados do aplicativo.

    A maioria das alterações no MongoDBOpsManager recurso personalizado trigger uma atualização contínua dos Pods no <om_resource_name> StatefulSet. A ativação do TLS para o Banco de Dados de Aplicativos também aciona uma reinicialização contínua porque a string de conexão com o Banco de Dados de Aplicativos muda. As alterações em spec.backup não trigger uma atualização contínua.

  4. O Kubernetes Operator invoca APIs MongoDB Ops Manager para criar um usuário administrador. O Operador do Kubernetes salva as credenciais deste usuário administrador no segredo do <om_resource_name>-admin-key . O Kubernetes Operator usa essas credenciais para todas as outras MongoDB Ops Manager API invocações de . Esta etapa de reconciliação acontece apenas uma vez quando você usa o Operador Kubernetes para implantar um novo recurso MongoDB Ops Manager . O Operador Kubernetes pula esta etapa quando atualiza o recurso.

  5. O Operador Kubernetes executa uma atualização contínua dos Pods no Banco de Dados de Aplicativo <om_resource_name>-db StatefulSet para permitir que o MongoDB Ops Manager o monitore. O monitoramento está habilitado por padrão. Essa etapa de reconciliação acontece apenas uma vez, como quando você implanta um novo recurso MongoDB Ops Manager .

  6. Se spec.backup.enabled for verdadeiro, o Operador Kubernetes cria o <om_resource_name>-backup-daemon StatefulSet ou verifica se ele está em execução. O Backup Daemon se conecta ao mesmo banco de dados de aplicativos que a implantação do MongoDB Ops Manager .

    Em sistemas de vários clusters, o Operador Kubernetes atribui o sufixo de índice do cluster de membros a cada StatefulSet do Backup Daemon, na forma de <om_resource_name>-backup-daemon-<cluster-idx>, por exemplo: om-backup-daemon-1.

  7. Se spec.backup.enabled for true , o Kubernetes Operator invocará APIs do Ops Manager para garantir que a configuração de backup do aplicativo de Ops Manager corresponda à que você define na definição de recurso personalizado.

Voltar

MongoDBOpsManager Resource