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 la implementación del recurso de 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 ClusterRole y ClusterRoleBinding para el webhook están incluidos en los archivos de configuración por defecto que se aplican durante la instalación. Para crear el rol y la vinculación, debes tener privilegios de administrador de 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 StatefulSet que no se pudo implementar.

Un StatefulSet Pod puede quedarse colgado con un estado de Pending si encuentra un error durante la implementación.

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.

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 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 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. Recupera las políticas de control de funciones para tu 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. Realiza los cambios en la aplicación Ops Manager.

4. Actualizar el arreglo policies con las políticas de control de funcionalidades 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, 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

   Borrar un recurso de MongoDB para el que activaste las copias de seguridad no borra los snapshots del recurso. Debe borrar instantáneas en Ops Manager, o borrar instantáneas en Cloud Manager.

3. Elimina un proyecto de Ops Manager o Cloud Manager mediante la interfaz de usuario o la API. Eliminar un proyecto en Ops Manager, o eliminar un proyecto en Cloud Manager.

   Alternativamente, elimina un proyecto utilizando la solicitud de la API de Ops Manager, o la solicitud de 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 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. 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 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 especificas 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 nodo 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 set de réplicas o nodo de clúster fragmentado, el nombre común, también conocido como nombre de dominio, del certificado de ese nodo debe coincidir con el FQDN del pod en el que se implementa este nodo 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 aprender más información sobre los requisitos de los certificados TLS, consulte los prerrequisitos en 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.

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 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 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, consulta Definir Variables de Entorno para un Contenedor.