Configurar o Recurso Personalizado MongoDB

Escolhendo um tipo de implantação

A primeira decisão que você precisa tomar é qual tipo de implantação do MongoDB criar. O campo spec.type aceita três valores, cada um visando um conjunto diferente de cargas de trabalho e requisitos operacionais. Compreender as compensações entre eles é essencial antes de gravar uma única linha de YAML.

As instâncias autônomo executam um único processo mongod. Eles são mais adequados para desenvolvimento local, cenários de teste ou avaliação de recursos em que a redundância não é uma preocupação. Como uma implantação autônoma não tem replicação, ela não oferece suporte a failover automático e não é recomendada para dados de produção.

Conjuntos de réplicas são a topologia de produção padrão para o MongoDB. Um conjunto de réplicas consiste em vários nós mongod (geralmente três ou mais) que mantêm cópias idênticas dos seus dados. Se o primário falhar, os nós restantes elegerão um novo primário sem intervenção manual. A escolha de um conjunto de réplicas oferece alta disponibilidade, escalabilidade de leitura por meio de leituras secundárias e a capacidade de realizar manutenção contínua. Para a maioria das equipes, é aqui que você começa:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

Clusters distribuem dados entre vários shards, cada um dos quais é um conjunto de réplicas. Na frente dos shards, há roteadores mongos que direcionam o tráfego do cliente e um conjunto de réplicas de servidor de configuração dedicado que armazena metadados do cluster. Se o seu conjunto de dados estiver crescendo além do que um único conjunto de réplicas pode servir com eficiência, ou se você precisar dimensionar as gravações horizontalmente, um cluster sharded é a escolha certa. A configuração é mais complexa porque você deve especificar contagens para shards, mongod instâncias por shard, mongos roteadores e servidores de configuração:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

Para obter detalhes completos sobre cada campo específico de cada tipo de implantação, consulte as seções Autônomo, Conjunto de réplicas e Cluster sharded da referência de especificação.

Conectando-se ao MongoDB Ops Manager

Todo recurso personalizado do MongoDB deve ser vinculado a um projeto do MongoDB Ops Manager. Essa conexão é como o Kubernetes Operator registra sua implantação para monitoramento, automação e backup. Duas configurações fazem a conexão funcionar: um ConfigMap que identifica seu projeto e um Secret que armazena suas credenciais de API.

O ConfigMap informa ao operador do Kubernetes em qual projeto do MongoDB Ops Manager a implantação deve ser colocada. No mínimo, ele deve conter um projectName e um baseUrl que aponte para sua instância do MongoDB Ops Manager. Opcionalmente, você pode fixar a implantação a uma organização específica com orgId:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project-configmap
data:
  projectName: "MyKubernetesProject"
  baseUrl: "https://ops-manager.example.com"
  orgId: "5e8f8b8b8b8b8b8b8b8b8b8b"

O Secret contém o par de chaves de API programáticas que o operador do Kubernetes usa para autenticar na API do MongoDB Ops Manager em seu nome:

kubectl create secret generic my-credentials \
  --from-literal="publicKey=<public-api-key>" \
  --from-literal="privateKey=<private-api-key>"

Em seguida, você faz referência a ambos no seu MongoDB CR:

spec:
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials

Para **aprender** mais sobre como criar esses pré-requisitos, consulte Criar credenciais para o operador do Kubernetes e Criar um projeto por implantação do MongoDB usando um ConfigMap.

Versão do MongoDB e compatibilidade de recursos

O campo spec.version define a versão do servidor MongoDB que o Kubernetes Operator implanta (por exemplo, "8.0.0"). Escolher a versão certa não é apenas obter os recursos mais recentes. Você também deve considerar a matriz de compatibilidade de versão com suas bibliotecas de driver, a versão do MongoDB Ops Manager que você está executando e a cadência de atualização de sua equipe.

