Menghapus node yang diblokir oleh PodDisruptionBudget

Dalam kondisi tertentu, kebijakan PodDisruptionBudgets (PDB) dapat mencegah node berhasil dihapus dari kumpulan node. Dalam kondisi ini, status node melaporkan Ready,SchedulingDisabled meskipun telah dihapus. Dokumen ini menunjukkan cara menghapus node dari cluster Google Distributed Cloud yang saat ini diblokir oleh masalah PDB.

Halaman ini ditujukan untuk Admin dan arsitek serta Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, dan merespons pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

PDB berkonflik dengan jumlah Pod yang tersedia

Kebijakan PDB membantu memastikan performa aplikasi dengan mencegah Pod berhenti bekerja secara bersamaan saat Anda melakukan perubahan pada sistem. Oleh karena itu, kebijakan PDB membatasi jumlah Pod yang tidak tersedia secara bersamaan dalam aplikasi yang direplikasi.

Namun, kebijakan PDB terkadang dapat mencegah penghapusan node yang ingin Anda lakukan jika Anda melanggar kebijakan dengan menghapus node.

Misalnya, kebijakan PDB dapat menentukan bahwa harus selalu ada dua Pod yang tersedia dalam sistem (.spec.minAvailable adalah 2). Namun, jika Anda hanya memiliki dua Pod, dan Anda mencoba menghapus node yang berisi salah satunya, kebijakan PDB akan berlaku dan mencegah penghapusan node.

Demikian pula, saat kebijakan PDB menentukan bahwa tidak ada Pod yang boleh tidak tersedia (.spec.maxUnavailable adalah 0), kebijakan tersebut juga mencegah penghapusan node terkait. Meskipun Anda mencoba menghapus satu Pod dalam satu waktu, kebijakan PDB akan mencegah Anda menghapus node yang terpengaruh.

Menonaktifkan dan mengaktifkan kembali kebijakan PDB

Untuk mengatasi konflik PDB, buat cadangan, lalu hapus kebijakan PDB. Setelah PDB berhasil dihapus, node akan dikuras dan Pod terkait akan dihapus. Kemudian, Anda dapat melakukan perubahan yang diinginkan, dan mengaktifkan kembali kebijakan PDB.

Contoh berikut menunjukkan cara menghapus node dalam kondisi ini, yang dapat memengaruhi semua jenis cluster Google Distributed Cloud: cluster admin, hybrid, mandiri, dan pengguna.

Prosedur umum yang sama berlaku untuk semua jenis cluster. Namun, perintah khusus untuk menghapus node dari kumpulan node cluster admin (untuk cluster admin, hybrid, atau mandiri) sedikit berbeda dengan perintah untuk menghapus node dari kumpulan node cluster pengguna.

1. Untuk memudahkan pembacaan, variabel ${KUBECONFIG} digunakan dalam perintah berikut.

   Bergantung pada jenis cluster, ekspor jalur kubeconfig cluster admin (ADMIN_KUBECONFIG) atau kubeconfig cluster pengguna (USER_CLUSTER_CONFIG) ke $(KUBECONFIG) dan selesaikan langkah-langkah berikut:

   • Untuk menghapus node dari cluster pengguna, tetapkan export KUBECONFIG=USER_CLUSTER_CONFIG
   • Untuk menghapus node dari cluster admin, tetapkan export KUBECONFIG=ADMIN_KUBECONFIG.

2. Opsional: Jika Anda menghapus node dari kumpulan node cluster pengguna, jalankan perintah berikut untuk mengekstrak file kubeconfig cluster pengguna:

   kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
     get secret USER_CLUSTER_NAME-kubeconfig  \
     -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
   

   Ganti entri berikut dengan informasi khusus untuk lingkungan cluster Anda:

   • ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.
   • CLUSTER_NAME: nama cluster yang ingin Anda ambil snapshot-nya.
   • USER_CLUSTER_CONFIG: jalur ke file konfigurasi cluster pengguna.

