Mengelola cluster GKE yang dioptimalkan untuk AI

Halaman ini menunjukkan cara mengelola cluster Google Kubernetes Engine (GKE) yang dioptimalkan AI untuk mesin A4X Max, A4X, A4, A3 Ultra, A3 Mega, dan A3 High (8 GPU), termasuk peristiwa umum berikut yang relevan dengan cluster GKE dan workload 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 yang mendasarinya, peristiwa tersebut akan melewati masa pemeliharaan dan pengecualian GKE . Meskipun sebagian besar instance komputasi memiliki kebijakan pemeliharaan host yang ditetapkan untuk migrasi langsung, yang meminimalkan gangguan pada workload, GPU dan TPU tidak mendukung migrasi langsung. Saat peristiwa host ini memengaruhi node GKE yang menjalankan workload 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 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 peristiwa pemeliharaan host yang dijadwalkan dengan cara berikut. Waktu mulai diwakili oleh label node Kubernetes di 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 mengirimkan 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 berkurang.

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, terus baca bagian ini untuk mempelajari hal berikut:

• Mengonfigurasi GKE untuk menghentikan workload Anda secara terkendali
• Proses penghentian terkendali
• Memantau progres penghentian terkendali yang aktif

Menggunakan informasi pemeliharaan host saat menjadwalkan workload

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 peristiwa 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 pemeliharaan terjadwal 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 disiapkan untuk gangguan pada instance komputasi yang mendasarinya, serta cluster GKE itu sendiri:

• Pemeliharaan host: Untuk mengelola pemeliharaan host instance komputasi mendasar, 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:
  • Masa 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 daftarkan cluster Anda 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 tambahan cakupan pengecualian pemeliharaan. Sebaiknya gunakan cakupan "no minor or node upgrades" untuk workload AI.

Melaporkan host yang rusak melalui GKE

Bagian ini menguraikan cara melaporkan host yang rusak yang memiliki instance komputasi yang disediakan menggunakan model penyediaan terikat pemesanan , melalui GKE. Jika Anda ingin melaporkan host yang rusak untuk node yang disediakan menggunakan model penyediaan flex-start (Pratinjau), maka hubungi tim akun Anda.

Perhatian: Melaporkan host yang rusak adalah tindakan yang mengganggu dan 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 untuk menyelesaikan masalah.

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

1. Mengeluarkan workload dari node secara terkendali.
2. Mencegah Pod baru dijadwalkan di node.
3. Memanggil API di instance komputasi untuk menandai host sebagai rusak.
4. Menunggu instance komputasi diaktifkan kembali di mesin host yang berfungsi dengan baik. Untuk pemesanan yang menggunakan mode operasional pemesanan all capacity, Compute Engine akan mengaktifkan kembali instance komputasi di node yang sama setelah operasi perbaikan selesai.
5. Menghapus taint dan label fault-behavior dari node.

Setelah itu, node akan siap untuk menayangkan workload lagi.

Persyaratan

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

• Anda harus menjalankan GKE versi patch 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 pemesanan.
• 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 dikenai batas frekuensi panggilan ke API ini per pemesanan per bulan berdasarkan evaluasi kesehatan blok Anda. Batas frekuensi tidak berlaku jika pemesanan Anda menggunakan all capacity mode operasional pemesanan.

Melaporkan host yang rusak

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

Untuk melaporkan host yang rusak:

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

