Memecahkan masalah error izin di Backup for GKE

Dokumen ini menjelaskan error dan kode yang sesuai yang mungkin Anda alami saat menggunakan Pencadangan untuk GKE guna melakukan operasi pemulihan. Setiap bagian mencakup hal-hal yang perlu dipertimbangkan saat melakukan tindakan untuk mengatasi error pemulihan, dan petunjuk tentang cara mengatasi error operasi pemulihan.

Error 200010301: Gagal menyelesaikan operasi pemulihan karena layanan webhook penerimaan tidak tersedia

Error 200010301 terjadi saat upaya untuk menyelesaikan operasi pemulihan gagal karena layanan webhook penerimaan, yang juga disebut sebagai callback HTTP, tidak tersedia, sehingga menghasilkan pesan error berikut. Pesan error menunjukkan bahwa server GKE API mencoba menghubungi webhook penerimaan saat mencoba memulihkan resource, tetapi layanan yang mendukung webhook tidak tersedia atau tidak ditemukan:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

Error ini terjadi saat resource GKE ValidatingAdmissionWebhook atau MutatingAdmissionWebhook aktif di cluster target, tetapi server GKE API tidak dapat menjangkau endpoint yang dikonfigurasi di webhook. Webhook penerimaan mencegat permintaan ke server GKE API, dan konfigurasinya menentukan cara server GKE API harus mengkueri permintaan.

clientConfig webhook menentukan backend yang menangani permintaan penerimaan, yang dapat berupa layanan cluster internal atau URL eksternal. Pilihan antara kedua opsi ini bergantung pada persyaratan operasional dan arsitektur spesifik webhook Anda. Bergantung pada jenis opsi, operasi pemulihan mungkin gagal karena alasan berikut:

  • Layanan dalam cluster: layanan GKE dan pod pendukungnya tidak dipulihkan atau siap saat server API GKE mencoba memanggil webhook. Hal ini terjadi selama operasi pemulihan saat konfigurasi webhook cakupan cluster diterapkan sebelum layanan cakupan namespace sepenuhnya dalam status ready.

  • URL eksternal: endpoint eksternal tidak tersedia untuk sementara karena masalah konektivitas jaringan antara cluster GKE dan endpoint eksternal, atau karena masalah resolusi DNS atau aturan firewall.

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi webhook yang gagal yang disebutkan dalam pesan error. Misalnya, failed calling webhook "...".

  2. Periksa webhook dengan menjalankan perintah kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ganti WEBHOOK_NAME dengan nama webhook yang diidentifikasi dalam pesan error.

    Anda juga dapat menjalankan perintah kubectl get mutatingwebhookconfigurations untuk memeriksa webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ganti WEBHOOK_NAME dengan nama webhook yang diidentifikasi dalam pesan error.

  3. Lakukan langkah-langkah pemecahan masalah berikut berdasarkan jenis konfigurasi Anda:

    Berbasis layanan clientConfig

    Tentukan urutan pemulihan kustom dengan mengubah resource RestorePlan untuk menyertakan RestoreOrder dengan entri GroupKindDependency. Hal ini memungkinkan komponen yang mendukung webhook seperti Deployment, StatefulSet, atau Service dipulihkan dan siap sebelum ValidatingWebhookConfiguration atau MutatingWebhookConfiguration.

    Untuk mengetahui petunjuk tentang cara menentukan urutan pemulihan kustom, lihat Menentukan urutan pemulihan resource selama pemulihan.

    Pendekatan ini dapat gagal karena pod layanan tidak memasuki status ready sepenuhnya meskipun setelah objek Service dibuat. Alasan lain kegagalan bisa disebabkan karena konfigurasi webhook mungkin dibuat secara tidak terduga oleh aplikasi lain. Atau, Anda dapat melakukan operasi pemulihan dua tahap menggunakan langkah-langkah berikut:

    1. Buat resource Restore menggunakan cadangan dengan mengonfigurasi operasi pemulihan dengan filter pemulihan terperinci yang akan mencakup resource tertentu yang diperlukan agar webhook dapat berfungsi, misalnya, Namespaces, Deployments, StatefulSets, atau Services.

      Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi pemulihan dengan filter pemulihan terperinci, lihat Mengaktifkan pemulihan terperinci.

    2. Buat resource Restore lain untuk operasi pencadangan dan konfigurasi resource lainnya yang Anda pilih.

    Berdasarkan URL clientConfig

    1. Verifikasi endpoint HTTPS eksternal dan pastikan endpoint tersebut aktif, dapat dijangkau, dan berfungsi dengan benar.

    2. Pastikan ada konektivitas jaringan dari node dan bidang kontrol cluster GKE Anda ke URL eksternal. Anda mungkin juga perlu memeriksa aturan firewall, misalnya, jika Anda menggunakan Virtual Private Cloud, lokal, atau penyedia cloud yang menghosting webhook, kebijakan jaringan, dan resolusi DNS.

  4. Coba lagi operasi pemulihan. Jika operasi terus gagal, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 200010302: Gagal menyelesaikan operasi pemulihan karena permintaan pembuatan resource ditolak

