Memecahkan masalah pod database yang mengalami crashlooping di AlloyDB Omni menggunakan orkestrator penampung

Pilih versi dokumentasi:

Halaman ini menjelaskan cara mengatasi masalah AlloyDB Omni untuk Kubernetes saat Anda mengalami situasi berikut:

  • Anda memiliki cluster database crashlooping di Kubernetes, dan Anda mengetahui nama serta namespace database, instance internalnya, dan pod.
  • Anda perlu mengakses file di pod database, tetapi loop error mencegah akses.

Pod database crashlooping adalah pod yang berulang kali dimulai, mengalami error, lalu otomatis dimulai ulang oleh Kubernetes. Siklus ini berlanjut tanpa batas hingga masalah yang mendasarinya teratasi. Database menjadi tidak tersedia dan tidak stabil selama proses ini.

Sebelum memulai

Sebelum mengikuti panduan pemecahan masalah dalam dokumen ini, coba solusi berikut:

  • Jika ketersediaan tinggi (HA) tersedia, picu failover. Dengan HA, instance standby sinkron siap menggantikan instance utama.
  • Pulihkan dari cadangan, jika tersedia. Pendekatan ini otomatis dan tidak terlalu rentan error.

Tidak dapat mengakses file di pod database crashlooping

Deskripsi: Pod database di cluster Kubernetes Anda memasuki status CrashLoopBackOff. Status ini mencegah Anda menggunakan kubectl exec untuk mengakses sistem file penampung database untuk proses debug.

Perbaikan yang direkomendasikan: Untuk mengatasi masalah ini, hentikan sementara loop error dengan menambal StatefulSet pod untuk mengganti perintah penampung. Sebelum melanjutkan, pertimbangkan alternatif yang lebih sederhana, seperti memicu failover atau memulihkan dari cadangan, jika tersedia.

Untuk mengakses pod, ikuti langkah-langkah berikut:

  1. Jeda semua resource AlloyDB Omni yang terkait dan terlihat oleh pengguna untuk mencegahnya mengganggu proses pemulihan.

    1. Buat daftar semua definisi resource kustom Kubernetes AlloyDB Omni:

      kubectl get crd | grep alloydbomni.dbadmin

    2. Tinjau daftar resource untuk cluster database Anda. Buat daftar resource yang Anda jeda agar dapat melanjutkan jedanya nanti. Minimal, Anda harus menjeda resource dbclusters.alloydbomni.dbadmin.goog.

    3. Jeda setiap resource secara terpisah dengan menambahkan anotasi ctrlfwk.internal.gdc.goog/pause.

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

      Ganti kode berikut:

      • RESOURCE_TYPE: jenis resource yang akan dijeda, misalnya, dbclusters.alloydbomni.dbadmin.goog.
      • NAMESPACE: namespace cluster database.
      • RESOURCE_NAME: nama resource yang akan dijeda.

  2. Jeda instance internal yang mengelola pod crashlooping.

    1. Temukan nama instance internal.

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

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.

    2. Jeda instance. Anotasi ctrlfwk.internal.gdc.goog/pause=true memberi tahu pengontrol AlloyDB Omni untuk menjeda pengelolaan resource-nya. Hal ini mencegah pengontrol otomatis merekonsiliasi atau mengubah resource saat Anda melakukan langkah-langkah pemecahan masalah secara manual, seperti menambal StatefulSet yang mendasarinya.

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

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.
      • INSTANCE_NAME: nama instance yang Anda temukan.

  3. Cegah pod mengalami crashlooping.

    Tambal StatefulSet pod untuk mengganti perintah penampung utama. Perubahan ini menghentikan aplikasi agar tidak dimulai dan mengalami error, sehingga Anda dapat mengakses pod.

    1. Konfirmasi nama pod crashlooping.

      kubectl get pod -n NAMESPACE

      Ganti NAMESPACE, yang merupakan nama namespace yang Anda minati.

    2. Temukan nama StatefulSet yang memiliki pod.

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

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.
      • POD_NAME: nama pod crashlooping.

    3. Tambal StatefulSet untuk mengganti perintah penampung database dengan 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
          }
        ]
      }
    }
  }
}
'

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.
      • STATEFULSET_NAME: nama StatefulSet.

    4. Hapus pod untuk menerapkan patch.

      kubectl delete pod -n NAMESPACE POD_NAME

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.
      • POD_NAME: nama pod crashlooping.

  4. Akses database di pod.

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

    Ganti kode berikut:

    • NAMESPACE: nama namespace yang Anda minati.
    • POD_NAME: nama pod crashlooping.

    Setelah pod baru dimulai, pod akan menjalankan perintah sleep, bukan aplikasi database. Sekarang Anda dapat mengakses shell pod.

  5. Lanjutkan jeda semua komponen.

    Setelah menyelidiki, pulihkan status asli dengan menghapus anotasi pause. Anda melanjutkan jeda resource dalam urutan terbalik dari saat menjedanya; misalnya, lanjutkan jeda instance sebelum Anda melanjutkan jeda DBCluster. Tindakan ini merekonsiliasi resource dan memulai ulang pod database dengan perintah aslinya.

    1. Untuk setiap resource yang Anda jeda, hapus anotasi dengan menambahkan tanda hubung ke nama anotasi. Contoh berikut menghapus anotasi dari instance:

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

      Ganti kode berikut:

      • NAMESPACE: nama namespace yang Anda minati.
      • INSTANCE_NAME: nama instance yang Anda temukan pada langkah sebelumnya.

    2. Ulangi proses ini untuk semua resource lain yang Anda jeda pada langkah pertama.