Menu Docs

Reconciliando o recurso personalizado do MongoDBOpsManager

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

Diagram describing how the MongoDB Enterprise Kubernetes
Operator reconciles changes to the MongoDBOpsManager
Custom Resource Definition on each member Kubernetes cluster.
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 do Aplicativo também Atlas Triggers uma reinicialização contínua porque a string de conexão com o Banco de Dados do Aplicativo muda. As alterações no 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.