Error 200010302 terjadi saat upaya untuk menyelesaikan operasi pemulihan gagal karena webhook penerimaan menolak permintaan pembuatan resource, yang menghasilkan pesan error berikut yang menunjukkan bahwa resource dari cadangan Anda tidak dapat dibuat di cluster target karena webhook penerimaan aktif mencegat permintaan dan menolaknya berdasarkan kebijakan kustom:

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

Error ini disebabkan oleh setelan konfigurasi di cluster GKE target, yang memiliki ValidatingAdmissionWebhook atau MutatingAdmissionWebhook yang menerapkan aturan tertentu pada pembuatan dan modifikasi resource, sehingga memblokir permintaan pembuatan resource. Misalnya, webhook mencegah pembuatan resource karena resource terkait tetapi bertentangan sudah ada di cluster. Misalnya, webhook dapat menolak pembuatan deployment jika sudah dikelola oleh resource HorizontalPodAutoscaler GKE API.

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi webhook yang menolak permintaan menggunakan pesan error yang terjadi saat operasi pemulihan gagal. Misalnya, webhook WEBHOOK_NAME denied the request Pesan error berisi informasi berikut:

    • Nama webhook: nama webhook yang menolak permintaan.

    • Alasan penolakan: alasan spesifik penolakan permintaan.

  2. Periksa webhook dengan menjalankan perintah kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ganti WEBHOOK_NAME dengan nama webhook yang Anda identifikasi dalam pesan error.

    Anda juga dapat menjalankan perintah kubectl get mutatingwebhookconfigurations untuk memeriksa webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ganti WEBHOOK_NAME dengan nama webhook yang Anda identifikasi dari pesan error.

  3. Selesaikan masalah pokok di cluster target. Tindakan yang benar bergantung pada error tertentu. Sebagai contoh, jika ada konflik HorizontalPodAutoscaler, Anda harus menghapus HorizontalPodAutoscaler yang ada di cluster target sebelum menjalankan pemulihan untuk memungkinkan beban kerja yang dicadangkan dan resource terkaitnya dibuat.

  4. Coba lagi operasi pemulihan. Jika operasi pemulihan terus gagal, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 200060202: Gagal menyelesaikan operasi pemulihan karena resource GKE tidak ada selama validasi workload

Error 200060202 terjadi selama fase validasi workload operasi pemulihan saat resource GKE yang diharapkan Backup for GKE untuk divalidasi tidak dapat ditemukan di cluster target, sehingga menghasilkan pesan error berikut:

  Workload Validation Error: [KIND] "[NAME]" not found

Contoh, Example: Workload Validation Error: pods "jenkins-0" not found

