Problemas conhecidos no MongoDB Enterprise Kubernetes Operator

Volume de EBS subprovisionado causa longo tempo de espera de IOPS

Se você usou kops para provisionar um Kubernetes cluster Kubernetes no Amazon Web Amazon Web Services Services e está enfrentando problemas de desempenho ruins e tempos de espera de IOPS altos, o volume do Elastic Block Store (EBS) pode estar subprovisionado.

Para melhorar o desempenho, aumente a proporção de armazenamento para IOPS do seu volume de EBS. Por exemplo, se o seu banco de dados for 500 GB, aumente o IOPS para 1500, uma proporção 3:1 por GB. Para saber mais sobre como aumentar o IOPS,consulte a documentação do Amazon Web Services.

O nome mongodb-enterprise-operator-member-list do ConfigMap está codificado

Quando você executa o plugin kubectl mongodb , como durante o procedimento de início rápido de vários Kubernetes-cluster, o plugin cria um ConfigMap padrão denominado mongodb-enterprise-operator-member-list. Este ConfigMap contém todos os membros da implantação MongoDB do cluster multi-Kubernetes. Você não pode alterar o nome do ConfigMap. Para saber mais sobre os sinalizadores e ações do plugin -in, consulte Referência do plugin -in doMongoDB .

mongos As instâncias não atingem o estado Pronta após desativar a autenticação

Se você desabilitar a autenticação definindo spec.security.auth.enabled para false, os Pods mongos nunca atingirão um estado ready .

Como solução alternativa, exclua cada Pod mongos em seu sistema.

Execute o seguinte comando para listar todos os seus Pods:

kubectl get pods

Para cada Pod com um nome que contenha mongos, exclua-o com o seguinte comando:

kubectl delete pod <podname>

Quando você exclui um Pod, o Kubernetes o recria. Cada Pod que o Kubernetes recria recebe a configuração atualizada e pode atingir um estado READY . Para confirmar que todos os seus mongos Pods são READY, execute o seguinte comando:

kubectl get pods -n <metadata.namespace>

Uma resposta como a seguinte indica que todos os seus mongos Pods são READY:

NAME                                           READY   STATUS    RESTARTS   AGE
mongodb-enterprise-operator-6495bdd947-ttwqf   1/1     Running   0          50m
my-sharded-cluster-0-0                         1/1     Running   0          12m
my-sharded-cluster-1-0                         1/1     Running   0          12m
my-sharded-cluster-config-0                    1/1     Running   0          12m
my-sharded-cluster-config-1                    1/1     Running   0          12m
my-sharded-cluster-mongos-0                    1/1     Running   0          11m
my-sharded-cluster-mongos-1                    1/1     Running   0          11m
om-0                                           1/1     Running   0          42m
om-db-0                                        2/2     Running   0          44m
om-db-1                                        2/2     Running   0          43m
om-db-2                                        2/2     Running   0          43m

Atualize as regras de firewall do Google para corrigir problemas de webhook

Quando você implementa o Kubernetes Operator no GKE (Google Kubernetes Engine) clusters privados, os MongoDB recursos ou a criação do recurso MongoDBOpsManager pode expirar. A seguinte mensagem pode aparecer nos registros: Error setting state to reconciling: Timeout: request did not complete within requested timeout 30s.

O Google configura firewalls para restringir o acesso aos seus pods do Kubernetes . Para usar o serviço de webhook, adicione uma nova regra de firewall para conceder GKE (Google Kubernetes Engine) controle o acesso do plano ao seu serviço de webhook.

O serviço de webhook do Kubernetes Operator é executado na porta 443.

Configurar o armazenamento persistente corretamente

Se não houver volumes persistentes disponível quando você cria um recurso, o Pod resultante permanece no estado transitório e o operador falha (após 20 tentativas) com o seguinte erro:

Failed to update Ops Manager automation config: Some agents failed to register

Para evitar esse erro:

• Fornece Volumes Persistentes ou

