Mengelola cluster GKE yang dioptimalkan untuk AI

Halaman ini menunjukkan cara mengelola cluster Google Kubernetes Engine (GKE) yang dioptimalkan untuk AI pada mesin A4X Max, A4X, A4, A3 Ultra, A3 Mega, dan A3 High (8 GPU), termasuk peristiwa umum berikut yang relevan dengan cluster GKE dan beban kerja AI:

• Pemeliharaan host
• Upgrade cluster
• Pelaporan host yang rusak

Mengelola pemeliharaan host untuk workload AI

Node GKE berjalan di instance Compute Engine yang secara berkala mengalami peristiwa host yang dapat mengganggu workload AI. Karena peristiwa host terjadi pada infrastruktur Google Cloud dasar, peristiwa tersebut melewati masa pemeliharaan dan pengecualian GKE. Meskipun sebagian besar instance komputasi memiliki kebijakan pemeliharaan host yang ditetapkan ke migrasi langsung, yang meminimalkan gangguan beban kerja, GPU dan TPU tidak mendukung migrasi langsung. Jika peristiwa host ini memengaruhi node GKE yang menjalankan beban kerja AI, GKE harus menghentikan node dan Pod yang berjalan di node tersebut. Jika Pod di-deploy sebagai bagian dari workload yang lebih besar seperti Job atau Deployment, GKE akan mencoba memulai ulang Pod di node yang terpengaruh.

Untuk mempelajari lebih lanjut cara mengelola pemeliharaan host pada instance komputasi yang mendasarinya, lihat Mengelola gangguan node GKE untuk GPU dan TPU.

Memantau peristiwa pemeliharaan host

Untuk cluster yang menjalankan GKE versi 1.31.1-gke.2008000 atau yang lebih baru, Anda dapat melihat waktu mulai terjadwal dari peristiwa pemeliharaan host dengan cara berikut. Waktu mulai diwakili oleh label node Kubernetes pada node GKE yang sesuai untuk semua GPU dan TPU.

Untuk mengetahui detailnya, lihat Memantau notifikasi pemeliharaan.

Dengan label node ini, Anda dapat melakukan hal berikut:

• Memulai peristiwa pemeliharaan host secara manual
• Menggunakan informasi peristiwa pemeliharaan host saat menjadwalkan workload

Memulai peristiwa pemeliharaan host secara manual

Setelah Compute Engine mengeluarkan notifikasi tentang peristiwa pemeliharaan terjadwal, Anda dapat memulai pemeliharaan secara manual pada waktu yang sesuai dengan jadwal Anda. Misalnya, Anda dapat memilih untuk melakukan pemeliharaan selama periode aktivitas yang lebih rendah.

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

Ikuti petunjuk untuk Memulai peristiwa pemeliharaan host secara manual. Selain itu, lanjutkan membaca bagian ini untuk mempelajari hal berikut:

• Mengonfigurasi GKE untuk menghentikan workload Anda dengan benar
• Proses penghentian yang benar
• Memantau progres penghentian sementara yang aktif

Menggunakan informasi pemeliharaan host saat menjadwalkan workload Anda

Anda dapat menggunakan informasi pemeliharaan yang ditampilkan melalui label node GKE bersama dengan afinitas dan anti-afinitas node untuk meminimalkan gangguan pada workload Anda.

Lihat bagian berikut untuk mengetahui contoh cara menggunakan informasi ini.

Menjadwalkan Pod ke node yang tidak memiliki acara pemeliharaan terjadwal di masa mendatang

Anda dapat menginstruksikan GKE untuk hanya menjadwalkan Pod ke node yang tidak memiliki peristiwa pemeliharaan terjadwal di masa mendatang, seperti dengan cuplikan berikut:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Menjadwalkan Pod ke node yang memiliki pemeliharaan terjadwal setelah tanggal tertentu

Anda dapat menginstruksikan GKE untuk hanya menjadwalkan Pod ke node yang memiliki jadwal pemeliharaan setelah tanggal tertentu dengan memberikan waktu epoch Unix:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

Mengelola upgrade cluster GKE untuk workload AI

Workload AI sensitif terhadap gangguan.

