Memecahkan masalah Distributed Cloud terhubung

Google memantau dan memelihara deployment Google Distributed Cloud terhubung dari jarak jauh. Untuk tujuan ini, engineer Google memiliki akses Secure Shell (SSH) ke hardware Distributed Cloud yang terhubung. Jika Google mendeteksi masalah, engineer Google akan menghubungi Anda untuk memecahkan dan menyelesaikan masalah tersebut. Jika Anda telah mengidentifikasi masalah sendiri, segera hubungi Dukungan Google untuk mendiagnosis dan menyelesaikannya.

Upgrade software Distributed Cloud terhubung

Bagian ini menjelaskan cara menggunakan Metrics Explorer untuk memeriksa apakah cluster yang terhubung ke Distributed Cloud sedang menjalani upgrade software.

Prosedur ini menggunakan metrik Monitoring berikut:

  • Current Cluster Version (/edge_cluster/current_cluster_version): menunjukkan versi software Distributed Cloud connected saat ini yang berjalan di cluster.

  • Target Cluster Version (/edge_cluster/target_cluster_version): menunjukkan versi target Distributed Cloud yang terhubung ke cluster yang sedang diupgrade.

Untuk menyelesaikan langkah-langkah di bagian ini, Anda harus memenuhi prasyarat berikut:

  1. Akses ke konsol Google Cloud dan project Google Cloud yang terhubung ke Distributed Cloud.
  2. Peran IAM Monitoring Viewer, yang memungkinkan Anda melihat metrik Monitoring.
  3. (Opsional) nilai machine_id dari mesin Distributed Cloud terhubung target untuk memfilter hasil yang ditampilkan.

Menggunakan Metrics Explorer untuk memeriksa versi software cluster saat ini dan target

  1. Buka Metrics Explorer:

    1. Di konsol Google Cloud , buka bagian Monitoring.

    2. Di hierarki navigasi sebelah kiri, klik Metrics Explorer.

  2. Pilih jenis resource target:

    1. Di halaman Metrics Explorer, buka halaman Configuration.

    2. Klik Select a metric.

    3. Gunakan kotak penelusuran untuk menelusuri jenis resource Cluster. Anda juga dapat menggunakan ID resource lengkap edgecontainer.googleapis.com/Cluster.

    4. Di hasil yang ditampilkan, klik jenis resource Cluster.

  3. Dapatkan versi software cluster saat ini:

    1. Di bagian Metric, telusuri nilai current_cluster_version.

    2. Pilih metrik Machine Uptime. Jalur lengkapnya adalah edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

    3. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

  4. Dapatkan versi software target cluster:

    1. Klik Add Query.

    2. Di bagian Metric, telusuri nilai target_cluster_version.

    3. Pilih metrik Target Cluster Version. Jalur lengkapnya adalah edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

    4. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

  5. Periksa status upgrade software cluster di diagram yang muncul.

    • Jika baris Current Cluster Version dan Target Cluster Version masing-masing menunjukkan nilai yang berbeda, cluster sedang menjalani upgrade software.

    • Jika baris Current Cluster Version dan Target Cluster Version menunjukkan nilai yang sama, cluster tidak sedang menjalani upgrade software.

  6. Verifikasi hasil dari langkah sebelumnya menggunakan perintah berikut:

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

    Ganti kode berikut:

    • CLUSTER_ID: ID cluster target.
    • REGION: region Google Cloud , tempat cluster dibuat.

    Dalam output perintah, catat nilai kolom berikut:

    • Jika nilai kolom status adalah UPDATING, cluster sedang menjalani upgrade software.
    • Jika nilai kolom clusterVersion dan targetVersion berbeda, periksa nilai tersebut dengan nilai yang ditampilkan oleh Metrics Explorer.

Memahami hasil

Tabel berikut menjelaskan hasil yang ditampilkan oleh Metrics Explorer dan perintah gcloud.

Status cluster Diagnosis Resolusi
Berfungsi baik
Nilai currentVersion dan targetVersion cocok
Nilai `status` adalah RUNNING
 Cluster menjalankan software Distributed Cloud terhubung versi target. Tidak ada.
