Solucionar problemas del operador de Kubernetes

Obtener el estado de un recurso implementado

Para encontrar el estado de un recurso implementado con el operador de Kubernetes, invoque uno de los siguientes comandos:

• Para implementaciones de recursos de Ops Manager:

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

  • El status.applicationDatabase.phase El campo muestra el estado de implementación del recurso de la base de datos de la aplicación.

  • El status.backup.phase muestra el estado de implementación del recurso del demonio de respaldo.

  • El campo status.opsManager.phase muestra el estado de implementación del recurso Ops Manager.

  Nota

  El controlador de Cloud Manager o Ops Manager supervisa los recursos de la base de datos definidos en las siguientes configuraciones:

  • spec.backup.opLogStores

  • spec.backup.s3Stores

  • spec.backup.blockStores

• Para implementaciones de recursos de MongoDB:

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

  El campo status.phase muestra el estado de implementación del recurso MongoDB.

Los siguientes pares clave-valor describen los estados de implementación 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: 8.0.0

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

Revisar los registros

Mantenga y revise los registros adecuados para depurar problemas y supervisar la actividad del clúster. Utilice la arquitectura de registro recomendada para conservar los registros del pod incluso después de eliminarlo.

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

Comprobar mensajes desde el webhook de validación

El operador de Kubernetes utiliza un webhook de validación para evitar que los usuarios apliquen definiciones de recursos no válidas. El webhook rechaza las solicitudes no válidas.

El rol de clúster y el enlace del rol de clúster para el webhook se incluyen en los archivos de configuración predeterminados que se aplican durante la instalación. Para crear el rol y el enlace, debe tener privilegios de administrador del clúster.

Si crea una definición de recurso no válida, el webhook devuelve un mensaje similar al siguiente que describe el error al 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

Cuando el operador de Kubernetes concilia cada recurso, también lo valida. El operador de Kubernetes no requiere el webhook de validación para crear o actualizar recursos.

Si omite el webhook de validación, elimina su rol y enlace de la configuración predeterminada o no tiene suficientes privilegios para ejecutar la configuración, el operador de Kubernetes emite advertencias, ya que no se trata de errores críticos. Si detecta un error crítico, marca el recurso como Failed.

Ver todas MongoDB las especificaciones del recurso

Para ver todas las MongoDB especificaciones de recursos en el espacio de nombres proporcionado:

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

Restaurar un StatefulSet que no se pudo implementar

Un pod StatefulSet puede bloquearse con un estado de Pending si encuentra un error durante la implementación.

Pending Los pods no finalizan automáticamente, incluso si realiza y aplica cambios de configuración para resolver el error.

Para que el StatefulSet vuelva a un estado saludable, aplique los cambios de configuración al recurso MongoDB en el estado Pending y luego elimine esos 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

Reemplazar un ConfigMap para reflejar los cambios

Si no puede modificar o volver a implementar un archivo de recurso ya implementado ConfigMap mediante el comando kubectl apply, ejecute:

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

Esto elimina y vuelve a crear el archivo de recursos ConfigMap.

Este comando es útil en los casos en los que desea realizar un cambio recursivo inmediato o necesita actualizar archivos de recursos que no se pueden actualizar una vez inicializados.

Eliminar componentes de Kubernetes

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

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

Crear una nueva reclamación de volumen persistente después de eliminar un pod

Si elimina accidentalmente el conjunto de réplicas de MongoDB Pod y su reclamo de volumen persistente, el operador de Kubernetes no puede reprogramar el Pod de MongoDB y emite el siguiente mensaje de error:

scheduler error: pvc not found to schedule the pod

Para recuperarse de este error, debe crear manualmente una nueva PVC con el nombre del objeto PVC que corresponde a este Pod de conjunto de réplicas,data-<replicaset-pod-name> como.

Deshabilitar los controles de funciones de Ops Manager

Al administrar un proyecto de Ops Manager mediante el operador de Kubernetes, este implementa la EXTERNALLY_MANAGED_LOCK política de control de funciones en el proyecto. Esta política deshabilita ciertas funciones de la aplicación Ops Manager que podrían comprometer la configuración del operador de Kubernetes. Si necesita usar estas funciones bloqueadas, puede eliminar la política mediante la API de control de funciones, realizar cambios en la aplicación Ops Manager y, a continuación, restaurar la política original mediantela API.