Selama siklus proses cluster GKE, workload AI harus dipersiapkan untuk menghadapi gangguan pada instance komputasi yang mendasarinya, serta cluster GKE itu sendiri:

• Pemeliharaan host: Untuk mengelola pemeliharaan host instance komputasi yang mendasarinya, lihat Mengelola gangguan node GKE untuk GPU dan TPU. Hal ini juga dijelaskan di bagian sebelumnya.
• Upgrade cluster: Untuk mengelola gangguan dari upgrade cluster, Anda dapat menggunakan alat berikut:
  • Periode pemeliharaan: Jadwalkan kapan GKE dapat melakukan upgrade cluster dan jenis operasi cluster lainnya.
  • Pengecualian pemeliharaan: Mencegah upgrade cluster dan jenis operasi cluster lainnya selama jangka waktu tertentu.

Sebaiknya Anda tetap mendaftarkan cluster di saluran rilis. Cluster GKE, secara default, terdaftar di saluran rilis Reguler. Untuk mempelajari lebih lanjut manfaat saluran rilis, lihat Perbandingan antara cluster yang terdaftar dan tidak terdaftar di saluran rilis.

Dengan saluran rilis, Anda mendapatkan akses ke lebih banyak fitur, termasuk cakupan pengecualian pemeliharaan tambahan. Sebaiknya gunakan cakupan "tidak ada upgrade minor atau node" untuk workload AI.

Melaporkan host yang rusak melalui GKE

Bagian ini menguraikan cara melaporkan host yang rusak yang memiliki instance komputasi yang disediakan melalui GKE menggunakan model penyediaan terikat reservasi. Jika Anda ingin melaporkan host yang rusak untuk node yang disediakan menggunakan model penyediaan mulai fleksibel (Pratinjau), hubungi tim akun Anda.

Perhatian: Melaporkan host yang rusak adalah tindakan yang mengganggu dan akan menghentikan VM Anda. Sebelum melaporkan host, selidiki lingkungan Anda secara menyeluruh menggunakan alat seperti pemindai kesehatan cluster (CHS) untuk mengidentifikasi penyebab utama masalah. Hanya laporkan host sebagai rusak jika Anda tidak memiliki alternatif lain untuk menyelesaikan masalah Anda.

Host adalah mesin server fisik tunggal di pusat data yang menjalankan instance komputasi yang menghosting node GKE Anda. Anda dapat melaporkan host yang bermasalah dengan menerapkan label node fault-behavior ke node GKE yang terpengaruh. Setelah Anda menerapkan label node ke node GKE tertentu, GKE melakukan langkah-langkah berikut:

1. Mengeluarkan workload dari node secara tuntas.
2. Mencegah Pod baru dijadwalkan di node.
3. Memanggil API di instance komputasi untuk menandai host sebagai rusak.
4. Menunggu hingga instance komputasi diaktifkan kembali di mesin host yang responsif. Untuk reservasi yang menggunakan semua kapasitas mode operasional reservasi, Compute Engine akan mengembalikan instance komputasi di node yang sama setelah operasi perbaikan selesai.
5. Menghapus taint dan label fault-behavior dari node.

Setelah itu, node akan siap melayani workload lagi.

Persyaratan

Untuk melaporkan host yang rusak, node GKE Anda harus memenuhi persyaratan berikut:

• Anda harus menjalankan patch GKE versi 1.32.3-gke.1057001 atau yang lebih baru.
• Anda harus menjalankan salah satu jenis mesin GPU berikut: A4X Max, A4X, A4, A3 Ultra, A3 Mega, dan A3 High (8 GPU).
• Anda harus menjalankan node GKE di instance komputasi yang terikat dengan reservasi.
• Node GKE Anda harus dalam status RUNNING. Jika Anda mencoba melaporkan host yang rusak setelah menghapus instance komputasi, pesan error akan ditampilkan, dan mesin host tidak akan ditandai sebagai rusak.
• Anda mungkin dibatasi jumlah panggilan ke API ini per reservasi per bulan berdasarkan evaluasi kondisi blok Anda. Batas kecepatan tidak berlaku jika reservasi Anda menggunakan mode operasional reservasi semua kapasitas.

Melaporkan host yang rusak

