Problemas conhecidos no MongoDB Enterprise Kubernetes Operator
Nesta página
- Volume de EBS subprovisionado causa longo tempo de espera de IOPS
- O nome do ConfigMap
mongodb-enterprise-operator-member-list
é codificado mongos
As instâncias não atingem o estado Pronta após desativar a autenticação- Atualize as regras de firewall do Google para corrigir problemas de webhook
- Configurar o armazenamento persistente corretamente
- Remova recursos antes de remover o Kubernetes
- Crie namespaces separados para o Kubernetes Operator e os recursos do MongoDB
- HTTPS ativado após a implementação
- Não é possível atualizar o MongoDB Agent nos pods do aplicativo de banco de dados
- Não é possível extrair imagens do Enterprise Kubernetes Operator do IBM Cloud Paks
- Memória da máquina versus memória do container
Volume de EBS subprovisionado causa longo tempo de espera de IOPS
Se você usou kops para provisionar um cluster Kubernetes no AWS e estiver enfrentando um desempenho ruim e tempos de espera de IOPS altos, seu 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
Observação
Esse problema se aplica apenas a clusters fragmentados que atendem aos seguintes critérios:
Implementado usando o Kubernetes Operator 1.13.0
Usar autenticação X.509
Acesse kubernetes.io/tls segredos para certificados TLS para o MongoDB Agent
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:
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:
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.