Mengupgrade
Nilai currentVersion lebih rendah dari targetVersion
Nilai `status` adalah UPDATING
 Cluster sedang diupgrade ke versi target software Distributed Cloud terhubung. Pantau cluster di Metrics Explorer hingga nilai versi cluster saat ini dan target cocok.
Terhenti
Nilai currentVersion lebih rendah dari targetVersion tanpa batas waktu
Nilai `status` adalah UPDATING tanpa batas waktu
 Upgrade ke versi target software Distributed Cloud yang terhubung telah gagal di setidaknya satu node dalam cluster. Periksa konektivitas mesin dan log sistem; hubungi Google untuk mendapatkan bantuan.
Melakukan roll back
Nilai currentVersion lebih tinggi dari targetVersion
Nilai `status` adalah UPDATING
 Cluster sedang melakukan rollback ke versi software Distributed Cloud connected sebelumnya. Hubungi Google untuk mengidentifikasi alasan rollback.

Jika upgrade software pada cluster gagal atau cluster telah di-roll back ke versi software sebelumnya, periksa hal berikut:

  • Kondisi node. Pastikan setiap mesin fisik yang terhubung ke Distributed Cloud memiliki konektivitas jaringan dan melaporkan waktu beroperasi seperti yang dijelaskan di bagian berikutnya.
  • Masa pemeliharaan. Verifikasi apakah upgrade software telah dijeda karena periode pengecualian pemeliharaan.
  • Log sistem. Periksa log sistem Anda untuk mengidentifikasi kemungkinan alasan kegagalan upgrade software, seperti waktu tunggu pengeluaran Pod.

Jika langkah-langkah penyelesaian yang tercantum dalam tabel tidak menyelesaikan masalah, hubungi Dukungan Google dengan nilai machine_id mesin yang terpengaruh dan stempel waktu pemadaman layanan.

Memulai ulang mesin yang terhubung ke Distributed Cloud

Bagian ini menjelaskan cara menggunakan Metrics Explorer untuk memeriksa apakah mesin fisik yang terhubung ke Distributed Cloud telah dimulai ulang, dan menentukan alasan mulai ulang. Pemantauan mulai ulang membantu menentukan apakah hal tersebut merupakan bagian dari pemeliharaan terencana atau akibat kegagalan hardware atau gangguan daya.

Prosedur ini menggunakan metrik Monitoring berikut:

  • Waktu Operasional Mesin (/machine/uptime): menunjukkan waktu, dalam detik, sejak mulai ulang terakhir.

  • Mulai Ulang Mesin (/machine/restart_count): menunjukkan jumlah total mulai ulang untuk mesin target sejak deployment-nya.

Untuk menyelesaikan langkah-langkah di bagian ini, Anda harus memenuhi prasyarat berikut:

  1. Akses ke konsol Google Cloud dan project Google Cloud yang terhubung ke Distributed Cloud.
  2. Peran IAM Monitoring Viewer, yang memungkinkan Anda melihat metrik Monitoring.
  3. (Opsional) nilai machine_id dari mesin Distributed Cloud terhubung target untuk memfilter hasil yang ditampilkan.

