Menghapus node yang diblokir oleh Anggaran Gangguan Pod

Dalam kondisi tertentu, kebijakan Pod Disruption Budget (PDB) dapat mencegah node berhasil dihapus dari nodepool. Dalam kondisi ini, status node melaporkan Ready,SchedulingDisabled meskipun telah dihapus.

Anggaran Gangguan Pod bertentangan dengan jumlah Pod yang tersedia

Kebijakan PDB membantu memastikan performa aplikasi dengan mencegah Pod mati pada saat yang sama ketika Anda melakukan perubahan pada sistem. Akibatnya, 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 dengan menghapus node, Anda akan melanggar kebijakan.

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 mencoba menghapus node yang berisi salah satunya, kebijakan PDB akan berlaku dan mencegah penghapusan node.

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

Solusi: menonaktifkan dan mengaktifkan kembali kebijakan PDB

Untuk mengatasi konflik ini, cadangkan dan hapus kebijakan PDB. Setelah PDB berhasil dihapus, node akan dikosongkan dan Pod terkait akan dihapus. Setelah melakukan perubahan yang diinginkan, Anda dapat mengaktifkan kembali kebijakan PDB.

Contoh berikut menunjukkan cara menghapus node dalam kondisi ini, yang dapat memengaruhi semua jenis GKE pada cluster Bare Metal: Cluster Admin, Hybrid, Mandiri, dan Pengguna.

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

Variasi perintah untuk berbagai jenis cluster

Untuk memudahkan membaca, catat placeholder ${KUBECONFIG} dalam perintah berikut. Bergantung pada jenis cluster, ekspor jalur kubeconfig (ADMIN_KUBECONFIG) cluster admin (ADMIN_KUBECONFIG) atau jalur kubeconfig (USER_CLUSTER_CONFIG) cluster pengguna ke $(KUBECONFIG), lalu ikuti langkah-langkah di bawah ini.

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

(opsional): Jika Anda menghapus node dari nodepool cluster pengguna, jalankan perintah berikut untuk mengekstrak file kubeconfig cluster pengguna. Perhatikan bahwa variabel ADMIN_KUBECONFIG menentukan jalur ke cluster admin kubeconfig, dan variabel USER_CLUSTER_NAME menentukan nama cluster:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME  \
get secret USER_CLUSTER_NAME-kubeconfig  \
-o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```

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 yang berikut ini:

NAME        STATUS                    ROLES      AGE      VERSION
abmnewCP2   Ready                     Master     11m      v.1.18.6-gke.6600
abmnewCP3   Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
abmnewCP4   Ready                     <none>     9m18s    v.1.18.6-gke.6600

Periksa PDB di cluster Anda:

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

Sistem melaporkan PDB yang mirip dengan yang ditampilkan di bawah ini:

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
 ```

Periksa PDB. Anda harus menemukan kecocokan antara label Pod dalam PDB dan Pod yang cocok dalam node. Dengan pencocokan ini, Anda dapat menonaktifkan PDB yang benar agar node berhasil dihapus:
```
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
```
Sistem akan menampilkan hasil label yang cocok dalam kebijakan PDB:
```
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
```

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 akan menampilkan daftar Pod yang cocok dengan label PDB, dan memverifikasi kebijakan PDB yang perlu Anda hapus:

stackdriver-log-aggregator-0    abmnewCP3
stackdriver-log-aggregator-1    abmnewCP3

Setelah mengonfirmasi Pod yang terpengaruh, buat salinan cadangan kebijakan PDB, dalam contoh ini, kebijakan log-aggregator:
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
-o yaml >> log-aggregator.yaml
```
Hapus kebijakan PDB tertentu, dalam hal ini, kebijakan log-aggregator:
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
Setelah Anda menghapus kebijakan PDB, node akan mulai dikosongkan. Namun, perlu waktu beberapa saat (hingga 30 menit) agar node benar-benar dihapus, jadi terus periksa status node tersebut.

Perhatikan bahwa jika ingin menghapus node secara permanen, dan juga menghapus resource penyimpanan yang terkait dengan node, Anda dapat melakukannya sebelum memulihkan kebijakan PDB. Lihat Menghapus resource penyimpanan.

Pulihkan kebijakan PDB dari salinan Anda:

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

Pastikan bahwa Pod yang dihapus berhasil dibuat ulang. Dalam contoh ini, jika ada dua Pod stackdriver-log-aggregator-x, Pod tersebut akan dibuat ulang:
```
kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
```

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

Menghapus resource penyimpanan dari node yang dihapus secara permanen

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

Dalam perintah berikut, perhatikan variabel berikut:

ADMIN-KUBECONFIG menentukan jalur ke cluster admin
USER_CLUSTER_CONFIG menentukan jalur ke file YAML konfigurasi cluster.

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}'

Hapus PV yang terkait dengan node:

kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}