Mengelola cluster GKE yang dioptimalkan untuk AI

GPU ter-cluster

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

Catatan: Pelaporan host yang rusak tidak didukung untuk GPU Umum.

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 mengabaikan masa pemeliharaan dan pengecualian GKE. Meskipun sebagian besar instance komputasi memiliki kebijakan pemeliharaan host yang ditetapkan ke migrasi langsung, yang meminimalkan gangguan 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 terjadwal 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 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 halus
• Proses penghentian halus
• Memantau progres penghentian halus yang aktif

Menggunakan informasi pemeliharaan host saat menjadwalkan workload

Anda dapat menggunakan informasi pemeliharaan yang ditampilkan melalui label node GKE beserta 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 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 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:
  • 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. Secara default, cluster GKE 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, melalui GKE, Anda dapat melaporkan host yang rusak yang memiliki instance komputasi yang disediakan menggunakan model penyediaan standar, flex-start, atau terikat reservasi. Jika Anda ingin melaporkan host yang rusak untuk node yang disediakan menggunakan model penyediaan spot atau yang menggunakan GPU Umum, hubungi tim akun Anda.

Jika Anda mengamati error memori GPU atau Xid pada node dan ingin memverifikasi apakah langkah 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.

Perhatian: Melaporkan host yang rusak dapat menghentikan instance komputasi dan mengganggu workload Anda. Sebelum melaporkan host sebagai rusak, selidiki lingkungan Anda untuk mengidentifikasi penyebab utama masalah. Hanya laporkan host sebagai rusak jika Anda tidak memiliki alternatif untuk menyelesaikan masalah Anda.

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 dengan tuntas.
2. Mencegah Pod baru dijadwalkan pada node.
3. Memanggil API pada instance komputasi untuk menandai host sebagai rusak.
4. Menunggu instance komputasi ditampilkan kembali di mesin host yang responsif. Untuk pemesanan yang menggunakan mode operasional pemesanan semua kapasitas, Compute Engine mengembalikan instance komputasi pada node yang sama setelah operasi perbaikan selesai.
5. Menghapus taint dan label fault-behavior dari node.

Setelah ini, node akan siap melayani 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 dibatasi kapasitasnya dalam jumlah panggilan ke API ini per pemesanan per bulan berdasarkan evaluasi kondisi blok Anda. Pembatasan kapasitas tidak berlaku jika pemesanan Anda menggunakan mode operasional pemesanan semua kapasitas.

Melaporkan host yang bermasalah

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

Untuk melaporkan host yang bermasalah:

1. Gunakan alat kemampuan 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 dalam cluster dan Anda tidak melihat error XID apa pun dalam log, dan tidak ada pola kegagalan biasa lainnya seperti kerusakan data senyap yang terdeteksi.
     • SDC: gunakan nilai ini untuk kerusakan data tanpa gejala, jika Anda melihat kerusakan data, tetapi tidak ada error sistem. Kerusakan data ini dapat disebabkan oleh cacat CPU, bug software seperti use-after-free atau memory stomping, masalah kernel, atau cacat lainnya. Sering kali, istilah ini digunakan untuk merujuk pada cacat 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. Nilai ini merupakan 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 diagnostik perbaikan dan otomatis dihapus dari node setelah operasi selesai. Contoh: 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 Cloud Customer Care untuk memberikan detail kesalahan.