Ao atualizar entre as versões principais, o campo featureCompatibilityVersion (versão de compatibilidade do recurso) oferece uma rede de segurança. A versão de compatibilidade do recurso controla quais recursos de mecanismo de armazenamento e replicação estão ativos e pode ser definido como inferior à própria versão binária. Isso permite que você atualize os binários primeiro, verifique a estabilidade e, em seguida, aumente a versão de compatibilidade do recurso para desbloquear novos recursos em uma etapa separada e deliberada. Se você precisar reverter, uma versão de compatibilidade do recurso inferior garante que os arquivos de dados permaneçam compatíveis com a versão binária anterior.

spec:
  version: "8.0.0"
  featureCompatibilityVersion: "7.0"

Para referência, consulte spec.version e spec.featureCompatibilityVersion na especificação.

Protegendo sua implantação

A segurança em uma implantação do MongoDB no Kubernetes tem duas dimensões: criptografar o tráfego de rede com TLS e autenticar clientes e nós do cluster. Ambos são configurados no bloco spec.security, e entender como eles interagem é fundamental para obter uma implantação que seja segura e funcional.

spec:
  security:
    certsSecretPrefix: "mdb"
    tls:
      enabled: true
      ca: "custom-ca-configmap"

spec:
  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["SCRAM", "X509"]
      internalCluster: "X509"

Armazenamento e persistência

O MongoDB é uma carga de trabalho com estado, e a forma como você configura o armazenamento afeta diretamente o desempenho, a durabilidade e sua capacidade de se recuperar de falhas. O campo spec.persistent deve ser definido como true para qualquer ambiente em que a perda de dados seja inaceitável (que é essencialmente todo ambiente além de testes descartáveis). Quando a persistência está habilitada, o operador Kubernetes cria PersistentVolumeClaims (PVCs) que sobrevivem a reinícios e reagendamentos de Pod.

spec:
  podSpec:
    persistence:
      multiple:
        data:
          storage: "200Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "50Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "20Gi"
          storageClass: "standard"

spec:
  podSpec:
    persistence:
      single:
        storage: "100Gi"
        storageClass: "standard"

Alocação de recursos e modelos de pod

Dimensionar corretamente a CPU e a memória para os pods do MongoDB é uma das decisões mais impactantes que você toma no momento da implantação, e uma que você provavelmente revisitará à medida que as cargas de trabalho evoluem. O operador do Kubernetes expõe controles de recursos por meio do podSpec (para conjuntos de réplicas e autônomos) e por meio de shardPodSpec, configSrvPodSpec e mongosPodSpec (para clusters sharded).

Definir requests e limits para CPU e memória garante que o Kubernetes agende seus Pods em nós com capacidade adequada e evita que processos descontrolados afetem outras cargas de trabalho no mesmo nó. O exemplo a seguir ilustra uma configuração que você pode usar como ponto de partida. Nesta configuração, você cria nós de conjunto de réplicas de produção com pelo menos 2 nós de CPU e 4 GiB de memória como solicitações, com limites definidos para corresponder ou exceder esses valores:

spec:
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "4Gi"
              limits:
                cpu: "4"
                memory: "8Gi"

Os modelos de pod também permitem que você defina rótulos, anotações, tolerâncias e regras de afinidade. As regras de afinidade são particularmente importantes na produção, porque controlam como os nós do conjunto de réplicas são distribuídos entre os nós do Kubernetes e os domínios de falha.

Por exemplo, a seguinte regra de afinidade distribui os nós pelas zonas de disponibilidade para proteger contra interrupções no nível da zona:

spec:
  podSpec:
    podTemplate:
      spec:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: my-replica-set
                topologyKey: "topology.kubernetes.io/zone"

Para obter uma lista completa de campos podTemplate, consulte a referência de especificação, particularmente spec.podSpec.podTemplate.spec.affinity.

Configurando backups

Os backups no Kubernetes Operator usam a funcionalidade de backup contínuo criada no MongoDB Ops Manager. Quando ativado, o MongoDB Ops Manager captura o oplog em tempo real e tira snapshots periódicos, que juntos fornecem a restauração point-in-time. Isso significa que você pode restaurar para qualquer segundo dentro da janela de retenção configurada, não apenas para o carimbo de data/hora do último snapshot.

