Memecahkan masalah error penyimpanan di Backup for GKE

Halaman ini menjelaskan error terkait penyimpanan yang mungkin Anda alami saat menggunakan Pencadangan untuk GKE, hal-hal yang perlu dipertimbangkan saat melakukan tindakan, dan langkah-langkah cara memecahkan masalah.

Error 100010105: Gagal mencadangkan PersistentVolumeClaim - Disk yang dirujuk oleh PersistentVolume tidak ada

Error 100010105 terjadi saat upaya mencadangkan PersistentVolumeClaim gagal karena merujuk ke disk yang tidak ada, sehingga menghasilkan pesan error yang menyatakan Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

Di Google Kubernetes Engine, PersistentVolumeClaims meminta penyimpanan dari PersistentVolumes. PersistentVolume, pada gilirannya, merepresentasikan bagian dari penyimpanan, sering kali Persistent Disk Compute Engine yang mendasarinya. Error dapat terjadi saat PersistentVolumeClaim terikat ke PersistentVolume dan konfigurasi PersistentVolume menentukan Persistent Disk Compute Engine. Namun, disk sebenarnya dengan nama dan lokasi yang ditentukan dalam konfigurasi PersistentVolume tidak dapat ditemukan di project Google Cloud Anda. Oleh karena itu, Pencadangan untuk GKE tidak dapat melanjutkan pencadangan disk yang tidak ada, dan terjadi kegagalan.

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi PersistentVolumeClaim dan PersistentVolume yang bermasalah. Nama PersistentVolumeClaim yang bermasalah dan PersistentVolume terkaitnya tercantum di kolom state reason pada operasi Pencadangan untuk GKE yang gagal. Sebaiknya dokumentasikan nama PersistentVolumeClaim, namespace-nya, dan nama PersistentVolume.

  2. Periksa PersistentVolume. Untuk mendeskripsikan PersistentVolume, gunakan nama PersistentVolume yang Anda identifikasi dari kolom alasan status dalam perintah berikut:

    kubectl describe pv PERSISTENTVOLUME_NAME

    Ganti PERSISTENTVOLUME_NAME dengan nama PersistentVolume Anda.

  3. Pada output, periksa bagian source, khususnya di bagian csi. Bagian ini menjelaskan VolumeHandle yang coba direferensikan oleh PersistentVolume. Contoh:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    Dalam contoh ini, VolumeHandle berisi jalur lengkap ke disk, termasuk nama dan lokasinya. Contoh, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Gunakan VolumeHandle yang diperoleh dari deskripsi PersistentVolume untuk mengidentifikasi nama dan zona disk.

  5. Pastikan disk ada di project Google Cloud Anda menggunakan salah satu metode berikut:

    Disk zona

    Jika Anda menggunakan disk zona, gunakan Google Cloud CLI untuk menjalankan perintah gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

    Ganti kode berikut:

    • DISK_NAME: nama disk yang Anda peroleh dari deskripsi PersistentVolume.

    • ZONE_NAME: zona disk yang Anda dapatkan dari deskripsi PersistentVolume.

    • PROJECT_ID: Project ID Google Cloud Anda.

    Disk regional

    Jika Anda menggunakan disk regional, gunakan Google Cloud CLI untuk menjalankan perintah gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

    Ganti kode berikut:

    • DISK_NAME: nama disk yang Anda peroleh dari deskripsi PersistentVolume.

    • REGION_NAME: region disk yang Anda peroleh dari deskripsi PersistentVolume.

    • PROJECT_ID: Google Cloud Project ID Anda.

    Jika Anda mendapatkan pesan error Resource not found atau The resource DISK_NAME was not found, berarti disk tidak ada. Gunakan salah satu metode berikut untuk menyelesaikan masalah, bergantung pada skenario yang paling sesuai dengan kebutuhan Anda:

    • Jika disk tidak sengaja dihapus atau salah diberi nama dan Anda ingin menyimpan data atau PersistentVolumeClaim, atau PersistentVolume dikonfigurasi dengan nama disk yang salah, gunakan salah satu metode berikut untuk menyelesaikan masalah:

      • Pulihkan disk: jika Anda memiliki cadangan disk, pulihkan dengan nama dan lokasi yang sama persis dengan yang dirujuk oleh PersistentVolume.

      • Buat disk baru: jika memulihkan disk tidak memungkinkan, buat disk baru dengan nama dan lokasi yang sama dengan yang ada dalam konfigurasi PersistentVolume.

    • Jika PersistentVolumeClaim atau PersistentVolume, datanya, atau aplikasinya tidak lagi diperlukan, sebaiknya hapus entitas yang tidak diperlukan:

      • Hapus PersistentVolumeClaim: hapus PersistentVolumeClaim menggunakan alat command line kubectl untuk menjalankan perintah kubectl delete pvc:
      kubectl delete pvc PVC_NAME -n NAMESPACE

      Ganti kode berikut:

      • PVC_NAME: nama PersistentVolumeClaim yang ingin Anda hapus.

      • NAMESPACE: namespace dari PersistentVolumeClaim yang ingin Anda hapus.

    • PersistentVolume masih ada setelah Anda menghapus PersistentVolumeClaim: jika PersistentVolumeReclaimPolicy PersistentVolume ditetapkan ke Delete, PersistentVolume akan otomatis dihapus saat PersistentVolumeClaim dihapus. Jika persistentVolumeReclaimPolicy disetel ke Retain, Anda harus menghapus PersistentVolume secara manual setelah PersistentVolumeClaim dihapus. Untuk menghapus PersistentVolume, gunakan alat command line kubectl untuk menjalankan perintah kubectl delete pv:

      kubectl delete pv PV_NAME

      Ganti PV_NAME dengan nama PersistentVolume yang ingin Anda hapus.

