Résoudre les problèmes liés à un pod de base de données en boucle de plantage dans AlloyDB Omni à l'aide de l'orchestrateur de conteneurs

Sélectionnez une version de la documentation :

Cette page explique comment résoudre les problèmes liés à AlloyDB Omni pour Kubernetes lorsque vous rencontrez les situations suivantes :

  • Vous disposez d'un cluster de bases de données en boucle de plantage dans Kubernetes, et vous connaissez le nom et l'espace de noms de la base de données, son instance interne et le pod.
  • Vous devez accéder à un fichier sur le pod de base de données, mais la boucle de plantage vous en empêche.

Un pod de base de données en boucle de plantage est un pod qui démarre, plante et est ensuite redémarré automatiquement par Kubernetes. Ce cycle se poursuit indéfiniment jusqu'à ce que le problème sous-jacent soit résolu. La base de données devient indisponible et instable pendant ce processus.

Avant de commencer

Avant de suivre les conseils de dépannage de ce document, essayez les solutions suivantes :

  • Si la haute disponibilité est disponible, déclenchez un basculement. Avec la haute disponibilité, une instance de secours synchrone est prête à remplacer l'instance principale.
  • Effectuez une récupération à partir d'une sauvegarde, si elle est disponible. Cette approche est automatisée et moins sujette aux erreurs.

Impossible d'accéder aux fichiers sur un pod de base de données en boucle de plantage

Description : un pod de base de données de votre cluster Kubernetes passe à l'état CrashLoopBackOff. Cet état vous empêche d'utiliser kubectl exec pour accéder au système de fichiers du conteneur de base de données à des fins de débogage.

Correction recommandée : pour résoudre ce problème, arrêtez temporairement la boucle de plantage en appliquant un correctif au StatefulSet du pod afin de remplacer la commande du conteneur. Avant de continuer, envisagez des alternatives plus simples, telles que le déclenchement d'un basculement ou la récupération à partir d'une sauvegarde, si elles sont disponibles.

Pour accéder au pod, procédez comme suit :

  1. Mettez en pause toutes les ressources AlloyDB Omni associées et destinées aux utilisateurs pour éviter qu'elles n'interfèrent avec le processus de récupération.

    1. Répertoriez toutes les définitions de ressources personnalisées Kubernetes AlloyDB Omni :

      kubectl get crd | grep alloydbomni.dbadmin

    2. Consultez la liste des ressources de votre cluster de bases de données. Conservez une liste des ressources que vous mettez en pause afin de pouvoir les réactiver ultérieurement. Vous devez au moins mettre en pause la ressource dbclusters.alloydbomni.dbadmin.goog.

    3. Mettez en pause chaque ressource séparément en ajoutant l'annotation ctrlfwk.internal.gdc.goog/pause.

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

      Remplacez les éléments suivants :

      • RESOURCE_TYPE: type de ressource à mettre en pause, par exemple, dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: espace de noms du cluster de bases de données.
      • RESOURCE_NAME: nom de la ressource à mettre en pause.

  2. Mettez en pause l'instance interne qui gère le pod en boucle de plantage.

    1. Recherchez le nom de l'instance interne.

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

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.

    2. Mettez en pause l'instance. L'annotation ctrlfwk.internal.gdc.goog/pause=true indique au contrôleur AlloyDB Omni de mettre en pause la gestion de la ressource. Cela empêche le contrôleur de réconcilier ou de modifier automatiquement la ressource pendant que vous effectuez manuellement des étapes de dépannage, telles que l'application d'un correctif au StatefulSet sous-jacent.

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

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.
      • INSTANCE_NAME: nom de l'instance que vous avez trouvée.

  3. Empêchez le pod de se mettre en boucle de plantage.

    Appliquez un correctif au StatefulSet du pod afin de remplacer la commande du conteneur principal. Cette modification empêche l'application de démarrer et de planter, ce qui vous permet d'accéder au pod.

    1. Confirmez le nom du pod en boucle de plantage.

      kubectl get pod -n NAMESPACE

      Remplacez NAMESPACE, qui correspond au nom de l'espace de noms qui vous intéresse.

    2. Recherchez le nom du StatefulSet qui possède le pod.

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

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.
      • POD_NAME: nom du pod en boucle de plantage.

    3. Appliquez un correctif au StatefulSet pour remplacer la commande du conteneur de base de données par 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
          }
        ]
      }
    }
  }
}
'

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.
      • STATEFULSET_NAME: nom du StatefulSet.

    4. Supprimez le pod pour appliquer le correctif.

      kubectl delete pod -n NAMESPACE POD_NAME

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.
      • POD_NAME: nom du pod en boucle de plantage.

  4. Accédez à la base de données dans le pod.

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

    Remplacez les éléments suivants :

    • NAMESPACE: nom de l'espace de noms qui vous intéresse.
    • POD_NAME: nom du pod en boucle de plantage.

    Une fois le nouveau pod démarré, il exécute la commande sleep au lieu de l'application de base de données. Vous pouvez désormais accéder au shell du pod.

  5. Réactivez tous les composants.

    Après avoir effectué votre enquête, restaurez l'état d'origine en supprimant les annotations pause. Vous réactivez les ressources dans l'ordre inverse de leur mise en pause. Par exemple, réactivez l'instance avant de réactiver le DBCluster. Cette action réconcilie les ressources et redémarre le pod de base de données avec sa commande d'origine.

    1. Pour chaque ressource que vous avez mise en pause, supprimez l'annotation en ajoutant un trait d'union au nom de l'annotation. L'exemple suivant supprime l'annotation d'une instance :

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

      Remplacez les éléments suivants :

      • NAMESPACE: nom de l'espace de noms qui vous intéresse.
      • INSTANCE_NAME: nom de l'instance que vous avez trouvée à l'étape précédente.

    2. Répétez ce processus pour toutes les autres ressources que vous avez mises en pause à la première étape.