Mengelola gangguan node GKE untuk GPU dan TPU

Selama siklus proses cluster GKE yang berjalan lama, gangguan berkala pada beban kerja terjadi karena peristiwa pemeliharaan otomatis yang dikeluarkan olehGoogle Cloud untuk resource Compute Engine yang mendasari infrastruktur GKE. Halaman ini membantu Anda memahami arti gangguan node di GKE, memantau notifikasi pemeliharaan, dan meminimalkan dampak gangguan di node GKE dengan GPU dan TPU yang terpasang.

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

Apa yang dimaksud dengan gangguan node di GKE?

Cluster GKE Anda mengelola siklus proses node GKE. Node ini disediakan di VM Compute Engine, yang secara berkala mengalami peristiwa host yang disebabkan oleh berbagai alasan, seperti berikut:

  • Update dan pemeliharaan hardware atau software. Peristiwa pemeliharaan otomatis diterbitkan oleh Google Cloud.
  • Kegagalan hardware.
  • Upgrade ke VM Compute Engine. Upgrade ini berbeda dengan upgrade ke node GKE atau versi node pool.

Peristiwa host dikeluarkan untuk infrastruktur Google Cloud yang mendasarinya dan peristiwa tersebut mengabaikan kebijakan dan pengecualian pemeliharaan GKE. Selama siklus proses cluster GKE yang berjalan lama, node mungkin mengalami gangguan berkala pada beban kerja pelatihan atau penayangan. Jika gangguan ini memengaruhi node GKE Anda yang menjalankan workload AI/ML, GKE perlu memulai ulang workload yang sedang berjalan dan node yang mendasarinya.

Alasan GPU dan TPU memerlukan pengelolaan gangguan

Sebagian besar VM Compute Engine, dengan beberapa pengecualian, memiliki kebijakan pemeliharaan host yang ditetapkan ke migrasi langsung, yang berarti bahwa beban kerja yang berjalan biasanya mengalami sedikit atau tidak ada gangguan. Namun, class VM tertentu tidak mendukung migrasi langsung, termasuk VM dengan GPU dan TPU yang terpasang. 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.

Anda, atau framework yang Anda gunakan, dapat menangani konfigurasi beban kerja untuk bereaksi dengan tepat terhadap peristiwa pemeliharaan. Misalnya, Anda dapat menyimpan status tugas pelatihan AI untuk mengurangi kehilangan data.

Untuk mengelola gangguan pada beban kerja AI/ML, Anda dapat melakukan hal berikut:

Memantau notifikasi pemeliharaan

Compute Engine akan mengirimkan notifikasi saat node dan VM yang mendasarinya dijadwalkan untuk peristiwa host yang mengganggu, dan saat peristiwa ini menjadi aktif. Notifikasi tersebut mencakup informasi tentang waktu mulai yang direncanakan, jenis peristiwa, dan detail lainnya.

Di GKE versi 1.31.1-gke.2008000 dan yang lebih baru, Anda dapat memantau peristiwa pemeliharaan mendatang, termasuk peristiwa yang dijelaskan di bagian ini.

Pemeliharaan mendatang dijadwalkan, tetapi tidak aktif

Sebelum VM dengan GPU atau TPU terpasang memiliki peristiwa pemeliharaan terjadwal, Compute Engine akan mengirimkan notifikasi ke semua VM-nya. Notifikasi ini melaporkan awal masa pemeliharaan. Jika pemeliharaan mendatang dijadwalkan oleh VM, tetapi tidak aktif, GKE akan menambahkan scheduled-maintenance-time ke label node.

Untuk membuat kueri notifikasi ini di tingkat node, jalankan perintah berikut:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

Outputnya mirip dengan hal berikut ini:

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

Kolom SCHEDULED-MAINTENANCE-TIME mewakili detik, yang ditampilkan dalam format waktu epoch Unix.

Untuk membuat kueri notifikasi ini di tingkat metadata node, periksa instance untuk notifikasi peristiwa pemeliharaan.

Pemeliharaan terjadwal dimulai

Untuk kelompok mesin yang dioptimalkan akselerator yang mendukung pemeliharaan lanjutan, Anda dapat mengakses endpoint upcoming-maintenance yang memberikan informasi tentang peristiwa pemeliharaan terjadwal dan dimulai.

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

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