Menggunakan Metrics Explorer untuk memeriksa waktu beroperasi mesin dan jumlah mulai ulang

  1. Buka Metrics Explorer:

    1. Di konsol Google Cloud , buka bagian Monitoring.

    2. Di hierarki navigasi sebelah kiri, klik Metrics Explorer.

  2. Pilih jenis resource target:

    1. Di halaman Metrics Explorer, buka halaman Configuration.

    2. Klik Select a metric.

    3. Gunakan kotak penelusuran untuk menelusuri jenis resource Machine. Anda juga dapat menggunakan ID resource lengkap edgecontainer.googleapis.com/Machine.

    4. Di hasil yang ditampilkan, klik jenis resource Machine.

  3. Periksa uptime mesin:

    1. Di bagian Metric, telusuri nilai uptime.

    2. Pilih metrik Machine Uptime. Jalur lengkapnya adalah edgecontainer.googleapis.com/machine/uptime.

    3. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

    4. Dalam diagram waktu yang muncul, pastikan grafik uptime terus meningkat. Jika nilai waktu beroperasi turun ke nol dan dimulai ulang, ini menunjukkan bahwa mesin telah dimulai ulang.

  4. Periksa jumlah mulai ulang mesin:

    1. Di bagian Metric, telusuri nilai restart_count.

    2. Pilih metrik Machine Restarts. Jalur lengkapnya adalah edgecontainer.googleapis.com/machine/restart_count.

    3. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

    4. Pada diagram waktu yang muncul, pastikan garis grafik tetap berada di 0, yang menunjukkan tidak ada mulai ulang yang terjadi. Jika pada titik mana pun garis melonjak ke 1, hal ini menunjukkan bahwa mesin telah dimulai ulang; catat stempel waktu yang tepat dari mulai ulang untuk pemecahan masalah lebih lanjut.

    5. (Opsional) Untuk melihat setiap peristiwa, bukan grafik, buka bagian Aggregation di halaman, tetapkan kolom Alignment period ke 1 minute dan kolom Per-series aligner ke Delta.

Memahami hasil

Tabel berikut menjelaskan hasil yang ditampilkan oleh Metrics Explorer.

Status mesin Diagnosis Resolusi
Stabil
Metrik "Waktu Operasional Mesin" meningkat secara stabil
Delta metrik "Mulai Ulang Mesin" adalah 0
 Perangkat belum dimulai ulang. Tidak ada.
Mulai ulang bersih
Metrik "Machine Uptime" turun ke 0
Metrik "Machine Restarts" melonjak ke 1
 Mesin telah berhasil dimulai ulang dan dihubungkan kembali ke Google Cloud. Periksa log sistem untuk menentukan alasan mulai ulang.
Pemadaman listrik
Grafik metrik "Machine Uptime" memiliki jeda tanpa data
Metrik "Machine Restarts" tidak berubah selama jeda dalam waktu aktif mesin
 Mesin kehilangan daya atau konektivitas jaringan sebelum dapat dimulai ulang. Periksa kabel daya dan jaringan, konfigurasi jaringan lokal, status indikator LED.
Terputus-putus
Nilai metrik "Mesin Terhubung" bergantian antara 0 dan 1
Nilai metrik "Konektivitas Jaringan" bergantian antara 0 dan 1
 Koneksi jaringan tidak stabil, paket hilang, atau latensi berlebihan. Periksa jaringan lokal Anda untuk mengetahui apakah ada kemacetan dan hardware yang rusak.

Jika langkah-langkah penyelesaian yang tercantum dalam tabel tidak menyelesaikan masalah, hubungi Dukungan Google dengan nilai machine_id mesin yang terpengaruh dan stempel waktu pemadaman layanan.

Konektivitas mesin Distributed Cloud terhubung

Bagian ini menjelaskan cara memeriksa konektivitas internet dan Google Cloud untuk mesin yang terhubung ke Distributed Cloud menggunakan fitur Metrics Explorer di Cloud Monitoring.

Prosedur ini menggunakan metrik Monitoring berikut:

  • Machine Connected (/machine/connected): menunjukkan apakah mesin terhubung ke Google Cloud.

  • Network Connectivity (/machine/network/connectivity): menunjukkan apakah antarmuka jaringan utama mesin memiliki konektivitas internet.

Untuk menyelesaikan langkah-langkah di bagian ini, Anda harus memenuhi prasyarat berikut:

  1. Akses ke konsol Google Cloud dan project Google Cloud yang terhubung ke Distributed Cloud.
  2. Peran IAM Monitoring Viewer, yang memungkinkan Anda melihat metrik Monitoring.
  3. (Opsional) nilai machine_id dari mesin Distributed Cloud terhubung target untuk memfilter hasil yang ditampilkan.