Para habilitar o backup em um recurso do MongoDB, defina spec.backup.mode como enabled. Você também pode configurar um agendamento de snapshot que controla a frequência com que os snapshots são tirados e por quanto tempo são retidos, conforme mostrado no exemplo a seguir:

spec:
  backup:
    mode: enabled
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 24

Se sua organização exigir a criptografia de dados de backup em repouso, você poderá integrar-se a um servidor de gerenciamento de chaves compatível com KMIP, conforme mostrado no exemplo a seguir:

spec:
  backup:
    mode: enabled
    encryption:
      kmip:
        client:
          clientCertificatePrefix: "backup-kmip"

O sinalizador autoTerminateOnDeletion controla se os dados de backup são limpos quando o recurso MongoDB é excluído. Defina-o como true em ambientes não produtivos para evitar o estado de backup órfão; deixe-o false em produção para que os dados de backup sobrevivam à exclusão acidental de recursos:

spec:
  backup:
    mode: enabled
    autoTerminateOnDeletion: false

Os rótulos de atribuição permitem controlar qual infraestrutura de backup (armazenamento de oplog, armazenamento de snapshots) uma implantação específica usa, o que é útil quando várias implantações compartilham uma única instância do MongoDB Ops Manager.

Para o conjunto completo de configurações de backup, consulte as Configurações do conjunto de réplicas na referência de especificação. Para saber como implantar a infraestrutura de backup em si, consulte Configurar backups do banco de dados MongoDB.

Expondo sua implantação externamente

Por padrão, as implantações do MongoDB no Kubernetes são acessíveis apenas dentro do cluster. Muitas equipes precisam acessar seus bancos de dados a partir de aplicativos em execução fora do Kubernetes, a partir de ferramentas cliente durante o desenvolvimento ou a partir de um cluster Kubernetes diferente em uma arquitetura multirregional.

O bloco spec.externalAccess instrui o operador Kubernetes a criar serviços Kubernetes que roteiam o tráfego externo para seus Pods MongoDB. Você pode escolher entre serviços LoadBalancer, que provisionam balanceadores de carga de provedor de nuvem, e serviços NodePort, que expõem portas estáticas em cada nó do cluster, conforme mostrado no exemplo a seguir:

spec:
  externalAccess:
    externalService:
      spec:
        type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

Para conjuntos de réplicas, você pode configurar adicionalmente externalDomain para atribuir nomes de host DNS previsíveis a cada nó, o que simplifica a construção de string de conexão no lado do cliente:

spec:
  externalAccess:
    externalDomain: "mongodb.example.com"
    externalService:
      spec:
        type: LoadBalancer

Para saber mais, consulte Conectar a um recurso de banco de dados MongoDB de fora do Kubernetes.

Ajustando os parâmetros do MongoDB Server

Nem todas as configurações de ajuste do MongoDB têm um campo de primeira classe no recurso personalizado. Para quaisquer configurações que não estejam incluídas no esquema explícito do Operador Kubernetes, o bloco spec.additionalMongodConfig permite que você passe opções de configuração mongod arbitrárias. Eles são traduzidos diretamente para a configuração do servidor que o MongoDB Ops Manager aplica.

Os usos comuns para additionalMongodConfig incluem ajustar o tamanho do cache do WiredTiger, restringir as versões do protocolo TLS ou alterar a porta de escuta, conforme mostrado no exemplo a seguir:

spec:
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 4

Em um cluster sharded, cada componente (shard, servidor de configuração, mongos) tem seu próprio campo additionalMongodConfig, para que você possa ajustá-los independentemente. Para obter a lista completa de opções suportadas, consulte Parâmetros do MongoDB Server no Manual do MongoDB.

Configuração do MongoDB Agent

Cada MongoDB Pod executa um MongoDB Agent que gerencia o processo mongod, lida com tarefas de automação e relata a integridade ao MongoDB Ops Manager. Você pode ajustar o comportamento do MongoDB Agent por meio de spec.agent, incluindo opções de inicialização, como limites de rotação de log e tempos limite de conexão, conforme mostrado no exemplo a seguir:

spec:
  agent:
    startupOptions:
      maxLogFiles: "10"
      maxLogFileSize: "100"
      dialTimeout: "20"

