Memahami cara melakukan pemeliharaan host di GKE

Selama siklus proses cluster GKE yang berjalan lama, gangguan berkala pada workload terjadi karena gangguan infrastruktur yang dikeluarkanCloud de Confiance by S3NS . Peristiwa otomatis ini dapat terjadi untuk merespons keputusan penjadwalan (peristiwa preemption), atau update node, yang mencakup upgrade otomatis node GKE (peristiwa pemeliharaan), atau remediasi masalah yang terdeteksi (peristiwa penghentian).

Dokumen ini membantu Anda memahami arti gangguan node di GKE dan meminimalkan dampak gangguan pada node GKE Anda.

Untuk mengetahui detail tentang cara memantau notifikasi dan peristiwa pemeliharaan, lihat Memantau peristiwa pemeliharaan.

Dokumen ini berlaku untuk jenis mesin berikut:

Dokumen ini ditujukan untuk admin dan operator Platform yang mengelola siklus proses infrastruktur teknis yang mendasarinya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Cloud de Confiance by S3NS , lihat Peran dan tugas pengguna GKE umum.

Apa yang dimaksud dengan gangguan infrastruktur di GKE?

Cluster GKE Anda mengelola siklus proses node GKE. Node ini disediakan di VM Compute Engine, yang secara berkala mengalami gangguan berikut:

  • Perbaikan masalah yang terdeteksi (TerminationEvent): peristiwa ini terjadi karena Cloud de Confiance by S3NS mendeteksi masalah dan mengganggu infrastruktur cluster Anda. Peristiwa TerminationEvent tidak mendukung penghentian normal. Peristiwa TerminationEvent dipicu oleh masalah berikut:

    • Perbaikan otomatis terjadi saat GKE memperbaiki node setelah health check gagal berulang kali.
    • HostError terjadi saat error hardware atau software pada mesin fisik menyebabkan VM berhenti.

  • Peristiwa pemeliharaan atau upgrade (MaintenanceEvent): peristiwa ini terjadi saat Cloud de Confiance by S3NS harus menginterupsi VM untuk melakukan pemeliharaan. Peristiwa ini dipicu oleh tugas pemeliharaan berikut:

    • Peristiwa pemeliharaan terjadi saat Cloud de Confiance by S3NS mengupgrade host yang mendasarinya.
    • Update node, yang mencakup upgrade otomatis node, terjadi saat GKE mengupdate konfigurasi node, seperti versi GKE.

    Untuk mengetahui informasi selengkapnya tentang cara Anda dan GKE mengelola perubahan selama siklus proses cluster, lihat Jenis perubahan.

  • Respons terhadap keputusan penjadwalan (PreemptionEvent): peristiwa ini terjadi saat Cloud de Confiance by S3NS harus mendahului VM untuk menyediakan kapasitas bagi resource dengan prioritas lebih tinggi. Peristiwa PreemptionEvent dapat berupa salah satu dari hal berikut:

    • Pengusiran: terjadi saat infrastruktur preemptible atau Spot di-preempt untuk mengakomodasi VM dengan prioritas lebih tinggi.
    • Defragmentasi: terjadi saat GKE mendahului slice TPU yang lebih kecil untuk mengakomodasi slice TPU yang lebih besar. Defragmentasi hanya terjadi pada slice TPU.

Selama siklus proses cluster GKE yang berjalan lama, node mungkin mengalami gangguan berkala pada workload. Jika gangguan ini memengaruhi node GKE yang menjalankan workload Anda, GKE harus memulai ulang workload yang berjalan dan node yang mendasarinya.

Alasan node yang tidak mendukung migrasi langsung memerlukan pengelolaan gangguan

Sebagian besar VM Compute Engine, dengan beberapa pengecualian, memiliki kebijakan pemeliharaan host yang ditetapkan ke migrasi langsung, yang berarti bahwa workload yang berjalan biasanya mengalami sedikit atau tanpa gangguan. Namun, kelas VM tertentu tidak mendukung migrasi langsung, termasuk jenis mesin berikut:

  • Jenis mesin dengan GPU dan TPU yang terpasang.
  • Jenis mesin H4D.
  • Jenis mesin c4a-highmem-96-metal.
  • Jenis mesin bare metal C4D (c4d-standard-384-metal, c4d-highcpu-384-metal, dan c4d-highmem-384-metal).
  • Jenis mesin Z3 dengan Titanium SSD terpasang yang berkapasitas lebih dari 18 TiB.
  • Jenis mesin Z4D dengan lebih dari 42 TiB Titanium SSD yang terpasang.
  • Jenis mesin Z4M dengan Titanium SSD terpasang lebih dari 48 TiB, atau instance Z4M apa pun yang menggunakan Cloud RDMA.

