Tentang penyediaan GPU dan TPU dengan mode penyediaan flex-start

Halaman ini menjelaskan mode penyediaan fleksibel di Google Kubernetes Engine (GKE). Flex-start, yang didukung oleh Dynamic Workload Scheduler, memberikan teknik yang fleksibel dan hemat biaya untuk mendapatkan GPU dan TPU saat Anda perlu menjalankan workload AI/ML.

Flex-start memungkinkan Anda menyediakan GPU dan TPU secara dinamis sesuai kebutuhan, hingga tujuh hari, tidak dibatasi oleh waktu mulai tertentu, dan tanpa pengelolaan reservasi jangka panjang. Oleh karena itu, flex-start berfungsi dengan baik untuk workload berukuran kecil hingga sedang dengan persyaratan permintaan yang berfluktuasi atau durasi yang singkat. Misalnya, pra-pelatihan model kecil, penyesuaian model, atau model penayangan yang skalabel.

Informasi di halaman ini dapat membantu Anda melakukan hal berikut:

• Memahami cara kerja flex-start di GKE.
• Menentukan apakah flex-start tepat untuk workload Anda.
• Tentukan konfigurasi flex-start yang tepat untuk workload Anda.
• Mengelola gangguan saat menggunakan flex-start.
• Memahami batasan flex-start di GKE.

Halaman ini ditujukan untuk Admin dan operator platform serta Engineer machine learning (ML) yang ingin mengoptimalkan infrastruktur akselerator untuk workload mereka.

Kapan harus menggunakan flex-start

Sebaiknya gunakan flex-start jika beban kerja Anda memenuhi semua kondisi berikut:

• Workload Anda memerlukan resource GPU.
• Workload Anda memerlukan resource TPU yang berjalan di node pool slice TPU host tunggal.
• Anda memiliki kapasitas GPU atau TPU yang dicadangkan yang terbatas atau tidak ada, dan Anda memerlukan akses yang lebih andal ke akselerator ini.
• Workload Anda fleksibel waktunya dan kasus penggunaan Anda dapat menunggu untuk mendapatkan semua kapasitas yang diminta, misalnya, saat GKE mengalokasikan resource GPU di luar jam tersibuk.

Persyaratan

Untuk menggunakan flex-start di GKE, cluster Anda harus memenuhi persyaratan berikut:

• Untuk menjalankan GPU, gunakan GKE versi 1.32.2-gke.1652000 atau yang lebih baru.

• Untuk menjalankan TPU, gunakan GKE versi 1.33.0-gke.1712000 atau yang lebih baru. Flex-start mendukung versi dan zona berikut:

  • TPU Trillium (v6e) di asia-northeast1-b dan us-east5-a.
  • TPU v5e di us-west4-a.
  • TPU v5p di us-east5-a.

  TPU v3 dan v4 tidak didukung.

Cara kerja mode penyediaan fleksibel

Dengan flex-start, Anda menentukan kapasitas GPU atau TPU yang diperlukan dalam workload. Selain itu, dengan cluster Standar, Anda mengonfigurasi flex-start di node pool tertentu. GKE secara otomatis menyediakan VM dengan menyelesaikan proses berikut saat kapasitas tersedia:

1. Workload meminta kapasitas yang tidak langsung tersedia. Permintaan ini dapat dilakukan langsung oleh spesifikasi beban kerja atau melalui alat penjadwalan seperti class komputasi kustom atau Kueue.
2. GKE mengidentifikasi bahwa node Anda telah mengaktifkan flex-start dan workload dapat menunggu selama waktu yang tidak ditentukan.
3. Autoscaler cluster menerima permintaan Anda dan menghitung jumlah node yang diperlukan, memperlakukannya sebagai satu unit.
4. Autoscaler cluster menyediakan node yang diperlukan saat node tersebut tersedia. Node ini berjalan maksimal tujuh hari, atau selama durasi yang lebih singkat jika Anda menentukan nilai dalam parameter maxRunDurationSeconds. Parameter ini tersedia dengan GKE versi 1.28.5-gke.1355000 atau yang lebih baru. Jika Anda tidak menentukan nilai untuk parameter maxRunDurationSeconds, defaultnya adalah tujuh hari.
5. Setelah waktu berjalan yang Anda tentukan dalam parameter maxRunDurationSeconds berakhir, node dan Pod akan diprioritaskan.
6. Jika Pod selesai lebih cepat dan node tidak lagi digunakan, autoscaler cluster akan menghapusnya sesuai dengan profil penskalaan otomatis.

GKE menghitung durasi untuk setiap permintaan flex-start di tingkat node. Waktu yang tersedia untuk menjalankan Pod mungkin sedikit lebih kecil karena keterlambatan selama startup. Percobaan ulang Pod berbagi durasi ini, yang berarti lebih sedikit waktu yang tersedia untuk Pod setelah percobaan ulang. GKE menghitung durasi untuk setiap permintaan flex-start secara terpisah.

Konfigurasi flex-start

GKE mendukung konfigurasi flex-start berikut:

• Flex-start, tempat GKE mengalokasikan resource node satu per satu. Konfigurasi ini hanya mengharuskan Anda menetapkan tanda --flex-start selama pembuatan node.

• Flex-start dengan penyediaan yang diantrekan, dengan GKE mengalokasikan semua resource yang diminta secara bersamaan. Untuk menggunakan konfigurasi ini, Anda harus menambahkan flag --flex-start dan enable-queued-provisioning saat membuat node pool. GKE mengikuti proses dalam Cara kerja mode penyediaan flex-start dalam dokumen ini, tetapi juga menerapkan kondisi berikut:

  • Penjadwal menunggu hingga semua resource yang diminta tersedia di satu zona.
  • Semua Pod beban kerja dapat berjalan bersama di node yang baru disediakan.
  • Node yang disediakan tidak digunakan kembali di antara eksekusi beban kerja.

Tabel berikut membandingkan konfigurasi flex-start:

Mengoptimalkan konfigurasi flex-start

Untuk membuat infrastruktur AI/ML yang andal dan dioptimalkan biaya, Anda dapat menggabungkan konfigurasi flex-start dengan fitur GKE yang tersedia. Sebaiknya gunakan Class Komputasi untuk menentukan daftar prioritas konfigurasi node berdasarkan persyaratan workload Anda. GKE akan memilih konfigurasi yang paling sesuai berdasarkan ketersediaan dan prioritas yang Anda tentukan.

Mengelola gangguan pada workload yang menggunakan Dynamic Workload Scheduler

Workload yang memerlukan ketersediaan semua node, atau sebagian besar node, dalam node pool sensitif terhadap pengusiran. Selain itu, node yang disediakan dengan menggunakan permintaan Dynamic Workload Scheduler tidak mendukung perbaikan otomatis. Perbaikan otomatis menghapus semua beban kerja dari node, sehingga mencegahnya berjalan.

Semua node yang menggunakan flex-start, penyediaan dalam antrean, atau keduanya, menggunakan upgrade berumur pendek saat control plane cluster menjalankan versi minimum untuk flex-start, 1.32.2-gke.1652000 atau yang lebih baru.

Upgrade berumur pendek akan mengupdate node pool Standard atau grup node di cluster Autopilot tanpa mengganggu node yang sedang berjalan. Node baru dibuat dengan konfigurasi baru, yang secara bertahap mengganti node yang ada dengan konfigurasi lama dari waktu ke waktu. GKE versi sebelumnya, yang tidak mendukung upgrade dengan waktu aktif singkat atau fleksibel, memerlukan praktik terbaik yang berbeda.

Praktik terbaik untuk meminimalkan gangguan beban kerja untuk node yang menggunakan upgrade berumur pendek

Node fleksibel dan node yang menggunakan penyediaan dalam antrean akan otomatis dikonfigurasi untuk menggunakan upgrade berumur pendek saat cluster menjalankan versi 1.32.2-gke.1652000 atau yang lebih baru.

Untuk meminimalkan gangguan pada workload yang berjalan di node yang menggunakan upgrade berumur pendek, lakukan tugas berikut:

• Konfigurasikan masa pemeliharaan dan pengecualian untuk menetapkan kapan GKE harus dan tidak boleh melakukan operasi update, seperti upgrade node, sekaligus memastikan bahwa GKE masih memiliki waktu untuk melakukan pemeliharaan otomatis.
• Nonaktifkan perbaikan otomatis node.

Untuk node di cluster yang menjalankan versi sebelum 1.32.2-gke.1652000, sehingga tidak menggunakan upgrade berumur pendek, lihat panduan khusus untuk node tersebut.

Praktik terbaik untuk meminimalkan gangguan workload untuk node penyediaan yang diantrekan tanpa upgrade berumur pendek

Node yang menggunakan penyediaan dalam antrean di cluster yang menjalankan versi GKE sebelum 1.32.2-gke.1652000 tidak menggunakan upgrade berumur pendek. Cluster yang diupgrade ke versi 1.32.2-gke.1652000 atau yang lebih baru dengan node penyediaan yang ada dalam antrean akan otomatis diupdate untuk menggunakan upgrade berumur pendek.

Untuk node yang menjalankan versi sebelumnya ini, lihat panduan berikut:

• Bergantung pada pendaftaran saluran rilis cluster Anda, gunakan praktik terbaik berikut untuk mencegah upgrade otomatis node mengganggu workload Anda:
  • Jika cluster Anda terdaftar di saluran rilis, gunakan periode pemeliharaan dan pengecualian untuk mencegah GKE mengupgrade node secara otomatis saat workload Anda berjalan.
  • Jika cluster Anda tidak terdaftar di saluran rilis, nonaktifkan upgrade otomatis node. Namun, sebaiknya gunakan saluran rilis, tempat Anda dapat menggunakan pengecualian pemeliharaan dengan cakupan yang lebih terperinci.
• Nonaktifkan perbaikan otomatis node.
• Gunakan masa pemeliharaan dan pengecualian untuk meminimalkan gangguan pada workload yang sedang berjalan, sekaligus memastikan bahwa GKE masih memiliki waktu untuk melakukan pemeliharaan otomatis. Pastikan untuk menjadwalkan waktu tersebut saat tidak ada workload yang berjalan.
• Untuk memastikan node pool Anda tetap yang terbaru, upgrade node pool secara manual jika tidak ada permintaan Dynamic Workload Scheduler yang aktif dan node pool kosong.

Pertimbangan saat cluster Anda dimigrasikan ke upgrade berumur pendek

GKE mengupdate node yang ada menggunakan penyediaan dalam antrean untuk menggunakan upgrade berumur pendek saat cluster diupgrade ke versi 1.32.2-gke.1652000 atau yang lebih baru. GKE tidak memperbarui setelan lain, seperti mengaktifkan upgrade otomatis node jika Anda menonaktifkannya untuk node pool tertentu.

Sebaiknya pertimbangkan untuk menerapkan praktik terbaik berikut sekarang karena kumpulan node Anda menggunakan upgrade berumur pendek:

• Jika Anda menonaktifkan upgrade otomatis node menggunakan tanda --no-enable-autoupgrade, migrasi ini tidak mengaktifkan kembali upgrade otomatis node untuk node pool. Sebaiknya aktifkan upgrade otomatis node, karena upgrade berumur pendek tidak mengganggu node yang ada dan workload yang berjalan di dalamnya. Untuk mengetahui informasi selengkapnya, lihat Upgrade berumur pendek.
• Sebaiknya, jika cluster Anda belum terdaftar di saluran rilis, daftarkan cluster, sehingga Anda dapat menggunakan cakupan pengecualian pemeliharaan yang lebih terperinci.

Daur ulang node di flex-start

Untuk membantu memastikan transisi node yang lancar dan mencegah periode nonaktif untuk tugas yang sedang berjalan, flex-start mendukung mendaur ulang node. Saat node mencapai akhir durasi, GKE akan otomatis mengganti node dengan node baru untuk mempertahankan beban kerja yang sedang berjalan.

Untuk menggunakan pengelolaan ulang node, Anda harus membuat profil class komputasi kustom dan menyertakan kolom nodeRecycling dalam spesifikasi flexStart dengan parameter leadTimeSeconds.

Parameter leadTimeSeconds memungkinkan Anda menyeimbangkan ketersediaan resource dan efisiensi biaya. Parameter ini menentukan seberapa awal (dalam detik) sebelum node mencapai akhir durasi tujuh harinya agar proses penyediaan node baru mulai menggantikannya. Waktu tunggu yang lebih lama akan meningkatkan kemungkinan node baru siap sebelum node lama dihapus, tetapi mungkin menimbulkan biaya tambahan.

Proses pendaurulangan node terdiri dari langkah-langkah berikut:

1. Fase daur ulang: GKE memvalidasi bahwa node yang disediakan dengan flex-start memiliki kolom nodeRecycling dengan parameter leadTimeSeconds yang ditetapkan. Jika ya, GKE akan memulai fase daur ulang node saat tanggal saat ini lebih besar dari atau sama dengan perbedaan antara nilai dari kolom berikut:

   • creationTimestamp plus maxRunDurationSeconds
   • leadTimeSeconds

   Flag creationTimeStamp menyertakan waktu saat node dibuat. Kolom maxRunDurationSeconds dapat ditentukan di class komputasi kustom, dan default-nya adalah tujuh hari.

2. Pembuatan node: proses pembuatan node baru dimulai, yang dilanjutkan melalui fase antrean dan penyediaan. Durasi fase antrean dapat bervariasi secara dinamis bergantung pada zona dan kapasitas akselerator tertentu.

3. Tandai node yang mencapai akhir durasi tujuh harinya: setelah node baru berjalan, node lama akan ditandai. Tindakan ini mencegah Pod baru dijadwalkan di dalamnya. Pod yang ada di node tersebut akan terus berjalan.

4. Penghentian penyediaan node: node yang mencapai akhir durasi tujuh harinya akhirnya akan dihentikan penyediaannya setelah periode yang sesuai, yang membantu memastikan bahwa beban kerja yang berjalan telah dimigrasikan ke node baru.

Contoh konfigurasi class komputasi berikut mencakup kolom leadTimeSeconds dan maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Untuk informasi selengkapnya tentang cara menggunakan daur ulang node, coba tutorial Menayangkan LLM di GKE dengan strategi penyediaan GPU yang hemat biaya dan ketersediaan tinggi.

Batasan

• Anti-afinitas antar-pod tidak didukung. Autoscaler cluster tidak mempertimbangkan aturan anti-afinitas antar-pod selama penyediaan node, yang dapat menyebabkan workload yang tidak dapat dijadwalkan. Situasi ini dapat terjadi saat node untuk dua atau beberapa objek Dynamic Workload Scheduler disediakan di node pool yang sama.
• Hanya node GPU yang didukung.
• Pemesanan tidak didukung dengan Dynamic Workload Scheduler. Anda harus menentukan flag --reservation-affinity=none saat membuat node pool. Dynamic Workload Scheduler hanya memerlukan dan mendukung kebijakan lokasi ANY untuk penskalaan otomatis cluster.
• Satu permintaan Dynamic Workload Scheduler dapat membuat hingga 1.000 virtual machine (VM), yang merupakan jumlah maksimum node per zona untuk satu node pool.
• GKE menggunakan kuota ACTIVE_RESIZE_REQUESTS Compute Engine untuk mengontrol jumlah permintaan Dynamic Workload Scheduler yang tertunda dalam antrean. Secara default, kuota ini memiliki batas 100 permintaan per project Google Cloud. Jika Anda mencoba membuat permintaan Dynamic Workload Scheduler yang lebih besar dari kuota ini, permintaan baru akan gagal.
• Node pool yang menggunakan Dynamic Workload Scheduler sensitif terhadap gangguan karena node disediakan secara bersamaan. Untuk mempelajari lebih lanjut, lihat Mengelola gangguan pada workload yang menggunakan Dynamic Workload Scheduler.
• Anda mungkin melihat VM tambahan berumur pendek yang tercantum di Google Cloud konsol. Perilaku ini dimaksudkan karena Compute Engine dapat membuat, lalu segera menghapus VM hingga kapasitas untuk menyediakan semua mesin yang diperlukan tersedia.
• Spot VM tidak didukung.
• Dynamic Workload Scheduler tidak mendukung volume sementara. Anda harus menggunakan volume persisten untuk penyimpanan. Untuk memilih jenis penyimpanan terbaik yang menggunakan volume persisten, lihat Ringkasan penyimpanan untuk cluster GKE.
• Jika beban kerja menggunakan daur ulang node dan di-deploy oleh Tugas, konfigurasikan Tugas dengan mode penyelesaian yang ditetapkan ke Indexed.

Langkah berikutnya

• Memilih jenis GPU
• Men-deploy GPU dengan Dynamic Workload Scheduler.