Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise

Solucionar problemas do Kubernetes Operator

Nesta página

Importante

Esta seção é somente para sistemas de cluster Kubernetes únicos. Para sistemas do MongoDB de vários clusters Kubernetes, consulte Solucionar problemas de sistemas de vários clusters Kubernetes.

Para localizar o status de um recurso distribuído com o Kubernetes Operator, invoque um dos seguintes comandos:

  • Para sistemas de recursos do Ops Manager:

    kubectl get <resource-name> -n <metadata.namespace> -o yaml
    • O campo status.applicationDatabase.phase exibe o status do sistema do recurso do aplicativo de banco de dados.

    • O status.backup.phase exibe o status da implantação de recurso do daemon da cópia de segurança.

    • O campo status.opsManager.phase exibe o status do sistema do recurso do Ops Manager.

    Observação

    O controlador do Cloud Manager ou do Ops Manager observa os recursos do banco de dados definidos nas seguintes configurações:

  • Para implantações de recursos do MongoDB:

    kubectl get mdb <resource-name> -n <metadata.namespace> -o yaml

    O campo status.phase exibe o status do sistema do recurso do MongoDB.

Os seguintes pares de valores-chave descrevem os status de implantação de recursos:

Chave
Valor
message
Mensagem explicando por que o recurso está em um estado Pending ou Failed.
phase
Status
Significado
Pending

O operador Kubernetes não consegue reconciliar o estado de implantação do recurso. Isso acontece quando uma reconciliação expira ou quando o operador Kubernetes exige que você tome medidas para que o recurso entre em um estado de execução.

Se um recurso estiver pendente porque atingiu o tempo limite da reconciliação, o Kubernetes Operator tenta reconciliar o estado do recurso em 10 segundos.

Pending

O Kubernetes Operator está reconciliando o estado do recurso.

Os recursos entram neste estado depois que você cria ou atualizá-os, ou se o Kubernetes Operator estiver tentando reconciliar um recurso anteriormente em um estado Failed.

O Kubernetes Operator tenta reconciliar o estado do recurso em 10 segundos.

Running
O recurso está sendo executado corretamente.
Failed

O recurso não está sendo executado corretamente. O campo message fornece mais informações.

O Kubernetes Operator tenta reconciliar o estado do recurso em 10 segundos.

lastTransition
Carimbo 8601 de data/hora na ISO formato de data e hora em UTC quando a última reconciliação aconteceu.
link
URL de implantação no Ops Manager.
backup.statusName
Se você habilitou backups contínuos com spec.backup.mode no Kubernetes para seu recurso MongoDB, este campo indicará o status do backup, como backup.statusName:"STARTED". Os valores possíveis são STARTED, STOPPED e TERMINATED.
Campos específicos de recursos
Para obter descrições desses campos, consulte Especificação do recurso do banco de dados MongoDB.

Exemplo

Para visualizar o status de um conjunto de réplicas denominado my-replica-set no namespace developer, execute:

kubectl get mdb my-replica-set -n developer -o yaml

Se o my-replica-set estiver em execução, você verá:

status:
lastTransition: "2019-01-30T10:51:40Z"
link: http://ec2-3-84-128-187.compute-1.amazonaws.com:9080/v2/5c503a8a1b90141cbdc60a77
members: 1
phase: Running
version: 4.2.2-ent

Se o my-replica-set não estiver em execução, você deverá visualizar:

status:
lastTransition: 2019-02-01T13:00:24Z
link: http://ec2-34-204-36-217.compute-1.amazonaws.com:9080/v2/5c51c040d6853d1f50a51678
members: 1
message: 'Failed to create/update replica set in Ops Manager: Status: 400 (Bad Request),
Detail: Something went wrong validating your Automation Config. Sorry!'
phase: Failed
version: 4.2.2-ent

Mantenha e faça a revisão de registros para depurar problemas e monitorar a atividade de clusters. Use a arquitetura de registro recomendada para reter Pod registros mesmo após a exclusão de um Pod.

