Résoudre les problèmes liés à un pod de base de données en boucle de plantage dans AlloyDB Omni pour Kubernetes

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 base 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.
  • Récupérez-le à partir d'une sauvegarde, si 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.

Solution recommandée : pour résoudre ce problème, arrêtez temporairement la boucle de plantage en corrigeant le StatefulSet du pod afin de remplacer la commande du conteneur. Avant de continuer, envisagez des alternatives plus simples, comme 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 veille 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. Affichez la liste de toutes les définitions de ressources personnalisées Kubernetes AlloyDB Omni :

      kubectl get crd | grep alloydbomni.dbadmin

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

    3. Mettez en veille 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 à suspendre (par exemple, dbclusters.alloydbomni.dbadmin.goog).
      • NAMESPACE : espace de noms du cluster de bases de données.
      • RESOURCE_NAME : nom de la ressource à suspendre.

  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 l'instance en veille. L'annotation ctrlfwk.internal.gdc.goog/pause=true indique au contrôleur AlloyDB Omni de suspendre 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, comme corriger le 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 boucler sur les plantages.

    Corrigez le StatefulSet du pod pour 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 par le nom de l'espace de noms qui vous intéresse.

    2. Recherchez le nom de l'StatefulSet propriétaire du 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. Corrigez le 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 devez réactiver les ressources dans l'ordre inverse de leur suspension. 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 suspendue, supprimez l'annotation en ajoutant un tiret 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 cette procédure pour toutes les autres ressources que vous avez mises en veille lors de la première étape.