Setelah Anda melaporkan host yang rusak untuk sebuah node, waktu mulai ulang node bervariasi berdasarkan mode operasional pemesanan yang ditentukan dalam pemesanan yang digunakan node. Untuk memverifikasi mode operasional pemesanan untuk pemesanan, lihat kolom reservationOperationalMode dalam pemesanan. Tabel berikut merangkum proses host yang rusak untuk dua mode operasional pemesanan 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 (8 GPU)
Pembatasan kapasitas API laporan host yang rusak	Tidak ada pembatasan kapasitas yang berlaku.	Panggilan API mungkin dibatasi kapasitasnya.
Proses laporan host yang rusak	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 rusak, GKE akan menerapkan taint pada node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang berjalan di node secara tuntas. GKE mematuhi Anggaran Gangguan Pod (PDB) dan kolom spec.terminationGracePeriodSeconds manifes Pod Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi GKE untuk menghentikan workload Anda secara halus. Melaporkan dan memperbaiki host yang rusak: GKE memanggil Compute Engine API untuk melaporkan dan memperbaiki host yang rusak. Urutan operasi ini biasanya memerlukan waktu antara 10 dan 12 menit untuk melaporkan host yang rusak, dan dari 3 hingga 14 hari, atau bahkan terkadang lebih lama, untuk memperbaiki host. Mulai ulang node: setelah operasi perbaikan host selesai, salah satu hal berikut akan terjadi: Jika node berada dalam status REPAIRING dan resource tersedia saat perbaikan selesai, Compute Engine akan otomatis memulai ulang node di host yang diperbaiki. Jika tidak, jika node berada dalam status TERMINATED atau jika resource tidak tersedia saat perbaikan selesai, status node akan tetap berada dalam atau berubah menjadi TERMINATED. Anda harus memulai ulang node secara manual saat ingin menjalankannya. Namun, jika resource tidak tersedia saat Anda memulai ulang node—misalnya, jika instance komputasi lain sudah menggunakan host yang diperbaiki—maka mulai ulang mungkin akan gagal.	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 rusak, GKE akan menerapkan taint pada node untuk memblokir penjadwalan Pod baru. GKE juga mulai mengeluarkan Pod yang berjalan di node secara tuntas. GKE mematuhi Anggaran Gangguan Pod (PDB) dan kolom spec.terminationGracePeriodSeconds manifes Pod Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi GKE untuk menghentikan workload Anda secara halus. Melaporkan dan mulai memperbaiki host yang rusak: GKE memanggil Compute Engine API untuk melaporkan dan memperbaiki host yang rusak. Urutan operasi ini biasanya memerlukan waktu antara 10 dan 12 menit untuk melaporkan host yang rusak. Perilaku node saat operasi perbaikan host dimulai bervariasi menurut seri mesin: A4 dan A3 Ultra: GKE mencoba melakukan migrasi langsung node ke host lain. Jika Anda tidak memiliki kapasitas yang dicadangkan yang memadai atau kapasitas tidak tersedia di zona node, node akan berhenti. A3 Mega dan A3 High: GKE menghentikan node dan memulai ulang node tersebut di host yang responsif. Memperbaiki host asli yang rusak dapat memerlukan waktu 3 hingga 14 hari, atau terkadang bahkan lebih lama. Migrasikan atau mulai ulang node: setelah operasi perbaikan host dimulai, Compute Engine akan mencoba memesan host yang responsif untuk menggantikan host yang dilaporkan rusak dalam kapasitas yang Anda pesan. Jika Compute Engine menemukan host pengganti, hal berikut akan terjadi: A4 dan A3 Ultra: jika node telah dimigrasikan secara langsung pada langkah sebelumnya, node tersebut akan terus berjalan di host pengganti. Jika node dihentikan, node akan dimulai ulang di host pengganti. A3 Mega dan A3 High: node dimulai ulang di host pengganti. Jika Compute Engine tidak dapat segera menemukan host pengganti, node akan dimulai ulang sebagai berikut: Jika node berada dalam status REPAIRING dan resource tersedia sebelum atau saat perbaikan selesai, Compute Engine akan otomatis memulai ulang node di host yang responsif. Jika tidak, jika node berada dalam status TERMINATED atau jika resource tidak tersedia sebelum atau saat perbaikan selesai, status node akan tetap berada dalam atau berubah menjadi TERMINATED. Anda harus memulai ulang node secara manual saat ingin menjalankannya. Tidak seperti dalam mode semua kapasitas, Anda tidak perlu menunggu host yang rusak diperbaiki sebelum workload dapat dilanjutkan.

Memantau progres operasi

Anda dapat memantau progres operasi GKE menggunakan label node cloud.google.com/report-and-replace-status pada 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 sebagai rusak dan node GKE siap dipindahkan ke host baru.
• OperationFAILED: API pada instance komputasi gagal karena batas kuota atau masalah infrastruktur lainnya. Untuk memahami error, lihat Memecahkan masalah error API host yang rusak. Untuk mempelajari cara memulihkan, lihat Menangani kegagalan laporkan dan ganti.
• 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 menerapkan taint cloud.google.com/report-and-replace-failed:NoSchedule ke node. Taint ini mencegah Pod baru dijadwalkan pada node, sehingga memastikan bahwa workload tidak ditempatkan pada node dengan host yang berpotensi rusak. Untuk mempelajari lebih lanjut, lihat Menangani kegagalan laporkan dan ganti.

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

Menangani kegagalan laporkan dan ganti

Jika operasi laporkan dan ganti gagal, GKE akan menerapkan taint cloud.google.com/report-and-replace-failed:NoSchedule ke node yang terpengaruh. Taint ini membuat node tetap ditandai sebagai tidak dapat dijadwalkan sehingga tidak ada workload baru yang dijadwalkan di dalamnya, sementara host yang mendasarinya mungkin masih rusak.

Memeriksa taint kegagalan

Untuk memeriksa apakah node memiliki taint kegagalan report-and-replace, jalankan perintah berikut:

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

Memulihkan dari kegagalan laporkan dan ganti

Untuk memulihkan dari kegagalan laporkan dan ganti, lakukan salah satu tindakan 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 memastikan bahwa node tersebut 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 jejaring cluster menggunakan NCCL/gIB.

• Pelajari cara memecahkan masalah error API laporkan host yang rusak.