O Kubernetes Operator grava nos registros do Pod usando um encapsulador que converte os registros do MongoDB Agent e os componentes do mongod no Pod do sistema de banco de dados em uma entrada de registro estruturada no seguinte formato JSON :

{ "logType": "<log-type>", "contents": "<log line from a log file>" }

O Kubernetes Operator é compatível com os seguintes tipos de registro:

  • automation-agent-verbose

  • automation-agent-stderr

  • mongodb

  • mongodb-audit

  • agent-launcher-script

  • automation-agent

  • monitoring-agent

  • backup-agent

Ao ler os logs de um container de banco de dados, o Kubernetes Operator gera a entrada JSON estruturada que contém registros de diferentes fontes.

Para analisar os registros do Kubernetes Operator, invoque este comando:

kubectl logs -f deployment/mongodb-enterprise-operator -n <metadata.namespace>

Você também pode verificar os logs do Ops Manager para ver se algum problema foi relatado ao Ops Manager.

Para ver quais pods estão disponíveis, primeiro invoque este comando:

kubectl get pods -n <metadata.namespace>

Dica

Veja também:

Documentação do Kubernetes sobre kubectl get.

Se você deseja restringir sua revisão a um Pod específico , você pode invocar este comando:

kubectl logs <podName> -n <metadata.namespace>

Exemplo

Se o seu conjunto de réplicas estiver rotulado como myrs, execute:

kubectl logs myrs-0 -n <metadata.namespace>

Isso retorna o log do agente de automação para esse conjunto de réplicas.

Você pode restringir sua revisão a um tipo de registro específico. Por exemplo, o comando a seguir retorna os registros de auditoria dos registros do Kubernetes do Pod especificado, especificando o tipo de registro mongodb-audit:

kubectl logs -c mongodb-enterprise-database replica-set-0 | jq -r 'select(.logType == "mongodb-audit") | .contents'

O comando gera uma entrada semelhante à seguinte saída:

{{{ "atype":"startup","ts":{"$date":"2023-08-30T20:43:54.649+00:00"},"uuid":{"$binary":"oDcPEY69R1yiUtpMupaXOQ==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}
{"atype":"startup","ts":{"$date":"2023-08-30T20:44:05.466+00:00"},"uuid":{"$binary":"OUbUWC1DQM6k/Ih4hKZq4g==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}}}

Para incluir registros de auditoria nos registros do Pod do Kubernetes, adicione a seguinte configuração do additionalMongodConfig.auditLog à sua definição de recurso. Você pode atualizar o nome do arquivo fornecido conforme necessário.

spec:
additionalMongodConfig:
auditLog:
destination: file
format: JSON
path: /var/log/mongodb-mms-automation/mongodb-audit.log

O operador Kubernetes usa um webhook de validação para evitar que os usuários apliquem definições de recursos inválidas. O webhook rejeita solicitações inválidas.

O ClusterRole e ClusterRoleBinding para o webhook estão incluídos nos arquivos de configuração padrão que você aplica durante a instalação. Para criar a função e a associação, é necessário ter privilégios de administrador do cluster.

Se você criar uma definição de recurso inválida, o webhook gera uma mensagem semelhante à seguinte que descreve o erro para a shell:

error when creating "my-ops-manager.yaml":
admission webhook "ompolicy.mongodb.com" denied the request:
shardPodSpec field is not configurable for application databases as
it is for sharded clusters and appdb replica sets

Quando o Kubernetes Operator concilia cada recurso, ele também o valida. Ele não exige o webhook de validação para criar nem atualizar recursos.

Se você omitir o webhook de validação, ou se remover a função e a vinculação do webhook da configuração padrão, ou tiver privilégios insuficientes para executar a configuração, o Kubernetes Operator emitirá avisos, pois esses não são erros críticos. Se o Kubernetes Operator encontrar um erro crítico, ele marcará o recurso como Failed.

Observação

Implementações do GKE (Google Kubernetes Engine)

GKE (Google Kubernetes Engine) tem um problema conhecido com o webhook ao distribuir em clusters privados. Para saber mais, veja Como atualizar regras de firewall do Google para corrigir problemas de webhook.

Para ver todas as especificações do recurso MongoDB no namespace fornecido:

kubectl get mdb -n <metadata.namespace>

Exemplo

Para ler detalhes sobre o recurso standalone do dublin, execute este comando:

kubectl get mdb dublin -n <metadata.namespace> -o yaml

Isso retorna a seguinte resposta:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"mongodb.com/v1","kind":"MongoDB","metadata":{"annotations":{},"name":"dublin","namespace":"mongodb"},"spec":{"credentials":"credentials","persistent":false,"podSpec":{"memory":"1Gi"},"project":"my-om-config","type":"Standalone","version":"4.0.0-ent"}}
clusterDomain: ""
creationTimestamp: 2018-09-12T17:15:32Z
generation: 1
name: dublin
namespace: mongodb
resourceVersion: "337269"
selfLink: /apis/mongodb.com/v1/namespaces/mongodb/mongodbstandalones/dublin
uid: 7442095b-b6af-11e8-87df-0800271b001d
spec:
credentials: my-credentials
type: Standalone
persistent: false
project: my-om-config
version: 4.2.2-ent

Um pod StatefulSet pode travar com um status de se Pending encontrar um erro durante o sistema.

Pending Pods não encerram automaticamente, mesmo que você faça e aplique alterações de configuração para resolver o erro.

Para retornar o StatefulSet a um estado saudável, aplique as alterações de configuração ao recurso MongoDB no estado Pending e, em seguida, exclua esses Pods.

Exemplo

Um sistema host tem diversos Pods em execução:

kubectl get pods
my-replica-set-0 1/1 Running 2 2h
my-replica-set-1 1/1 Running 2 2h
my-replica-set-2 0/1 Pending 0 2h

my-replica-set-2 está preso no estágio Pending. Para obter mais informações sobre o erro, execute:

kubectl describe pod my-replica-set-2
<describe output omitted>
Warning FailedScheduling 15s (x3691 over 3h) default-scheduler
0/3 nodes are available: 1 node(s) had taints that the pod
didn't tolerate, 2 Insufficient memory.

A saída indica um erro na alocação de memória.

Atualizar as alocações de memória no recurso do MongoDB é insuficiente, pois o pod não termina automaticamente depois de aplicar atualizações de configurações.

Para corrigir esse problema, atualize e aplique a configuração e, em seguida, exclua o pod suspenso:

vi <my-replica-set>.yaml
kubectl apply -f <my-replica-set>.yaml
kubectl delete pod my-replica-set-2

Depois que esse Pod suspenso for excluído, os outros Pods serão reiniciados com sua nova configuração como parte da atualização contínua do Statefulset.

Observação

Para saber mais sobre este problema, consulte Problema do Kubernetes 67250.

Se você não puder modificar nem reimplantar um arquivo de recurso ConfigMap já implantado usando o comando kubectl apply, execute:

kubectl replace -f <my-config-map>.yaml

Isso exclui e recria o arquivo de recurso ConfigMap.

Este comando é útil se você deseja fazer uma alteração recursiva e imediata, ou se precisa atualizar arquivos de recursos que não podem ser atualizados depois de inicializados.

Importante

Para remover qualquer componente, você precisa das seguintes permissões:

  • mongodb-enterprise-operator-mongodb-webhook

  • mongodb-enterprise-operator-mongodb-certs

  • mongodb-enterprise-operator-mongodb-webhook-binding

  • mongodb-enterprise-operator-mongodb-certs

Para remover quaisquer instâncias que o Kubernetes distribuiu, é necessário usar o Kubernetes.

Importante

Exemplo

Para remover uma única instância do MongoDB que você criou usando o Kubernetes:

kubectl delete mdb <name> -n <metadata.namespace>

Para remover todas as instâncias do MongoDB que você criou usando o Kubernetes:

kubectl delete mdb --all -n <metadata.namespace>

Para remover o operador Kubernetes:

  1. Remover todos os recursos do Kubernetes:

    kubectl delete mdb --all -n <metadata.namespace>
  2. Remover o Kubernetes Operator:

    kubectl delete deployment mongodb-enterprise-operator -n <metadata.namespace>

Para remover o CustomResourceDefinitions:

  1. Remover todos os recursos do Kubernetes:

    kubectl delete mdb --all -n <metadata.namespace>
  2. Remova CustomResourceDefinitions:

    kubectl delete crd mongodb.mongodb.com
    kubectl delete crd mongodbusers.mongodb.com
    kubectl delete crd opsmanagers.mongodb.com

Para remover o namespace:

  1. Remover todos os recursos do Kubernetes:

    kubectl delete mdb --all -n <metadata.namespace>
  2. Remova namespace:

    kubectl delete namespace <metadata.namespace>

Se você excluir acidentalmente o Pod do conjunto de réplicas do MongoDB e sua Declaração de volume persistente, o operador Kubernetes não conseguirá reprogramar o Pod do MongoDB e emitirá a seguinte mensagem de erro:

scheduler error: pvc not found to schedule the pod

Para recuperar deste erro, você deve criar manualmente um novo PVC com o nome do objeto PVC que corresponde a esse Pod do conjunto de réplicas, como data-<replicaset-pod-name>.

Quando você gerencia um projeto do MongoDB Ops Manager por meio do Kubernetes Operator, o Kubernetes Operator coloca a política de controle de recursos EXTERNALLY_MANAGED_LOCK no projeto. Essa política desabilita determinados recursos no aplicativo MongoDB Ops Manager que podem comprometer a configuração do seu Kubernetes Operator. Se você precisar usar esses recursos bloqueados, poderá remover a política por meio da APIde controles de recursos, fazer alterações no aplicativo MongoDB Ops Manager e, em seguida, restaurar a política original por meio da API.

Aviso

O procedimento a seguir permite que você use recursos no aplicativo Ops Manager que, de outra forma, seriam bloqueados pelo Kubernetes Operator.

  1. Recupere as políticas de controle de funcionalidades do seu projeto do Ops Manager.

    curl --user "{USERNAME}:{APIKEY}" --digest \
    --header "Accept: application/json" \
    --header "Content-Type: application/json" \
    --include \
    --request GET "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true"

    Salve a resposta que a API gera. Depois de fazer alterações no aplicativo de Ops Manager, adicione as políticas de volta ao projeto.

    Importante

    Observe os campos e valores destacados na seguinte resposta de amostra. Você deve enviar estes mesmos campos e valores em etapas posteriores ao remover e adicionar políticas de controle da funcionalidades.

    O campo externalManagementSystem.version corresponde à versão do Kubernetes Operator. Você deve enviar o mesmo valor de campo exato em suas solicitações mais tarde nesta tarefa.

    Sua resposta deve ser semelhante a:

    {
    "created": "2020-02-25T04:09:42Z",
    "externalManagementSystem": {
    "name": "mongodb-enterprise-operator",
    "systemId": null,
    "version": "1.4.2"
    },
    "policies": [
    {
    "disabledParams": [],
    "policy": "EXTERNALLY_MANAGED_LOCK"
    },
    {
    "disabledParams": [],
    "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
    }
    ],
    "updated": "2020-02-25T04:10:12Z"
    }
  2. Atualize a array policies com uma lista vazia:

    Observação

    Os valores fornecidos para o objeto externalManagementSystem, como o campo externalManagementSystem.version, devem corresponder aos valores recebidos na resposta na etapa 1.

    curl --user "{USERNAME}:{APIKEY}" --digest \
    --header "Accept: application/json" \
    --header "Content-Type: application/json" \
    --include \
    --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
    --data
    '{
    "externalManagementSystem": {
    "name": "mongodb-enterprise-operator",
    "systemId": null,
    "version": "1.4.2"
    },
    "policies": []
    }'

    As funcionalidades anteriormente bloqueadas agora estão disponíveis no aplicativo de Ops Manager.

  3. Faça suas alterações no aplicativo Ops Manager.

  4. Atualize a array policies com as políticas de controle de funcionalidades originais:

    Observação

    Os valores fornecidos para o objeto externalManagementSystem, como o campo externalManagementSystem.version, devem corresponder aos valores recebidos na resposta na etapa 1.

    curl --user "{USERNAME}:{APIKEY}" --digest \
    --header "Accept: application/json" \
    --header "Content-Type: application/json" \
    --include \
    --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
    --data
    '{
    "externalManagementSystem": {
    "name": "mongodb-enterprise-operator",
    "systemId": null,
    "version": "1.4.2"
    },
    "policies": [
    {
    "disabledParams": [],
    "policy": "EXTERNALLY_MANAGED_LOCK"
    },
    {
    "disabledParams": [],
    "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
    }
    ]
    }'

    Os recursos agora estão bloqueados novamente, impedindo que você faça mais alterações por meio do aplicativo Ops Manager. No entanto, o operador Kubernetes retém todas as alterações feitas no aplicativo Ops Manager enquanto os recursos estavam disponíveis.

Quando você exclui um recurso personalizado do MongoDB por meio do Kubernetes Operator, o Kubernetes Operator lida com a remoção da implantação no Cloud Manager ou no MongoDB Ops Manager. Para saber mais, consulte Remover um recurso MongoDB .

No entanto, a remoção de recursos pode falhar no Kubernetes. Por exemplo, se o Kubernetes Operator falhar antes de excluir o recurso MongoDB , você deverá remover manualmente as implantações e excluir seus projetos no Cloud Manager ou MongoDB Ops Manager.

Para remover recursos do MongoDB Ops Manager ou Cloud Manager manualmente:

  1. Desative os controles de recursos MongoDB Ops Manager .

  2. Remova uma implantação do MongoDB Ops Manager ou Cloud Manager no projeto usando a UI ou a API.

    Remova um sistema na interface do usuário do MongoDB Ops Manager ou Cloud Manager . No MongoDB Ops Manager, remova uma implantação da Automação e remova uma implantação do Monitoramento.

    No Cloud Manager, remova uma implantação da Automação e remova uma implantação do Monitoramento.

    Como alternativa, remova uma implantação usando a API para atualizar a configuração de automação no MongoDB Ops Manager ou no Cloud Manager com uma configuração vazia usando a solicitação de MongoDB Ops Manager API API do ou a Cloud Manager API solicitação de do .

    Execute o comando semelhante ao seguinte exemplo do MongoDB Ops Manager :

    curl --user "{USERNAME}:{APIKEY}" --digest \
    --header "Content-Type: application/json" \
    --include \
    --request PUT "https://{OPSMANAGER-HOST}/api/public/v1.0/groups/{PROJECT-ID}/automationConfig" \
    --data '{}'

    Observação

    Excluir um recurso MongoDB para o qual você habilitou o backup não exclui os snapshots do recurso. Você deve excluir snapshots no MongoDB Ops Manager ou excluir snapshots no Cloud Manager.

  3. Exclua um projeto do MongoDB Ops Manager ou Cloud Manager usando a UI ou a API. Exclua um projeto no MongoDB Ops Manager ou exclua um projeto no Cloud Manager.

    Como alternativa, exclua um projeto usando a MongoDB Ops Manager API solicitação da API do ou a Cloud Manager API solicitação da do .

    Execute o comando semelhante ao seguinte exemplo do MongoDB Ops Manager :

    curl --user "{USERNAME}:{APIKEY}" --digest \
    --request DELETE "{OPSMANAGER-HOST}/api/public/v1.0/groups/${PROJECT-ID}"

Um container pode falhar com um erro que resulta em Kubernetes reiniciando o container em um loop.

Talvez seja necessário interagir com esse container para inspecionar arquivos ou executar comandos. Isso exige que você evite que o container seja reiniciado.

  1. No editor de texto de sua preferência, abra o recurso MongoDB que você precisa reparar.

  2. Para este recurso, adicione uma collection podSpec que se assemelha ao seguinte.

    podSpec:
    podTemplate:
    spec:
    containers:
    - name: mongodb-enterprise-database
    command: ['sh', '-c', 'echo "Hello!" && sleep 3600' ]

    O sono comando no spec.podSpec.podTemplate.spec instrui o container a aguardar pelo número de segundos que você especifica. Neste exemplo, o container aguardará 1 hora.

  3. Aplique esta alteração ao recurso.

    kubectl apply -f <resource>.yaml
  4. Invoque a shell dentro do container.

    kubectl exec -it <pod-name> bash

Um conjunto de réplicas ou cluster fragmentado do MongoDB pode não atingir o estado READY se o certificado TLS for inválido.

Ao configurar TLS para conjuntos de réplicas ou clusters fragmentados do MongoDB, certifique-se de especificar um certificado válido.

Se você não especificar o Nome de Domínio correto para cada certificado TLS , os logs do Operador Kubernetes poderão conter uma mensagem de erro semelhante à seguinte, em que foo.svc.local é o Nome de Domínio especificado incorretamente para o Pod do membro do cluster:

TLS attempt failed : x509: certificate is valid for foo.svc.local,
not mongo-0-0.mongo-0.mongodb.svc.cluster.local

Cada certificado deve incluir um nome de domínio válido.

Para cada conjunto de réplicas ou nó de cluster fragmentado, o nome comum, também conhecido como nome de domínio, do certificado desse nó deve corresponder ao FQDN do pod em que esse nó do cluster está distribuído.

O nome FQDN em cada certificado contém a seguinte sintaxe: pod-name.service-name.namespace.svc.cluster.local. Este nome é diferente para cada Pod que hospeda um nó do conjunto de réplicas ou cluster fragmentado.

Por exemplo, para um nó de um conjunto de réplicas distribuído em um Pod com o nome rs-mongos-0-0, no serviço do Kubernetes Operator denominado mongo-0 que é criado no namespace padrão do mongodb, o FQDN é:

rs-mongos-0-0.mongo-0.mongodb.svc.cluster.local

Para verificar se você configurou corretamente os certificados TLS:

  1. Executar:

    kubectl logs -f <pod_name>
  2. Verifique se há mensagens relacionadas ao TLS nos arquivos de log do Kubernetes Operator.

Para saber mais sobre os requisitos do certificado TLS , consulte os pré-requisitos na aba TLS-Encrypted Connections em Distribuir um conjunto de réplicas ou em Distribuir um cluster fragmentado.

CustomResource do MongoDB podem não atingir um estado de Running se o Ops Manager estiver sendo executado no Modo Local e você especificar uma versão do MongoDB que não existe ou uma versão válida do MongoDB para a qual o Ops Manager distribuído no modo local não baixou um arquivo do MongoDB correspondente.

Se você especificar uma versão do MongoDB que não existe, ou uma versão válida do MongoDB para a qual o Ops Manager não pôde baixar um arquivo do MongoDB, mesmo que os Pods possam atingir o estado READY, os logs do Kubernetes Operator conterão uma mensagem de erro semelhante à seguinte:

Failed to create/update (Ops Manager reconciliation phase):
Status: 400 (Bad Request), Detail:
Invalid config: MongoDB <version> is not available.

Isso pode significar que o MongoDB Agent não conseguiu baixar corretamente um binário do MongoDB correspondente para o diretório /var/lib/mongodb-mms-automation. Nos casos em que o MongoDB Agent pode baixar o binário do MongoDB para a versão especificada do MongoDB corretamente, esse diretório conterá uma pasta de binários do MongoDB, como mongodb-linux-x86_64-4.4.0.

Para conferir se uma pasta binária do MongoDB está presente:

  1. Especifique o nome do Pod para este comando:

    kubectl exec --stdin --tty $<pod_name> /bin/sh
  2. Verifique se uma pasta binária MongoDB está presente no diretório /var/lib/mongodb-mms-automation.

  3. Se você não conseguir localizar uma pasta binária do MongoDB, copie o arquivo MongoDB para o Volume persistente do Ops Manager para cada conjunto de réplicas do Ops Manager distribuído.

Você poderá receber o seguinte erro ao atualizar o Kubernetes Operator:

Forbidden: updates to statefulset spec for fields other than
'replicas', 'template', and 'updateStrategy' are forbidden

Para solucionar este erro:

  1. Remova a antiga implantação do operador Kubernetes.

    kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

    Observação

    Remover a implantação do operador Kubernetes não afeta o ciclo de vida de seus recursos MongoDB.

  2. Repita o comando kubectl apply para atualizar para a nova versão do operador Kubernetes.

Você poderá receber o seguinte erro ao atualizar o Kubernetes Operator:

Error: UPGRADE FAILED: cannot patch "mongodb-enterprise-operator"
with kind Deployment: Deployment.apps "mongodb-enterprise-operator"
is invalid: ... field is immutable

Para solucionar este erro:

  1. Remova a antiga implantação do operador Kubernetes.

    kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

    Observação

    Remover a implantação do operador Kubernetes não afeta o ciclo de vida de seus recursos MongoDB.

  2. Repita o comando helm para atualizar para a nova versão do operador Kubernetes.

Depois de fazer a atualização da versão 1.10 ou anterior do Kubernetes Operator para a versão 1.11 ou posterior, o cluster do Kubernetes poderá ter duas instâncias distribuídas do Kubernetes Operator.

Use o comando get pods para visualizar os pods do Kubernetes Operator:

Observação

Se você implantou o Kubernetes Operator no OpenShift, substitua os comandos do kubectl nesta seção por comandos do oc.

kubectl get pods

Se a resposta contiver um enterprise-operator e um pod mongodb-enterprise-operator, seu cluster terá duas instâncias do operador Kubernetes:

NAME READY STATUS RESTARTS AGE
enterprise-operator-767884c9b4-ltkln 1/1 Running 0 122m
mongodb-enterprise-operator-6d69686679-9fzs7 1/1 Running 0 68m

Você pode remover com segurança a implantação do enterprise-operator. Execute o seguinte comando para removê-la:

kubectl delete deployment/enterprise-operator

Se um recurso personalizado permanecer em um estado Pending ou Failed por um longo período de tempo, Kubernetes Operator recuperará automaticamente seus recursos MongoDB enviando a configuração de automação para o MongoDB Ops Manager. Isso evita um bloqueio quando o MongoDB Agent não consegue enviar uma alteração de configuração de automação atualizada porque o StatefulSet está preso em um estado Pending devido a um envio anterior de uma configuração de automação inválida.

Para configurar a recuperação automática, defina as seguintes variáveis ambientais no seu arquivo mongodb-enterprise.yaml:

  • MDB_AUTOMATIC_RECOVERY_ENABLE para habilitar ou desabilitar a recuperação automática de recursos do MongoDB por Pod.

  • MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S para definir o número de segundos em que um recurso personalizado pode permanecer em um estado Pending ou Failed antes de o Kubernetes Operator recuperar automaticamente seus recursos MongoDB.

Exemplo

1spec:
2 template:
3 spec:
4 serviceAccountName: mongodb-enterprise-operator
5 containers:
6 - name: mongodb-enterprise-operator
7 image: <operatorVersionUrl>
8 imagePullPolicy: <policyChoice>
9 env:
10 - name: MDB_AUTOMATIC_RECOVERY_ENABLE
11 value: true
12 - name: MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S
13 value: 1200

Para aprender como definir variáveis de ambiente, consulte Como definir variáveis de ambiente para um contêiner.

Voltar

Notas de versão