Error ini terjadi saat Pencadangan untuk GKE berhasil membuat atau mengupdate resource GKE sebagai bagian dari proses operasi pemulihan, tetapi saat tahap validasi dimulai, satu atau beberapa resource GKE tidak ada lagi di cluster target karena resource tersebut dihapus setelah resource dibuat atau diupdate awalnya oleh proses pemulihan, tetapi sebelum validasi workload untuk resource GKE dapat selesai. Error seperti ini dapat terjadi karena alasan berikut:

  • Penghapusan manual: pengguna atau administrator menghapus resource secara manual menggunakan kubectl atau alat Google Cloud lainnya.

  • Otomatisasi eksternal: Pengontrol GitOps seperti Config Sync, ArgoCD, Flux, skrip kustom, atau alat pengelolaan cluster lainnya membatalkan atau menghapus resource agar sesuai dengan status yang diinginkan di repositori.

  • Pengontrol GKE: pengontrol GKE menghapus resource karena bertentangan dengan resource atau kebijakan lain, atau rantai OwnerReference menyebabkan pengumpulan sampah, atau proses pembersihan otomatis oleh GKE yang menghapus resource dependen saat resource owner-nya dihapus.

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi resource yang hilang menggunakan pesan error yang muncul saat operasi pemulihan gagal diselesaikan.

  2. Temukan namespace tempat resource berada menggunakan salah satu metode berikut:

    • Log audit GKE: periksa log audit GKE yang dibuat saat Anda mencoba operasi pemulihan. Anda dapat memfilter log untuk operasi penghapusan pada resource Kind dan Name. Entri log audit berisi namespace asli.

    • Detail pencadangan: tinjau cakupan operasi pemulihan dan isi cadangan Anda. Indeks cadangan menampilkan namespace asli resource. Anda juga dapat memverifikasi apakah RestorePlan berisi TransformationRule yang menentukan aturan untuk memulihkan resource di namespace yang Anda pilih.

    • Menelusuri di seluruh namespace: jalankan perintah kubectl get untuk menelusuri resource di semua namespace:

      kubectl get KIND --all-namespaces | grep NAME

      Ganti KIND dan NAME dengan nilai dari pesan error. Jika resource masih ada, perintah ini akan menampilkan namespace-nya.

  3. Verifikasi penghapusan dengan menjalankan perintah kubectl get:

    kubectl get KIND NAME -n [NAMESPACE]

    Ganti KIND dan NAME dengan nilai dari pesan error. Anda akan menerima pesan error not found

  4. Selidiki penyebab penghapusan menggunakan salah satu metode berikut:

    • Log audit GKE: mengidentifikasi entitas mana yang mengeluarkan permintaan penghapusan. Misalnya, pengguna, akun layanan, atau pengontrol.

    • Tinjau otomatisasi yang dikonfigurasi: Jika Anda menggunakan GitOps atau alat otomatisasi lainnya, periksa log dan statusnya untuk melihat apakah alat tersebut mengganggu resource yang dipulihkan.

    • Periksa peristiwa terkait: periksa peristiwa GKE di namespace yang ditentukan dengan menjalankan perintah kubectl get events:

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      Ganti NAMESPACE_NAME dengan nama namespace.

  5. Atasi penyebab penghapusan resource berdasarkan hasil langkah sebelumnya. Misalnya, menjeda otomatisasi yang bertentangan, memperbaiki kesalahan konfigurasi, atau menyesuaikan izin pengguna.

  6. Pulihkan resource yang hilang menggunakan salah satu metode berikut:

    • Terapkan kembali file manifes: jika Anda memiliki manifes untuk aset yang hilang, Anda dapat menerapkannya kembali ke namespace yang benar.

    • Lakukan pemulihan terperinci: lakukan operasi pemulihan terperinci untuk memulihkan secara selektif hanya resource yang hilang dari cadangan yang sama, yang memastikan Anda menentukan namespace yang benar. Untuk mengetahui informasi selengkapnya tentang cara melakukan operasi pemulihan terperinci, lihat Mengaktifkan pemulihan terperinci.

  7. Coba lagi operasi pemulihan. Jika operasi pemulihan terus gagal, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 200060201: Gagal menyelesaikan operasi pemulihan karena waktu tunggu validasi beban kerja habis