Menggunakan Metrics Explorer untuk memeriksa konektivitas mesin

  1. Buka Metrics Explorer:

    1. Di konsol Google Cloud , buka bagian Monitoring.

    2. Di hierarki navigasi sebelah kiri, klik Metrics Explorer.

  2. Pilih jenis resource target:

    1. Di halaman Metrics Explorer, buka halaman Queries.

    2. Gunakan kotak penelusuran untuk menelusuri jenis resource Machine. Anda juga dapat menggunakan ID resource lengkap edgecontainer.googleapis.com/Machine.

    3. Di hasil yang ditampilkan, klik jenis resource Machine.

  3. Periksa koneksi mesin ke Google Cloud:

    1. Di bagian Metric, telusuri nilai connected.

    2. Pilih metrik Machine Connected. Jalur lengkapnya adalah edgecontainer.googleapis.com/machine/connected.

    3. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

    4. Pada diagram waktu yang muncul, pastikan baris Healthy tetap berada di 100% secara berurutan. Jika kapan pun nilai ini adalah 0% atau Tidak Sehat, mesin telah kehilangan konektivitas dengan Google Cloud pada waktu yang ditunjukkan.

  4. Periksa konektivitas internet mesin:

    1. Di bagian Metric, telusuri nilai connectivity.

    2. Pilih metrik Network Connectivity. Jalur lengkapnya adalah edgecontainer.googleapis.com/machine/network/connectivity.

    3. (Opsional) Filter menurut nilai machine_id target menggunakan bagian Filter.

    4. Pada diagram waktu yang muncul, pastikan baris Healthy tetap berada di 100% secara berurutan. Jika pada titik mana pun nilai ini adalah 0% Tidak Sehat, berarti mesin telah kehilangan konektivitas internet pada waktu yang ditunjukkan.

Memahami hasil

Tabel berikut menjelaskan hasil yang ditampilkan oleh Metrics Explorer.

Status mesin Diagnosis Resolusi
Sehat
Nilai metrik "Mesin Terhubung" adalah 1
Nilai metrik "Konektivitas Jaringan" adalah 1
 Operasi normal. Tidak ada.
Terputus
Nilai metrik "Mesin Terhubung" adalah 0
Nilai metrik "Konektivitas Jaringan" adalah 1
 Mesin memiliki konektivitas internet, tetapi tidak dapat terhubung ke Google Cloud. Periksa aturan firewall Anda untuk layanan Google dan endpoint API. Pastikan agen yang terhubung ke Distributed Cloud berjalan di mesin.
Terisolasi
Nilai metrik "Mesin Terhubung" adalah 0
Nilai metrik "Konektivitas Jaringan" adalah 0
 Mesin tidak memiliki konektivitas internet. Periksa kabel daya dan jaringan, konfigurasi jaringan lokal, status indikator LED. Verifikasi konfigurasi VLAN dan pemilihan rute Anda.
Terputus-putus
Nilai metrik "Mesin Terhubung" bergantian antara 0 dan 1
Nilai metrik "Konektivitas Jaringan" bergantian antara 0 dan 1
 Koneksi jaringan tidak stabil, paket hilang, atau latensi berlebihan. Periksa jaringan lokal Anda untuk mengetahui apakah ada kemacetan dan hardware yang rusak.

Jika Anda melihat nilai 0 yang berkelanjutan untuk salah satu metrik, ikuti langkah-langkah pemecahan masalah yang dijelaskan dalam tabel untuk mengatasinya. Jika masalah berlanjut, hubungi Dukungan Google dengan nilai machine_id mesin yang terpengaruh dan stempel waktu pemadaman layanan.

Virtual machine macet dalam status Pending

Workload virtual machine dapat terhenti dalam status Pending dan gagal dijadwalkan pada node jika salah satu hal berikut terjadi:

  • Distributed Cloud yang terhubung tidak dapat mengalokasikan resource yang diminta, seperti waktu CPU, memori, atau kapasitas disk, ke virtual machine.
  • Terjadi kesalahan dalam konfigurasi virtual machine.
  • Ada kesalahan pada penyimpanan virtual machine.
  • Node target di-taint.