3. Setelah menghapus node dari kumpulan node, periksa status node. Node yang terpengaruh melaporkan Ready, SchedulingDisabled:

   kubectl get nodes --kubeconfig ${KUBECONFIG}
   

   Status node terlihat mirip dengan output contoh berikut:

   NAME   STATUS                    ROLES      AGE      VERSION
   CP2    Ready                     Master     11m      v.1.18.6-gke.6600
   CP3    Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
   CP4    Ready                     <none>     9m18s    v.1.18.6-gke.6600
   

4. Periksa PDB di cluster Anda:

   kubectl get pdb --kubeconfig ${KUBECONFIG} -A
   

   Sistem melaporkan PDB yang mirip dengan yang ditampilkan dalam output contoh berikut:

   NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
   gke-system    istio-ingress    1                N/A               1                     19m
   gke-system    istiod           1                N/A               1                     19m
   kube-system   coredns          1                N/A               0                     19m
   kube-system   log-aggregator   N/A              0                 0                     19m
   kube-system   prometheus       N/A              0                 0                     19m
   

5. Periksa PDB. Temukan kecocokan antara label Pod dalam PDB dan Pod yang cocok di node. Kecocokan ini memastikan Anda menonaktifkan PDB yang benar untuk berhasil menghapus node:

   kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
   

   Sistem menampilkan hasil label yang cocok dalam kebijakan PDB:

   {"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
   

6. Temukan Pod yang cocok dengan label kebijakan PDB:

   kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
     -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'
   

   Perintah ini menampilkan daftar Pod yang cocok dengan label PDB, dan memverifikasi kebijakan PDB yang perlu Anda hapus:

   stackdriver-log-aggregator-0    CP3
   stackdriver-log-aggregator-1    CP3
   

7. Setelah mengonfirmasi Pod yang terpengaruh, buat salinan cadangan kebijakan PDB. Contoh berikut mencadangkan kebijakan log-aggregator:

   kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
     -o yaml >> log-aggregator.yaml
   

8. Hapus kebijakan PDB tertentu. Sekali lagi, contoh berikut menghapus kebijakan log-aggregator:

   kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
   

   Setelah Anda menghapus kebijakan PDB, node akan melanjutkan pengurasan. Namun, penghapusan node sepenuhnya dapat memerlukan waktu hingga 30 menit. Terus periksa status node untuk mengonfirmasi bahwa proses telah berhasil diselesaikan.

   Jika Anda ingin menghapus node secara permanen, dan juga menghapus resource penyimpanan yang terkait dengan node, Anda dapat melakukannya sebelum memulihkan kebijakan PDB. Untuk mengetahui informasi selengkapnya, lihat Menghapus resource penyimpanan.

9. Pulihkan kebijakan PDB dari salinan Anda:

   kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}
   

10. Pastikan Pod yang dihapus berhasil dibuat ulang. Dalam contoh ini, jika ada dua Pod stackdriver-log-aggregator-x, keduanya akan dibuat ulang:

    kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
    

11. Jika ingin memulihkan node, edit konfigurasi kumpulan node yang sesuai, dan pulihkan alamat IP node.

Menghapus resource penyimpanan dari node yang dihapus secara permanen

Jika Anda menghapus node secara permanen, dan tidak ingin memulihkannya ke sistem, Anda juga dapat menghapus resource penyimpanan yang terkait dengan node tersebut.

1. Periksa dan dapatkan nama volume persisten (PV) yang terkait dengan node:

   kubectl get pv --kubeconfig ${KUBECONFIG}  \
     -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t"}  \
     {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'
   

2. Hapus PV yang terkait dengan node:

   kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
   

   Ganti PV_NAME dengan nama volume persisten yang akan dihapus.

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Layanan Pelanggan Cloud. Anda juga dapat melihat Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang resource dukungan, termasuk hal berikut:

• Persyaratan untuk membuka kasus dukungan.
• Alat untuk membantu Anda memecahkan masalah, seperti konfigurasi lingkungan, log, dan metrik.
• Komponen yang didukung .