GKE akan mengeluarkan Pod dan menghentikan workload dengan baik dalam waktu maksimum yang telah ditentukan sebelumnya dalam periode notifikasi pemeliharaan.

Meminimalkan dampak gangguan

Untuk meminimalkan dampak gangguan node, Anda dapat memulai peristiwa pemeliharaan host secara manual.

Jika Anda tidak memulai peristiwa pemeliharaan, Compute Engine akan menyelesaikan pemeliharaan terjadwal secara rutin.

Memulai peristiwa pemeliharaan host secara manual

Saat Compute Engine mengeluarkan notifikasi tentang peristiwa pemeliharaan terjadwal, Anda dapat memulai pemeliharaan secara manual pada waktu yang sesuai dengan jadwal operasional Anda, misalnya, selama periode aktivitas yang berkurang.

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

GKE akan mengeluarkan Pod secara terkendali dan menghentikan workload sebelum peristiwa pemeliharaan dimulai dengan tindakan perform-maintenance. Durasi antara penerapan label dan dimulainya pemeliharaan bervariasi.

Mengonfigurasi GKE untuk menghentikan workload Anda dengan baik

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 terkendali dan untuk 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 penampung apa pun di Pod.

Untuk mengonfigurasi periode penghentian halus, tetapkan masa tenggang penghentian (detik) di kolom spec.terminationGracePeriodSeconds manifes Pod Anda. Misalnya, untuk mendapatkan waktu notifikasi 10 menit, tetapkan kolom spec.terminationGracePeriodSeconds dalam 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 diselesaikan dalam jangka waktu notifikasi. Jika workload Anda menggunakan framework ML seperti MaxText, Pax, atau JAX dengan Orbax, workload tersebut dapat menangkap sinyal SIGTERM shutdown dan memulai proses pembuatan checkpoint. Untuk mempelajari lebih lanjut, lihat Autocheckpoint TPU.

Proses penghentian tuntas

Saat peristiwa gangguan dimulai, baik dipicu secara manual maupun otomatis oleh VM, Compute Engine akan menandakan penonaktifan mesin yang akan datang dengan memperbarui kunci metadata maintenance-event. Dalam kedua kasus penghentian node yang akan datang, GKE akan memulai penghentian yang wajar.

Alur kerja berikut menunjukkan cara GKE menjalankan penghentian node yang wajar saat ada penonaktifan node yang akan datang:

  1. Dalam waktu 60 detik, hal berikut akan terjadi:
    1. Komponen sistem menerapkan label node cloud.google.com/active-node-maintenance yang ditetapkan ke ONGOING untuk menunjukkan bahwa beban kerja dihentikan.
    2. GKE menerapkan taint node untuk mencegah Pod baru dijadwalkan di node. Taint memiliki kunci cloud.google.com/impending-node-termination:NoSchedule. Sebaiknya ubah workload Anda untuk menoleransi taint ini karena penghentian yang diketahui terjadi.
  2. Komponen pengendali pemeliharaan mulai mengeluarkan Pod dengan mengeluarkan Pod workload terlebih dahulu, lalu mengeluarkan Pod sistem (misalnya, kube-system).
  3. GKE mengirimkan sinyal penonaktifan SIGTERM ke Pod beban kerja yang berjalan di node untuk memberi tahu Pod tersebut bahwa penghentian akan segera dilakukan. Pod dapat menggunakan pemberitahuan ini untuk menyelesaikan tugas yang sedang berlangsung. GKE berupaya semaksimal mungkin untuk menghentikan Pod ini secara terkendali.
  4. Setelah penghapusan 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 saat proses selesai. Untuk meningkatkan periode penghentian untuk workload Anda yang menggunakan GPU atau TPU, selesaikan langkah-langkah di bagian Memulai peristiwa pemeliharaan host secara manual.

Memantau progres penghentian halus yang aktif

Anda dapat memfilter log GKE berdasarkan peristiwa penghentian yang wajar 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 beban kerja dihentikan, dan ke terminating saat beban kerja selesai dan node siap dihentikan.
  • Saat membatasi penjadwalan workload baru, GKE akan menerapkan taint cloud.google.com/impending-node-termination:NoSchedule.

Langkah selanjutnya