1. Recupere las políticas de control de funciones para su proyecto de 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"

   Guarde la respuesta que devuelve la API. Después de realizar cambios en la aplicación Ops Manager, debe volver a agregar estas políticas al proyecto.

   Importante

   Tenga en cuenta los campos y valores resaltados en la siguiente respuesta de ejemplo. Debe enviar estos mismos campos y valores en pasos posteriores al eliminar y agregar políticas de control de funciones.

   El campo externalManagementSystem.version corresponde a la versión del operador de Kubernetes. Debe enviar exactamente el mismo valor de campo en sus solicitudes más adelante en esta tarea.

   Su respuesta debería ser similar 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. Actualice la policies matriz con una lista vacía:

   Nota

   Los valores que proporcione para el objeto externalManagementSystem, como el campo externalManagementSystem.version, deben coincidir con los valores que recibió en la respuesta en el Paso 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": []
          }'

   Las funciones anteriormente bloqueadas ahora están disponibles en la aplicación Ops Manager.

3. Realice sus cambios en la aplicación Ops Manager.

4. Actualice la policies matriz con las políticas de control de características originales:

   Nota

   Los valores que proporcione para el objeto externalManagementSystem, como el campo externalManagementSystem.version, deben coincidir con los valores que recibió en la respuesta en el Paso 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"
              }
            ]
          }'

   Las funciones están bloqueadas de nuevo, lo que impide realizar más cambios a través de la aplicación Ops Manager. Sin embargo, el operador de Kubernetes conserva los cambios realizados en la aplicación Ops Manager mientras las funciones estaban disponibles.

Eliminar recursos cuando falla el operador de Kubernetes

Al eliminar un recurso personalizado de MongoDB mediante el operador de Kubernetes, este gestiona la eliminación de la implementación en Cloud Manager u Ops Manager. Para obtener más información, consulte Eliminar un MongoDB recurso.

Sin embargo, la eliminación de recursos podría fallar en Kubernetes. Por ejemplo, si el operador de Kubernetes falla antes de eliminar el recurso de MongoDB, deberá eliminar manualmente las implementaciones y sus proyectos en Cloud Manager u Ops Manager.

Para eliminar recursos de Ops Manager o Cloud Manager manualmente:

1. Desactivar los controles de funcionalidades de Ops Manager.

2. Elimine una implementación de Ops Manager o Cloud Manager en el proyecto mediante la interfaz de usuario o la API.

   Elimine una implementación en la interfaz de Ops Manager o Cloud Manager. En Ops Manager, elimine una implementación de Automationy de Monitoring.

   En Cloud Manager, elimina una implementación de la automatización y elimina una implementación de supervisión.

   Como alternativa, elimine una implementación mediante la API para actualizar la configuración de automatización en Ops Manager o Cloud Manager con una configuración vacía mediante la solicitud de API de Ops Manager o la solicitud de API de Cloud Manager.

   Ejecute el comando similar al siguiente ejemplo de 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 '{}'

   Nota

   Eliminar un recurso de MongoDB para el que se habilitó la copia de seguridad no elimina las instantáneas del recurso. Debe eliminarlas en Ops Manager o en Cloud Manager.

3. Elimine un proyecto de Ops Manager o Cloud Manager mediante la interfaz de usuario o la API. Elimine un proyecto en Ops Manager o Cloud Manager.

   Como alternativa, elimine un proyecto mediante la solicitud de API de Ops Manager o la solicitud de API de Cloud Manager.

   Ejecute el comando similar al siguiente ejemplo de Ops Manager:

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

Depurar un contenedor con fallos

Un contenedor puede fallar con un error que haga que Kubernetes reinicie ese contenedor en un bucle.

Es posible que necesite interactuar con ese contenedor para inspeccionar archivos o ejecutar comandos. Esto requiere que evite que el contenedor se reinicie.

1. En su editor de texto preferido, abra el recurso MongoDB que necesita reparar.

2. A este recurso, agregue una colección podSpec que se parezca a la siguiente.

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

   El comando sleep en indica al contenedor que espere los segundos especificados. En este ejemplo, el contenedor spec.podSpec.podTemplate.spec esperará 1 horas.

3. Aplicar este cambio al recurso.

   kubectl apply -f <resource>.yaml

4. Invocar el shell dentro del contenedor.

   kubectl exec -it <pod-name> bash

Verificar la exactitud de los nombres de dominio en los certificados TLS

Es posible que un conjunto de réplicas de MongoDB o un clúster fragmentado no alcance el READY estado si el certificado TLS no es válido.

Al configurar TLS para conjuntos de réplicas o clústeres fragmentados de MongoDB, verifique que especifique un certificado válido.

Si no especifica el nombre de dominio correcto para cada certificado TLS, los registros del operador de Kubernetes pueden contener un mensaje de error similar al siguiente, donde foo.svc.local es el nombre de dominio especificado incorrectamente para el pod del miembro del clúster:

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

Cada certificado debe incluir un nombre de dominio válido.

Para cada conjunto de réplicas o miembro del clúster fragmentado, el nombre común, también conocido como nombre de dominio, para el certificado de ese miembro debe coincidir con el FQDN del pod en el que está implementado este miembro del clúster.