Misalnya, saat peristiwa host terjadi pada VM dalam slice TPU, seluruh slice akan terganggu, lalu dijadwalkan ulang karena semua peristiwa pemeliharaan dikoordinasikan di tingkat slice. Jadi, jika Anda membuat slice TPU yang memiliki ratusan VM, semua VM tersebut akan menerima jadwal peristiwa pemeliharaan yang sama.

Saat peristiwa host terjadi, GKE menghentikan node dan Pod-nya. Jika Pod di-deploy sebagai bagian dari workload yang lebih besar, seperti Job atau Deployment, GKE akan memulai ulang Pod di node yang terpengaruh.

Mengelola peristiwa pemeliharaan

Bagian selanjutnya dalam dokumen ini menjelaskan cara mengelola gangguan MaintenanceEvent.

Mengelola gangguan node selama peristiwa pemeliharaan host mengikuti alur kerja tiga tahap:

  1. Mendeteksi pemeliharaan host terjadwal: gunakan label node GKE, endpoint metadata, atau log.
  2. Tindak lanjuti pemeliharaan yang terdeteksi: jika pemeliharaan dijadwalkan, evaluasi infrastruktur dan workload Anda, lalu tentukan tindakan terbaik untuk kasus penggunaan Anda. Lakukan tindakan yang sesuai, seperti membiarkan sistem menangani peristiwa pemeliharaan secara otomatis, memulai pemeliharaan host secara manual, atau mengatur strategi pemeliharaan.
  3. Verifikasi hasil peristiwa pemeliharaan: verifikasi bahwa peristiwa pemeliharaan dimulai dengan benar, baik saat Compute Engine memulai peristiwa pemeliharaan sesuai jadwal atau saat Anda memulainya secara manual.

Mendeteksi pemeliharaan host terjadwal

Untuk memantau dan mendeteksi peristiwa pemeliharaan mendatang, Anda harus melihat notifikasi dari GKE dan Compute Engine.

Untuk mengetahui detail tentang cara memantau notifikasi dan peristiwa pemeliharaan, lihat Memantau peristiwa pemeliharaan.

Menindaklanjuti pemeliharaan yang terdeteksi

Jika Anda melihat notifikasi pemeliharaan terjadwal mendatang untuk satu atau beberapa node di cluster, gunakan pohon keputusan berikut untuk menentukan cara terbaik menangani gangguan:

  1. Pemeliharaan otomatis: mengizinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal. VM Anda akan otomatis dimigrasikan secara langsung di latar belakang dengan gangguan minimal atau tanpa gangguan.

    1. Jika VM host mendukung migrasi langsung, sebaiknya biarkan peristiwa pemeliharaan terjadi secara otomatis.
    2. Jika workload Anda berjalan di node fleksibel nonaktif, Anda dapat mengoptimalkan waktu pemeliharaan secara otomatis dengan mengonfigurasi pemeliharaan oportunistik. Hal ini akan memicu update yang diperlukan hanya selama periode waktu tidak ada aktivitas yang alami.

  2. Memulai peristiwa pemeliharaan host secara manual: evaluasi pertanyaan berikut untuk menentukan cara terbaik dalam menangani gangguan secara manual:

    1. Apakah node yang terpengaruh adalah VM tunggal atau terisolasi?

      • Ya (Saya menjalankan VM tunggal atau terisolasi):
        • Jika Anda tidak memerlukan kontrol waktu yang tepat, izinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal (otomatis default).
        • Jika Anda perlu menghindari preemption yang tidak terduga, mulai peristiwa pemeliharaan host secara manual pada setiap node pada waktu yang tepat, misalnya, selama periode traffic kecil.
      • Tidak (Saya menjalankan node pool akselerator): pilih salah satu opsi di langkah berikutnya.

    2. Pilih salah satu opsi berikut berdasarkan kasus penggunaan Anda:

      • Jika pool akselerator Anda menjalankan tugas pelatihan AI/ML yang digabungkan: terapkan strategi paralel. Simpan status pelatihan Anda ke checkpoint, nonaktifkan pool dengan baik, dan lakukan update host serta upgrade cluster GKE secara bersamaan sebelum memulai ulang.

      • Jika pool akselerator Anda menjalankan endpoint inferensi atau penyaluran AI/ML dengan ketersediaan tinggi: terapkan strategi berkelanjutan. Koordinasikan pemeliharaan host terjadwal dan upgrade versi dalam batch berkelanjutan dalam batas zona atau pool Anda, menggunakan replika aktif untuk melindungi SLA.