Jika operasi terus gagal, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 100010202: Gagal membuat snapshot volume

Error 100010202 terjadi saat pembuatan snapshot Persistent Disk Compute Engine gagal, sehingga menampilkan pesan error yang menyatakan Snapshotting volume failed.

Operasi snapshot Persistent Disk Compute Engine akan gagal jika status lampiran disk ke instance virtual machine (VM) berubah selama proses pembuatan snapshot yang dimulai oleh layanan Pencadangan untuk GKE. Skenario umum yang memicu hal ini meliputi:

  • Perbaikan otomatis node: node yang tidak responsif dibuat ulang, yang menyebabkan Pod dijadwalkan ulang serta disk dilepas dan dipasang kembali.
  • Upgrade node: selama upgrade node pool, node biasanya dikuras dan diganti. Pod dihentikan dengan baik dan dijadwalkan ulang pada node baru, sehingga memicu siklus pelepasan dan pemasangan kembali disk.
  • Penskalaan otomatis cluster: selama peristiwa penurunan skala, jika autoscaler cluster menghapus node, semua Pod di node tersebut dengan Persistent Disk akan dikeluarkan, sehingga menyebabkan pelepasan disk. Jika Pod ini dijadwalkan ulang di tempat lain, lampiran akan terjadi di node baru. Selama peristiwa peningkatan skala, node baru tidak secara langsung menyebabkan pemasangan ulang, tetapi Pod yang dijadwalkan di node tersebut akan memicu pemasangan awal.

Ini adalah error sementara. Pencadangan biasanya berhasil pada proses otomatis berikutnya setelah lampiran disk stabil. Untuk mencegah peristiwa cluster memengaruhi cadangan Anda, terapkan rekomendasi berikut:

  1. Aktifkan Penjadwalan cerdas: Konfigurasi rencana pencadangan Anda menggunakan Penjadwalan cerdas (jadwal berbasis RPO). Hal ini memungkinkan sistem untuk otomatis mencoba ulang kegagalan sementara dalam periode waktu yang Anda tentukan tanpa memengaruhi RPO keseluruhan rencana pencadangan.

  2. Menyiapkan periode pengecualian pencadangan: Jika Anda melakukan upgrade node pool atau operasi pengubahan ukuran cluster, tambahkan periode pengecualian pencadangan ke setelan pencadangan Anda selama interval tersebut. Hal ini memastikan bahwa layanan Pencadangan untuk GKE akan dijeda dan menghindari penjadwalan snapshot saat cluster Anda secara aktif mengubah lampiran disk.

  3. Coba Lagi Pencadangan Manual: Dalam kasus pencadangan manual atau on-demand, coba lagi operasi pencadangan setelah peristiwa cluster selesai.

Jika operasi terus gagal, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Langkah berikutnya