Solucionar problemas do Kubernetes Operator

Obter o status de um recurso distribuído

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:

  • spec.backup.opLogStores

  • spec.backup.s3Stores

  • spec.backup.blockStores

• 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:

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

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

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

Revisar os registros

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.

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

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

kubectl get pods -n <metadata.namespace>

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

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

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

{{{ "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}}}

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

Verifique as mensagens do webhook de validação

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.

Ver todas MongoDB as especificações do recurso

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

kubectl get mdb -n <metadata.namespace>

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

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

Restaurar StatefulSet que não foi distribuído

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.

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

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.

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

Substituir um ConfigMap para refletir as alterações

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.

Remover componentes do Kubernetes

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

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

Criar uma nova reivindicação de volume persistente após a exclusão de um Pod

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>.

Desativar controles de recursos do Ops Manager

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.

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.

Remover recursos quando o operador Kubernetes falhar

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}"

Depurar um container com falha

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

Verificar se os nomes dos domínios em certificados TLS estão corretos

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.

Verificar a versão do MongoDB ao executar no modo local

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.

Falha na atualização usando kubectl ou oc

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.

Falha na atualização ao usar gráficos Helm

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.

Duas instâncias de operador após uma atualização

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:

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

Recuperar recurso devido a configuração de automação quebrada

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.

1
spec:
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.