O recurso personalizado do MongoDB define implantações de banco de dados que o Kubernetes Operator gerencia. Suas especificações de recurso personalizado definem esses recursos, e o Kubernetes Operator os monitora. Quando você atualiza a especificação de um recurso, o Kubernetes operador envia as alterações para o MongoDB Ops Manager, que modifica a configuração da implantação do MongoDB.
O CRD MongoDB oferece suporte a três tipos de implantação. O diagrama a seguir ilustra a composição de cada um:
Aviso
O Kubernetes Operator não oferece suporte a nós arbiter.
Recurso autônomo
Embora você possa implantar um recurso Standalone, recomendamos que você implante um recurso ReplicaSet com um nó em vez disso, porque um conjunto de réplicas permite que você adicione nós no futuro. Em Kubernetes, um recurso Standalone é equivalente a um recurso ReplicaSet com somente um nó.
Para um recurso Standalone, o Operador Kubernetes implanta um conjunto de réplicas com um único nó como um StatefulSet. O Operador Kubernetes cria o StatefulSet, que contém a especificação Pod, e depende do Controlador StatefulSet do Kubernetes para criar o Pod para esta única instância mongod.
Recurso de conjunto de réplicas
Para um recurso ReplicaSet, o Operador Kubernetes implanta um conjunto de réplicas como um StatefulSet, com um número de nós igual ao valor de spec.members. O Operador Kubernetes depende do Controlador StatefulSet Kubernetes para criar um Pod por nó. Cada Pod executa uma instância de MongoDB Agent que gerencia o processo mongod nesse Pod.
Recurso de cluster sharded
Um recurso ShardedCluster consiste em servidores de configuração, instâncias mongos e nós do shard. O operador Kubernetes implanta:
Um StatefulSet para todos os servidores de configuração
Um StatefulSet para todas as instâncias do
mongosUm StatefulSet para cada shard
O Operador Kubernetes depende do Controlador StatefulSet Kubernetes para criar um Pod em cada StatefulSet. Para um cluster sharded com 2 shard, isso significa 4 StatefulSets no total (1 para servidor de configuração + 1 para mongos + 2 para shard).
Tipo de implementação | StatefulSets | Tamanho do StatefulSet |
|---|---|---|
Autônomo | 1 | 1 Pod |
Conjunto de réplicas | 1 | 1 Pod por membro |
Cluster fragmentado | <numberOfShards> + 2 | 1 Pod por |
Reconciliação de recursos do MongoDB
Quando você aplica uma especificação de recurso personalizada do MongoDB, o Kubernetes Operator implanta cada recurso como um StatefulSet. O Kubernetes Operator entra em um loop de reconciliação contínuo:
Lê a configuração do projeto do ConfigMap especificado em
spec.opsManager.configMapRef.name.Lê as credenciais da API do Secret especificado em
spec.credentialsou de sua ferramenta de armazenamento secreto.Conecta-se ao MongoDB Ops Manager e executa o seguinte:
Lê a organização do
orgIdno ConfigMap.Lê ou cria o projeto especificado em
projectName.Verifica se o
<project-id>-group-secretexiste ou o cria com as chaves da API do MongoDB Ops Manager.Registra o operador Kubernetes como um observador do ConfigMap e dos secrets de credenciais.
Verifica certificados TLS e X.509 , se ativado:
Para conjuntos de réplicas: procura certificados em
<prefix>-<resource-name>-cert.Para clusters sharded: procura certificados em
<prefix>-<resource-name>-x-cert(por shard),<prefix>-<resource-name>-config-cert(servidor de configuração) e<prefix>-<resource-name>-mongos-cert(instânciamongos).
Cria ou atualiza StatefulSets. O número depende do tipo de implantação. Neste ponto, cada Pod executa um MongoDB Agent, mas ainda não contém
mongodinstâncias.Cada MongoDB Agent pesquisa o MongoDB Ops Manager para a configuração de automação.
Em contêineres não estáticos, o MongoDB Agent faz o download dos binários do MongoDB com a versão especificada em
spec.version.Depois de receber a configuração, o MongoDB Agent inicia
mongod.O operador do Kubernetes gera PersistentVolumeClaims para cada Pod (exceto
mongosPods), a menos quespec.persistentsejafalse.
Envia atualizações de configuração de automação para o MongoDB Ops Manager. Cada MongoDB Agent pesquisa a configuração atualizada e a aplica. Se você alterar qualquer campo, o Operador Kubernetes executará uma atualização de rolagem do StatefulSets.
Cria ou atualiza serviços do Kubernetes:
Para
ReplicaSetouStandalone: um serviçoClusterIPsem cabeça chamado<resource-name>-svc.Para
ShardedCluster:mongos: usa o nome emspec.serviceou<resource-name>-svc.Config servers:
<resource-name>-cs.Cada shard:
<resource-name>-sh.
O diagrama a seguir ilustra o fluxo de reconciliação para conjuntos de réplicas:
O diagrama a seguir ilustra o fluxo de reconciliação para clusters:
Reconciliação de recursos do MongoDBUser
Se o método de autenticação do usuário for SCRAM, o recurso MongoDBUser dependerá de um segredo que armazena as credenciais do usuário. O Operador Kubernetes observa o segredo em busca de mudanças e reconcilia da seguinte forma:
Determina o recurso do usuário do MongoDB a partir do
spec.MongoDBResourceRef.name.Conecta-se ao MongoDB Ops Manager, lê a organização e o projeto e verifica o segredo do agente.
Atualiza as credenciais do usuário no MongoDB Ops Manager ou cria um novo usuário se não existir. Se o nome de usuário tiver sido alterado, o operador do Kubernetes removerá o nome antigo e adicionará um novo.
O diagrama a seguir ilustra o fluxo de reconciliação MongoDBUser:
