Solucionar problemas de un pod de base de datos en bucle de fallos en AlloyDB Omni para Kubernetes

Selecciona una versión de la documentación:

En esta página se describe cómo resolver problemas con AlloyDB Omni para Kubernetes cuando se dan las siguientes situaciones:

  • Tienes un clúster de base de datos en bucle de fallos en Kubernetes y conoces el nombre y el espacio de nombres de la base de datos, su instancia interna y el pod.
  • Necesitas acceder a un archivo del pod de la base de datos, pero el bucle de fallos impide el acceso.

Un pod de base de datos en bucle de fallos es un pod que se inicia, falla y se reinicia automáticamente de forma repetida por Kubernetes. Este ciclo continúa indefinidamente hasta que se resuelve el problema subyacente. La base de datos deja de estar disponible y se vuelve inestable durante este proceso.

Antes de empezar

Antes de seguir las instrucciones para solucionar problemas que se indican en este documento, prueba estas soluciones:

  • Si la alta disponibilidad está disponible, activa una conmutación por error. Con la alta disponibilidad, una instancia de espera asíncrona está lista para sustituir a la instancia principal.
  • Recuperar a partir de una copia de seguridad, si hay alguna disponible. Este enfoque es automático y menos propenso a errores.

No se puede acceder a los archivos de un pod de base de datos en bucle de fallos

Descripción: un pod de base de datos de tu clúster de Kubernetes entra en el estado CrashLoopBackOff. Este estado te impide usar kubectl exec para acceder al sistema de archivos del contenedor de la base de datos con fines de depuración.

Solución recomendada: para resolver este problema, detén temporalmente el bucle de fallos parcheando el StatefulSet del pod para anular el comando del contenedor. Antes de continuar, considera alternativas más sencillas, como activar una conmutación por error o restaurar una copia de seguridad, si están disponibles.

Para acceder al pod, sigue estos pasos:

  1. Pausa todos los recursos de AlloyDB Omni relacionados con el usuario para evitar que interfieran en el proceso de recuperación.

    1. Lista de todas las definiciones de recursos personalizados de Kubernetes de AlloyDB Omni:

      kubectl get crd | grep alloydbomni.dbadmin

    2. Revisa la lista de recursos de tu clúster de base de datos. Mantén una lista de los recursos que pausas para poder reactivarlos más adelante. Como mínimo, debes pausar el recurso dbclusters.alloydbomni.dbadmin.goog.

    3. Pausa cada recurso por separado añadiendo la ctrlfwk.internal.gdc.goog/pauseanotación.

      kubectl annotate RESOURCE_TYPE -n NAMESPACE RESOURCE_NAME ctrlfwk.internal.gdc.goog/pause=true

      Haz los cambios siguientes:

      • RESOURCE_TYPE: el tipo de recurso que se va a pausar. Por ejemplo, dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: el espacio de nombres del clúster de la base de datos.
      • RESOURCE_NAME: el nombre del recurso que se va a pausar.

  2. Pausa la instancia interna que gestiona el pod en bucle de fallos.

    1. Busca el nombre de la instancia interna.

      kubectl get instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.

    2. Pausar la instancia. La anotación ctrlfwk.internal.gdc.goog/pause=true indica al controlador de AlloyDB Omni que pause la gestión del recurso. De esta forma, el controlador no reconciliará ni cambiará automáticamente el recurso mientras realizas manualmente los pasos para solucionar el problema, como parchear el StatefulSet subyacente.

      kubectl annotate instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE INSTANCE_NAME ctrlfwk.internal.gdc.goog/pause=true

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.
      • INSTANCE_NAME: el nombre de la instancia que has encontrado.

  3. Evita que el pod entre en un bucle de fallos.

    Aplica un parche al StatefulSet del pod para anular el comando del contenedor principal. Este cambio impide que la aplicación se inicie y falle, lo que te permite acceder al pod.

    1. Confirma el nombre del pod en bucle de fallos.

      kubectl get pod -n NAMESPACE

      Sustituye NAMESPACE por el nombre del espacio de nombres que te interese.

    2. Busca el nombre del StatefulSet propietario del pod.

      kubectl get pod -n NAMESPACE POD_NAME -ojsonpath='{.metadata.ownerReferences[0].name}'

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.
      • POD_NAME: el nombre del pod en bucle de fallos.

    3. Aplica un parche a StatefulSet para sustituir el comando del contenedor de la base de datos por sleep infinity:

      kubectl patch statefulset STATEFULSET_NAME -n NAMESPACE --type='strategic' -p '
{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "name": "database",
            "command": ["sleep"],
            "args": ["infinity"],
            "livenessProbe": null,
            "startupProbe": null
          }
        ]
      }
    }
  }
}
'

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.
      • STATEFULSET_NAME: el nombre de la StatefulSet.

    4. Elimina el pod para aplicar el parche.

      kubectl delete pod -n NAMESPACE POD_NAME

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.
      • POD_NAME: el nombre del pod en bucle de fallos.

  4. Accede a la base de datos en el pod.

    kubectl exec -ti -n NAMESPACE POD_NAME -c database -- bash

    Haz los cambios siguientes:

    • NAMESPACE: el nombre del espacio de nombres que te interesa.
    • POD_NAME: el nombre del pod en bucle de fallos.

    Una vez que se inicia el nuevo pod, ejecuta el comando sleep en lugar de la aplicación de base de datos. Ahora puedes acceder a la shell del pod.

  5. Reanuda todos los componentes.

    Después de investigar, restaura el estado original quitando las anotaciones pause. Despausa los recursos en el orden inverso al que los pausaste. Por ejemplo, despausa la instancia antes de despausar el clúster de base de datos. Esta acción concilia los recursos y reinicia el pod de la base de datos con su comando original.

    1. En cada recurso que hayas pausado, elimina la anotación añadiendo un guion al nombre de la anotación. En el siguiente ejemplo se elimina la anotación de una instancia:

      kubectl annotate instances.alloydbomni.internal.dbadmin.goog -n NAMESPACE INSTANCE_NAME ctrlfwk.internal.gdc.goog/pause-

      Haz los cambios siguientes:

      • NAMESPACE: el nombre del espacio de nombres que te interesa.
      • INSTANCE_NAME: el nombre de la instancia que has encontrado en el paso anterior.

    2. Repite este proceso con todos los demás recursos que hayas pausado en el primer paso.