Untuk mengatasi masalah ini, lakukan langkah berikut:

  1. Dapatkan kredensial cluster seperti yang dijelaskan dalam Mendapatkan kredensial untuk cluster.

  2. Dapatkan informasi tentang virtual machine yang terpengaruh:

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    Ganti kode berikut:

    • VM_NAME: Nama virtual machine target.
    • NAMESPACE: Namespace virtual machine target.

    Perintah ini menampilkan output yang mirip dengan berikut ini:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

    Output perintah berisi pesan yang mungkin menunjukkan batasan resource, kegagalan penjadwalan, kesalahan penyimpanan, dan masalah lainnya.

  3. Periksa output untuk menentukan penyebab kegagalan penjadwalan seperti yang dijelaskan di bagian berikutnya.

Resource tidak cukup

Anda mungkin melihat pesan yang menunjukkan resource yang tidak memadai, seperti CPU, memori, atau kapasitas disk. Contoh:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Untuk mengatasi masalah ini, periksa resource yang dialokasikan ke virtual machine yang terpengaruh dan workload lain yang dijadwalkan pada node, lalu lakukan hal berikut sesuai dengan kebutuhan bisnis Anda:

  • Perkecil skala workload lain yang dijadwalkan pada node,
  • Kurangi jumlah resource yang dialokasikan ke virtual machine yang terpengaruh,
  • Tambahkan lebih banyak mesin ke cluster yang terpengaruh.

Node yang terkena taint

Anda mungkin melihat pesan yang menunjukkan bahwa node target di-taint. Contoh:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Untuk mengatasi masalah ini, lakukan hal berikut:

  1. Gunakan perintah berikut untuk memeriksa taint pada node:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    Perintah ini menampilkan output yang mirip dengan berikut ini:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. Lakukan salah satu hal berikut:

    • Untuk taint yang tidak terduga, hapus taint tersebut seperti yang dijelaskan dalam Taint dan Toleransi.
    • Untuk taint yang diharapkan, tambahkan toleransi yang sesuai ke konfigurasi virtual machine, seperti yang dijelaskan dalam Taint dan Toleransi.

Kesalahan penyimpanan

Anda mungkin melihat pesan yang menunjukkan kesalahan pada penyimpanan virtual machine. Contoh:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Pesan ini mungkin menunjukkan bahwa volume persisten yang sesuai gagal dipasang di node target.

Untuk mengatasi masalah ini, lakukan hal berikut:

  1. Gunakan perintah berikut untuk mendapatkan status klaim volume persisten (PVC) di namespace virtual machine yang terpengaruh:

    kubectl get pvc -n NAMESPACE

    Ganti NAMESPACE dengan nama namespace target.

    Perintah ini menampilkan output yang mirip dengan berikut ini:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. Pastikan PVC yang sesuai memiliki status Bound; jika statusnya adalah Pending, subsistem penyimpanan gagal menyediakan volume. Dalam kasus tersebut, Anda harus memecahkan masalah konfigurasi subsistem penyimpanan dan memastikan bahwa StorageClass yang sesuai tersedia.

Penguncian penjadwalan yang disebabkan oleh webhook penerimaan yang gagal

Webhook penerimaan memungkinkan Anda mencegat permintaan ke server Kubernetes API sebelum objek menjadi persisten. Meskipun berguna untuk menerapkan kebijakan keamanan kustom, webhook yang salah dikonfigurasi dapat menyebabkan pemadaman layanan di seluruh cluster, terutama selama operasi penting seperti upgrade software dan pembaruan sertifikat. Secara khusus, webhook penerimaan yang diblokir atau tidak tersedia dapat menghentikan bidang kontrol Kubernetes, sehingga mencegah penjadwalan workload lebih lanjut di cluster.

Deadlock bidang kontrol

