Solucionar problemas del operador de Kubernetes

Obtener el estado de un recurso implementado

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

• Para implementaciones de recursos de Ops Manager:

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

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

  • El status.backup.phase muestra el estado de la implementación del recurso del daemon de copias de seguridad.

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

  Nota

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

  • spec.backup.opLogStores

  • spec.backup.s3Stores

  • spec.backup.blockStores

• Para las 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

Mantener y revisar registros adecuados para ayudar a depurar problemas y supervisar la actividad del clúster. Use la arquitectura de registro recomendada para conservar los registros de Pod incluso después de que se borre un Pod.

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

kubectl logs -f deployment/mongodb-kubernetes-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

Revisar mensajes del 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.

Los roles ClusterRole y ClusterRoleBinding 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 creas una definición de recurso no válida, el webhook devuelve un mensaje similar al siguiente que describe el error en el 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 valida ese recurso. El Operador de Kubernetes no requiere el webhook de validación para crear o actualizar recursos.

Si omites el webhook de validación o si remueves el rol y la vinculación del webhook de la configuración por defecto, o si tienes privilegios insuficientes para ejecutar la configuración, el Operador de Kubernetes emitirá advertencias, ya que no se trata de errores críticos. Si el Operador de Kubernetes encuentra un error crítico, marca el recurso como Failed.

Ver todas las especificaciones de recursos de MongoDB

Para ver todas las especificaciones de recursos MongoDB 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 StatefulSet que no se pudo implementar.

Un Pod de StatefulSet puede quedarse bloqueado con un estado de Pending si encuentra un error durante el despliegue.

Pending Pods no se terminan automáticamente, incluso si se realizan y se aplican cambios de configuración para resolver el error.

Para devolver el StatefulSet a un estado saludable, aplica los cambios de configuración al recurso MongoDB en el estado Pending, y luego borra 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 recursos ya implementado ConfigMap usando el comando kubectl apply, ejecute:

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

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

Utilice este comando cuando desee realizar un cambio recursivo inmediato o cuando necesite actualizar archivos de recursos que no se pueden actualizar una vez inicializados.

Remover componentes de Kubernetes

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

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

Crea una nueva Solicitud de Volumen Persistente tras borrar un pod

Si borras accidentalmente el Pod del set de réplicas de MongoDB 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 solucionar este error, debe crear manualmente un nuevo PVC con el nombre del objeto PVC que corresponda a este Pod del conjunto de réplicas, como por ejemplo data-<replicaset-pod-name>.

Deshabilitar controles de funcionalidades de Ops Manager

Cuando gestionas un Proyecto de Ops Manager a través del operador de Kubernetes, este ubica la EXTERNALLY_MANAGED_LOCK política de control de funcionalidad en el Proyecto. Esta política desactiva ciertas funcionalidades en la aplicación Ops Manager que pueden comprometer la configuración del operador de Kubernetes. Si necesitas utilizar estas funcionalidades bloqueadas, puedes eliminar la política mediante la API de controles de funcionalidad, realizar cambios en la aplicación Ops Manager, y luego restablecer la política original a través de la API.

1. Recupere las directivas 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 añadir estas políticas nuevamente al proyecto.

   Importante

   Tenga en cuenta los campos y valores resaltados en la siguiente respuesta de muestra. Debes enviar estos mismos campos y valores en pasos posteriores cuando remuevas y agregues políticas de control de funciones.

   El campo externalManagementSystem.version corresponde a la versión de Kubernetes operador. Debes enviar exactamente el mismo valor de campo en tus solicitudes más tarde en esta tarea.

   Su respuesta se parece a lo siguiente:

   {
    "created": "2020-02-25T04:09:42Z",
    "externalManagementSystem": {
      "name": "mongodb-kubernetes-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. Actualiza el array policies con una lista vacía:

   Nota

   Los valores que proporciones para el objeto externalManagementSystem, como el campo externalManagementSystem.version, deben coincidir con los valores recibidos en la respuesta del 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-kubernetes-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": []
          }'

   Las funcionalidades previamente bloqueadas ya están disponibles en la aplicación Ops Manager.

3. Realiza los cambios en la aplicación Ops Manager.

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

   Nota

   Los valores que proporciones para el objeto externalManagementSystem, como el campo externalManagementSystem.version, deben coincidir con los valores recibidos en la respuesta del 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-kubernetes-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": [
              {
                "disabledParams": [],
                "policy": "EXTERNALLY_MANAGED_LOCK"
              },
              {
                "disabledParams": [],
                "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
              }
            ]
          }'

   Las funcionalidades ahora están bloqueadas de nuevo, lo que impide realizar más cambios por medio de la aplicación Ops Manager. Sin embargo, el operador de Kubernetes conserva cualquier cambio que hayas realizado en la aplicación de Ops Manager mientras las funcionalidades estuvieron disponibles.

Remover recursos cuando el operador de Kubernetes falle

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

Sin embargo, la eliminación de recursos podría fallar en Kubernetes. Por ejemplo, si el Operador de Kubernetes falla antes de que borres el recurso de MongoDB, debes remover manualmente las implementaciones y borrar sus proyectos en Cloud Manager u Ops Manager.

