Memasukkan node ke mode pemeliharaan

Saat Anda perlu memperbaiki atau memelihara {i>node<i}, Anda harus terlebih dahulu menempatkan node ke mode pemeliharaan. Hal ini menghabiskan pod dan workload yang ada dengan lancar, kecuali pod sistem yang penting seperti server API. Mode pemeliharaan juga mencegah node agar tidak menerima penetapan pod baru. Dalam mode pemeliharaan, Anda dapat mengerjakan node Anda tanpa risiko mengganggu traffic pod.

Catatan: Saat Anda mengupgrade cluster, Google Distributed Cloud akan menggunakan mode pemeliharaan yang dijelaskan di halaman ini untuk menguras node sebelum diupgrade. Untuk selengkapnya informasi tentang proses upgrade, lihat Siklus proses dan tahapan cluster upgrade.

Cara kerjanya

Google Distributed Cloud menyediakan cara untuk menempatkan node ke mode pemeliharaan. Ini memungkinkan komponen cluster lain mengetahui dengan benar bahwa node tersebut mode pemeliharaan. Saat Anda menempatkan node dalam mode pemeliharaan, tidak ada pod tambahan dapat dijadwalkan pada node, dan pod yang ada akan dihentikan.

Daripada menggunakan mode pemeliharaan, Anda dapat menggunakan perintah Kubernetes secara manual seperti sebagai kubectl cordon dan kubectl drain di node tertentu.

Saat Anda menggunakan proses mode pemeliharaan, Google Distributed Cloud akan melakukan berikut ini:

1,29

• Google Distributed Cloud menambahkan baremetal.cluster.gke.io/maintenance:NoSchedule taint ke node tertentu untuk mencegah penjadwalan pod baru pada node.

• Google Distributed Cloud menggunakan Penghapusan API untuk mengeluarkan setiap Pod. Metode pengosongan node ini mematuhi PodDisruptionBudgets (PDB). Anda dapat mengonfigurasi PDB untuk melindungi workload Anda dengan menentukan tingkat gangguan yang dapat ditoleransi untuk kumpulan pod menggunakan kolom minAvailable dan maxUnavailable. Pengosongan node dengan cara ini memberikan perlindungan yang lebih baik terhadap beban kerja gangguan layanan. Penghentian node berbasis penghapusan tersedia sebagai GA untuk rilis 1,29.

• Waktu tunggu 20 menit diterapkan untuk memastikan node tidak macet saat menunggu agar pod berhenti. Pod mungkin tidak berhenti jika dikonfigurasikan untuk menoleransi semua taint atau mereka memiliki penyelesaian. Google Distributed Cloud berupaya menghentikan semua pod, tetapi jika waktu tunggunya habis terlampaui, node dialihkan ke mode pemeliharaan. Waktu tunggu ini mencegah menjalankan pod agar tidak memblokir upgrade.

1.28 dan yang lebih lama

• Google Distributed Cloud menambahkan baremetal.cluster.gke.io/maintenance:NoSchedule taint ke node tertentu untuk mencegah penjadwalan pod baru pada node.

• Google Distributed Cloud menambahkan taint baremetal.cluster.gke.io/maintenance:NoExecute. Bertindak berdasarkan taint NoExecute, Google Distributed Cloud kube-scheduler menghentikan pod dan menguras node. Metode pengosongan {i>node<i} ini tidak memenuhi PDB.

• Waktu tunggu 20 menit diterapkan untuk memastikan node tidak macet saat menunggu agar pod berhenti. Pod mungkin tidak berhenti jika dikonfigurasikan untuk menoleransi semua taint atau mereka memiliki penyelesaian. Google Distributed Cloud berupaya menghentikan semua pod, tetapi jika waktu tunggunya habis terlampaui, node dialihkan ke mode pemeliharaan. Waktu tunggu ini mencegah menjalankan pod agar tidak memblokir upgrade.

Pengosongan berbasis penghapusan

Tidak ada perubahan prosedural yang terkait dengan peralihan ke berbasis penghapusan pengosongan node dari pengosongan berbasis taint. Tombol memengaruhi logika rekonsiliasi saja.

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, pengeringan node berbasis taint yang dilakukan oleh Google Distributed Cloud kube-scheduler tidak menggunakan untuk mengalirkan pod dari sebuah node. Dengan pengosongan node berbasis penghapusan, pod dikeluarkan dalam urutan tertentu berdasarkan prioritas. Prioritas penghapusan adalah yang dikaitkan dengan kriteria pod tertentu, seperti ditunjukkan dalam tabel berikut:

Urutan pengosongan	Kriteria pod (harus cocok semua) dan
1	Pod yang cocok dengan kriteria berikut akan dihapus: Pod tanpa spec.prorityClassName Pod yang tidak cocok dengan Container Storage Interface (CSI) apa pun yang dikenal nama Pod yang tidak termasuk dalam DaemonSet
2	Pod yang cocok dengan kriteria berikut akan dihapus: Pod yang termasuk dalam DaemonSet Pod tidak memiliki PriorityClass Pod yang tidak cocok dengan Container Storage Interface (CSI) apa pun yang dikenal nama
3	Pod yang cocok dengan kriteria berikut akan dihapus: Pod dengan Spec.ProrityClassName Pod yang tidak cocok dengan Container Storage Interface (CSI) apa pun yang dikenal nama Urutan penghapusan untuk pod yang cocok didasarkan pada PriorityClass.value, dari rendah ke tinggi.
4	Tunggu hingga CSI membersihkan dudukan PV/PVC setelah pod selesai dikeluarkan. Gunakan Node.Status.VolumesInUse untuk menunjukkan semua volume akan dibersihkan.
5	Pod yang cocok dengan kriteria berikut akan dihapus: Pod yang cocok dengan Container Storage Interface (CSI) yang dikenal nama Pod ini masih perlu dikeringkan, karena kubelet tidak memberikan kompatibilitas upgrade langsung di tempat.

Karena pengosongan node berbasis penghapusan mengikuti PDB, setelan PDB mungkin memblokir node mungkin habis dalam keadaan tertentu. Untuk mengetahui informasi pemecahan masalah terkait kumpulan node pengosongan, lihat Memeriksa mengapa node berada dalam status terkuras untuk waktu yang lama waktu.

Menonaktifkan pengosongan node berbasis penghapusan

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

Mengatur node ke mode pemeliharaan

Pilih node yang ingin Anda masukkan ke mode pemeliharaan dengan menentukan rentang IP untuk node yang dipilih pada maintenanceBlocks dalam konfigurasi cluster Anda . Node yang Anda pilih harus dalam status siap, dan berfungsi di .

Untuk mengalihkan node ke mode pemeliharaan:

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

   Anda dapat mengedit file konfigurasi dengan editor pilihan Anda, atau Anda bisa 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 {i>node<i} yang Anda inginkan untuk dialihkan 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 mengalihkan node ke 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-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 diperhatikan bahwa node masih dapat dijadwalkan, tetapi taint menyimpan pod apa pun (tanpa toleransi yang sesuai) agar tidak dijadwalkan di node.

5. Jalankan perintah berikut untuk mendapatkan jumlah node dalam mode pemeliharaan:

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   Respons 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 di mode pemeliharaan.

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

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 bisa 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 hapus semua tindakan dari pemeliharaan mode.

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 untuk melumpuhkan cluster secara lengkap, gunakan petunjuk di bagian berikut untuk mematikan cluster dan mengaktifkannya kembali dengan aman.

Menonaktifkan cluster

Jika Anda menonaktifkan cluster yang mengelola cluster pengguna, Anda harus menonaktifkan cluster 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 {i>kubeconfig<i} untuk cluster tersebut.

   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 bukan Ready, kami sangat merekomendasikan agar Anda memecahkan masalah node dan melanjutkan hanya jika semua node bernilai Ready.

2. Jika Anda menonaktifkan cluster pengguna, periksa status admin node cluster:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Ganti ADMIN_KUBECONFIG dengan jalur {i>kubeconfig<i} untuk mengelola cluster.

   Langkah berikutnya memiliki dependensi pada cluster admin. Jika STATUS untuk node bukan Ready, maka kami sangat menyarankan agar 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 Anda memeriksa.

   • ADMIN_KUBECONFIG: jalur file kubeconfig untuk cluster pengelola.

   Perbaiki masalah yang dilaporkan sebelum melanjutkan.

4. Untuk cluster yang sedang dinonaktifkan, pastikan semua Pod etcd berlari:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   Ganti CLUSTER_KUBECONFIG dengan jalur {i>kubeconfig<i} untuk cluster tersebut.

   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, kami sangat merekomendasikan agar Anda memecahkan masalah pod dan melanjutkan hanya saat semua pod Running.