• Configurar persistent : false para o recurso

Apenas para testes, você também pode definir persistent : false. Isso não deve ser usado na produção, pois os dados não são preservados entre as reinicializações.

Remova recursos antes de remover o Kubernetes

Às vezes, o Ops Manager pode particionar do Kubernetes. Isso ocorre principalmente quando os recursos do Kubernetes são removidos manualmente. O Ops Manager pode continuar exibindo um agente de automação que foi desligado.

Se você quiser remover implantações do MongoDB no Kubernetes, use a especificação de recursos para excluir recursos primeiro, para que não haja agentes de automação inativos.

Para solucionar quaisquer problemas que possam ocorrer, consulte:

• Remover um recurso MongoDB

• Desativar controles de recursos do Ops Manager

• Remover recursos quando o operador Kubernetes falhar

Crie namespaces separados para o Kubernetes Operator e os recursos do MongoDB

A melhor estratégia é criar o Kubernetes Operator e seus recursos em diferentes namespaces para que as seguintes operações funcionem corretamente:

kubectl delete pods --all

ou

kubectl delete namespace mongodb

Se o Kubernetes Operator e os recursos estiverem no mesmo mongodb namespace do , o operador também seria removido na mesma operação. Isso significaria que não poderia limpar as configurações, o que teria que ser feito no aplicativo MongoDB Ops Manager .

HTTPS ativado após a implementação

Recomendamos que você habilite o HTTPS antes de implantar seus recursos do Ops Manager. No entanto, se você habilitar o HTTPS após a implantação, seus recursos managed não poderão mais se comunicar com o Ops Manager e o Kubernetes Operator relatará o status dos seus recursos como Failed.

Para resolver este problema, você deve excluir seus Pods executando o seguinte comando para cada Pod:

kubectl delete pod <replicaset-pod-name>

Após a exclusão, o Kubernetes reinicia automaticamente os Pods excluídos. Durante esse período, o recurso fica inacessível e incorre em tempo de inatividade.

Não é possível atualizar o MongoDB Agent nos pods do aplicativo de banco de dados

Você não pode usar o MongoDB Ops Manager para atualizar os MongoDB Agent que são executados nos pods do banco de dados de aplicativos. A versão do MongoDB Agent que é executada nesses Pods é incorporada na imagem do Docker do Banco de Dados do Aplicativo.

Você pode usar o Kubernetes Operator para atualizar a versão do MongoDB Agent nos Pods do banco de dados de aplicativo, à medida que o MongoDB publica novas imagens.

Não é possível extrair imagens do Enterprise Kubernetes Operator do IBM Cloud Paks

Se você extrair as imagens do Kubernetes Operator de um registro de container hospedado no IBM Cloud Paks, o IBM Cloud Paks altera os nomes das imagens adicionando um SHA de resumo aos nomes oficiais das imagens. Esta ação resulta em mensagens de erro do operador Kubernetes semelhantes às seguintes:

Failed to apply default image tag "cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@
sha256:10.14.24.6505-1": couldn't parse image reference "cp.icr.io/cp/cpd/
ibm-cpd-mongodb-agent@sha256:10.14.24.6505-1": invalid reference format

Como uma solução alternativa, atualize a definição de recurso do reconhecimento de data center da aplicação do Ops Manager em spec.applicationDatabase.podSpec.podTemplate para especificar os novos nomes para as imagens do Kubernetes Operator que contêm os SHAs de resumo, semelhantes ao exemplo a seguir.

applicationDatabase:
  # The version specified must match the one in the image provided in the `mongod` field
  version: 4.4.11-ubi8
  members: 3
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-agent
            image: 'cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@sha256:689df23cc35a435f5147d9cd8a697474f8451ad67a1e8a8c803d95f12fea0b59'

Memória da máquina versus memória do container

O agente de automação no Cloud Manager e no Ops Manager relata o uso de memória do host (RAM) em vez do uso de memória do container do Kubernetes.