Catatan: Data SSD lokal akan dihapus setelah pemanggilan API berhasil saat instance komputasi berpindah host. Sebaiknya cadangkan data SSD lokal Anda sebelum melaporkan node yang rusak melalui GKE.

Untuk melaporkan host yang rusak:

1. Gunakan alat observasi GKE, alat pemantauan Anda sendiri, atau log untuk mengidentifikasi node GKE yang mengalami masalah performa. Simpan NODE_NAME.

2. Laporkan node sebagai rusak:

   Penting: Setelah Anda melaporkan host sebagai rusak, jangan kirim permintaan tambahan hingga operasi selesai. GKE menolak permintaan tambahan saat operasi sedang berlangsung.

     kubectl label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON
   

   Ganti kode berikut:

   • NODE_NAME: nama node yang bermasalah.
   • FAULT_REASON: alasan kesalahan yang sesuai menggunakan satu atau beberapa nilai berikut:
     • PERFORMANCE: gunakan nilai ini jika GPU pada instance komputasi berperforma lebih lambat daripada GPU lain dalam cluster dan Anda tidak melihat error XID dalam log, dan tidak ada pola kegagalan umum lainnya seperti kerusakan data diam-diam yang terdeteksi.
     • SDC: gunakan nilai ini untuk kerusakan data senyap, jika Anda melihat kerusakan data tetapi tidak ada error sistem. Kerusakan data ini dapat disebabkan oleh kerusakan CPU, bug software seperti use-after-free atau memory stomping, masalah kernel, atau kerusakan lainnya. Biasanya, istilah ini digunakan untuk merujuk pada kerusakan akibat hardware.
     • XID: gunakan nilai ini jika Anda mengidentifikasi error GPU yang tidak dapat dipulihkan dengan XID untuk instance komputasi.
     • unspecified: gunakan nilai ini jika Anda tidak yakin perilaku apa yang menyebabkan masalah pada instance komputasi Anda. Nilai ini adalah nilai default. Namun, sebaiknya tentukan salah satu nilai lainnya, jika berlaku.

Setelah Anda melaporkan host yang rusak untuk node, waktu saat node dimulai ulang bervariasi berdasarkan mode operasional reservasi yang ditentukan dalam reservasi yang digunakan node. Untuk memverifikasi mode operasional pemesanan, lihat kolom reservationOperationalMode di pemesanan. Tabel berikut merangkum proses host yang bermasalah untuk dua mode operasional reservasi yang tersedia: mode semua kapasitas dan mode terkelola.

	Semua mode kapasitas (ALL_CAPACITY)	Mode terkelola (HIGHLY_AVAILABLE_CAPACITY)