Memulai peristiwa pemeliharaan host secara manual di VM tunggal atau terisolasi

Anda dapat memulai pemeliharaan yang dapat dijadwalkan ulang secara manual saat sesuai dengan jadwal Anda, seperti selama waktu aktivitas rendah. Untuk melakukannya, terapkan label cloud.google.com/perform-maintenance=true jika kondisi berikut terpenuhi:

  • Compute Engine mengeluarkan pemberitahuan tentang peristiwa pemeliharaan terjadwal.
  • Peristiwa pemeliharaan Compute Engine yang mendasarinya dapat dijadwalkan ulang. Untuk memeriksa apakah jadwal peristiwa dapat diubah, cari notifikasi can_reschedule=TRUE di metadata peristiwa. Jika jadwal acara tidak dapat diubah, penetapan label cloud.google.com/perform-maintenance=true tidak akan berpengaruh, dan pemeliharaan akan dilakukan pada waktu yang dijadwalkan semula.

Jika kondisi sebelumnya terpenuhi, pada node di node pool, tetapkan label node cloud.google.com/perform-maintenance ke true. Contoh:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Jika Anda memulai peristiwa pemeliharaan, GKE akan menjalankan operasi berikut:

  1. Memberi taint pada node.
  2. Mengeluarkan Pod secara tuntas.
  3. Meminta Compute Engine untuk segera memulai peristiwa pemeliharaan, bukan menunggu waktu yang dijadwalkan.

Memverifikasi hasil peristiwa pemeliharaan

Setelah mendeteksi peristiwa pemeliharaan mendatang dan memutuskan tindakan terbaik, Anda dapat memverifikasi hasil peristiwa pemeliharaan.

Compute Engine memulai peristiwa pemeliharaan sesuai jadwal

Saat peristiwa pemeliharaan dimulai, node mungkin akan dihentikan satu atau beberapa kali dengan waktu notifikasi singkat sebelum penghentiannya yang akan segera terjadi. Dalam kasus ini, GKE melakukan upaya terbaik untuk menghentikan workload dan mengeluarkan Pod secara halus.

Pemeliharaan terjadwal dimulai

Saat pemeliharaan terjadwal dimulai, Compute Engine akan memperbarui metadata di direktori http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine mengupdate label metadata sebagai berikut:

  • Menetapkan maintenance-event ke TERMINATE_ON_HOST_MAINTENANCE.
  • Di upcoming-maintenance, tetapkan maintenance_status ke ONGOING.

GKE mendeteksi dan menangani peristiwa pemeliharaan host terjadwal, baik Anda memicunya secara manual maupun membiarkan GKE melanjutkan secara otomatis.

Metrik sistem GKE berikut melaporkan jumlah gangguan untuk node GKE sejak sampel terakhir (metrik diambil sampelnya setiap 60 detik):

  • kubernetes.io/node/interruption_count

Kolom interruption_type (seperti TerminationEvent, MaintenanceEvent, atau PreemptionEvent) dan interruption_reason (seperti HostError, Eviction, atau AutoRepair) dapat membantu memberikan alasan mengapa node terganggu.

Untuk mendapatkan perincian gangguan dan penyebabnya di node TPU dalam cluster di project Anda, gunakan kueri PromQL berikut:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Agar hanya melihat peristiwa pemeliharaan host, perbarui kueri untuk memfilter nilai HW/SW Maintenance untuk interruption_reason. Gunakan kueri PromQL berikut:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Untuk melihat jumlah gangguan yang digabungkan berdasarkan node pool, gunakan kueri PromQL berikut:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Konfigurasi lanjutan untuk meminimalkan gangguan

Bagian ini menjelaskan alat tambahan untuk mengonfigurasi cluster dan workload Anda guna meminimalkan gangguan.

Mengaktifkan penanganan gangguan

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Untuk mengaktifkan penanganan gangguan, buat file bernama maintenance-config.yaml dengan ConfigMap ini. Terapkan ConfigMap ke cluster dengan perintah berikut:

kubectl apply -f my-configmap.yaml

Mengonfigurasi GKE untuk menghentikan workload Anda secara halus