Para remover los recursos de Ops Manager o Cloud Manager manualmente:

1. Desactivar los controles de funcionalidades de Ops Manager.

2. Remover una implementación de Ops Manager o Cloud Manager en el Proyecto utilizando la Interfaz de Usuario o la API.

   Elimina una implementación en la interfaz de usuario de Ops Manager o Cloud Manager. En Ops Manager, remueva una implementación de automatización y remueva una implementación de supervisión.

   En Cloud Manager, elimine una implementación de Automatización y elimine una implementación de Monitorización.

   Como alternativa, remueve una implementación utilizando 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 Ops Manager API, o en la solicitud de Cloud Manager API.

   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 eliminar las instantáneas 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 en Cloud Manager.

   Como alternativa, puede eliminar un proyecto mediante la solicitud a la API de Ops Manager o la solicitud a la 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 que falla

Un contenedor podría fallar con un error que provoque que Kubernetes reinicie dicho contenedor en un bucle.

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

1. En tu editor de texto preferido, abre el recurso de MongoDB que necesitas reparar.

2. A este recurso, añade una colección podSpec que se asemeje a la siguiente.

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

   El comando sleep en spec.podSpec.podTemplate.spec le indica al contenedor que espere la cantidad de segundos que especifique. En este ejemplo, el contenedor espera 1 horas.

3. Aplica este cambio al recurso.

   kubectl apply -f <resource>.yaml

4. Invoca la shell dentro del contenedor.

   kubectl exec -it <pod-name> bash

Verifica la corrección de los nombres de dominio en los certificados TLS

Un conjunto de réplicas o un clúster fragmentado de MongoDB puede fallar al alcanzar el estado READY si el certificado TLS no es válido.

Cuando configuras TLS para **sets de réplicas** de MongoDB o **clústeres**, verifica que especifiques 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 miembro del conjunto de réplicas o del clúster fragmentado, el nombre común, también conocido como nombre de dominio, del certificado de ese miembro debe coincidir con el FQDN del pod en el que está implementado dicho miembro del clúster.

El nombre FQDN en cada certificado tiene la siguiente sintaxis: pod-name.service-name.namespace.svc.cluster.local. 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 nombre rs-mongos-0-0, en el servicio Operador de Kubernetes llamado mongo-0 que se crea en el espacio de nombres predeterminado mongodb, 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. Compruebe si hay 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 pestaña TLS-Encrypted Connections de Implementar un conjunto de réplicas o en Implementar un clúster fragmentado.

Verifica la versión de MongoDB cuando se ejecuta en modo local.

MongoDB CustomResource puede fallar al alcanzar un estado Running si Ops Manager se ejecuta en Modo Local y se especifica una versión de MongoDB que no existe, o una versión válida de MongoDB para la cual Ops Manager desplegado en modo local no descargó un fichero correspondiente de MongoDB.

Si especifica una versión de MongoDB que no existe, o una versión de MongoDB válida para la que Ops Manager no pudo descargar un fichero de MongoDB, aunque los Pods puedan alcanzar el estado READY, 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 MongoDB Agent no pudo descargar correctamente el binario correspondiente de MongoDB en el directorio /var/lib/mongodb-mms-automation. En los casos en que el MongoDB Agent pueda descargar correctamente el binario de MongoDB para la versión especificada de MongoDB, este directorio contiene una carpeta de binarios de MongoDB, como mongodb-linux-x86_64-8.0.0.

Para verificar si existe una carpeta binaria de MongoDB:

1. Especifica el nombre del Pod para este comando:

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

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

3. Si no puede localizar una carpeta binaria de MongoDB, copie el fichero de MongoDB en el Volumen Persistente de Ops Manager para cada set de réplicas de Ops Manager desplegado.

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. Elimine la implementación antigua de Kubernetes Operator.

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

   Nota

   Eliminar la implementación de Kubernetes Operator no afecta al ciclo de vida de los recursos de MongoDB.

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

La actualización falla usando Helm Charts

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

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

Para resolver este error:

1. Elimine la implementación antigua de Kubernetes Operator.

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

   Nota

   Eliminar la implementación de Kubernetes Operator no afecta al ciclo de vida de los recursos de MongoDB.

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

Recuperar recurso debido a una configuración de automatización rota

Si un recurso personalizado permanece en estado Pending o Failed durante un período prolongado, Kubernetes Operator recupera automáticamente los recursos MongoDB enviando la configuración de automatización a Ops Manager. Esto evita un bloqueo cuando el agente de MongoDB no puede enviar una configuración de automatización actualizada porque StatefulSet se encuentra en estado Pending debido a un envío previo de una configuración de automatización no válida.

Para configurar la recuperación automática, define las siguientes variables de entorno en tu archivo mongodb-kubernetes.yaml:

• MDB_AUTOMATIC_RECOVERY_ENABLE para activar o desactivar la recuperación automática de hasta MongoDB recursos por pod.

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

1
spec:
2
  template:
3
     spec:
4
        serviceAccountName: mongodb-kubernetes-operator
5
        containers:
6
          - name: mongodb-kubernetes-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 la sección Definir variables de entorno para un contenedor.