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 menggunakan 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 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 konfigurasi yang ditetapkan 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 API GKE HorizontalPodAutoscaler.

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 menggunakan 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 menggunakan 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 mengembalikan 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: gunakan 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 menggunakan 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 menggunakan perintah kubectl get events:

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

      Ganti NAMESPACE 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.

Langkah berikutnya