5. Lakukan pencadangan seperti yang dijelaskan dalam Mencadangkan cluster.

   Penting untuk melakukan pencadangan {i>etcd<i} sebelum mematikan cluster Anda agar bahwa cluster Anda dapat dipulihkan jika Anda mengalami masalah saat memulai ulang cluster. Kerusakan etcd, kegagalan hardware node, jaringan masalah konektivitas, dan kemungkinan kondisi lain dapat mencegah cluster sehingga tidak dapat memulai ulang dengan benar.

6. Jika Anda menonaktifkan cluster yang memiliki worker node, tempatkan worker node masuk ke dalam mode pemeliharaan.

   Langkah ini meminimalkan jumlah penulisan ke {i>etcd<i}, yang mengurangi kemungkinan bahwa sejumlah besar operasi tulis etcd perlu direkonsiliasi ketika cluster sudah dimulai ulang.

7. Masukkan node bidang kontrol ke mode pemeliharaan.

   Langkah ini mencegah penulisan yang rusak untuk beban kerja stateful selama penghentian node ke bawah.

8. Matikan node cluster dengan urutan berikut:

   1. Node pekerja
   2. Node load balancer bidang kontrol

   3. Node bidang kontrol, dimulai dengan pengikut etcd dan diakhiri dengan {i>etcd leader<i}

      Jika memiliki cluster ketersediaan tinggi (HA), Anda dapat menemukan dll. pemimpin 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 menampilkan true jika node adalah pemimpin {i>etcd<i}.

   Catatan: Server API diperkirakan tidak aktif setelah pengikut etcd ke bawah. Hal ini karena server API tidak dapat menjalankan permintaan jika {i>etcd<i} cluster kehilangan kuorum, yang diperkirakan akan terjadi saat dimatikan. Etcd diperoleh kembali kuorum setelah semua node bidang kontrol kembali online.

Pada tahap ini, cluster Anda akan dinonaktifkan sepenuhnya. Setelah Anda melakukan pemeliharaan tambahan yang diperlukan, Anda dapat memulai ulang cluster bagian.

Mulai ulang cluster

Gunakan langkah-langkah berikut untuk memulai ulang cluster yang sudah dinyalakan sepenuhnya. ke bawah.

1. Nyalakan mesin node dalam urutan terbalik dari daya mati urutan waktu.

2. Hapus node bidang kontrol dari mode pemeliharaan.

   Untuk mengetahui petunjuknya, lihat Menghapus node dari pemeliharaan mode.

   Catatan: Mesin tidak perlu dikeluarkan dari mode pemeliharaan satu per satu waktu, tetapi akan lebih baik untuk memulai dengan satu {i>node<i}, pastikan node responsif, lalu perlahan-lahan meningkatkan jumlah node dari waktu ke waktu.

3. Hapus 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 errorlooping etcd, mencegah cluster memulai ulang dengan benar, coba pulihkan cluster dari status terakhir yang diketahui cadangan. Untuk petunjuknya, lihat Memulihkan cluster.

Mode penagihan dan pemeliharaan

Penagihan untuk Google Distributed Cloud didasarkan pada jumlah vCPU cluster Anda untuk Node yang mampu menjalankan workload. Saat Anda menginstal Node ke dalam pemeliharaan mode, taint NoExecute dan NoSchedule ditambahkan ke Node, tetapi tidak ditambahkan menonaktifkan penagihan. Setelah mengalihkan node ke mode pemeliharaan, hubungkan node (kubectl cordon NODE_NAME) untuk menandainya sebagai tidak dapat dijadwalkan. Setelah node ditandai sebagai tidak dapat dijadwalkan, Node dan vCPU terkait akan dikecualikan dari penagihan.

Penting: Mematikan node tidak mengubah penagihannya . Untuk mengecualikan node dari penagihan, lakukan salah satu tindakan berikut:

• Hapus node individual dari kumpulan node
• Menghapus kumpulan node dari cluster
• Memasukkan node ke dalam pemeliharaan mode dan aktifkan agar tidak dapat dijadwalkan

Seperti yang dijelaskan di halaman harga, Anda dapat menggunakan kubectl untuk melihat kapasitas vCPU (digunakan untuk penagihan) setiap pengguna Anda klaster. Perintah tidak mempertimbangkan apakah {i>Node<i} dapat dijadwalkan, dan hanya menyediakan jumlah vCPU per node.

Untuk mengidentifikasi jumlah vCPU per node untuk cluster pengguna:

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.