Menempatkan node ke mode pemeliharaan

Mode pemeliharaan memungkinkan Anda memperbaiki dan menyervis node dengan gangguan minimal pada workload Anda. Saat Anda menambahkan node ke bagian maintenanceBlocks pada konfigurasi cluster, Google Distributed Cloud akan mengosongkan workload-nya dengan baik dan mencegah pod baru dijadwalkan di node tersebut. Jika perlu membuat seluruh cluster offline, Anda juga dapat menonaktifkan dan memulai ulang cluster dengan aman.

Selama upgrade cluster, Google Distributed Cloud otomatis menggunakan mode pemeliharaan untuk mengosongkan node sebelum diupgrade. Untuk mengetahui informasi selengkapnya tentang proses upgrade, lihat Siklus proses dan tahap upgrade cluster.

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

Alih-alih 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 di node tersebut.

  • Google Distributed Cloud menggunakan Eviction API untuk mengeluarkan setiap Pod. Metode pengosongan node ini mematuhi PodDisruptionBudget (PDB). Anda dapat mengonfigurasi PDB untuk melindungi workload dengan menentukan tingkat gangguan yang dapat ditoleransi untuk sekumpulan pod menggunakan kolom minAvailable dan maxUnavailable. Mengosongkan node dengan cara ini memberikan perlindungan yang lebih baik terhadap gangguan workload. Pengosongan node berbasis pengeluaran tersedia sebagai GA untuk rilis 1.29.

  • Waktu tunggu 20 menit diterapkan untuk memastikan node tidak terjebak menunggu pod berhenti. Pod mungkin tidak berhenti jika dikonfigurasi untuk mentoleransi semua taint atau memiliki finalizer. Google Distributed Cloud mencoba menghentikan semua pod, tetapi jika waktu tunggu terlampaui, node akan dimasukkan 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 di node tersebut.

  • Google Distributed Cloud menambahkan taint baremetal.cluster.gke.io/maintenance:NoExecute. Berdasarkan taint NoExecute, 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 terjebak menunggu pod berhenti. Pod mungkin tidak berhenti jika dikonfigurasi untuk mentoleransi semua taint atau memiliki finalizer. Google Distributed Cloud mencoba menghentikan semua pod, tetapi jika waktu tunggu terlampaui, node akan dimasukkan ke mode pemeliharaan. Waktu tunggu ini mencegah pod yang berjalan memblokir upgrade.

Pengosongan berbasis pengeluaran

Tidak ada perubahan prosedural yang terkait dengan peralihan ke pengosongan node berbasis pengeluaran dari pengosongan 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 kube-scheduler Google Distributed Cloud tidak menggunakan algoritma tertentu untuk mengosongkan pod dari node. Dengan pengosongan node berbasis pengeluaran, pod dikeluarkan dalam urutan tertentu berdasarkan prioritas. Prioritas penghapusan dikaitkan 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:

  • Pod tanpa spec.prorityClassName
  • Pod yang tidak cocok dengan nama Container Storage Interface (CSI) yang diketahui
  • Pod yang bukan milik DaemonSet
2

Pod yang cocok dengan kriteria berikut akan dikeluarkan:

  • Pod yang termasuk dalam DaemonSet
  • Pod tidak memiliki PriorityClass
  • Pod yang tidak cocok dengan nama Container Storage Interface (CSI) yang diketahui
3

Pod yang cocok dengan kriteria berikut akan dikeluarkan:

  • Pod dengan Spec.ProrityClassName
  • Pod yang tidak cocok dengan nama Container Storage Interface (CSI) yang diketahui

Urutan penghapusan untuk pod yang cocok didasarkan pada PriorityClass.value, dari rendah ke tinggi.
4

Tunggu hingga CSI membersihkan pemasangan PV/PVC setelah semua pod dikeluarkan. Gunakan Node.Status.VolumesInUse untuk menunjukkan bahwa semua volume telah dibersihkan.
5

Pod yang cocok dengan kriteria berikut akan dikeluarkan:

  • Pod yang cocok dengan nama Container Storage Interface (CSI) yang diketahui