Deadlock dependensi sirkular dapat terjadi saat webhook penerimaan bertanggung jawab untuk memvalidasi resource yang diperlukan untuk pemulihan webhook itu sendiri. Misalnya, jika webhook penerimaan dikonfigurasi untuk memvalidasi Pod dan Pod webhook tersebut perlu dijadwalkan ulang selama upgrade software node, server Kubernetes API dapat mencoba menghubungi webhook untuk mengizinkan pembuatan Pod baru. Jika webhook tidak dapat dijangkau, permintaan akan gagal, Pod tidak akan dibuat, dan cluster akan memasuki status deadlock sehingga tidak ada workload baru yang dapat dijadwalkan.

Jika webhook dikonfigurasi dengan failurePolicy: Fail, setiap error komunikasi atau waktu tunggu habis antara server API dan webhook akan menyebabkan penolakan permintaan API. Hal ini menyebabkan masalah berikut:

  • Upgrade software gagal: Komponen sistem dan VM tidak dapat dijadwalkan selama dan setelah upgrade software node.
  • Layanan sistem tidak dapat dimulai: Pod infrastruktur, seperti Symcloud Storage dan VM Runtime di GDC, tidak dapat dimulai.
  • Node terjebak dalam mode pemeliharaan: Node dalam mode pemeliharaan tidak dapat direkonsiliasi atau keluar karena pengontrol diblokir oleh logika penerimaan.

Praktik terbaik konfigurasi webhook

Ikuti praktik terbaik yang dijelaskan di bagian ini untuk mencegah deadlock bidang kontrol yang dijelaskan sebelumnya. Praktik terbaik ini berlaku untuk semua objek ValidatingWebhookConfiguration dan MutatingWebhookConfiguration.

Gunakan failurePolicy: Ignore

Kecuali jika persyaratan bisnis Anda mengharuskan permintaan API harus gagal jika tidak dapat divalidasi, selalu tetapkan kolom failurePolicy ke Ignore. Hal ini memastikan bahwa server Kubernetes API terus berfungsi bahkan saat layanan webhook yang terpengaruh tidak aktif, sehingga Pod yang penting bagi sistem dapat dijadwalkan dan dipulihkan.

Mengecualikan namespace yang dicadangkan

Webhook Anda tidak boleh menangkap permintaan untuk resource di namespace yang dicadangkan. Anda harus mengecualikan namespace tersebut dari konfigurasi webhook menggunakan kolom namespaceSelector. Lihat Batasan namespace pengelolaan untuk mengetahui daftar lengkap namespace yang dicadangkan. Contoh:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Memulihkan cluster yang mengalami deadlock akibat webhook yang gagal

Jika cluster Anda mengalami deadlock karena webhook yang gagal, dan perintah kubectl untuk membuat resource mengalami waktu tunggu habis atau menampilkan error, biasanya hal ini terjadi karena webhook memiliki failurePolicy yang ditetapkan ke Fail. Ikuti langkah-langkah di bagian ini untuk memulihkan cluster dari deadlock. Jika webhook yang gagal adalah webhook mutasi, gunakan mutatingwebhookconfiguration, bukan validatingwebhookconfiguration.

  1. Identifikasi webhook yang gagal:

    1. Cantumkan webhook validasi yang di-deploy di cluster:

      kubectl get validatingwebhookconfigurations

    2. Cantumkan webhook mutasi yang di-deploy di cluster:

      kubectl get mutatingwebhookconfigurations

  2. Pastikan Pod yang mendukung webhook tersebut berjalan:

    kubectl get pods -A | grep WEBHOOK_SERVICE

    Ganti WEBHOOK_SERVICE dengan nama layanan webhook target.

  3. Tetapkan failurePolicy webhook yang gagal ke Ignore:

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    Ganti WEBHOOK_SERVICE dengan nama layanan webhook target.

  4. (Opsional) Jika langkah sebelumnya gagal, hapus paksa konfigurasi webhook yang terpengaruh:

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    Ganti WEBHOOK_CONFIG dengan nama konfigurasi webhook target.

Setelah mengubah atau menghapus paksa konfigurasi webhook, server Kubernetes API akan melanjutkan pemrosesan permintaan, menyelesaikan deadlock, dan memungkinkan proses yang diblokir selesai.