Saat perlu memperbaiki atau memelihara node, Anda harus terlebih dahulu mengalihkan node ke mode pemeliharaan. Hal ini akan mengosongkan pod dan workload yang ada dengan baik, kecuali pod sistem penting seperti server API. Mode Pemeliharaan juga mencegah node menerima penetapan pod baru. Dalam mode pemeliharaan, Anda dapat mengerjakan node tanpa risiko mengganggu traffic pod.
Cara kerjanya
Google Distributed Cloud menyediakan cara untuk menempatkan node ke dalam mode pemeliharaan. Pendekatan ini memungkinkan komponen cluster lain mengetahui dengan benar bahwa node tersebut berada dalam mode pemeliharaan. Saat Anda menempatkan node dalam mode pemeliharaan, tidak ada pod tambahan yang dapat dijadwalkan pada node, dan pod yang ada akan dihentikan.
Daripada menggunakan mode pemeliharaan, Anda dapat menggunakan perintah Kubernetes secara manual seperti kubectl cordon
dan kubectl drain
pada node tertentu.
Saat Anda menggunakan proses mode pemeliharaan, Google Distributed Cloud akan melakukan hal berikut:
1,29
Google Distributed Cloud menambahkan taint
baremetal.cluster.gke.io/maintenance:NoSchedule
ke node yang ditentukan untuk mencegah penjadwalan pod baru pada node.Google Distributed Cloud menggunakan Eviction API untuk mengeluarkan setiap Pod. Metode pengosongan node ini mematuhi PodDisruptionBudgets (PDB). Anda dapat mengonfigurasi PDB untuk melindungi workload dengan menentukan tingkat gangguan yang dapat ditoleransi untuk satu set pod menggunakan kolom
minAvailable
danmaxUnavailable
. Menguras node dengan cara ini memberikan perlindungan yang lebih baik terhadap gangguan beban kerja. Penghentian node berbasis penghapusan tersedia sebagai GA untuk rilis 1.29.Waktu tunggu 20 menit diterapkan untuk memastikan node tidak macet saat menunggu pod berhenti. Pod mungkin tidak akan berhenti jika dikonfigurasi untuk menoleransi semua taint atau memiliki finalizer. Google Distributed Cloud mencoba menghentikan semua pod, tetapi jika waktu tunggu habis, node akan dialihkan ke mode pemeliharaan. Waktu tunggu ini mencegah pod yang berjalan memblokir upgrade.
1.28 dan yang lebih lama
Google Distributed Cloud menambahkan taint
baremetal.cluster.gke.io/maintenance:NoSchedule
ke node yang ditentukan untuk mencegah penjadwalan pod baru pada node.Google Distributed Cloud menambahkan taint
baremetal.cluster.gke.io/maintenance:NoExecute
. Dengan bertindak pada taintNoExecute
,kube-scheduler
Google Distributed Cloud akan menghentikan pod dan mengosongkan node. Metode pengosongan node ini tidak mematuhi PDB.Waktu tunggu 20 menit diterapkan untuk memastikan node tidak macet saat menunggu pod berhenti. Pod mungkin tidak akan berhenti jika dikonfigurasi untuk menoleransi semua taint atau memiliki finalizer. Google Distributed Cloud mencoba menghentikan semua pod, tetapi jika waktu tunggu habis, node akan dialihkan ke mode pemeliharaan. Waktu tunggu ini mencegah pod yang berjalan memblokir upgrade.
Draining berbasis penghapusan
Tidak ada perubahan prosedural yang terkait dengan peralihan ke node berbasis penggusuran yang menguras node berbasis taint. Tombol ini hanya memengaruhi logika rekonsiliasi.
Kemampuan ini tidak berada pada tahap peluncuran yang sama untuk semua versi yang didukung:
- 1,29: GA
- 1,28: Tidak tersedia
- 1.16: Tidak tersedia
Urutan pengosongan
Sebelum rilis 1.29, pengosongan node berbasis taint yang dilakukan oleh
Google Distributed Cloud kube-scheduler
tidak menggunakan algoritma
tertentu untuk menguras pod dari node. Dengan pengosongan node berbasis penghapusan, pod
akan dikeluarkan dalam urutan tertentu berdasarkan prioritas. Prioritas penghapusan terkait dengan kriteria pod tertentu seperti yang ditunjukkan dalam tabel berikut:
Urutan pengosongan | Kriteria pod (harus cocok dengan semua) dan |
---|---|
1 |
Pod yang cocok dengan kriteria berikut akan dikeluarkan:
|
2 |
Pod yang cocok dengan kriteria berikut akan dikeluarkan:
|
3 |
Pod yang cocok dengan kriteria berikut akan dikeluarkan:
Urutan penghapusan untuk pod yang cocok didasarkan pada
|
4 |
Tunggu hingga CSI membersihkan dudukan PV/PVC setelah semua pod dikeluarkan. Gunakan |
5 |
Pod yang cocok dengan kriteria berikut akan dikeluarkan:
Pod ini masih perlu dikosongkan, karena kubelet tidak menyediakan kompatibilitas upgrade yang ada. |
Karena pengosongan node berbasis penghapusan memenuhi PDB, setelan PDB mungkin memblokir pengosongan node dalam beberapa situasi. Untuk mengetahui informasi pemecahan masalah tentang pengosongan kumpulan node, lihat Memeriksa alasan node berada dalam status pengosongan dalam waktu yang lama.
Menonaktifkan pengosongan node berbasis penghapusan
Penghentian node berbasis penghapusan diaktifkan secara default untuk cluster di versi minor
1.29 atau cluster yang diupgrade ke versi minor 1.29. Jika pengosongan node
berbasis eviction menyebabkan masalah dengan upgrade cluster atau pemeliharaan cluster, Anda
dapat kembali ke pengosongan node berbasis taint dengan menambahkan
anotasi baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true
ke
resource cluster Anda.
Memasukkan node ke mode pemeliharaan
Pilih node yang ingin dimasukkan ke dalam mode pemeliharaan dengan menentukan rentang IP untuk node yang dipilih di bagian maintenanceBlocks
dalam file konfigurasi cluster Anda. Node yang Anda pilih harus dalam status siap dan berfungsi dalam
cluster.
Untuk menyetel node ke mode pemeliharaan:
Edit file konfigurasi cluster untuk memilih node yang ingin Anda masukkan ke mode pemeliharaan.
Anda dapat mengedit file konfigurasi dengan editor pilihan, atau mengedit resource kustom cluster secara langsung dengan menjalankan perintah berikut:
kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
Ganti kode berikut:
CLUSTER_NAMESPACE
: namespace cluster.CLUSTER_NAME
: nama cluster.
Tambahkan bagian
maintenanceBlocks
ke file konfigurasi cluster untuk menentukan satu alamat IP, atau rentang alamat, untuk node yang ingin dimasukkan ke dalam mode pemeliharaan.Contoh berikut menunjukkan cara memilih beberapa node dengan menentukan rentang alamat IP:
metadata: name: my-cluster namespace: cluster-my-cluster spec: maintenanceBlocks: cidrBlocks: - 172.16.128.1-172.16.128.64
Simpan dan terapkan konfigurasi cluster yang telah diupdate.
Google Distributed Cloud mulai mengalihkan node ke mode pemeliharaan.
Jalankan perintah berikut untuk mendapatkan status node di cluster Anda:
kubectl get nodes --kubeconfig=KUBECONFIG
Outputnya mirip dengan hal berikut ini:
NAME STATUS ROLES AGE VERSION user-anthos-baremetal-01 Ready control-plane 2d22h v1.27.4-gke.1600 user-anthos-baremetal-04 Ready worker 2d22h v1.27.4-gke.1600 user-anthos-baremetal-05 Ready worker 2d22h v1.27.4-gke.1600 user-anthos-baremetal-06 Ready worker 2d22h v1.27.4-gke.1600
Perlu diketahui bahwa node masih dapat dijadwalkan, tetapi taint membuat pod apa pun (tanpa toleransi yang sesuai) dijadwalkan pada node.
Jalankan perintah berikut untuk mendapatkan jumlah node dalam mode pemeliharaan:
kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG
Responsnya akan terlihat seperti contoh berikut:
NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN np1 3 0 0 1 0
Kolom
UNDERMAINTENANCE
dalam contoh ini menunjukkan bahwa satu node sedang dalam mode pemeliharaan.Google Distributed Cloud juga menambahkan taint berikut ke node saat masuk ke mode pemeliharaan:
baremetal.cluster.gke.io/maintenance:NoExecute
baremetal.cluster.gke.io/maintenance:NoSchedule
Menghapus node dari mode pemeliharaan
Untuk menghapus node dari mode pemeliharaan:
Edit file konfigurasi cluster untuk menghapus node yang ingin Anda hapus dari mode pemeliharaan.
Anda dapat mengedit file konfigurasi dengan editor pilihan, atau mengedit resource kustom cluster secara langsung dengan menjalankan perintah berikut:
kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
Ganti kode berikut:
CLUSTER_NAMESPACE
: namespace cluster.CLUSTER_NAME
: nama cluster.
Edit alamat IP untuk menghapus node tertentu dari mode pemeliharaan atau hapus bagian
maintenanceBlocks
menghapus semua yang dilakukan dari mode pemeliharaan.Simpan dan terapkan konfigurasi cluster yang telah diupdate.
Gunakan perintah
kubectl
untuk memeriksa status node Anda.
Mematikan dan memulai ulang cluster
Jika diperlukan untuk menonaktifkan cluster lengkap, gunakan petunjuk di bagian berikut untuk menonaktifkan cluster dan mengaktifkannya kembali dengan aman.
Mematikan cluster
Jika menonaktifkan cluster yang mengelola cluster pengguna, Anda harus menonaktifkan semua cluster pengguna terkelola terlebih dahulu. Petunjuk berikut berlaku untuk semua jenis cluster Google Distributed Cloud.
Periksa status semua node cluster:
kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
Ganti
CLUSTER_KUBECONFIG
dengan jalur file kubeconfig untuk cluster.Outputnya mirip dengan hal berikut ini:
NAME STATUS ROLES AGE VERSION control-0 Ready control-plane 202d v1.27.4-gke.1600 control-1 Ready control-plane 202d v1.27.4-gke.1600 control-2 Ready control-plane 202d v1.27.4-gke.1600 worker-0 Ready worker 202d v1.27.4-gke.1600 worker-1 Ready worker 202d v1.27.4-gke.1600 worker-2 Ready worker 202d v1.27.4-gke.1600 worker-3 Ready worker 202d v1.27.4-gke.1600 worker-4 Ready worker 154d v1.27.4-gke.1600 worker-5 Ready worker 154d v1.27.4-gke.1600 worker-6 Ready worker 154d v1.27.4-gke.1600 worker-7 Ready worker 154d v1.27.4-gke.1600 worker-8 Ready worker 154d v1.27.4-gke.1600 worker-9 Ready worker 154d v1.27.4-gke.1600
Jika
STATUS
untuk sebuah node bukanReady
, sebaiknya pecahkan masalah node tersebut dan hanya lanjutkan saat semua node sudahReady
.Jika Anda menonaktifkan cluster pengguna, periksa status node cluster admin:
kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
Ganti
ADMIN_KUBECONFIG
dengan jalur file kubeconfig untuk cluster pengelola.Langkah-langkah berikutnya akan bergantung pada cluster admin. Jika
STATUS
untuk node bukanReady
, kami sangat menyarankan agar Anda memecahkan masalah node dan hanya melanjutkan jika semua node adalahReady
.Periksa kondisi cluster yang ingin dinonaktifkan:
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Ganti kode berikut:
CLUSTER_NAME
: nama cluster yang Anda periksa.ADMIN_KUBECONFIG
: jalur file kubeconfig untuk cluster pengelola.
Perbaiki masalah yang dilaporkan sebelum melanjutkan.
Untuk cluster yang akan dinonaktifkan, pastikan semua Pod
etcd
berjalan:kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -l component=etcd
Ganti
CLUSTER_KUBECONFIG
dengan jalur file kubeconfig untuk cluster.Outputnya mirip dengan hal berikut ini:
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system etcd-control-0-admin 1/1 Running 0 2d22h kube-system etcd-control-1-admin 1/1 Running 0 2d22h kube-system etcd-control-2-admin 1/1 Running 0 2d22h
Jika
STATUS
untuk sebuah pod bukanRunning
, sebaiknya Anda memecahkan masalah pod dan melanjutkan hanya ketika semua pod sudahRunning
.Lakukan pencadangan seperti yang dijelaskan dalam Mencadangkan cluster.
Penting untuk melakukan pencadangan etcd sebelum menonaktifkan cluster agar cluster Anda dapat dipulihkan jika Anda mengalami masalah saat memulai ulang cluster. Kerusakan Etcd, kegagalan hardware node, masalah konektivitas jaringan, dan potensi kondisi lainnya dapat mencegah cluster dimulai ulang dengan benar.
Jika Anda menonaktifkan cluster dengan node pekerja, masukkan node pekerja ke dalam mode pemeliharaan.
Langkah ini meminimalkan jumlah penulisan ke etcd, yang mengurangi kemungkinan besarnya penulisan etcd harus direkonsiliasi saat cluster dimulai ulang.
Tempatkan node bidang kontrol ke mode pemeliharaan.
Langkah ini mencegah penulisan yang rusak untuk workload stateful selama penonaktifan node.
Matikan node cluster dengan urutan berikut:
- Node pekerja
- Node load balancer bidang kontrol
Node bidang kontrol, dimulai dengan pengikut etcd dan diakhiri dengan leader etcd
Jika memiliki cluster ketersediaan tinggi (HA), Anda dapat menemukan pemimpin etcd dengan menggunakan SSH untuk terhubung ke setiap node bidang kontrol dan menjalankan perintah
etcdctl
berikut:ETCDCTL_API=3 etcdctl \ --cacert /etc/kubernetes/pki/etcd/ca.crt \ --cert /etc/kubernetes/pki/etcd/server.crt \ --key /etc/kubernetes/pki/etcd/server.key \ --write-out=table endpoint status
Respons mencakup kolom
IS LEADER
, yang menampilkantrue
jika node adalah pemimpin etcd.
Pada tahap ini, cluster Anda dinonaktifkan sepenuhnya. Setelah melakukan pemeliharaan yang diperlukan, Anda dapat memulai ulang cluster seperti yang dijelaskan di bagian berikutnya.
Memulai ulang cluster
Gunakan langkah-langkah berikut untuk memulai ulang cluster yang sudah benar-benar dimatikan.
Aktifkan mesin node dalam urutan terbalik dari urutan power down.
Lepaskan node bidang kontrol dari mode pemeliharaan.
Untuk mengetahui petunjuknya, lihat Menghapus node dari mode pemeliharaan.
Hapus worker node dari mode pemeliharaan.
Jalankan health check cluster untuk memastikan cluster beroperasi dengan benar:
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Jika ada masalah, seperti etcd errorlooping, mencegah cluster memulai ulang dengan benar, coba pulihkan cluster dari cadangan terakhir yang diketahui. Untuk mengetahui petunjuknya, lihat Memulihkan cluster.
Mode penagihan dan pemeliharaan
Penagihan untuk Google Distributed Cloud didasarkan pada jumlah vCPU yang dimiliki cluster Anda untuk Node yang mampu menjalankan workload. Saat Anda menempatkan Node dalam mode pemeliharaan, taint NoExecute
dan NoSchedule
akan ditambahkan ke Node, tetapi tidak menonaktifkan penagihan. Setelah menyetel node ke mode pemeliharaan, tandai node
(kubectl cordon NODE_NAME
) untuk menandainya sebagai tidak dapat dijadwalkan. Setelah node ditandai sebagai tidak dapat dijadwalkan, Node dan vCPU terkaitnya akan dikecualikan dari penagihan.
Seperti yang dijelaskan di halaman harga, Anda dapat menggunakan kubectl
untuk melihat kapasitas vCPU (digunakan untuk penagihan) dari setiap cluster pengguna. Perintah ini tidak mempertimbangkan apakah Node dapat dijadwalkan atau tidak. Perintah ini hanya memberikan jumlah vCPU per node.
Untuk mengidentifikasi jumlah vCPU per node untuk cluster pengguna Anda:
kubectl get nodes \
--kubeconfig USER_KUBECONFIG \
-o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
{.status.capacity.cpu}{\"\n\"}{end}"
Ganti USER_KUBECONFIG dengan jalur file kubeconfig untuk cluster pengguna Anda.