Soluciona problemas de un Pod de base de datos en bucle de fallas 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 presentan las siguientes situaciones:

  • Tienes un clúster de base de datos en bucle de fallas 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 en el pod de la base de datos, pero el bucle de fallas impide el acceso.

Un Pod de base de datos en bucle de fallas 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 comenzar

Antes de seguir la guía para solucionar problemas de este documento, prueba estas soluciones:

  • Si la alta disponibilidad (HA) está disponible, activa una conmutación por error. Con la HA, una instancia en espera síncrona está lista para reemplazar la instancia principal.
  • Recuperar desde una copia de seguridad, si hay una disponible Este enfoque es automático y menos propenso a errores.

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

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

Corrección recomendada: Para resolver este problema, detén temporalmente el bucle de fallas aplicando un parche a StatefulSet del pod para anular el comando del contenedor. Antes de continuar, considera alternativas más simples, como activar una conmutación por error o recuperar datos de una copia de seguridad, si están disponibles.

Para acceder a la cápsula, sigue estos pasos:

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

    1. Enumera 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 reanudarlos más adelante. Como mínimo, debes pausar el recurso dbclusters.alloydbomni.dbadmin.goog.

    3. Pausa cada recurso por separado agregando la anotación ctrlfwk.internal.gdc.goog/pause.

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

      Reemplaza lo siguiente:

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

  2. Pausa la instancia interna que administra el pod en bucle de fallas.

    1. Busca el nombre de la instancia interna.

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

      Reemplaza lo siguiente:

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

    2. Pausa la instancia. La anotación ctrlfwk.internal.gdc.goog/pause=true le indica al controlador de AlloyDB Omni que pause la administración del recurso. Esto evita que el controlador concilie o cambie automáticamente el recurso mientras realizas manualmente los pasos para solucionar problemas, como aplicar parches al StatefulSet subyacente.

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

      Reemplaza lo siguiente:

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

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

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

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

      kubectl get pod -n NAMESPACE

      Reemplaza NAMESPACE, que es el nombre del espacio de nombres que te interesa.

    2. Busca el nombre del StatefulSet que posee el pod.

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

      Reemplaza lo siguiente:

      • NAMESPACE: Es el nombre del espacio de nombres que te interesa.
      • POD_NAME: Es el nombre del Pod en bucle de fallas.

    3. Aplica un parche a StatefulSet para reemplazar 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
          }
        ]
      }
    }
  }
}
'

      Reemplaza lo siguiente:

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

    4. Borra el Pod para aplicar el parche.

      kubectl delete pod -n NAMESPACE POD_NAME

      Reemplaza lo siguiente:

      • NAMESPACE: Es el nombre del espacio de nombres que te interesa.
      • POD_NAME: Es el nombre del Pod en bucle de fallas.

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

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

    Reemplaza lo siguiente:

    • NAMESPACE: Es el nombre del espacio de nombres que te interesa.
    • POD_NAME: Es el nombre del Pod en bucle de fallas.

    Después de que se inicia el nuevo pod, ejecuta el comando sleep en lugar de la aplicación de la base de datos. Ahora puedes acceder al shell del pod.

  5. Reanuda todos los componentes.

    Después de investigar, restablece el estado original quitando las anotaciones pause. Debes reanudar los recursos en el orden inverso en que los pausaste. Por ejemplo, reanuda la instancia antes de reanudar el clúster de base de datos. Esta acción reconcilia los recursos y reinicia el pod de la base de datos con su comando original.

    1. Para cada recurso que pausaste, quita la anotación agregando un guion al nombre de la anotación. En el siguiente ejemplo, se quita la anotación de una instancia:

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

      Reemplaza lo siguiente:

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

    2. Repite este proceso para todos los demás recursos que pausaste en el primer paso.