Di bagian ini, Anda akan mengonfigurasi GKE untuk mengelola siklus proses aplikasi dan meminimalkan gangguan pada workload. Jika Anda tidak mengonfigurasi masa tenggang, masa tenggang akan ditetapkan secara default ke 30 detik.

GKE melakukan upaya terbaik untuk menghentikan Pod ini secara tuntas dan menjalankan tindakan penghentian yang Anda tentukan, misalnya, menyimpan status pelatihan. GKE mengirimkan sinyal SIGTERM ke Pod di awal masa tenggang. Jika Pod tidak keluar pada akhir masa tenggang, GKE akan mengirimkan sinyal SIGKILL lanjutan ke proses apa pun yang masih berjalan di container mana pun dalam Pod.

Untuk mengonfigurasi periode penghentian tuntas, tetapkan masa tenggang penghentian (detik) di kolom spec.terminationGracePeriodSeconds manifes Pod Anda. Misalnya, untuk mendapatkan waktu notifikasi 10 menit, tetapkan kolom spec.terminationGracePeriodSeconds di manifes Pod Anda ke 600 detik, seperti berikut:

    spec:
      terminationGracePeriodSeconds: 600

Sebaiknya tetapkan masa tenggang penghentian yang cukup lama agar tugas yang sedang berlangsung dapat selesai dalam jangka waktu notifikasi. Jika workload Anda menggunakan framework ML seperti MaxText, Pax, atau JAX dengan Orbax, workload dapat menangkap sinyal SIGTERM shutdown dan memulai proses checkpointing. Untuk mempelajari lebih lanjut, lihat TPU Autocheckpoint.

Proses penghentian tuntas

Saat peristiwa pemeliharaan yang dimulai secara manual dimulai, Compute Engine akan memberi sinyal penonaktifan mesin yang akan datang dengan memperbarui kunci metadata maintenance-event. GKE memulai penghentian halus.

Alur kerja berikut menunjukkan cara GKE menjalankan penghentian node secara halus saat ada penonaktifan node yang akan terjadi:

  1. Dalam waktu 60 detik, hal berikut akan terjadi:
    1. Komponen sistem menerapkan kumpulan label node cloud.google.com/active-node-maintenance ke ONGOING untuk menunjukkan bahwa workload sedang dihentikan.
    2. GKE menerapkan taint node untuk mencegah Pod baru dijadwalkan pada node. Taint memiliki kunci cloud.google.com/impending-node-termination:NoSchedule. Sebaiknya Anda tidak mengubah workload untuk mentoleransi taint ini karena penghentian yang diketahui terjadi.
  2. Komponen maintenance-handler mulai mengeluarkan Pod dengan mengeluarkan Pod workload terlebih dahulu, lalu mengeluarkan Pod sistem (misalnya, kube-system).
  3. GKE mengirimkan sinyal shutdown SIGTERM ke Pod workload yang berjalan di node untuk memberi tahu bahwa node akan segera dihentikan. Pod dapat menggunakan pemberitahuan ini untuk menyelesaikan tugas yang sedang berlangsung. GKE melakukan upaya terbaik untuk menghentikan Pod ini secara halus.
  4. Setelah pengosongan selesai, GKE akan memperbarui nilai label cloud.google.com/active-node-maintenance menjadi terminating untuk menunjukkan bahwa node siap dihentikan.

Setelah itu, penghentian node akan terjadi dan node pengganti akan dialokasikan. GKE akan menghapus label dan taint setelah proses selesai. Untuk meningkatkan periode penghentian workload menggunakan GPU atau TPU, selesaikan langkah-langkah di bagian Memulai peristiwa pemeliharaan host secara manual.

Memverifikasi progres penghentian halus yang aktif

Anda dapat memfilter log GKE berdasarkan peristiwa penghentian halus berikut:

  • Saat VM mendeteksi gangguan karena penghentian node yang akan datang seperti peristiwa pemeliharaan host Compute Engine, GKE akan menetapkan cloud.google.com/active-node-maintenance ke ONGOING saat workload dihentikan, dan ke terminating saat workload selesai dan node siap dihentikan.
  • Saat membatasi workload baru agar tidak dijadwalkan, GKE menerapkan taint cloud.google.com/impending-node-termination:NoSchedule.

Meminimalkan gangguan pada workload yang berjalan dengan pemeliharaan oportunistik

Anda dapat meminimalkan gangguan pada workload yang sedang berjalan dengan memicu pemeliharaan secara otomatis saat GKE mendeteksi bahwa node dengan GPU atau TPU tidak ada aktivitas. Untuk mengaktifkan fitur ini, buat node pool baru. Anda tidak dapat mengaktifkan pemeliharaan oportunistik pada node pool yang ada.