Error 200060201 terjadi saat satu atau beberapa workload yang dipulihkan gagal menjadi ready sepenuhnya selama operasi pemulihan dalam batas waktu yang diharapkan setelah resource dibuat di cluster, sehingga menghasilkan pesan error berikut:

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Error ini terjadi karena Pencadangan untuk GKE melakukan langkah validasi setelah memulihkan konfigurasi resource GKE untuk memastikan bahwa workload penting berfungsi dengan benar. Pencadangan untuk GKE menunggu workload tertentu mencapai status ready, tetapi setidaknya satu workload tidak memenuhi kriteria kesiapan berikut dalam periode waktu tunggu yang dialokasikan:

  • Untuk Pods: status.Phase adalah Running

  • Untuk Deployments: status.ReadyReplicas sama dengan spec.Replicas

  • Untuk StatefulSets: status.ReadyReplicas sama dengan spec.Replicas

  • Untuk DaemonSets: status.NumberReady sama dengan status.DesiredNumberScheduled

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi workload yang tidak dalam status ready dalam pesan error yang mencantumkan workload dan namespace-nya yang gagal memasuki status ready.

  2. Periksa status beban kerja dan dapatkan detail serta peristiwa untuk beban kerja yang gagal dengan menjalankan perintah kubectl describe:

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    Ganti kode berikut:

    • WORKLOAD_TYPE: jenis beban kerja, misalnya, Deployment, StatefulSet, atau DaemonSet.

    • WORKLOAD_NAME: nama instance beban kerja tertentu.

    • NAMESPACE_NAME: namespace tempat workload berada.

    • SELECTOR_FOR_WORKLOAD: pemilih label untuk menemukan Pods yang terkait dengan workload. Misalnya, app=my-app.

    Untuk pod dalam jenis beban kerja Deployments atau StatefulSets, periksa status setiap Pod dengan menjalankan perintah kubectl describe pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Ganti kode berikut:

    • POD_NAME: nama pod tertentu.

    • NAMESPACE_NAME: namespace tempat pod berada.

  3. Di bagian Events, analisis peristiwa dan log dalam output describe dan temukan informasi berikut:

    • ImagePullBackOff / ErrImagePull: menunjukkan bahwa ada masalah saat mengambil image container.

    • CrashLoopBackOff: menunjukkan bahwa penampung sedang dimulai dan mengalami error.

  4. Di bagian Containers, analisis log container dalam output describe untuk menemukan nama container dengan menjalankan perintah kubectl logs:

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Ganti kode berikut:

    • POD_NAME: nama pod tertentu.

    • NAMESPACE_NAME: namespace tempat pod berada.

    • CONTAINER_NAME: nama container dalam Pod.

    Menurut output describe, ada beberapa alasan mengapa pod mungkin tidak muncul dalam output resource, termasuk:

    • Kegagalan pemeriksaan kesiapan: pemeriksaan kesiapan container tidak berhasil.

    • Masalah resource: tidak ada cukup CPU, memori, atau resource lain di cluster atau batas kuota telah tercapai.

    • Masalah container init: kegagalan di container init yang menghalangi container utama untuk dimulai.

    • Error konfigurasi: error dalam ConfigMaps, Secrets, atau variabel lingkungan.

    • Masalah jaringan: Pods tidak dapat berkomunikasi dengan layanan yang diperlukan.

  5. Periksa resource cluster GKE untuk memastikan cluster GKE memiliki kapasitas node, CPU, dan memori yang cukup untuk menjalankan workload yang dipulihkan. Di cluster Autopilot, penyediaan otomatis node mungkin memerlukan waktu tambahan, oleh karena itu, sebaiknya periksa apakah ada batasan atau error penskalaan node. Atasi masalah mendasar berdasarkan temuan Anda, dan selesaikan masalah yang mencegah workload memasuki status ready. Pendekatan ini dapat mencakup mengoreksi manifes, menyesuaikan permintaan atau batas resource, memperbaiki kebijakan jaringan, atau memastikan dependensi terpenuhi.

  6. Setelah masalah mendasar teratasi, tunggu hingga workload memasuki status ready. Anda tidak perlu menjalankan operasi pemulihan lagi.