O campo spec.logLevel define o detalhamento do log do MongoDB Agent. Durante a configuração inicial ou a solução de problemas, DEBUG pode ser inestimável; na produção em estado estacionário, INFO ou WARN evita volume excessivo de log:

spec:
  logLevel: "DEBUG"

Para configurações completas relacionadas ao MongoDB Agent, consulte a referência de especificação.

Sistemas de vários clusters

Para equipes que precisam distribuir uma única implantação do MongoDB em vários clusters Kubernetes, talvez para redundância geográfica, recuperação de desastre ou soberania de dados, o operador Kubernetes suporta uma topologia de vários clusters. Definir spec.topology como MultiCluster instrui o operador Kubernetes que os conjuntos de réplicas definidos em spec.clusterSpecList vivem em diferentes clusters Kubernetes, conforme mostrado no exemplo a seguir:

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 2
    - clusterName: "cluster-us-west"
      members: 2
    - clusterName: "cluster-eu-west"
      members: 1

As implantações de vários clusters introduzem pré-requisitos adicionais, incluindo rede entre clusters e malha de serviço ou configuração de DNS externo. Antes de prosseguir, revise os pré-requisitos de vários clusters e a arquitetura de vários clusters.

Para os campos de especificação de vários clusters, consulte a Especificação de vários clusters Kubernetes.

Manutenção da configuração de recursos personalizados do MongoDB ao longo do tempo

Um recurso personalizado do MongoDB não é um artefato único. À medida que os requisitos da sua equipe evoluem, você dimensionará nós, adicionará shards, habilitará backup, girará certificados TLS, atualizará versões do MongoDB ou ajustará os limites de recursos. O operador Kubernetes foi projetado para isso: você atualiza o manifesto YAML, aplica-o com kubectl apply e o operador Kubernetes reconcilia as alterações incrementalmente.

Algumas diretrizes para iteração segura:

• Dimensionar nós gradualmente. Adicionar ou remover nós do conjunto de réplicas um de cada vez reduz o risco de interrupção da eleição.

• Atualize as versões em duas etapas. Aumente a versão binária primeiro, mantendo featureCompatibilityVersion no nível anterior, e depois aumente a versão de compatibilidade do recurso após verificar a estabilidade.

• Gire os certificados antes do vencimento. Os certificados TLS têm uma vida útil finita. Planeje um processo de rotação, idealmente automatizado com cert-manager, e teste-o primeiro em um ambiente não produtivo.

• Teste as alterações de armazenamento com cuidado. Algumas alterações de armazenamento (como a troca de classes de armazenamento) podem exigir a migração manual do volume. Sempre valide em um cluster de staging.

• Monitore o status do recurso. Após qualquer alteração, valide se o operador Kubernetes reconciliou suas alterações com sucesso verificando o status do recurso com kubectl get mdb e revisando os logs do operador Kubernetes para erros de reconciliação.

Para procedimentos práticos de modificação de uma implantação, consulte Editar um recurso de banco de dados.

Juntando tudo

O exemplo a seguir combina os conceitos abordados nesta página em uma configuração de conjunto de réplicas pronta para produção. Ele inclui TLS, autenticação SCRAM, backup, agendamento anti-afinidade, volumes de dados/diário/log divididos e ajuste do WiredTiger:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: prod-replica-set
  namespace: mongodb-production
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  featureCompatibilityVersion: "8.0"
  opsManager:
    configMapRef:
      name: prod-project-configmap
  credentials: prod-credentials
  persistent: true
  security:
    certsSecretPrefix: "prod-mdb"
    tls:
      enabled: true
      ca: "prod-ca-configmap"
    authentication:
      enabled: true
      modes: ["SCRAM"]
      internalCluster: "X509"
  backup:
    mode: enabled
    autoTerminateOnDeletion: false
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 48
  podSpec:
    persistence:
      multiple:
        data:
          storage: "500Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "100Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "50Gi"
          storageClass: "standard"
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "8Gi"
              limits:
                cpu: "4"
                memory: "16Gi"
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: prod-replica-set
                topologyKey: "topology.kubernetes.io/zone"
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 8