2. Laporkan node sebagai rusak menggunakan perintah berikut. Anda dapat memberikan alasan, dan, dengan versi yang lebih baru, deskripsi:

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

     kubectl patch node NODE_NAME --type merge -p '{
       "metadata": {
         "labels": {
           "cloud.google.com/fault-behavior": "FAULT_REASON"
         },
         "annotations": {
           "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
         }
       }
     }'
   

   Ubah perintah sebagai berikut:

   • Ganti NODE_NAME dengan nama node yang rusak.
   • Ganti FAULT_REASON dengan alasan kerusakan yang sesuai menggunakan satu atau beberapa nilai berikut:
     • PERFORMANCE: gunakan nilai ini jika GPU pada instance komputasi berperforma lebih lambat daripada GPU lain di cluster dan Anda tidak melihat error XID di log, serta tidak ada pola kegagalan umum lainnya seperti kerusakan data senyap 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 penggunaan setelah pembebasan atau stomping memori, masalah kernel, atau kerusakan lainnya. Sering kali, istilah ini digunakan untuk merujuk pada kerusakan yang disebabkan oleh 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. Ini adalah nilai default. Namun, sebaiknya tentukan salah satu nilai lainnya, jika berlaku.
   • Sesuaikan blok annotations berdasarkan versi bidang kontrol cluster GKE Anda:
     • 1.35.6-gke.1017000 atau yang lebih baru, atau 1.36.0-gke.3251000 atau yang lebih baru: pertahankan blok anotasi dan ganti FAULT_DESCRIPTION dengan deskripsi teks tentang kerusakan yang diamati. Hal ini dapat mencakup kode error XID, gejala, atau stempel waktu. Deskripsi ini diteruskan ke Compute Engine untuk membantu diagnosis perbaikan dan otomatis dihapus dari node setelah operasi selesai. Misalnya: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
     • Versi sebelumnya: hapus seluruh blok annotations dari perintah. Kolom fault-description tidak diteruskan ke Compute Engine dalam versi ini dan tidak otomatis dihapus dari node. Sebagai gantinya, hubungi tim akun Anda atau Layanan Pelanggan Cloud untuk memberikan detail kerusakan.

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

	Mode all capacity (ALL_CAPACITY)	Mode terkelola (HIGHLY_AVAILABLE_CAPACITY)
Jenis mesin yang didukung	A4X Max dan A4X	A4, A3 Ultra, A3 Mega, dan A3 High
Batas frekuensi API laporan host yang rusak	Tidak ada batas frekuensi yang berlaku.	Panggilan ke API mungkin dikenai batas frekuensi.
Proses laporan host yang rusak	Saat Anda melaporkan host yang rusak untuk node yang berjalan dalam mode all capacity, hal berikut akan terjadi: Keluarkan Pod: Setelah label diterapkan ke node yang rusak, GKE menandai node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang 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 secara terkendali. Laporkan dan perbaiki host yang rusak: GKE 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. 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, status instance akan tetap atau berubah menjadi TERMINATED. Anda harus memulai ulang instance secara manual jika ingin menjalankannya. 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: Keluarkan Pod: Setelah label diterapkan ke node yang rusak, GKE akan menandai node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang 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 secara terkendali. Laporkan dan mulai perbaiki host yang rusak: GKE 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. Migrasikan dan mulai ulang instance: Setelah operasi perbaikan host dimulai (biasanya 10-12 menit), Compute Engine akan mencoba memesan satu host lagi untuk mengganti host yang rusak yang Anda laporkan dalam kapasitas yang Anda pesan. Jika Compute Engine menemukan host yang berfungsi dengan baik—jika berhasil mengganti host yang rusak atau menemukan host yang berfungsi dengan baik dan cocok dalam kapasitas yang Anda pesan—Compute Engine akan memigrasikan instance ke host tersebut. Kemudian, memulai ulang instance terjadi 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 berfungsi dengan baik. Jika tidak, jika instance dalam status TERMINATED atau jika resource tidak tersedia sebelum atau saat perbaikan selesai, status instance akan tetap atau berubah menjadi TERMINATED. Anda harus memulai ulang instance secara manual jika ingin menjalankannya. 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 Anda, yang memiliki salah satu nilai berikut:

• PodsEvicted: GKE telah selesai mengeluarkan Pod dari node yang terpengaruh.
• OperationRUNNING: operasi untuk melaporkan host yang rusak sedang berjalan.
• OperationDone: host yang mendasarinya telah dilaporkan sebagai 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 operasi host yang rusak, lihat Meninjau operasi host yang rusak.

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

Langkah berikutnya

• Pelajari cara menjadwalkan workload GKE dengan Topology Aware Scheduling.

• Pelajari cara mengoptimalkan jejaring cluster menggunakan NCCL/gIB.

• Pelajari cara me mecahkan masalah error API host yang rusak.