Risolvi i problemi relativi a un pod di database in crash in AlloyDB Omni per Kubernetes

Seleziona una versione della documentazione:

Questa pagina descrive come risolvere i problemi relativi ad AlloyDB Omni per Kubernetes quando si verificano le seguenti situazioni:

  • Hai un cluster di database in crashlooping in Kubernetes e conosci il nome e lo spazio dei nomi del database, la sua istanza interna e il pod.
  • Devi accedere a un file sul pod del database, ma il ciclo di arresti anomali impedisce l'accesso.

Un pod di database crashlooping è un pod che viene avviato, si arresta in modo anomalo e viene riavviato automaticamente da Kubernetes. Questo ciclo continua all'infinito finché il problema sottostante non viene risolto. Durante questa procedura, il database diventa non disponibile e instabile.

Prima di iniziare

Prima di seguire le indicazioni per la risoluzione dei problemi riportate in questo documento, prova queste soluzioni:

  • Se è disponibile l'alta disponibilità (HA), attiva un failover. Con l'alta disponibilità, un'istanza in standby sincrona è pronta a sostituire l'istanza principale.
  • Esegui il ripristino da un backup, se disponibile. Questo approccio è automatizzato e meno soggetto a errori.

Impossibile accedere ai file su un pod di database in crashloop

Descrizione:un pod di database nel cluster Kubernetes entra in uno stato CrashLoopBackOff. Questo stato impedisce di utilizzare kubectl exec per accedere al file system del container del database per il debug.

Correzione consigliata: per risolvere questo problema, interrompi temporaneamente il ciclo di arresti anomali applicando una patch al StatefulSet del pod per ignorare il comando del container. Prima di procedere, valuta alternative più semplici, come l'attivazione di un failover o il ripristino da un backup, se disponibili.

Per accedere al pod, segui questi passaggi:

  1. Metti in pausa tutte le risorse AlloyDB Omni correlate rivolte agli utenti per impedire che interferiscano con il processo di recupero.

    1. Elenca tutte le definizioni di risorse personalizzate di AlloyDB Omni Kubernetes:

      kubectl get crd | grep alloydbomni.dbadmin
      
    2. Esamina l'elenco delle risorse per il cluster di database. Tieni un elenco delle risorse che metti in pausa per poterle riattivare in un secondo momento. Come minimo, devi mettere in pausa la risorsa dbclusters.alloydbomni.dbadmin.goog.

    3. Metti in pausa ogni risorsa separatamente aggiungendo l'annotazione ctrlfwk.internal.gdc.goog/pause.

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

      Sostituisci quanto segue:

      • RESOURCE_TYPE: il tipo di risorsa da mettere in pausa, ad esempio dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: lo spazio dei nomi del cluster di database.
      • RESOURCE_NAME: il nome della risorsa da mettere in pausa.
  2. Metti in pausa l'istanza interna che gestisce il pod in crashloop.

    1. Trova il nome dell'istanza interna.

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

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
    2. Metti in pausa l'istanza. L'annotazione ctrlfwk.internal.gdc.goog/pause=true indica al controller AlloyDB Omni di sospendere la gestione della risorsa. In questo modo, il controller non riconcilia o modifica automaticamente la risorsa mentre esegui manualmente i passaggi per la risoluzione dei problemi, ad esempio l'applicazione di patch al StatefulSet sottostante.

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

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
      • INSTANCE_NAME: il nome dell'istanza che hai trovato.
  3. Impedisci al pod di entrare in un ciclo di arresti anomali.

    Applica una patch al StatefulSet del pod per eseguire l'override del comando del container principale. Questa modifica impedisce l'avvio e l'arresto anomalo dell'applicazione, consentendoti di accedere al pod.

    1. Conferma il nome del pod in crashloop.

      kubectl get pod -n NAMESPACE
      

      Sostituisci NAMESPACE, ovvero il nome dello spazio dei nomi che ti interessa.

    2. Trova il nome di StatefulSet proprietario del pod.

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

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
      • POD_NAME: il nome del pod in crashlooping.
    3. Applica la patch a StatefulSet per sostituire il comando del container del database con 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
                }
              ]
            }
          }
        }
      }
      '
      

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
      • STATEFULSET_NAME: il nome del StatefulSet.
    4. Elimina il pod per applicare la patch.

      kubectl delete pod -n NAMESPACE POD_NAME
      

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
      • POD_NAME: il nome del pod in crashlooping.
  4. Accedi al database nel pod.

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

    Sostituisci quanto segue:

    • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
    • POD_NAME: il nome del pod in crashlooping.

    Dopo l'avvio, il nuovo pod esegue il comando sleep anziché l'applicazione di database. Ora puoi accedere alla shell del pod.

  5. Riattiva tutti i componenti.

    Dopo l'indagine, ripristina lo stato originale rimuovendo le annotazioni pause. Riavvia le risorse nell'ordine inverso rispetto alla sospensione. Ad esempio, riavvia l'istanza prima di riavviare il DBCluster. Questa azione riconcilia le risorse e riavvia il pod del database con il comando originale.

    1. Per ogni risorsa che hai messo in pausa, rimuovi l'annotazione aggiungendo un trattino al nome dell'annotazione. L'esempio seguente rimuove l'annotazione da un'istanza:

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

      Sostituisci quanto segue:

      • NAMESPACE: il nome dello spazio dei nomi che ti interessa.
      • INSTANCE_NAME: il nome dell'istanza che hai trovato nel passaggio precedente.
    2. Ripeti questa procedura per tutte le altre risorse che hai messo in pausa nel primo passaggio.