El nombre FQDN de cada certificado tiene la siguientepod-name.service-name.namespace.svc.cluster.local sintaxis:. Este nombre es diferente para cada pod que aloja un miembro del conjunto de réplicas o un clúster fragmentado.

Por ejemplo, para un miembro de un conjunto de réplicas implementado en un pod con el rs-mongos-0-0 nombre, en el servicio de operador de Kubernetes llamado mongo-0 que se crea en el espacio de nombres mongodb predeterminado, el FQDN es:

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

Para comprobar si ha configurado correctamente los certificados TLS:

1. Ejecuta:

   kubectl logs -f <pod_name>

2. Busque mensajes relacionados con TLSen los archivos de registro del operador de Kubernetes.

Para obtener más información sobre los requisitos del certificado TLS, consulte los requisitos previos en la TLS-Encrypted Connections pestaña en Implementar un conjunto de réplicas o en Implementar un clúster fragmentado.

Verificar la versión de MongoDB al ejecutar en modo local

Es posible que MongoDB no alcance un CustomResource Running estado si Ops Manager se ejecuta en modo local y usted especifica una versión de MongoDB que no existe o una versión válida de MongoDB para la cual Ops Manager implementado en modo local no descargó un archivo MongoDB correspondiente.

Si especifica una versión de MongoDB que no existe, o una versión de MongoDB válida para la cual Ops Manager no pudo descargar un archivo de MongoDB, aunque los pods puedan alcanzar el READY estado, los registros del operador de Kubernetes contienen un mensaje de error similar al siguiente:

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

Esto podría significar que el Agente de MongoDB no pudo descargar correctamente el binario correspondiente de MongoDB al directorio /var/lib/mongodb-mms-automation. Si el Agente de MongoDB puede descargar correctamente el binario de MongoDB para la versión especificada, este directorio contiene una carpeta de binarios de MongoDB, como mongodb-linux-x86_64-8.0.0.

Para comprobar si hay una carpeta binaria de MongoDB presente:

1. Especifique el nombre del Pod con este comando:

   kubectl exec --stdin --tty $<pod_name> /bin/sh

2. Compruebe si hay una carpeta binaria de MongoDB en el directorio /var/lib/mongodb-mms-automation.

3. Si no puede encontrar una carpeta binaria de MongoDB, copie el archivo de MongoDB en el volumen persistente de Ops Manager para cada conjunto de réplicas de Ops Manager implementado.

La actualización falla al usar kubectl o oc

Puedes recibir el siguiente error al actualizar el Operador de Kubernetes:

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

Para resolver este error:

1. Eliminar la antigua implementación del operador de Kubernetes.

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

   Nota

   Eliminar la implementación del operador de Kubernetes no afecta el ciclo de vida de sus recursos de MongoDB.

2. Repita el comando kubectl apply para actualizar a la nueva versión del operador de Kubernetes.

La actualización falla al usar las cartas de Helm

Puedes recibir el siguiente error al actualizar el Operador de Kubernetes:

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

Para resolver este error:

1. Eliminar la antigua implementación del operador de Kubernetes.

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

   Nota

   Eliminar la implementación del operador de Kubernetes no afecta el ciclo de vida de sus recursos de MongoDB.

2. Repita el comando helm para actualizar a la nueva versión del operador de Kubernetes.

Dos instancias de operador después de una actualización

Después de actualizar de la versión 1.10 o anterior de Kubernetes Operator a una versión 1.11 o posterior, su clúster de Kubernetes podría tener dos instancias de Kubernetes Operator implementadas.

Utilice el comando get pods para ver sus pods de operador de Kubernetes:

kubectl get pods

Si la respuesta contiene un pod enterprise-operator y un pod mongodb-enterprise-operator, su clúster tiene dos instancias de operador de 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

Puede eliminar la implementación enterprise-operator de forma segura. Ejecute el siguiente comando para eliminarla:

kubectl delete deployment/enterprise-operator

Recuperar recursos debido a una configuración de automatización defectuosa

Si un recurso personalizado permanece en estado Pending o Failed durante un período prolongado, Kubernetes Operator recupera MongoDB automáticamente sus recursos enviando la configuración de automatización a Ops Manager. Esto evita un bloqueo cuando el agente de MongoDB no puede enviar un cambio actualizado en la configuración de automatización porque el StatefulSet está bloqueado en Pending estado debido a una transferencia previa de una configuración de automatización no válida.

Para configurar la recuperación automática, define las siguientes variables ambientales en el archivo mongodb-enterprise.yaml:

• MDB_AUTOMATIC_RECOVERY_ENABLE para habilitar o deshabilitar la recuperación automática de MongoDB recursos por pod.

• MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S para establecer la cantidad de segundos que un recurso personalizado puede permanecer en un Pending Failed estado o antes de que el operador de Kubernetes recupere automáticamente sus MongoDB recursos.

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 a definir variables de entorno, consulte Definir variables de entorno para un contenedor.