Imagens de Container

Arquitetura

A arquitetura dos containers estáticos e não estáticos difere significativamente e requer várias etapas para migrar de um para o outro. Para saber mais, consulte Migrar para containers estáticos e Migrar para containers não estáticos.

Arquitetura de container não estática

A arquitetura de contêiner não estático padrão pressupõe que você inicialize um contêiner de shell vazio, baixe e inicie o MongoDB Agent, que então baixa os binários para mongod e mongosh do Cloud Manager ou MongoDB Ops Manager.

clique para ampliar

Arquitetura de contêiner estático

A arquitetura de contêiner estático utiliza afuncionalidade de namespace compartilhado do Kubernetes para executar o MongoDB Agent como um processo separado para que ele possa controlar o ciclo de vida completo do mongod e evitar o download de arquivos por uma rede.

Os containers estáticos são mais seguros e simples do que os containers não estáticos. Os containers estáticos são imutáveis no tempo de execução. Além disso:

• Durante a execução, os containers estáticos não podem baixar binários ou executar scripts ou outros utilitários por meio de conexões de rede. Os containers estáticos só podem baixar arquivos de configuração de tempo de execução.

• Durante a execução, os containers estáticos não podem modificar nenhum arquivo, exceto as montagens do volume de armazenamento.

• Os containers estáticos não exigem que você verifique se há vulnerabilidades de segurança nos containers, ao contrário dos containers não estáticos que exigem verificação de segurança de containers. Se você usar containers estáticos, só poderá executar verificações de segurança nas próprias imagens de container, mas não em seus containers.

• Se você tiver um ambiente com lacuna de ar, os contêineres estáticos não exigem que você hospede o binário do MongoDB no servidor que hospeda o MongoDB Ops Manager ou outro servidor HTTPS .

• Você não pode executar scripts CMD extensivos para o container estático.

• Você não pode copiar arquivos entre containers estáticos usando initContainer.

Observação

Quando implantado como containers estáticos, um sistema do Kubernetes Operator consiste em dois containers - um container mongodb-agent e um container mongodb-enterprise-server. O recurso personalizado do banco de dados de dados MongoDB herda as definições de limite de recursos do contêiner mongodb-agent, que executa o processo mongod em um sistema de contêiner estático. Para modificar os limites de recursos do banco de banco de dados MongoDB , você deve especificar os limites de recursos desejados no mongodb-agent contêiner.

clique para ampliar

Limitações

Se você habilitar containers estáticos:

• Você deve Desabilitar Queryable Backups para que o Backup Daemon Service não tente baixar os binários do MongoDB do MongoDB Ops Manager, o que prejudica a natureza imutável dos contêineres estáticos.

• Com MongoDB Ops Manager, somente as versões 6.0.24, 7.0.5 ou posterior são compatíveis. O Kubernetes Operator usa automaticamente a versão correta do container do MongoDB Agent com base na versão do MongoDB Ops Manager selecionada para gerenciar uma sistema específica.

• Com o MongoDB Cloud Manager, sua versão do MongoDB Agent pode ficar atrasada em relação à versão mais recente do MongoDB Cloud Manager porque o operador Kubernetes não pode chamar o endpoint agentVersion no MongoDB Cloud Manager. Para garantir que seu MongoDB Agent esteja atualizado com o MongoDB Cloud Manager, você pode executar uma das seguintes ações:

  • Especifique uma versão compatível do MongoDB Agent na especificação de MongoDB do MongoDB substituindo o StatefulSet imagem de contêiner para o MongoDB Agent. Por exemplo:

    podSpec:
      podTemplate:
        spec:
          containers:
            - name: mongodb-agent-ubi
              Image: 12.0.29.7785-1_1.24.0

  • Atualize o Kubernetes Operator para a versão mais recente, que atualiza automaticamente o MongoDB Agent.

• Atualizar uma versão do MongoDB Atlas Triggers uma reinicialização contínua de todos os Pods, em ordem do último para o primeiro, e pode causar mais eleições, até o número de Pods. Isso vale para qualquer atualização que trigger uma reinicialização contínua.

• Você não poderá determinar se ocorreu uma atualização do MongoDB database a partir do MongoDB Agent. Quando o Kubernetes rotaciona Pods após uma atualização, o MongoDB Agent substitui o arquivo de status de integridade para que você não saiba pelo status de integridade que ocorreu uma alteração de versão, apenas o status de integridade atual.

Migrar para contêineres estáticos

Para migrar de contêineres não estáticos para estáticos, defina as variáveis de ambiente do MongoDB Agent e habilite os contêineres estáticos seguindo as etapas abaixo. Você também pode habilitar contêineres estáticos durante a instalação ou atualização.

kubectl apply -f mongodb-enterprise.yaml

oc apply -f mongodb-enterprise-openshift.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
  --set registry.pullPolicy='IfNotPresent'

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

Migrar para contêineres não estáticos

Para migrar de contêineres estáticos para não estáticos, desative os contêineres estáticos seguindo as etapas abaixo. Você também pode desabilitar contêineres estáticos durante a instalação ou atualização.

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"