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

  • La 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 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. Utilizar la arquitectura de registro recomendada para conservar los registros del Pod, incluso después de borrar 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 Webhook para evitar que los usuarios apliquen definiciones de recursos no válidas. El webhook rechaza las solicitudes invá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 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 MongoDB especificaciones de recursos

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 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 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 que deseas realizar un cambio recursivo inmediato, o necesitas 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>

Crear una Nueva Solicitud de Volumen Persistente después de borrar 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 recuperarte de este error, debes crear manualmente un nuevo PVC con el nombre del objeto PVC que corresponde a este pod de set de réplicas, como 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 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 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.

   Tu respuesta debe ser similar a:

   {
    "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. Actualizar el arreglo 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. 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 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

Cuando borras un recurso personalizado de MongoDB a través del operador de Kubernetes, este último se encarga de eliminar el despliegue en Cloud Manager u Ops Manager. Para obtener más información, consulta Eliminar un recurso de 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, 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 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 el spec.podSpec.podTemplate.spec le indica al contenedor que espere el número de segundos que especifique. En este ejemplo, el contenedor esperará durante 1 hora.

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

Un set de réplicas de MongoDB o un clúster puede no 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 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 en cada certificado tiene la siguiente sintaxis: pod-name.service-name.namespace.svc.cluster.local. Este nombre es diferente para cada Pod que aloje un nodo del set de réplicas o un clúster fragmentado.

Por ejemplo, para un nodo de un set de réplicas implementado en un Pod con el nombre rs-mongos-0-0, en el servicio de Kubernetes Operador denominado mongo-0 que se crea en el namespace por defecto mongodb, el FQDN es:

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

Para verificar si ha configurado correctamente los certificados TLS:

1. Ejecuta:

   kubectl logs -f <pod_name>

2. Comprueba los 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 set de réplicas o en Implementar un clúster.

Verifica la versión de MongoDB cuando se ejecuta 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 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 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 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. Repita 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. Repita 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 un estado Pending o Failed durante un período prolongado, el Operador de Kubernetes recupera automáticamente tus recursos MongoDB enviando la configuración de automatización a Ops Manager. Esto impide un bloqueo mutuo cuando el MongoDB Agent no puede implementar un cambio de configuración de automatización actualizado porque el StatefulSet está atascado en un estado Pending debido a un intento previo de implementación 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 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-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 Definir variables de entorno para un contenedor.