Reconciliando o recurso personalizado do MongoDBOpsManager

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

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.

   • Each Pod runs one MongoDB Agent instance. Each MongoDB Agent starts a mongod instance on its 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.

   Most changes to the MongoDBOpsManager custom resource trigger a rolling upgrade of the Pods in the <om_resource_name> StatefulSet. Enabling TLS for the Application Database also triggers a rolling restart because the connection string to the Application Database changes. Changes to spec.backup don't trigger a rolling upgrade.

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.