Jika masalah berlanjut, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 200060102: Gagal menyelesaikan operasi pemulihan karena error validasi volume

Error 200060102 terjadi karena satu atau beberapa resource VolumeRestore, yang mengelola proses memulihkan data dari VolumeBackup ke PersistentVolume, telah memasuki status failed atau deleting selama fase validasi volume operasi pemulihan. Pemulihan volume yang gagal akan menghasilkan pesan error berikut di kolom stateReason resource pemulihan:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

Pesan error mencantumkan nama resource lengkap dari VolumeRestore yang gagal, termasuk nama dan namespace PersistentVolumeClaim target. Pesan error menunjukkan bahwa proses pemulihan data untuk PersistentVolumeClaim yang terpengaruh tidak berhasil diselesaikan saat Backup untuk GKE memulai penyediaan resource VolumeRestore dari VolumeBackups, dan pembuatan Persistent Disk yang mendasarinya dari snapshot gagal.PersistentVolumes Kegagalan VolumeRestore dapat terjadi karena alasan berikut:

  • Kuota tidak mencukupi: tidak ada kuota Persistent Disk yang dialokasikan dalam jumlah yang cukup di project atau region, misalnya, SSD_TOTAL_GB.

  • Masalah izin: akun layanan yang digunakan oleh Backup for GKE tidak memiliki izin yang diperlukan untuk membuat disk atau mengakses snapshot.

  • Masalah jaringan: ada masalah jaringan sementara atau persisten yang mengganggu proses pembuatan disk.

  • Snapshot tidak valid: snapshot sumber VolumeBackup atau Persistent Disk yang mendasarinya rusak atau tidak dapat diakses.

  • Batasan resource: batasan resource cluster lainnya menghambat penyediaan volume.

  • Error internal: ada masalah internal dalam layanan Persistent Disk.