Pod ini masih perlu dikosongkan, karena kubelet tidak menyediakan kompatibilitas upgrade di tempat.

Karena pengosongan node berbasis pengosongan mematuhi PDB, setelan PDB mungkin memblokir pengosongan node dalam beberapa situasi. Untuk mengetahui informasi pemecahan masalah tentang pengosongan node pool, lihat Memeriksa alasan node berada dalam status pengosongan dalam waktu lama.

Batas waktu untuk pengosongan berbasis penghapusan

Saat Anda menempatkan node ke mode pemeliharaan, sistem akan menerapkan waktu tunggu default selama 20 menit (1200 detik) untuk mengosongkan node. Setelah waktu tunggu berlalu, semua Pod yang tidak menoleransi mode pemeliharaan akan dikeluarkan dan node akan dimasukkan ke mode pemeliharaan. Mulai versi 1.16, Anda dapat menambahkan anotasi baremetal.cluster.gke.io/maintenance-mode-deadline-seconds ke resource cluster untuk menyesuaikan durasi waktu tunggu. Misalnya, untuk mengubah waktu tunggu menjadi 10 menit, tambahkan anotasi baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600" ke resource cluster Anda.

Pengosongan berbasis pengeluaran terkadang dapat melebihi batas waktu yang ditentukan oleh maintenance-mode-deadline-seconds. Jika Pod terjebak dalam status penghentian setelah batas waktu terlampaui, jangan gunakan kubectl dengan flag --grace-period=0 --force untuk menghapusnya secara paksa, karena hal ini dapat menyebabkan kerusakan data atau masalah split-brain untuk aplikasi stateful. Sebagai gantinya, mulai ulang node dengan Pod stateful yang macet.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care. Anda juga dapat melihat Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang referensi dukungan, termasuk referensi berikut:

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

Menonaktifkan pengosongan node berbasis pengeluaran

Pengosongan node berbasis pengeluaran diaktifkan secara default untuk cluster pada versi minor 1.29 dan yang lebih baru atau cluster yang diupgrade ke versi minor 1.29 dan yang lebih baru. Jika pengosongan node berbasis pengusiran menyebabkan masalah pada upgrade cluster atau pemeliharaan cluster, Anda dapat kembali ke pengosongan node berbasis taint dengan menambahkan anotasi baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: "" ke resource cluster.

Untuk memulihkan perilaku pengosongan node berbasis pengeluaran default, hapus anotasi sepenuhnya. Menetapkan anotasi ke false tidak akan mengaktifkan kembali perilaku default.

Menempatkan node ke dalam mode pemeliharaan

Pilih node yang ingin Anda tempatkan ke 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 di cluster.

Untuk menempatkan node ke dalam mode pemeliharaan:

  1. Edit file konfigurasi cluster untuk memilih node yang ingin Anda tempatkan ke mode pemeliharaan.

    Anda dapat mengedit file konfigurasi dengan editor pilihan Anda, atau Anda dapat 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.

  2. Tambahkan bagian maintenanceBlocks ke file konfigurasi cluster untuk menentukan satu alamat IP, atau rentang alamat, untuk node yang ingin Anda tempatkan ke 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

  3. Simpan dan terapkan konfigurasi cluster yang telah diperbarui.

    Google Distributed Cloud mulai menempatkan node ke dalam mode pemeliharaan.

  4. 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-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600

    Perhatikan bahwa node masih dapat dijadwalkan, tetapi taint mencegah pod apa pun (tanpa toleransi yang sesuai) dijadwalkan pada node.

  5. 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 berada dalam mode pemeliharaan.

    Google Distributed Cloud juga menambahkan taint berikut ke node saat node tersebut dimasukkan ke dalam 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:

  1. Edit file konfigurasi cluster untuk menghapus node yang ingin Anda hapus dari mode pemeliharaan.

    Anda dapat mengedit file konfigurasi dengan editor pilihan Anda, atau Anda dapat 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.

  2. Edit alamat IP untuk menghapus node tertentu dari mode pemeliharaan atau hapus bagian maintenanceBlocks untuk menghapus semua node dari mode pemeliharaan.

  3. Simpan dan terapkan konfigurasi cluster yang telah diperbarui.

  4. Gunakan perintah kubectl untuk memeriksa status node Anda.