Membuat node pool baru dengan pemeliharaan oportunistik

Perintah berikut menunjukkan cara membuat node pool dengan pemeliharaan oportunistik yang diaktifkan:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Ganti nilai berikut:

  • NODE_POOL_NAME: nama node pool GKE Anda.
  • CLUSTER_NAME : nama cluster GKE Anda.
  • NODE_IDLE_TIME : jumlah waktu yang dapat digunakan node untuk tetap tidak ada aktivitas (yaitu, tidak ada workload yang menggunakan akselerator yang berjalan) sebelum pemeliharaan dipicu. Nilai ini mewakili durasi dalam detik, dengan maksimal sembilan digit pecahan, dan diakhiri dengan karakter s, misalnya: 80000s.
  • MIN_NODES : jumlah minimum node yang harus tersedia di node pool. Opsi ini memblokir pemeliharaan jika menyebabkan jumlah node yang berjalan berada di bawah nilai ini, misalnya: 10.
  • WINDOW : periode waktu, dalam detik, saat pemeliharaan oportunistik dapat dijalankan. Nilai diakhiri dengan karakter s. Misalnya, nilai 14 hari, atau 1209600s, berarti pemeliharaan oportunistik hanya dapat dijalankan dalam dua minggu sebelum tanggal pemeliharaan terjadwal. Nilai 28 hari, atau 2419200s, memungkinkan pemeliharaan oportunistik berjalan kapan saja selama masa pemeliharaan terjadwal. Periode untuk pemeliharaan host Compute Engine ini berbeda dengan masa pemeliharaan GKE, yang menentukan kapan pemeliharaan cluster GKE dapat terjadi dan dikonfigurasi secara terpisah.

Contoh konfigurasi untuk pemeliharaan oportunistik

Perhatikan contoh berikut. Anda memiliki node pool dengan empat node dan konfigurasi pemeliharaan oportunistik ditetapkan ke --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. Dalam skenario ini, hal berikut akan terjadi:

  • node1 memiliki workload GPU yang berjalan di dalamnya. Node ini tidak dalam status tidak ada aktivitas, sehingga dilewati.
  • node2 tidak ada aktivitas selama 60 detik. Node ini belum tidak ada aktivitas dalam waktu yang cukup, sehingga dilewati.
  • node3 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak ada aktivitas.
  • node4 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak ada aktivitas.

node3 dan node4 memenuhi persyaratan tidak ada aktivitas. Namun, hanya satu dari node ini yang akan memicu pemeliharaan oportunistik karena nilai opsi min-nodes ditetapkan ke 3.

Memeriksa konfigurasi dan status node dengan pemeliharaan oportunistik

Periksa apakah pemeliharaan oportunistik dikonfigurasi untuk node dengan menjalankan perintah berikut:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Ganti NODE_NAME dengan nama node yang ingin Anda periksa.

Periksa apakah node yang dikonfigurasi dengan pemeliharaan oportunistik sedang menjalani pemeliharaan:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Jika node dipicu oleh pemeliharaan oportunistik, anotasi maintenance-state akan menampilkan opportunistic-triggered sebagai true.

Batasan

Perhatikan batasan pemeliharaan oportunistik berikut:

  • Fitur ini hanya dapat digunakan dengan node pool GPU dan TPU.
  • Pemeliharaan oportunistik tidak kompatibel dengan penskalaan otomatis cluster karena autoscaler cluster sudah memperkecil skala node yang tidak ada aktivitas.
  • Untuk node pool TPU multi-host, nilai setelan min-nodes-per-pool harus 0 karena node pool ini bersifat atomik.
  • Versi GKE minimum yang didukung adalah 1.33.3-gke.1118000.
  • Hanya pemeliharaan terencana yang menyertakan notifikasi can_reschedule=TRUE yang didukung.
  • Untuk menonaktifkan fitur ini, Anda harus membuat ulang node pool tanpa flag masing-masing. Atau, Anda dapat menonaktifkan fitur ini secara manual di node tertentu dengan cloud.google.com/opportunistic-disable=true.
  • Dalam kasus yang jarang terjadi, pemeliharaan mungkin memerlukan waktu lebih lama untuk diselesaikan pada sebuah node. Pelanggan yang menggunakan fitur ini mungkin mengalami lebih sedikit node yang tersedia, hingga nilai setelan min-nodes-per-pool, selama jangka waktu tertentu.

Langkah berikutnya