Mengelola cluster GKE yang dioptimalkan untuk AI

Halaman ini menunjukkan cara mengelola cluster Google Kubernetes Engine (GKE) yang dioptimalkan AI dari 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 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 Anda

Memulai peristiwa pemeliharaan host secara manual

Setelah Compute Engine mengeluarkan notifikasi tentang peristiwa pemeliharaan yang dijadwalkan, 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 yang dijadwalkan 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 secara terkendali
• Proses penghentian terkendali
• Memantau progres penghentian terkendali 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 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 yang dijadwalkan setelah tanggal tertentu

Anda dapat menginstruksikan GKE untuk hanya menjadwalkan Pod ke node yang memiliki pemeliharaan yang dijadwalkan 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, didaftarkan 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 reservasi , melalui GKE. Jika Anda ingin melaporkan host yang rusak untuk node yang disediakan menggunakan model penyediaan flex-start (Pratinjau), maka hubungi tim akun Anda.

Jika Anda mengamati error memori GPU atau Xid pada node dan ingin memverifikasi apakah tindakan pemulihan manual seperti memicu reboot OS tamu (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true) dapat menyelesaikan masalah sebelum Anda melaporkan host sebagai rusak, lihat Meninjau pesan Xid messages.

Perhatian: Melaporkan host yang rusak adalah tindakan yang mengganggu dan menghentikan VM Anda. Sebelum melaporkan host, selidiki lingkungan Anda secara menyeluruh untuk mengidentifikasi penyebab utama masalah. Hanya laporkan host sebagai rusak jika Anda tidak memiliki alternatif untuk menyelesaikan masalah.

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 responsif. Untuk reservasi yang menggunakan mode operasional reservasi 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 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 dikenai batas kapasitas pada jumlah panggilan ke API ini per reservasi per bulan berdasarkan evaluasi status blok Anda. Batas kapasitas tidak berlaku jika reservasi Anda menggunakan mode operasional reservasi all capacity.

Melaporkan host yang rusak

Catatan: Data SSD lokal akan dihapus saat pemanggilan API berhasil saat instance komputasi memindahkan host. Sebaiknya buat cadangan 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 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 kesalahan 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, dan tidak ada pola kegagalan biasa 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. Paling sering, istilah ini digunakan untuk merujuk ke 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 dari kesalahan 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 atau Cloud Customer Care untuk memberikan detail kesalahan.

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

	Mode semua kapasitas (ALL_CAPACITY)	Mode terkelola (HIGHLY_AVAILABLE_CAPACITY)
Jenis mesin yang didukung	A4X Max dan A4X	A4, A3 Ultra, A3 Mega, dan A3 High
Batas kapasitas API laporan host yang rusak	Tidak ada batas kapasitas yang berlaku.	Panggilan ke API mungkin dikenai batas kapasitas.
Proses laporan host yang rusak	Saat Anda melaporkan host yang rusak untuk node yang berjalan dalam mode semua kapasitas, 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 mempertimbangkan 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 mempertimbangkan 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 dipesan. Jika Compute Engine menemukan host yang responsif—jika berhasil mengganti host yang rusak atau menemukan host yang responsif yang cocok dalam kapasitas yang dipesan—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 responsif. 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.
• OperationFAILED: API di instance komputasi gagal karena batas kuota atau masalah infrastruktur lainnya. Untuk memahami error, lihat Memecahkan masalah error API laporan host yang rusak. Untuk mempelajari cara memulihkan, lihat Menangani kegagalan laporan dan penggantian.
• Error: panggilan API gagal karena permintaan tidak memenuhi salah satu persyaratan yang dijelaskan di bagian sebelumnya.

Anda juga dapat melihat label node node.gke.io/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,node.gke.io/report-and-replace-operation

Jika terjadi error API, GKE akan menetapkan label node cloud.google.com/report-and-replace-status ke Error. Jika terjadi kegagalan operasi, GKE akan menetapkan label ke OperationFAILED. Dalam kedua kasus tersebut, GKE akan menghapus label node cloud.google.com/fault-behavior. Selain itu, di GKE versi 1.35.6-gke.1256000 atau yang lebih baru, atau 1.36.0-gke.4060000 atau yang lebih baru, GKE akan menerapkan taint cloud.google.com/report-and-replace-failed:NoSchedule ke node. Taint ini mencegah Pod baru dijadwalkan di node, yang memastikan bahwa workload tidak ditempatkan di node dengan host yang berpotensi rusak. Untuk mempelajari lebih lanjut, lihat Menangani kegagalan laporan dan penggantian.

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

Menangani kegagalan laporan dan penggantian

Jika operasi laporan dan penggantian gagal, GKE akan menerapkan taint cloud.google.com/report-and-replace-failed:NoSchedule ke node yang terpengaruh. Taint ini membuat node ditutup sehingga tidak ada workload baru yang dijadwalkan di node tersebut saat host yang mendasarinya mungkin masih rusak.

Memeriksa taint kegagalan

Untuk memeriksa apakah node memiliki taint kegagalan laporan dan penggantian, jalankan perintah berikut:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Memulihkan dari kegagalan laporan dan penggantian

Untuk memulihkan dari kegagalan laporan dan penggantian, lakukan salah satu hal berikut:

• Coba lagi operasi dengan menerapkan kembali label cloud.google.com/fault-behavior ke node. Jika percobaan ulang berhasil, GKE akan otomatis menghapus taint cloud.google.com/report-and-replace-failed:NoSchedule:

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

• Hapus taint secara manual jika Anda telah menentukan bahwa node responsif atau Anda ingin mengembalikannya ke layanan:

    kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-
  

Langkah berikutnya

• Pelajari cara menjadwalkan workload GKE dengan Topology Aware Scheduling.

• Pelajari cara mengoptimalkan jaringan cluster menggunakan NCCL/gIB.

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