Mematikan dan memulai ulang cluster

Jika perlu menonaktifkan seluruh cluster, gunakan petunjuk di bagian berikut untuk menonaktifkan cluster dan mengaktifkannya kembali dengan aman.

Mematikan cluster

Jika Anda 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.

  1. 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 node bukan Ready, sebaiknya Anda memecahkan masalah node dan melanjutkan hanya jika semua node adalah Ready.

  2. 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 pengelolaan.

    Langkah-langkah berikutnya memiliki dependensi pada cluster admin. Jika STATUS untuk node bukan Ready, sebaiknya Anda memecahkan masalah node dan melanjutkan hanya jika semua node adalah Ready.

  3. Periksa kondisi cluster yang ingin Anda nonaktifkan:

    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 pengelolaan.

    Perbaiki masalah yang dilaporkan sebelum melanjutkan.

  4. Untuk cluster yang Anda nonaktifkan, 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 pod bukan Running, sebaiknya Anda memecahkan masalah pod dan melanjutkan hanya jika semua pod adalah Running.

  5. Lakukan pencadangan seperti yang dijelaskan dalam Mencadangkan cluster.

    Anda harus melakukan pencadangan etcd sebelum menonaktifkan cluster agar cluster dapat dipulihkan jika Anda mengalami masalah saat memulai ulang cluster. Kerusakan etcd, kegagalan hardware node, masalah konektivitas jaringan, dan kemungkinan kondisi lainnya dapat mencegah cluster dimulai ulang dengan benar.

  6. Jika Anda menonaktifkan cluster dengan worker node, tempatkan worker node ke dalam mode pemeliharaan.

    Langkah ini meminimalkan jumlah penulisan ke etcd, sehingga mengurangi kemungkinan bahwa sejumlah besar penulisan etcd perlu direkonsiliasi saat cluster dimulai ulang.

  7. Tempatkan node bidang kontrol ke dalam mode pemeliharaan.

    Langkah ini mencegah penulisan yang rusak untuk workload stateful selama penonaktifan node.

  8. Matikan node cluster dalam urutan berikut:

    1. Worker node
    2. Node load balancer bidang kontrol

    3. Node bidang kontrol, dimulai dengan pengikut etcd dan diakhiri dengan pemimpin 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

      Responsnya mencakup kolom IS LEADER, yang menampilkan true jika node adalah leader etcd.

Pada tahap ini, cluster Anda telah 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 telah dimatikan sepenuhnya.

  1. Nyalakan mesin node dalam urutan terbalik dari urutan penonaktifan.

  2. Hapus node bidang kontrol dari mode pemeliharaan.

    Untuk mengetahui petunjuknya, lihat Menghapus node dari mode pemeliharaan.

  3. Menghapus worker node dari mode pemeliharaan.

  4. Jalankan health check cluster untuk memastikan cluster beroperasi dengan benar:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

  5. Jika masalah, seperti crashlooping etcd, mencegah cluster dimulai ulang dengan benar, coba pulihkan cluster dari cadangan terakhir yang diketahui berfungsi dengan baik. 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 ke mode pemeliharaan, taint NoExecute dan NoSchedule akan ditambahkan ke Node, tetapi tidak menonaktifkan penagihan. Setelah menempatkan node ke dalam mode pemeliharaan, beri cordon pada node (kubectl cordon NODE_NAME) untuk menandainya sebagai tidak dapat diberi schedule. Setelah node ditandai sebagai tidak dapat diberi schedule, Node dan vCPU terkait akan dikecualikan dari penagihan.

Seperti yang dijelaskan di halaman harga, Anda dapat menggunakan kubectl untuk melihat kapasitas vCPU (digunakan untuk penagihan) untuk 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.