Untuk mengatasi error ini, gunakan petunjuk berikut:

  1. Identifikasi PersistentVolumeClaims yang gagal yang tercantum dalam pesan error, yang mencantumkan nama resource lengkap dari objek VolumeRestore yang gagal.

  2. Dapatkan detail setiap resource VolumeRestore yang gagal dengan menjalankan perintah gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    Ganti kode berikut:

    • VOLUME_RESTORE_ID: ID resource VolumeRestore yang gagal.

    • PROJECT_ID: ID Google Cloud project Anda.

    • LOCATION: Google Cloud lokasi pemulihan.

    • RESTORE_PLAN_ID: ID paket pemulihan.

    • RESTORE_ID: ID operasi pemulihan.

  3. Periksa kolom state dan stateMessage dalam output untuk mengetahui detail terkait kegagalan.

  4. Periksa status target PersistentVolumeClaim dengan menjalankan perintah kubectl get pvc:

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Ganti kode berikut:

    • PVC_NAME: nama resource PersistentVolumeClaim.

    • NAMESPACE_NAME: namespace tempat PersistentVolumeClaim berada.

  5. Pastikan bagian status.phase output menunjukkan fase Pending. Fase ini berarti PersistentVolumeClaim belum terikat ke PersistentVolume, yang diharapkan jika VolumeRestore gagal.

  6. Periksa bagian Events dalam output YAML untuk melihat pesan terkait kegagalan penyediaan, seperti ProvisioningFailed, misalnya:

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    Output menunjukkan bahwa ada masalah izin saat mengakses kunci enkripsi selama pembuatan disk. Untuk memberikan compute service agent izin yang relevan untuk mengakses kunci, gunakan petunjuk yang dijelaskan dalam dokumentasi Pencadangan untuk GKE tentang mengaktifkan enkripsi CMEK.

  7. Tinjau peristiwa GKE di namespace PersistentVolumeClaim, yang memberikan pesan error mendetail dari pengontrol PersistentVolume atau driver CSI, dengan menjalankan perintah kubectl get events:

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    Ganti NAMESPACE_NAME dengan namespace PersistentVolumeClaim,

  8. Identifikasi peristiwa yang terkait dengan nama PersistentVolumeClaim, yang berisi kata kunci seperti FailedProvisioning atau ExternalProvisioning. Peristiwa ini juga dapat berisi error dari penyedia penyimpanan, seperti pd.csi.storage.gke.io.

  9. Periksa log Persistent Disk dengan memeriksa Cloud Audit Logs dan log Persistent Disk di Cloud Logging untuk menemukan error terkait operasi pembuatan disk di sekitar waktu terjadinya kegagalan.

  10. Berdasarkan pesan error yang dihasilkan, atasi masalah mendasar berikut:

    • Tingkatkan kuota Persistent Disk jika ditunjukkan, seperti (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Verifikasi dan perbaiki izin IAM.

    • Menyelidiki dan menyelesaikan masalah jaringan.

    • Hubungi Layanan Pelanggan Cloud untuk menyelesaikan masalah terkait snapshot atau layanan Persistent Disk.

    • PersistentVolumeClaim tetap dalam status Pending.

    • Proses operasi pemulihan tidak otomatis mencoba ulang VolumeRestore. Untuk mengatasi hal ini, Anda harus memicu operasi pemulihan untuk workload Deployment atau StatefulSet yang menggunakan PersistentVolumeClaim yang terpengaruh.

    • Gunakan pemulihan terperinci untuk memulihkan workload Deployment atau StatefulSet yang terkait dengan PersistentVolumeClaim yang gagal secara selektif. Pendekatan ini memungkinkan mekanisme GKE standar menangani proses pembuatan dan pengikatan PersistentVolumeClaim lagi jika masalah yang mendasarinya telah diperbaiki. Untuk mengetahui informasi selengkapnya tentang pemulihan terperinci, lihat Mengaktifkan pemulihan terperinci.

Jika masalah berlanjut atau penyebab kegagalan VolumeRestore tidak jelas, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Error 200060101: Gagal menyelesaikan operasi pemulihan karena waktu tunggu validasi volume habis

Error 200060101 terjadi selama fase validasi volume operasi pemulihan saat Backup untuk GKE berhenti menunggu karena setidaknya satu resource VolumeRestore, yang mengelola pemulihan data dari VolumeBackup, tidak mencapai status succeeded dalam periode waktu tunggu yang dialokasikan. Resource VolumeRestore lainnya juga mungkin tidak lengkap.

Pesan error di kolom stateReason resource Restore menampilkan resource VolumeRestore pertama yang ditemukan dan belum dalam status succeeded saat waktu tunggu habis diperiksa. Hal ini mencakup nama dan namespace PersistentVolumeClaim target untuk VolumeRestore tertentu tersebut, misalnya:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

Backup for GKE memulai penyediaan resource VolumeRestore PersistentVolumes dari VolumeBackups. Error ini menunjukkan bahwa pembuatan Persistent Disk yang mendasarinya dari snapshot dan pengikatan PersistentVolumeClaim berikutnya ke PersistentVolume membutuhkan waktu lebih lama daripada waktu tunggu yang dihitung untuk VolumeRestore yang dikutip. VolumeRestores lain untuk operasi pemulihan yang sama juga mungkin dalam status belum selesai.

Meskipun waktu tunggu telah tercapai dari perspektif Pencadangan untuk GKE, proses pembuatan disk yang mendasar untuk resource VolumeRestore yang disebutkan, dan mungkin resource VolumeRestore, mungkin masih berlangsung atau gagal.

Untuk mengatasi masalah ini, gunakan petunjuk berikut:

  1. Identifikasi nama dan namespace PersistentVolumeClaim yang waktunya habis dalam pesan error, misalnya, (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Tampilkan daftar semua VolumeRestores yang terkait dengan operasi pemulihan untuk melihat statusnya saat ini dengan menjalankan perintah gcloud beta container backup-restore volume-restores list:

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Ganti kode berikut:

    • PROJECT_ID: ID Google Cloud project.

    • LOCATION: Google Cloud lokasi pemulihan.

    • RESTORE_PLAN_NAME: nama paket pemulihan.

    • RESTORE_NAME: nama operasi pemulihan.

  3. Temukan VolumeRestores yang tidak dalam status succeeded.

  4. Dapatkan detail tentang VolumeRestore yang disebutkan dalam error dan VolumeRestores lainnya yang tidak dalam status succeeded dengan menjalankan perintah gcloud beta container backup-restore volume-restores describe:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Ganti kode berikut:

    • VOLUME_RESTORE_ID: ID resource VolumeRestore.

    • PROJECT_ID: ID Google Cloud project Anda.

    • LOCATION: Google Cloud lokasi pemulihan.

    • RESTORE_PLAN_NAME: nama paket pemulihan.

    • RESTORE_NAME: nama operasi pemulihan.

  5. Periksa kolom state dan stateMessage. Nilai kolom state kemungkinan adalah creating atau restoring. Kolom stateMessage dapat memberikan konteks lebih lanjut dan berisi detail PersistentVolumeClaim target.

  6. Periksa status target yang diidentifikasi PersistentVolumeClaims dengan menjalankan perintah kubectl get pvc:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Ganti kode berikut:

    • PVC_NAME: nama PersistentVolumeClaim.

    • PVC_NAMESPACE: namespace PersistentVolumeClaim.

    Nilai PersistentVolumeClaim's status.phase kemungkinan adalah Pending. Periksa bagian Events untuk mengetahui error berikut:

    • Waiting for first consumer to be created before binding: menunjukkan bahwa StorageClass memiliki volumeBindingMode: WaitForFirstConsumer.

      Penyediaan PersistentVolume ditunda hingga Pod yang menggunakan PersistentVolumeClaim dibuat dan dijadwalkan. Masalahnya mungkin terjadi pada penjadwalan Pod, bukan penyediaan volume itu sendiri. Oleh karena itu, sebaiknya konfirmasi alasan Pods yang menggunakan PersistentVolumeClaim tidak dijadwalkan atau tidak dimulai.

    • FailedProvisioning atau error dari penyedia penyimpanan: Misalnya, pd.csi.storage.gke.io.

  7. Tinjau peristiwa GKE di namespace yang relevan dengan menjalankan perintah kubectl get events:

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    Ganti PVC_NAMESPACE dengan namespace PersistentVolumeClaim.

    Cari peristiwa yang terkait dengan nama PersistentVolumeClaim, seperti pesan atau error penyediaan.

  8. Periksa log Cloud Audit Logs dan Persistent Disk di Cloud Logging.

  9. Pantau status semua VolumeRestores dalam status creating dan restoring.

    Setelah masalah diperbaiki, status VolumeRestores dapat bertransisi ke status succeeded atau failed. Jika VolumeRestores mencapai status succeeded, PersistentVolumeClaims akan menjadi Bound dan workload akan berfungsi. Jika ada VolumeRestore yang memasuki status failed, Anda harus melakukan langkah-langkah pemecahan masalah untuk mengatasi error validasi volume. Untuk mengetahui informasi selengkapnya, lihat Error 200060102: Gagal menyelesaikan operasi pemulihan karena error validasi volume

Jika VolumeRestores tetap dalam status creating atau restoring dalam jangka waktu yang terlalu lama, hubungi Cloud Customer Care untuk mendapatkan bantuan lebih lanjut.

Langkah berikutnya