Jenis mesin yang didukung	A4X Max dan A4X	A4, A3 Ultra, A3 Mega, dan A3 High
Pembatasan frekuensi API laporan host yang bermasalah	Tidak ada batas kapasitas yang berlaku.	Panggilan ke API mungkin dibatasi lajunya.
Proses pelaporan host yang bermasalah	Saat Anda melaporkan host yang rusak untuk node yang berjalan dalam mode semua kapasitas, hal berikut akan terjadi: Mengeluarkan Pod: Setelah label diterapkan ke node yang bermasalah, GKE akan memberi taint pada node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang sedang berjalan di node secara terkendali. GKE mematuhi Anggaran Gangguan Pod (PDB) dan kolom spec.terminationGracePeriodSeconds dari manifes Pod Anda. Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi GKE untuk menghentikan workload Anda dengan benar. Melaporkan dan memperbaiki host yang rusak: GKE secara otomatis melaporkan dan memperbaiki host yang rusak dengan memanggil Compute Engine API, yang menghasilkan urutan operasi yang biasanya memerlukan waktu 10-12 menit untuk melaporkan host yang rusak dan kemudian dapat memerlukan waktu 3-14 hari, atau bahkan lebih lama terkadang, untuk memperbaiki host. Mulai ulang instance: Setelah operasi perbaikan host selesai (biasanya 3-14 hari), salah satu hal berikut akan terjadi: Jika instance dalam status REPAIRING dan resource tersedia saat perbaikan selesai, Compute Engine akan otomatis memulai ulang instance di host yang diperbaiki. Jika tidak, jika instance dalam status TERMINATED atau jika resource tidak tersedia saat perbaikan selesai, maka status instance tetap atau berubah menjadi TERMINATED. Anda harus memulai ulang instance secara manual saat Anda ingin instance berjalan. Namun, memulai ulang instance mungkin gagal jika resource tidak tersedia saat Anda memulai ulang instance; misalnya, hal ini dapat terjadi jika instance lain sudah menggunakan host yang diperbaiki.	Saat Anda melaporkan host yang rusak untuk node yang berjalan dalam mode terkelola, hal berikut akan terjadi: Mengeluarkan Pod: Setelah label diterapkan ke node yang bermasalah, GKE akan memberi taint pada node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang sedang berjalan di node secara terkendali. GKE mematuhi Anggaran Gangguan Pod (PDB) dan kolom spec.terminationGracePeriodSeconds dari manifes Pod Anda. Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi GKE untuk menghentikan workload Anda dengan benar. Melaporkan dan mulai memperbaiki host yang rusak: GKE secara otomatis melaporkan dan memperbaiki host yang rusak dengan memanggil Compute Engine API, yang menghasilkan urutan operasi yang biasanya memerlukan waktu 10-12 menit untuk melaporkan host yang rusak, lalu dapat memerlukan waktu 3-14 hari, atau bahkan lebih lama terkadang, untuk memperbaiki host. Memigrasikan dan memulai ulang instance: Setelah operasi perbaikan host dimulai (biasanya 10-12 menit), Compute Engine akan mencoba mencadangkan satu host lagi untuk menggantikan host yang dilaporkan rusak dalam kapasitas yang dicadangkan. Jika Compute Engine menemukan host yang responsif—jika berhasil mengganti host yang rusak atau menemukan host responsif yang cocok dalam kapasitas yang Anda pesan—maka Compute Engine akan memigrasikan instance ke host tersebut. Kemudian, instance dimulai ulang melalui salah satu hal berikut: Jika instance dalam status REPAIRING dan resource tersedia sebelum atau saat perbaikan selesai, Compute Engine akan otomatis memulai ulang instance di host yang responsif. Jika tidak, jika instance berada dalam status TERMINATED atau jika resource tidak tersedia sebelum atau saat perbaikan selesai, maka status instance tetap atau berubah menjadi TERMINATED. Anda harus memulai ulang instance secara manual saat Anda ingin instance berjalan. Namun, memulai ulang instance mungkin gagal jika resource tidak tersedia saat Anda memulai ulang instance; misalnya, hal ini dapat terjadi jika instance lain sudah menggunakan host yang diperbaiki.

Memantau progres operasi

Anda dapat memantau progres operasi GKE menggunakan label node cloud.google.com/report-and-replace-status di node GKE, yang memiliki salah satu nilai berikut:

• PodsEvicted: GKE telah selesai mengeluarkan Pod dari node yang terpengaruh.
• OperationRUNNING: operasi untuk melaporkan host yang bermasalah sedang berjalan.
• OperationDone: host yang mendasarinya telah dilaporkan rusak dan node GKE siap dipindahkan ke host baru
• Error: Panggilan API gagal, karena alasan yang mencakup salah satu persyaratan yang dijelaskan di bagian sebelumnya.

Anda juga dapat melihat label node cloud.google.com/report-and-replace-operation untuk melihat ID operasi Compute Engine guna memantau status operasi.

Anda dapat melihat kedua label node ini menggunakan perintah berikut:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/report-and-replace-operation

Jika terjadi error API, GKE akan menetapkan label node cloud.google.com/report-and-replace-status=ERROR. GKE menghapus taint node dan menghapus label node cloud.google.com/fault-behavior.

Untuk mempelajari cara melacak status mendetail dari operasi melaporkan host yang rusak, lihat Meninjau operasi melaporkan host yang rusak.

Untuk mencoba lagi operasi karena error sementara seperti batas kecepatan, terapkan kembali label cloud.google.com/fault-behavior ke node.

Langkah berikutnya

• Pelajari cara menjadwalkan workload GKE dengan Topology Aware Scheduling.

• Pelajari cara mengoptimalkan jaringan cluster menggunakan NCCL/gIB.

• Pelajari cara memecahkan masalah error API host yang salah dalam laporan.