Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Tentang ComputeClass kustom

Autopilot Standard

Anda dapat membuat ComputeClass sendiri untuk mengontrol properti node yang disediakan Google Kubernetes Engine (GKE) saat menskalakan cluster secara otomatis. Dokumen ini ditujukan untuk administrator platform yang ingin menentukan profil penskalaan otomatis untuk node secara deklaratif, sehingga workload tertentu berjalan di hardware yang memenuhi persyaratannya. Untuk mengetahui informasi selengkapnya tentang ComputeClass, lihat Tentang ComputeClass GKE.

Ringkasan ComputeClasses

Di GKE, ComputeClass adalah profil yang terdiri dari serangkaian atribut node yang digunakan GKE untuk menyediakan node yang menjalankan workload Anda selama peristiwa penskalaan otomatis. ComputeClass dapat menargetkan pengoptimalan tertentu, seperti menyediakan node berperforma tinggi atau memprioritaskan konfigurasi yang dioptimalkan biaya untuk biaya operasi yang lebih murah. ComputeClass Kustom memungkinkan Anda menentukan profil yang kemudian digunakan GKE untuk menskalakan node secara otomatis agar sesuai dengan persyaratan workload tertentu.

ComputeClass tersedia untuk digunakan dalam mode GKE Autopilot dan mode GKE Standard di versi 1.30.3-gke.1451000 dan yang lebih baru, serta menawarkan pendekatan deklaratif untuk menentukan atribut node dan prioritas penskalaan otomatis. ComputeClass tersedia untuk dikonfigurasi dan digunakan di semua cluster GKE yang memenuhi syarat secara default.

Manfaat ComputeClass kustom

ComputeClass kustom menawarkan manfaat berikut:

Prioritas komputasi penggantian: menentukan hierarki konfigurasi node di setiap ComputeClass untuk diprioritaskan oleh GKE. Jika konfigurasi yang paling disukai tidak tersedia, GKE akan otomatis memilih konfigurasi berikutnya dalam hierarki. Model penggantian ini membantu memastikan bahwa meskipun resource komputasi tidak tersedia, workload Anda tetap berjalan di hardware yang dioptimalkan dengan penundaan penjadwalan yang minimal.
Kontrol penskalaan otomatis terperinci: menentukan konfigurasi node yang paling sesuai untuk workload tertentu. GKE memprioritaskan konfigurasi tersebut saat membuat node selama penskalaan.
Konfigurasi infrastruktur deklaratif: terapkan pendekatan deklaratif untuk pengelolaan infrastruktur sehingga GKE otomatis membuat node untuk Anda yang sesuai dengan persyaratan workload spesifik Anda.
Migrasi aktif: jika resource komputasi untuk konfigurasi mesin yang lebih disukai tersedia di lokasi Anda, GKE akan otomatis memigrasikan workload Anda ke node baru yang menggunakan konfigurasi yang diinginkan.
Pengoptimalan biaya: prioritaskan jenis node yang hemat biaya seperti Spot VM untuk mengurangi pengeluaran cluster Anda.
ComputeClass kustom default: menetapkan ComputeClass kustom sebagai default untuk seluruh cluster atau untuk namespace Kubernetes tertentu, sehingga workload berjalan di hardware yang dioptimalkan meskipun tidak meminta ComputeClass tertentu.
Batas konsolidasi node kustom: menentukan batas penggunaan resource kustom untuk node. Jika penggunaan resource node tertentu berada di bawah nilai minimum, GKE akan mencoba menggabungkan workload ke node serupa yang tersedia dan memperkecil skala node yang kurang dimanfaatkan.
Kapasitas minimum deklaratif: mempertahankan jumlah minimum node ComputeClass ini di cluster Anda secara proaktif, yang membantu memastikan bahwa kapasitas tersedia untuk workload penting.

Kasus penggunaan untuk ComputeClass kustom

Sebaiknya gunakan ComputeClass kustom dalam skenario seperti berikut:

Anda ingin menjalankan workload AI/ML pada konfigurasi GPU atau TPU tertentu.
Anda ingin menetapkan konfigurasi hardware default untuk workload yang dijalankan tim tertentu, sehingga mengurangi beban operator aplikasi.
Anda menjalankan workload yang berperforma optimal pada seri mesin atau konfigurasi hardware Compute Engine tertentu.
Anda ingin mendeklarasikan konfigurasi hardware yang memenuhi persyaratan bisnis tertentu, seperti performa tinggi, pengoptimalan biaya, atau ketersediaan tinggi.
Anda ingin GKE secara hierarkis beralih menggunakan konfigurasi hardware tertentu selama resource komputasi tidak tersedia, sehingga workload Anda selalu berjalan di mesin yang sesuai dengan persyaratannya.
Anda ingin memutuskan konfigurasi yang optimal secara terpusat di seluruh fleet perusahaan, sehingga biaya Anda lebih dapat diprediksi dan workload Anda berjalan dengan lebih andal.
Anda ingin menentukan secara terpusat pemesanan kapasitas Compute Engine mana yang harus digunakan GKE untuk menyediakan node baru bagi workload tertentu.
Anda ingin menentukan kebijakan penempatan rapat untuk digunakan dengan GKE Autopilot. Untuk mengetahui detailnya, lihat: penempatan rapat.

Cara kerja ComputeClass kustom

ComputeClass kustom adalah resource kustom Kubernetes yang menyediakan infrastrukturGoogle Cloud . Anda menentukan objek ComputeClass di cluster, lalu meminta ComputeClass tersebut dalam workload atau menetapkan ComputeClass tersebut sebagai default untuk namespace Kubernetes. Saat workload yang cocok memerlukan infrastruktur baru, GKE akan menyediakan node baru sesuai dengan prioritas yang Anda tetapkan dalam definisi ComputeClass.

Atribut yang Anda tetapkan di ComputeClass menentukan cara GKE mengonfigurasi node baru untuk menjalankan workload. Saat Anda mengubah ComputeClass yang ada, semua node mendatang yang dibuat GKE untuk ComputeClass tersebut akan menggunakan konfigurasi yang diubah. GKE tidak mengubah konfigurasi node yang ada secara retroaktif agar sesuai dengan modifikasi Anda.

ComputeClass kustom memengaruhi keputusan penskalaan otomatis, tetapi tidak dipertimbangkan oleh kube-scheduler. Selama penjadwalan Pod, scheduler mungkin tidak memprioritaskan node dengan prioritas ComputeClass kustom yang lebih tinggi, meskipun node yang ada tersedia di berbagai prioritas.

Untuk memastikan ComputeClass kustom Anda dioptimalkan untuk fleet, pertimbangkan panduan berikut:

Pahami persyaratan komputasi fleet Anda, termasuk persyaratan hardware khusus aplikasi.
Tentukan tema yang memandu desain setiap ComputeClass. Misalnya, ComputeClass yang dioptimalkan untuk performa mungkin memiliki strategi penggantian yang hanya menggunakan jenis mesin dengan CPU tinggi.
Tentukan kelompok mesin dan seri mesin Compute Engine yang paling sesuai dengan workload Anda. Untuk mengetahui detailnya, lihat Panduan perbandingan dan resource kelompok mesin.
Rencanakan strategi penggantian dalam setiap ComputeClass agar workload selalu berjalan di node yang menggunakan konfigurasi mesin yang serupa. Misalnya, jika seri mesin N4 tidak tersedia, Anda dapat beralih ke mesin C3.

Melihat definisi resource kustom lengkap

Untuk melihat definisi resource kustom (CRD) terbaru untuk resource kustom ComputeClass, termasuk semua kolom dan hubungannya, lihat dokumentasi referensi ComputeClass.

Anda juga dapat melihat CRD di cluster dengan menjalankan perintah berikut:

kubectl describe crd computeclasses.cloud.google.com

Merencanakan ComputeClass kustom

Untuk merencanakan, men-deploy, dan menggunakan ComputeClass kustom secara efektif di cluster, lakukan langkah-langkah berikut:

Pilih prioritas komputasi penggantian Anda: Tentukan serangkaian aturan yang mengatur properti node yang dibuat GKE untuk ComputeClass.
Mengonfigurasi node pool dan ComputeClass GKE Standard: Untuk cluster mode Standard, lakukan langkah-langkah konfigurasi yang diperlukan untuk menggunakan ComputeClass dengan node pool Anda.
Tentukan perilaku penskalaan saat tidak ada aturan prioritas yang berlaku: secara opsional, beri tahu GKE apa yang harus dilakukan jika node yang memenuhi aturan prioritas Anda tidak dapat disediakan.
Menetapkan parameter penskalaan otomatis untuk konsolidasi node: memberi tahu GKE kapan harus mengonsolidasikan workload dan menghapus node yang kurang dimanfaatkan.
Konfigurasikan migrasi aktif ke node dengan prioritas lebih tinggi: opsional, beri tahu GKE untuk memindahkan workload ke node yang lebih disukai saat hardware tersedia.
Menggunakan pemesanan Compute Engine: secara opsional, beri tahu GKE untuk menggunakan pemesanan zona Compute Engine yang ada saat membuat node baru.
Menyediakan jumlah minimum node: secara opsional, beri tahu GKE untuk mempertahankan jumlah minimum node di cluster Anda.

Memilih prioritas komputasi penggantian

Keuntungan utama menggunakan ComputeClass kustom adalah memiliki kontrol atas strategi penggantian saat node pilihan Anda tidak tersedia karena faktor-faktor seperti kehabisan resource zona (seperti melihat pesan ZONE_RESOURCE_POOL_EXHAUSTED atau GCE out of resources selama peristiwa FailedScaleUp) dan batasan kuota. Dengan menentukan daftar prioritas model penyediaan atau seri mesin alternatif, cluster Anda dapat otomatis menyediakan kapasitas yang tersedia, alih-alih membiarkan Pod dalam status Pending. Untuk mengetahui informasi selengkapnya tentang cara memecahkan masalah kapasitas komputasi yang tidak memadai, lihat Pembuatan node pool gagal karena resource tidak memadai dan Peningkatan skala node gagal: Compute Engine kehabisan resource.

Anda membuat strategi penggantian dengan menentukan daftar aturan prioritas di kolom priorities dalam spesifikasi ComputeClass. Setiap aturan prioritas dapat meminta node dengan salah satu cara berikut:

Properti node: menentukan properti node yang Anda inginkan untuk menjalankan Pod, seperti kelompok mesin yang akan digunakan. Saat Pod memicu operasi peningkatan skala, GKE akan mencoba membuat node yang memiliki properti tersebut. Setiap aturan prioritas harus menentukan jenis hardware yang akan disediakan, seperti yang dijelaskan di bagian Properti node tingkat atas untuk aturan prioritas.
Node pool selection: di cluster GKE Standard, tentukan nama node pool yang ada untuk dikaitkan dengan ComputeClass. Saat Pod memicu operasi peningkatan skala, GKE akan mencoba menempatkan Pod di node pool tersebut. Aturan prioritas yang memilih node pool tidak mendukung kolom lain. Untuk mengetahui informasi selengkapnya, lihat bagian Node pool GKE Standard dan ComputeClass.

Secara default, saat node baru diperlukan untuk Pod masuk yang memilih ComputeClass, GKE akan mencoba membuat node sesuai urutan kemunculan aturan prioritas dalam manifes ComputeClass. Di GKE versi 1.35.2-gke.1842000 dan yang lebih baru, Anda juga dapat secara eksplisit menetapkan skor untuk setiap aturan prioritas di ComputeClass menggunakan kolom priorityScore, yang dalam hal ini GKE memproses aturan secara berurutan dari skor tertinggi hingga skor terendah. Jika semua aturan prioritas di ComputeClass habis, GKE akan membuat node berdasarkan perilaku yang dijelaskan dalam Menentukan perilaku penskalaan saat tidak ada aturan prioritas yang berlaku.

Skor aturan prioritas

Memerlukan GKE versi 1.35.2-gke.1842000 atau yang lebih baru.

Untuk kontrol terperinci atas urutan pemrosesan aturan prioritas GKE untuk ComputeClass, gunakan kolom priorityScore dalam aturan Anda. Selama penskalaan, GKE memproses aturan prioritas Anda berdasarkan skor, dengan nilai skor yang lebih besar memiliki prioritas yang lebih tinggi daripada nilai yang lebih kecil.

Kolom priorityScore memiliki properti berikut:

Kolom ini menerima nilai bilangan bulat dengan nilai minimum 1 dan nilai maksimum 1000.
Anda harus menggunakan kolom priorityScore di semua aturan prioritas atau tidak sama sekali.
Anda dapat menetapkan skor prioritas yang sama untuk maksimal tiga aturan terpisah. Selama penskalaan, GKE memproses aturan yang memiliki skor yang sama secara bersamaan. GKE memilih aturan tertentu untuk digunakan berdasarkan kriteria operasi autoscaler cluster.

Aturan yang dikelompokkan dapat meningkatkan latensi penskalaan otomatis, karena GKE harus menjalankan lebih banyak simulasi untuk menentukan konfigurasi node yang optimal. Kemungkinan Anda melihat peningkatan latensi bergantung pada seberapa luas pilihan hardware dalam aturan, sebagai berikut:
- Aturan yang memiliki cakupan luas, seperti properti machineFamily, lebih cenderung berkontribusi pada sedikit peningkatan latensi penskalaan otomatis. Namun, GKE lebih cenderung menemukan hardware yang tersedia yang memenuhi persyaratan aturan tersebut.
- Aturan yang memiliki cakupan sempit, seperti properti machineType, cenderung tidak akan berkontribusi pada peningkatan latensi. Namun, GKE lebih cenderung tidak dapat menemukan hardware yang tersedia yang memenuhi persyaratan aturan tersebut.

Contoh berikut menunjukkan ComputeClass yang menetapkan skor aturan prioritas:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Selama peristiwa peningkatan skala untuk contoh ComputeClass ini, GKE melakukan hal berikut:

GKE mencoba membuat instance E2.
Jika instance E2 tidak tersedia, GKE akan membuat instance N2 atau T2D, bergantung pada hasil autoscaler cluster.
Jika instance N2 dan T2D tidak tersedia, GKE akan mencoba membuat instance N1.
Jika instance N1 tidak tersedia, GKE akan kembali ke seri mesin default untuk cluster.

Properti node tingkat atas untuk aturan prioritas

Saat menentukan aturan prioritas yang menentukan properti node, Anda harus memilih jenis hardware tingkat atas yang Anda inginkan untuk node. Properti lain yang dapat Anda tentukan untuk aturan bergantung pada properti tingkat teratas aturan tersebut.

Anda dapat menggunakan salah satu properti tingkat teratas berikut untuk aturan:

machineFamily: seri mesin Compute Engine, seperti n4.
machineType: jenis mesin Compute Engine tertentu, seperti n4-standard-32.
gpu: konfigurasi GPU, yang dapat mencakup jenis GPU, jumlah GPU tertentu, dan konfigurasi driver.
tpu: konfigurasi Cloud TPU, yang mungkin mencakup versi TPU, topologi, dan jumlah chip.

Konfigurasi akselerator tidak memerlukan kolom machineType atau machineFamily untuk ditentukan secara eksplisit, kecuali jika Anda menggunakannya dalam kombinasi dengan pemesanan.

Setiap generasi seri mesin Compute Engine mendukung jenis disk tertentu. Misalnya, seri mesin N4 mendukung jenis disk Hyperdisk ML, tetapi seri mesin N2 tidak. Di ComputeClass yang mencakup beberapa generasi, workload stateful yang meminta jenis disk tertentu mungkin tidak dapat mengakses data persisten jika jenis mesin tidak mendukung jenis disk tersebut. Bergantung pada cara Anda membuat dan menggunakan disk dalam workload, gunakan salah satu metode berikut untuk mengurangi risiko data persisten yang tidak dapat diakses:

Penyediaan volume dinamis: di GKE versi 1.35.3-gke.1290000 dan yang lebih baru, gunakan StorageClass yang mengonfigurasi pemilihan jenis disk otomatis. GKE membuat jenis disk yang kompatibel dengan jenis mesin node yang menjalankan workload Anda. Di versi GKE sebelumnya, pastikan semua seri mesin di ComputeClass Anda mendukung jenis disk yang disediakan StorageClass Anda.
Persistent disk yang sudah ada: pastikan semua seri mesin di ComputeClass Anda mendukung jenis disk dari persistent disk yang sudah ada.

Untuk mengetahui informasi selengkapnya tentang jenis disk yang didukung untuk setiap seri mesin, lihat tabel perbandingan seri mesin.

Konfigurasi machineFamily

Kolom machineFamily menerima seri mesin Compute Engine yang didukung GKE, seperti n2 atau c3. Jika tidak ditentukan, defaultnya adalah e2. Saat Anda menggunakan kolom machineFamily, GKE menyediakan node dari seri tersebut dengan jenis mesin yang cukup besar untuk menjalankan Pod Anda. Algoritma autoscaler menentukan ukuran yang paling sesuai berdasarkan permintaan resource gabungan dari semua Pod yang tertunda. Untuk kontrol lebih besar atas ukuran mesin yang tepat, gunakan kolom machineType.

Meminta kelompok mesin yang lebih luas tidak akan menyediakan jenis mesin bare metal. Misalnya, meminta c3 atau c4a tidak akan menyediakan jenis mesin seperti c3-standard-192-metal atau c4a-standard-72-metal. Karena jenis node bare metal memerlukan permintaan jenis mesin yang tepat, Anda juga tidak dapat menggunakan ComputeClass Performance Autopilot yang telah ditetapkan.

Untuk menyediakan jenis mesin bare metal, buat ComputeClass kustom dan tentukan jenis mesin yang tepat di kolom machineType. Jenis mesin bare metal memiliki persyaratan versi berikut:

Jenis mesin bare metal c3 dan c4a dengan ComputeClass, pembuatan otomatis node pool, atau mode Autopilot memerlukan GKE versi 1.35.3-gke.1389000 atau yang lebih baru.
Jenis mesin bare metal c4d dengan ComputeClass, pembuatan otomatis node pool, atau mode Autopilot memerlukan GKE versi 1.37.0-gke.4713000 atau yang lebih baru. Node pool dalam mode Standard yang menggunakan jenis mesin bare metal c4d memerlukan GKE versi 1.36 atau yang lebih baru. Pada versi sebelum 1.37.0-gke.4713000, Anda harus membuat dan menskalakan node pool Standard ini secara manual.

Anda dapat menggunakan kolom spec.priorities lainnya bersama kolom machineFamily untuk menentukan persyaratan komputasi secara deklaratif. Contoh:

spot: Spot VM. Nilai defaultnya adalah false.
minCores: vCPU minimum per node. Nilai defaultnya adalah 0. Kolom ini berguna untuk mencegah pembuatan node yang terlalu kecil untuk kebutuhan Anda.
minMemoryGb: memori minimum per node. Nilai defaultnya adalah 0.
storage.bootDiskType: jenis boot disk. Pada cluster Autopilot, hanya jenis pd-balanced dari bootDiskType yang didukung. Memerlukan GKE versi 1.34.1-gke.1431000 atau yang lebih baru.
storage.bootDiskSize: ukuran dalam GB untuk boot disk node. Memerlukan GKE versi 1.34.1-gke.1431000 atau yang lebih baru.
storage.bootDiskKMSKey: jalur ke kunci Cloud Key Management Service yang akan digunakan untuk enkripsi boot disk.
storage.secondaryBootDisks: Persistent Disk yang digunakan untuk melakukan pramuat node GKE dengan data, seperti model machine learning (ML) atau image container. Memerlukan GKE versi 1.31.2-gke.1105000 atau yang lebih baru. Untuk menyiapkan boot disk sekunder yang akan digunakan cluster Anda, lihat mengonfigurasi boot disk sekunder.
- storage.secondaryBootDisks.diskImageName: nama disk image yang akan dipramuat.
- storage.secondaryBootDisks.project: nama project yang memiliki disk image tersebut. Jika nilai ini tidak ditentukan, defaultnya adalah project cluster Anda.
- storage.secondaryBootDisks.mode: mode penggunaan boot disk sekunder. Jika nilai ini ditetapkan ke CONTAINER_IMAGE_CACHE, boot disk sekunder akan digunakan sebagai cache image container. Nilainya harus sama dengan CONTAINER_IMAGE_CACHE atau MODE_UNSPECIFIED. Jika nilai ini tidak ditentukan, defaultnya adalah MODE_UNSPECIFIED.
placement: spesifikasi penempatan mesin:
- policyName: nama kebijakan penempatan rapat atau kebijakan workload GKE Autopilot.
enableNestedVirtualization: apakah akan mengaktifkan virtualisasi bertingkat pada node. Nilai defaultnya adalah false.

Contoh berikut menunjukkan aturan prioritas yang menggunakan machineFamily:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset

Konfigurasi machineType

Kolom machineType menerima jenis mesin yang telah ditetapkan Compute Engine, seperti n4-standard-32, atau string jenis mesin kustom, seperti n4-custom-8-20480. Penggunaan jenis mesin kustom memerlukan GKE versi 1.33.2-gke.1111000 atau yang lebih baru. Anda dapat menentukan jenis mesin dari seri mesin yang didukung GKE.

Anda dapat menentukan kolom spec.priorities lainnya bersama kolom machineType untuk menentukan persyaratan komputasi secara deklaratif, misalnya:

spot: menggunakan Spot VM. Default-nya adalah false.
storage: mengonfigurasi penyimpanan node.
- storage.bootDiskType: jenis boot disk. Di Autopilot, hanya jenis pd-balanced dari bootDiskType yang didukung.
- storage.bootDiskKMSKey: jalur ke kunci Cloud KMS yang akan digunakan untuk enkripsi boot disk.
- storage.bootDiskSize: ukuran dalam GB untuk boot disk node.
- storage.localSSDCount: jumlah SSD lokal yang akan dipasang ke node. Jika ditentukan, harus minimal 1.
enableNestedVirtualization: apakah akan mengaktifkan virtualisasi bertingkat pada node. Nilai defaultnya adalah false.

Contoh berikut menunjukkan aturan prioritas yang menggunakan machineType untuk menyediakan jenis mesin n4-standard-32:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Konfigurasi GPU

Untuk memilih GPU dalam aturan prioritas, tentukan jenis, jumlah, dan driverVersion (opsional) GPU di kolom gpu aturan prioritas. Kolom berikut didukung:

gpu.type: jenis GPU, seperti nvidia-l4. Untuk mengetahui detailnya, lihat Memilih dukungan GPU menggunakan Autopilot atau Standard.
gpu.count: jumlah GPU yang akan dipasang. Untuk mengetahui jumlah yang didukung berdasarkan jenis GPU, lihat Jumlah GPU yang didukung.
gpu.driverVersion: versi driver NVIDIA yang akan diinstal. Nilainya harus default atau latest. Memerlukan GKE versi 1.31.1-gke.1858000 atau yang lebih baru.
acceleratorNetworkProfile: Profil jaringan akselerator untuk GPU, seperti auto. Memerlukan GKE versi 1.35.2-gke.1842000 atau yang lebih baru.

Anda juga dapat menentukan kolom spec.priorities lainnya seperti Spot VM, opsi penyimpanan, dan pemesanan yang dikombinasikan dengan kolom gpu.

Contoh berikut menunjukkan aturan untuk GPU:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true

Konfigurasi TPU

Memerlukan GKE versi 1.31.2-gke.1518000 atau yang lebih baru

Untuk memilih TPU dalam aturan prioritas, tentukan jenis, jumlah, dan topologi TPU di kolom tpu aturan prioritas. Kolom berikut wajib diisi:

tpu.type: jenis TPU, seperti tpu-v5p-slice. Untuk mengetahui detailnya, lihat Ketersediaan TPU di GKE Autopilot.
tpu.count: jumlah TPU yang akan dipasang.
tpu.topology: topologi TPU yang akan digunakan, seperti "2x2x1". Untuk mengetahui detailnya, lihat Memilih topologi untuk Autopilot.

Anda juga dapat menentukan kolom spec.priorities lainnya bersama dengan kolom tpu dalam aturan prioritas, misalnya:

spot: menggunakan Spot VM. Default-nya adalah false.
storage: mengonfigurasi penyimpanan node.
- storage.bootDiskType: jenis boot disk.
- storage.bootDiskKMSKey: jalur ke kunci Cloud KMS yang akan digunakan untuk enkripsi boot disk.
- storage.bootDiskSize: ukuran dalam GB untuk boot disk node.
reservations: menggunakan pemesanan Compute Engine. Untuk mengetahui detailnya, lihat bagian Menggunakan pemesanan Compute Engine.
location:
- zones: daftar zona Google Cloud tempat GKE dapat menyediakan node. Jika tidak ditentukan, GKE akan menyediakan node di zona yang dikonfigurasi dalam setelan node auto-provisioning cluster. Jika tidak ada zona yang dikonfigurasi untuk node auto-provisioning, GKE akan menyediakan node di salah satu zona standar yang digunakan bidang kontrol.
  Opsional: gunakan zona AI, seperti us-central1-ai1a. Zona AI adalah lokasi khusus yang dioptimalkan untuk workload AI/ML dalam region Google Cloud .
- zoneTypes: daftar jenis zona yang menentukan kumpulan zona Google Cloud tempat GKE dapat menyediakan node. Nilai yang didukung adalah CLUSTER_DEFAULT (default), STANDARD, dan AI. Untuk mengetahui informasi selengkapnya, lihat Menggunakan prioritas zoneTypes lokasi.

Contoh berikut menunjukkan aturan untuk TPU:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

Contoh ini menentukan perilaku penggantian berikut:

GKE mencoba menyediakan slice TPU v5p multi-host 16 node dengan menggunakan pemesanan Compute Engine bersama bernama tpu-reservation dari project reservation-project.
Jika pemesanan tidak memiliki TPU yang tersedia, GKE akan mencoba menyediakan slice TPU v5p multi-host 16 node yang berjalan di Spot VM.
Jika tidak ada aturan sebelumnya yang dapat dipenuhi, GKE akan mengikuti logika di bagian Menentukan perilaku penskalaan saat tidak ada aturan prioritas yang berlaku.

Setelah men-deploy ComputeClass kustom TPU ke cluster, pilih ComputeClass kustom tersebut di workload Anda:

Workload Autopilot: lihat bagian "Menyediakan TPU menggunakan ComputeClass kustom" di Men-deploy workload TPU di GKE Autopilot
Workload standar: lihat bagian "Menyediakan TPU menggunakan ComputeClass kustom" di Men-deploy workload TPU di GKE Standard.

Selain itu, untuk workload TPU, Anda dapat melakukan hal berikut:

Menentukan jenis workload
Menentukan SLO
Grup dalam koleksi di TPU Trillium (v6e)
Menargetkan zona AI

Zona AI target

Anda juga dapat menggunakan class komputasi untuk menentukan zona AI untuk Pod Anda. Zona AI adalah lokasi khusus dalam region Google Cloud yang dioptimalkan untuk workload AI/ML. Class komputasi berikut menetapkan daftar zona yang diprioritaskan, yang mencakup zona AI:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

ComputeClass ini mengonfigurasi GKE untuk menyediakan node dengan TPU v5p atau GPU A100 untuk workload. Node memiliki preferensi berikut:

Prioritas 1: mencoba menyediakan TPU di zona AI us-central1-ai1a.
Prioritas 2: jika TPU tidak tersedia di zona AI tertentu, coba sediakan di zona AI mana pun di region cluster.
Prioritas 3: jika TPU tidak tersedia di zona AI, coba sediakan GPU di zona standar us-central1-a atau us-central1-b.
Jika GPU A100 tidak tersedia di salah satu zona yang ditentukan, GKE tidak akan meningkatkan skala node pool.

Konfigurasi jaringan DRANET

Memerlukan GKE versi 1.35.2-gke.1842000 atau yang lebih baru

Untuk menggunakan DRANET yang dikelola GKE guna meminta dan mengalokasikan antarmuka jaringan untuk Pod, Anda harus mengaktifkan fitur ini di ComputeClass. Anda perlu:

Aktifkan driver jaringan DRANET dengan menetapkan nodePoolConfig.dra.networking.enabled ke true.
Tetapkan acceleratorNetworkProfile ke auto dalam daftar priorities.

Untuk mengetahui informasi selengkapnya tentang cara menggunakan DRANET, lihat Mengalokasikan resource jaringan menggunakan DRANET yang dikelola GKE.

Cara GKE membuat node menggunakan aturan prioritas

Saat Anda men-deploy workload yang meminta ComputeClass dan node baru diperlukan, GKE akan memproses daftar aturan di kolom priorities dari spesifikasi ComputeClass sesuai urutan kemunculannya atau, jika kolom priorityScore ditetapkan, dari skor tertinggi hingga terendah.

Misalnya, perhatikan spesifikasi berikut:

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

Saat Anda men-deploy workload yang meminta ComputeClass dengan aturan prioritas ini, GKE akan mencocokkan node sebagai berikut:

GKE menempatkan Pod di node yang ada yang terkait dengan ComputeClass ini.
Jika node yang ada tidak dapat mengakomodasi Pod, GKE akan menyediakan node baru yang menggunakan seri mesin N4, merupakan Spot VM, dan memiliki setidaknya 64 vCPU.
Jika Spot VM N4 dengan minimal 64 vCPU tidak tersedia di region tersebut, GKE akan menyediakan node baru yang menggunakan Spot VM N4 yang dapat memuat Pod, terlepas dari jumlah core-nya.
Jika tidak ada Spot VM N4 yang tersedia di region tersebut, GKE akan menyediakan VM N4 on-demand baru.
Jika tidak ada aturan sebelumnya yang dapat dipenuhi, GKE akan mengikuti logika di bagian Menentukan perilaku penskalaan saat tidak ada aturan prioritas yang berlaku.

Nilai default untuk aturan prioritas

Anda dapat menetapkan nilai default untuk beberapa kolom dalam aturan prioritas spesifikasi ComputeClass. Nilai default ini berlaku jika kolom yang sesuai dalam aturan tertentu dihilangkan. Anda dapat menetapkan nilai default ini menggunakan kolom priorityDefaults dalam spesifikasi ComputeClass.

Kolom priorityDefaults memiliki batasan berikut:

Memerlukan GKE versi 1.32.1-gke.1729000 atau yang lebih baru.
Tidak kompatibel dengan aturan prioritas nodepools, yang tidak berisi kolom apa pun.

Untuk mengetahui detail tentang jenis nilai default yang dapat Anda tetapkan, lihat bagian priorityDefaults di CustomResourceDefinition ComputeClass.

Node pool GKE Standard dan ComputeClass

Jika menggunakan mode GKE Standard, Anda mungkin harus melakukan konfigurasi manual untuk memastikan Pod ComputeClass Anda dijadwalkan sesuai harapan.

Node pool yang dibuat otomatis: tidak memerlukan konfigurasi manual. GKE secara otomatis melakukan langkah-langkah konfigurasi ComputeClass untuk Anda. Untuk mengetahui detailnya, lihat Pembuatan otomatis node pool dan ComputeClass.
Node pool yang dibuat secara manual: konfigurasi manual diperlukan. Anda harus menambahkan label node dan taint node ke node pool yang dibuat secara manual untuk mengaitkan node dengan ComputeClass tertentu. Untuk mengetahui detailnya, lihat Mengonfigurasi node pool yang dibuat secara manual untuk penggunaan ComputeClass.

Mengonfigurasi node pool yang dibuat secara manual untuk penggunaan ComputeClass

Jika cluster GKE Standard Anda memiliki node pool yang Anda buat secara manual, Anda harus mengonfigurasi node pool tersebut untuk mengaitkannya dengan ComputeClass tertentu. GKE hanya menjadwalkan Pod yang meminta ComputeClass tertentu pada node di node pool yang Anda kaitkan dengan ComputeClass tersebut. Persyaratan ini tidak berlaku untuk ComputeClass yang Anda konfigurasi sebagai default tingkat cluster.

Mode GKE Autopilot dan node pool yang dibuat otomatis dalam mode GKE Standard melakukan konfigurasi ini untuk Anda.

Untuk mengaitkan node pool yang dibuat secara manual dengan ComputeClass, Anda menambahkan label node dan taint node ke node pool selama pembuatan atau selama update dengan menentukan flag --node-labels dan flag --node-taints, sebagai berikut:

Label node: cloud.google.com/compute-class=COMPUTE_CLASS
Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

Dalam atribut ini, COMPUTE_CLASS adalah nama ComputeClass kustom Anda.

Misalnya, perintah berikut bersama-sama mengupdate node pool yang ada dan mengaitkan node pool dengan ComputeClass dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

Anda dapat mengaitkan setiap node pool di cluster dengan satu ComputeClass kustom. Pod yang dijadwalkan GKE pada node pool yang dibuat secara manual ini hanya memicu pembuatan node di dalam node pool tersebut selama peristiwa penskalaan otomatis.

Pembuatan otomatis node pool dan ComputeClass

Anda dapat menggunakan pembuatan otomatis node pool dengan ComputeClass kustom agar GKE otomatis membuat dan menghapus node pool berdasarkan aturan prioritas Anda.

Agar GKE dapat otomatis membuat node pool untuk ComputeClass, Anda harus melakukan hal berikut:

Tambahkan kolom nodePoolAutoCreation dengan nilai enabled: true ke spesifikasi ComputeClass Anda.
Jika cluster Anda menjalankan versi GKE yang lebih lama dari 1.33.3-gke.1136000, Anda juga harus mengaktifkan node auto-provisioning level cluster.

GKE kemudian dapat membuat node pool baru untuk Pod yang menggunakan ComputeClass Anda. GKE memutuskan apakah akan meningkatkan skala node pool yang ada atau membuat node pool baru berdasarkan faktor seperti ukuran cluster dan persyaratan Pod. Pod dengan ComputeClass yang tidak mengonfigurasi pembuatan otomatis node pool akan terus meningkatkan skala node pool yang ada.

Anda dapat menggunakan ComputeClass yang mengaktifkan pembuatan otomatis node pool bersama dengan ComputeClass yang berinteraksi dengan node pool yang dibuat secara manual di cluster yang sama.

Pertimbangkan interaksi berikut dengan pembuatan otomatis node pool:

Anda tidak dapat menggunakan pemilih node kelompok mesin atau Spot VM karena pemilih ini bertentangan dengan perilaku ComputeClass. GKE menolak Pod apa pun yang meminta ComputeClass dan juga meminta Spot VM atau seri mesin tertentu.
Jika Anda menetapkan ComputeClass default untuk cluster, Pod yang menggunakan pemilih node kelompok mesin hanya akan memicu pembuatan node untuk class default tersebut dalam salah satu situasi berikut:
- Pod memilih kelompok mesin yang cocok dengan salah satu aturan prioritas di class default tingkat cluster. Misalnya, Pod yang memilih instance N4 akan memicu pembuatan node jika class default tingkat cluster memiliki aturan prioritas untuk instance N4.
- ComputeClass default tingkat cluster memiliki nilai ScaleUpAnyway di kolom spec.whenUnsatisfiable. Meskipun Pod memilih kelompok mesin yang tidak ada dalam prioritas ComputeClass, GKE akan membuat node baru dengan kelompok mesin tersebut.
Pod yang memilih kelompok mesin yang tidak ada dalam prioritas class default tingkat cluster tidak akan memicu pembuatan node jika ComputeClass memiliki nilai DoNotScaleUp di kolom whenUnsatisfiable.
Anda dapat mengonfigurasi pembuatan otomatis node pool untuk ComputeClass yang menggunakan kolom nodepools untuk mereferensikan node pool yang ada. GKE memproses prioritas secara berurutan dan mencoba meningkatkan skala node pool yang ada untuk menempatkan Pod Anda.

Pertimbangkan contoh berikut untuk cluster yang memiliki node pool yang dibuat secara manual dan pembuatan otomatis node pool:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

Dalam contoh ini, GKE mencoba melakukan hal berikut:

Buat node baru di node pool manually-created-pool.
Sediakan node N4, baik di node pool N4 yang ada atau dengan membuat node pool baru.
Jika GKE tidak dapat membuat node N4, GKE akan mencoba meningkatkan skala node pool C4 yang ada atau membuat node pool C4 baru.

Menargetkan node pool tertentu dalam definisi ComputeClass

Kolom priorities.nodepools memungkinkan Anda menentukan daftar node pool yang dibuat secara manual, tempat GKE mencoba menjadwalkan Pod tanpa urutan tertentu di cluster GKE Standard yang menggunakan penskalaan otomatis cluster. Kolom ini hanya mendukung daftar node pool; Anda tidak dapat menentukan properti mesin tambahan seperti seri mesin dalam aturan prioritas yang sama. Saat Anda men-deploy workload yang meminta ComputeClass yang memiliki node pool bernama, GKE akan mencoba menjadwalkan Pod yang tertunda di node pool tersebut. GKE mungkin membuat node baru di node pool tersebut untuk menempatkan Pod.

Node pool yang Anda tentukan di kolom priorities.nodepools harus dikaitkan dengan ComputeClass tersebut menggunakan label node dan taint node, seperti yang dijelaskan di bagian Mengonfigurasi node pool yang dibuat secara manual untuk ComputeClass.

Daftar node pool yang Anda tentukan di kolom nodepools tidak memiliki prioritas. Untuk mengonfigurasi urutan penggantian untuk node pool bernama, Anda harus menentukan beberapa item priorities.nodepools terpisah. Misalnya, pertimbangkan spesifikasi berikut:

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

Dalam contoh ini, GKE pertama-tama mencoba menempatkan Pod yang tertunda yang meminta ComputeClass ini pada node yang ada di node pool yang diberi label dengan ComputeClass. Jika node yang ada tidak tersedia, GKE akan mencoba menyediakan node baru di pool1 atau pool2. Jika GKE tidak dapat menyediakan node baru di node pool ini, GKE akan mencoba menyediakan Pod baru di pool3.

Menentukan perilaku penskalaan jika tidak ada aturan prioritas yang berlaku

Dengan resource kustom ComputeClass, Anda dapat menentukan tindakan yang harus dilakukan GKE jika tidak ada node yang dapat memenuhi aturan prioritas apa pun. Kolom whenUnsatisfiable dalam spesifikasi mendukung nilai berikut.

ScaleUpAnyway: membuat node baru yang menggunakan konfigurasi mesin default cluster. Di GKE versi sebelum 1.33, ini adalah perilaku default jika Anda menghapus kolom ini.

GKE akan melakukan salah satu tindakan berikut:
- Di cluster Autopilot, GKE menempatkan Pod di node baru atau yang sudah ada, terlepas dari konfigurasi mesin node.
- Di cluster Standard yang tidak menggunakan pembuatan otomatis node pool, GKE mencoba meningkatkan skala node pool yang dibuat secara manual yang menentukan label dan taint yang cocok dengan ComputeClass tertentu.
- Di cluster Standard yang menggunakan pembuatan otomatis node pool, GKE mungkin membuat node pool baru yang menggunakan seri mesin E2 default untuk menempatkan Pod.
DoNotScaleUp: membiarkan Pod dalam status Pending hingga node yang memenuhi persyaratan ComputeClass tersedia. Di GKE versi 1.33 dan yang lebih baru, ini adalah perilaku default jika Anda menghapus kolom ini.

Meminta kebijakan penempatan

Mulai GKE versi 1.33.2-gke.1335000, di cluster GKE Autopilot, Anda dapat menggunakan penempatan rapat dengan kebijakan penempatan kustom atau kebijakan workload. Untuk mengetahui informasi selengkapnya, lihat Perbandingan kebijakan penempatan rapat dan kebijakan workload.

Kebijakan penempatan dan kebijakan workload menempatkan node secara fisik berdekatan untuk mengurangi latensi jaringan. Untuk menggunakan kebijakan tertentu, berikan namanya di kolom policyName. Kebijakan tersebut harus berupa kebijakan resource Compute Engine yang sudah ada di project GKE.

Perhatikan contoh berikut:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

Dalam konfigurasi ini, GKE menerapkan kebijakan penempatan rapat untuk semua workload yang menggunakan ComputeClass ini dan menyediakan nodenya sesuai dengan kebijakan resource yang ada bernama my-placement-policy.

Menetapkan parameter penskalaan otomatis untuk konsolidasi node

Secara default, GKE menghapus node yang kurang dimanfaatkan dengan menjalankan workload, menggabungkan workload tersebut di node lain yang memiliki kapasitas. Untuk semua ComputeClass, ini adalah perilaku default karena semua cluster yang menggunakan ComputeClass harus menggunakan autoscaler cluster atau merupakan cluster Autopilot. Selama konsolidasi node, GKE mengosongkan node yang kurang dimanfaatkan, membuat ulang workload di node lain, lalu menghapus node yang dikosongkan.

Waktu dan kriteria untuk penghapusan node bergantung pada profil penskalaan otomatis. Anda dapat menyesuaikan nilai minimum kurangnya pemanfaatan resource yang memicu penghapusan node dan konsolidasi workload menggunakan bagian autoscalingPolicy dalam definisi ComputeClass kustom Anda. Anda dapat menyesuaikan parameter berikut:

consolidationDelayMinutes: jumlah menit setelah GKE menghapus node yang kurang dimanfaatkan
consolidationThreshold: nilai minimum pemakaian untuk CPU dan memori sebagai persentase resource yang tersedia di node. GKE hanya mempertimbangkan node untuk dihapus jika pemakaian resource kurang dari batas ini.
gpuConsolidationThreshold: nilai minimum pemakaian untuk GPU sebagai persentase resource yang tersedia di node. GKE hanya mempertimbangkan node untuk dihapus jika pemakaian resource kurang dari batas ini. Sebaiknya tetapkan nilai ini ke 100 atau ke 0 agar GKE menggabungkan node yang tidak memiliki pemakaian 100% dari GPU yang terpasang.

Perhatikan contoh berikut:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

Dalam konfigurasi ini, GKE menghapus node yang tidak digunakan setelah lima menit, dan node hanya menjadi kandidat untuk konsolidasi jika pemakaian CPU dan memorinya kurang dari 70%.

Migrasi aktif

Migrasi aktif adalah fitur penskalaan otomatis opsional di ComputeClasses yang otomatis mengganti node yang ada dengan node baru. Jenis migrasi aktif berikut didukung:

optimizeRulePriority: GKE mengganti node yang menggunakan konfigurasi prioritas lebih rendah dengan node yang menggunakan konfigurasi prioritas lebih tinggi. Opsi ini memberikan pemulihan otomatis setelah kekurangan kapasitas zona sementara (ZONE_RESOURCE_POOL_EXHAUSTED). Opsi ini membantu memastikan bahwa Pod stateless atau yang toleran terhadap gangguan pada akhirnya kembali ke konfigurasi node yang paling Anda sukai, meskipun GKE awalnya harus menyediakan hardware pengganti dari aturan prioritas yang lebih rendah.
ensureAllDaemonSetPodsRunning: GKE mengganti node yang memiliki Pod DaemonSet yang tidak dapat dijadwalkan dengan node yang lebih besar yang dapat menjalankan semua Pod DaemonSet yang diperlukan. Opsi ini membantu Anda memastikan bahwa semua DaemonSet pada akhirnya berjalan di node Anda.

Selama migrasi aktif, GKE melakukan hal berikut:

GKE membuat node baru dengan konfigurasi yang memenuhi persyaratan jenis migrasi aktif.
GKE menutup akses ke node yang ada sehingga Pod baru tidak berjalan di node tersebut.
GKE mengosongkan node yang ada, sehingga Pod akan dikeluarkan dari node. Faktor-faktor berikut memengaruhi seberapa cepat node dikosongkan:
- PodDisruptionBudgets
- terminationGracePeriodSeconds
Pengontrol Kubernetes, seperti Deployment atau Job, membuat Pod untuk menggantikan Pod yang dikeluarkan. GKE menjadwalkan Pod baru ini di node baru.
Setelah node yang ada dikosongkan, GKE akan menghapus node tersebut.

Migrasi aktif tidak memengaruhi Pod dan node dalam skenario berikut:

Migrasi aktif tidak mengeluarkan Pod yang memiliki anotasi cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
Migrasi aktif tidak mengeluarkan Pod jika pengeluaran tersebut akan melanggar PodDisruptionBudget.
Migrasi aktif tidak menggantikan node yang tidak dapat dihapus. Misalnya, migrasi aktif tidak mengganti node jika hal itu melanggar setelan node pool --min-nodes.

Sebelum mengaktifkan migrasi aktif untuk ComputeClass, pertimbangkan potensi efek berikut:

Migrasi aktif tidak memigrasikan data yang disimpan di penyimpanan persisten, seperti Persistent Disk Compute Engine. Untuk meminimalkan risiko kehilangan data, jangan aktifkan migrasi aktif di ComputeClass yang digunakan workload stateful.
Di cluster Standard, jika Anda menggunakan pembuatan otomatis node pool, migrasi aktif dapat memicu pembuatan node pool baru jika node pool yang ada tidak memenuhi kriteria yang ditentukan dalam ComputeClass Anda.
Workload yang menggunakan volume persisten dengan resource zona seperti Hyperdisk mungkin tidak berfungsi dengan baik dengan migrasi aktif. Batasan zona dan batasan jenis mesin dari beberapa produk Hyperdisk dapat mengurangi efektivitas migrasi aktif. Selain itu, beberapa workload stateful mungkin tidak menoleransi gangguan yang disebabkan oleh migrasi aktif.
Jika Anda mengupdate ComputeClass yang ada untuk mengaktifkan migrasi aktif, GKE akan memigrasikan Pod yang ada ke node baru saat resource komputasi tersedia.

Migrasi aktif ke node prioritas lebih tinggi

Jenis migrasi aktif optimizeRulePriority memungkinkan GKE mengganti node yang ada yang menggunakan konfigurasi prioritas lebih rendah dengan node yang menggunakan konfigurasi prioritas lebih tinggi.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

Jika node N4 tidak tersedia saat Anda men-deploy Pod dengan ComputeClass ini—misalnya, karena kekurangan resource zona sementara (ZONE_RESOURCE_POOL_EXHAUSTED)—GKE akan menggunakan node C4 sebagai opsi pengganti. Saat kapasitas N4 pulih di lokasi Anda atau kuota Anda meningkat, GKE akan otomatis memigrasikan workload Anda kembali ke node N4:

GKE membuat node N4 baru.
GKE menutup akses dan mengosongkan node C4 yang ada. Pod Anda akan dihapus, dengan mempertimbangkan PodDisruptionBudget dan konfigurasi penghentian secara tuntas.
Pengontrol Kubernetes membuat Pod untuk menggantikan Pod yang dikeluarkan. Pod baru ini berjalan di node N4.
Setelah node C4 dikosongkan, GKE akan menghapus node tersebut.

Demikian pula, jika Anda menggunakan kolom priorityScore untuk menetapkan skor eksplisit untuk aturan prioritas, GKE akan mengganti node yang memiliki skor lebih rendah dengan node yang memiliki skor lebih tinggi.

Migrasi aktif untuk menjalankan Pod DaemonSet yang tidak dapat dijadwalkan

Jenis migrasi aktif ensureAllDaemonSetPodsRunning memungkinkan GKE otomatis mengganti node yang ada yang memiliki Pod DaemonSet yang tidak dapat diberi schedule dengan node yang lebih besar yang dapat menjalankan Pod DaemonSet tersebut.

Misalnya, spesifikasi ComputeClass berikut mengonfigurasi kelompok mesin N4:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  activeMigration:
    ensureAllDaemonSetPodsRunning: true

Pertimbangkan skenario saat Anda membuat Deployment Pod tunggal yang menggunakan ComputeClass ini dan meminta dua vCPU. Untuk menjalankan Pod ini, GKE membuat node n4-standard-2. Kemudian, Anda membuat DaemonSet yang juga meminta dua vCPU. Pod DaemonSet tidak dapat berjalan di node n4-standard-2. Dalam skenario ini, GKE melakukan hal berikut:

GKE membuat node yang menggunakan jenis mesin N4 yang lebih besar, seperti n4-standard-4, yang dapat menjalankan Pod Anda dan Pod DaemonSet. Pod DaemonSet yang tertunda akan dijadwalkan di node baru ini.
GKE menutup akses dan mengosongkan node n4-standard-2.
Saat Pod Anda dikeluarkan, Deployment akan membuat Pod pengganti. GKE menjadwalkan Pod ini di node n4-standard-4, bersama dengan Pod DaemonSet.
Setelah node n4-standard-2 dikosongkan, GKE akan menghapus node tersebut.

Menggunakan pemesanan Compute Engine

Tersedia di GKE versi 1.31.1-gke.2105000 dan yang lebih baru

Jika Anda menggunakan pemesanan kapasitas Compute Engine untuk mendapatkan tingkat jaminan ketersediaan hardware yang lebih tinggi di zonaGoogle Cloud tertentu, Anda dapat mengonfigurasi setiap prioritas penggantian di ComputeClass kustom sehingga GKE menggunakan pemesanan saat membuat node baru.

Untuk menggunakan pemesanan Compute Engine menggunakan ComputeClass kustom, Anda dapat menggunakan metode berikut:

Pembuatan otomatis node pool: GKE otomatis membuat node pool baru untuk menggunakan pemesanan yang Anda tentukan. Untuk mengetahui informasi selengkapnya, lihat Pembuatan otomatis node pool dan ComputeClass.
Node pool yang dibuat secara manual: di cluster mode Standard, Anda dapat merutekan workload ke node pool yang dibuat secara manual dengan menentukan kolom spec.priorities.nodepools di ComputeClass.

Mulai GKE versi 1.36.0-gke.3204000, Anda dapat mengonfigurasi workload untuk menggunakan pemesanan yang cocok tanpa kembali ke kapasitas on-demand menggunakan setelan afinitas AnyThenFail.

Menggunakan pemesanan di node pool yang dibuat secara manual

Untuk menggunakan pemesanan di node pool yang dibuat secara manual di cluster Standard menggunakan ComputeClass, ikuti langkah-langkah berikut:

Ikat pemesanan ke node pool dengan mengikuti langkah-langkah di Menggunakan reserved instance di GKE Standard.
Buat ComputeClass yang menggunakan aturan prioritas nodepools untuk memilih node pool yang Anda buat secara manual.

Misalnya, pertimbangkan skenario saat Anda memiliki dua node pool, yang masing-masing ditautkan ke pemesanan kapasitas terpisah. Anda lebih memilih Pod menggunakan kapasitas yang dicadangkan di node pool reservation-pool-1, bukan node pool reservation-pool-2. ComputeClass yang menerapkan preferensi ini mirip dengan contoh berikut:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

Dalam contoh ini, GKE mencoba menempatkan Pod di reservation-pool-1 terlebih dahulu, karena aturan prioritas tersebut muncul pertama di kolom priorities.

Membuat node pool secara otomatis untuk menggunakan pemesanan

Jika menggunakan pembuatan otomatis node pool, Anda dapat meminta GKE menggunakan pemesanan kapasitas untuk membuat node pool untuk aturan prioritas tertentu. Untuk menggunakan pemesanan di node pool yang dibuat otomatis, Anda harus memenuhi persyaratan berikut:

ComputeClass harus mengaktifkan pembuatan otomatis node pool.
Pemesanan non-TPU hanya dapat digunakan jika machineType atau machineFamily ditentukan.
ComputeClass yang mengonfigurasi SSD lokal harus menggunakan aturan prioritas machineType, bukan machineFamily. Untuk mengetahui detailnya, lihat bagian jenis aturan machineType.
ComputeClass yang menentukan pemesanan untuk machineType yang memiliki SSD lokal terpasang harus menyertakan kolom localSSDCount: secara eksplisit.

Pertimbangkan contoh spesifikasi ComputeClass berikut, yang memprioritaskan pemesanan bersama tertentu untuk digunakan saat menyediakan instance a3-highgpu-1g. Jika jenis instance yang diprioritaskan tidak tersedia, GKE akan menggunakan reservasi yang cocok dalam spesifikasi:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Jika Anda men-deploy Pod yang menggunakan ComputeClass accelerator-reservations, GKE akan mencoba menggunakan pemesanan a3-shared-reservation terlebih dahulu saat membuat instance a3-highgpu-1g baru untuk menjalankan Pod. Jika pemesanan khusus ini tidak memiliki kapasitas yang tersedia, GKE akan mencoba meningkatkan skala instance a3-highgpu-1g menggunakan pemesanan yang cocok. Jika tidak ada pemesanan yang dapat diakses, GKE akan beralih ke Spot VM a3-highgpu-1g. Terakhir, jika tidak ada Spot VM yang tersedia, operasi penskalaan akan gagal.

Dalam contoh ini, kedua aturan prioritas dengan referensi pemesanan secara eksplisit memerlukan kolom localSSDCount: karena bentuk mesin a3-highgpu-1g menyertakan SSD lokal.

Contoh berikut menunjukkan reservasi spesifik bersama, yang beralih ke VM Spot, lalu akhirnya ke VM on-demand:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

Anda dapat menggunakan jenis pemesanan berikut:

Reservasi project tunggal tertentu: konfigurasi kolom berikut:
- Tentukan nama pemesanan di kolom reservations.specific.name.
- Pastikan nilai kolom reservations.affinity adalah Specific.
Specific shared reservations: konfigurasi kolom berikut:
- Tentukan nama pemesanan di kolom reservations.specific.name.
- Tentukan project ID dari project yang memiliki pemesanan di kolom reservations.specific.project.
- Pastikan nilai kolom reservations.affinity adalah Specific.
Any matching reservations with fallback: konfigurasi kolom berikut:
- Pastikan nilai kolom reservations.affinity adalah AnyBestEffort.
- Jangan tetapkan nama atau project pemesanan.
Any matching reservations without fallback: konfigurasikan kolom berikut:
- Pastikan nilai kolom reservations.affinity adalah AnyThenFail.
- Jangan tetapkan nama atau project pemesanan.
- Opsional. Untuk menerapkan kegagalan secara ketat jika pemesanan yang cocok habis, konfigurasikan setelan whenUnsatisfiable: DoNotScaleUp di tingkat spec ComputeClass.

Pemesanan TPU memerlukan afinitas Spesifik. Setelan reservations.affinity: AnyBestEffort dan reservations.affinity: AnyThenFail tidak didukung.

Jika GKE tidak dapat menemukan kapasitas yang tersedia dalam pemesanan, perilaku yang dihasilkan bergantung pada jenis pemesanan yang dipilih dalam aturan prioritas ComputeClass, sebagai berikut:

Pemesanan khusus: GKE mencoba aturan prioritas berikutnya di ComputeClass.
Any matching reservations with fallback (AnyBestEffort): GKE mencoba menyediakan node on-demand yang memenuhi persyaratan aturan prioritas tersebut. Jika GKE tidak dapat menyediakan node on-demand, GKE akan mencoba aturan prioritas berikutnya di ComputeClass.
Setiap reservasi yang cocok tanpa penggantian (AnyThenFail): GKE melewati penyediaan node on-demand dan mencoba aturan prioritas berikutnya di ComputeClass. Jika tidak ada aturan lain yang berlaku, operasi penskalaan akan gagal, bergantung pada nilai setelan whenUnsatisfiable.

Jika GKE tidak dapat memenuhi persyaratan aturan prioritas apa pun untuk ComputeClass, perilaku saat tidak ada aturan yang berlaku akan terjadi.

Menggunakan blok pemesanan tertentu

Mulai GKE versi 1.31.4-gke.1072000, Anda dapat menargetkan blok reservasi tertentu dalam reservasi yang didukung hardware. Fitur ini tersedia untuk jenis mesin A3 Ultra dan A4.

Untuk menggunakan blok pemesanan tertentu, konfigurasikan resource ComputeClass Anda seperti yang ditunjukkan dalam contoh ini:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Ganti RESERVATION_BLOCK_NAME dengan nama blok pemesanan target.

Mulai GKE versi 1.33.1-gke.1788000, Anda dapat menargetkan sub-blok pemesanan tertentu dalam blok pemesanan. Fitur ini tersedia untuk jenis mesin A4X.

Untuk menggunakan sub-blok pemesanan tertentu, konfigurasikan resource ComputeClass Anda seperti yang ditunjukkan dalam contoh di Menggunakan sub-blok pemesanan tertentu.

Saat Anda menggunakan fitur ini, perhatikan pertimbangan berikut:

Fitur ini hanya berlaku untuk pemesanan spesifik dalam satu project atau project bersama.

Jumlah node minimum

Tersedia di GKE versi 1.36.3-gke.1253000 dan yang lebih baru.

Anda dapat menentukan jumlah minimum node yang harus dipertahankan GKE untuk seluruh ComputeClass atau untuk aturan prioritas tertentu menggunakan kolom minimumCapacity.targetNodeCount. GKE mempertahankan setidaknya jumlah node yang ditentukan, meskipun kapasitas tersebut tidak ada aktivitas. Menentukan kapasitas minimum cocok untuk workload yang memerlukan kapasitas komputasi dasar, seperti pelatihan AI/ML besar atau workload inferensi latensi rendah. GKE akan terus menskalakan otomatis node di atas jumlah minimum saat workload Anda memerlukan lebih banyak kapasitas.

Saat Anda menentukan kapasitas minimum untuk ComputeClass atau aturan prioritas, pertimbangkan perilaku berikut:

Jika kapasitasnya untuk seluruh ComputeClass, GKE akan mempertahankan setidaknya jumlah node tersebut di semua aturan prioritas dalam ComputeClass. Jika kapasitasnya untuk aturan prioritas tertentu, GKE akan mempertahankan setidaknya jumlah node tersebut untuk aturan prioritas tersebut.
Jika jumlah node kurang dari jumlah minimum yang ditentukan, GKE akan otomatis membuat node baru untuk mempertahankan kapasitas minimum, meskipun node tambahan tersebut tidak menjalankan Pod Anda.
GKE tidak memperkecil skala node yang membentuk kapasitas minimum, meskipun node tersebut kosong.
Kapasitas yang ditentukan adalah nilai minimum. Selama peristiwa peningkatan skala, GKE dapat melebihi jumlah minimum node untuk menjalankan Pod yang tertunda.
Jika Anda mengaktifkan migrasi aktif ke node prioritas yang lebih tinggi, GKE dapat mengganti node untuk kapasitas minimum dengan node dari aturan prioritas yang lebih tinggi. Namun, GKE tidak akan mengganti node jika penggantian tersebut menempatkan aturan prioritas di bawah kapasitas minimumnya.
Ketersediaan atau kuota resource dapat mencegah GKE membuat node untuk persyaratan kapasitas minimum.
Jika GKE tidak dapat membuat node yang cukup untuk kapasitas minimum aturan prioritas, GKE tidak akan beralih ke aturan prioritas lain. Sebagai gantinya, GKE akan membuat node yang hilang untuk aturan prioritas tersebut saat kapasitas tersedia.
Node mungkin masih dihapus dan diganti untuk menjaga responsivitas cluster (misalnya, untuk memperbaiki node yang tidak responsif atau untuk mendahului Spot VM). GKE otomatis membuat node baru untuk mempertahankan kapasitas minimum.

Bergantung pada apakah Anda mengonfigurasi kapasitas minimum untuk seluruh ComputeClass atau untuk aturan prioritas tertentu, persyaratan berikut berlaku:

Kapasitas minimum untuk ComputeClass: jika Anda menentukan kolom minimumCapacity.targetNodeCount untuk seluruh ComputeClass, semua aturan prioritas harus secara langsung atau tidak langsung meminta jenis mesin tertentu. Setiap aturan prioritas harus menggunakan setidaknya salah satu konfigurasi berikut:
- machineType
- gpu
- tpu
- Pemesanan kapasitas tertentu
GKE menolak ComputeClass yang menggunakan konfigurasi fleksibel dalam aturan prioritas, seperti kolom machineFamily, dan yang juga menentukan kapasitas minimum untuk seluruh ComputeClass.
Kapasitas minimum untuk aturan prioritas: jika Anda menentukan kolom minimumCapacity.targetNodeCount untuk aturan prioritas tertentu, aturan prioritas tersebut harus secara langsung atau tidak langsung meminta jenis mesin tertentu menggunakan setidaknya salah satu konfigurasi berikut:
- machineType
- gpu
- tpu
- Pemesanan kapasitas tertentu

Contoh berikut menunjukkan konfigurasi kapasitas minimum untuk ComputeClass dan untuk aturan prioritas:

ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: gpu-class-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  # Define a global minimum capacity of 5 nodes for this ComputeClass
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - gpu:
      type: "nvidia-tesla-a100"
      count: 1
    machineType: "a2-highgpu-1g"
  - gpu:
      type: "nvidia-l4"
      count: 1
    machineType: "g2-standard-8"

Aturan prioritas:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tiered-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: "n2-standard-16"
    # Maintain at least three nodes of this specific configuration
    minimumCapacity:
      targetNodeCount: 3
  - machineType: "e2-standard-4"

Kapasitas minimum untuk ComputeClass dan aturan prioritasnya

Jika Anda menentukan kapasitas minimum untuk ComputeClass dan untuk beberapa aturan prioritasnya, minimum aturan prioritas akan dihitung terhadap minimum ComputeClass. Perilaku berikut berlaku:

Jika jumlah minimum aturan prioritas setidaknya sama dengan minimum ComputeClass, maka node untuk aturan prioritas juga memenuhi minimum ComputeClass. GKE tidak membuat node tambahan untuk minimum ComputeClass, bahkan dalam aturan prioritas lebih tinggi yang tidak menentukan kapasitas minimum.
Minimum ComputeClass tidak membatasi minimum aturan prioritas. GKE membuat semua node untuk setiap minimum aturan prioritas, meskipun totalnya melebihi minimum ComputeClass.
Jika jumlah minimum aturan prioritas kurang dari jumlah minimum ComputeClass, GKE akan membuat node yang tersisa menggunakan aturan prioritas secara berurutan. Jika diperlukan, GKE akan kembali ke aturan prioritas yang lebih rendah untuk node yang tersisa ini.

Misalnya, pertimbangkan ComputeClass berikut, yang menentukan kapasitas minimum untuk ComputeClass dan untuk aturan prioritas kedua:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

Untuk ComputeClass ini, GKE membuat tiga node e2-standard-16 untuk aturan prioritas kedua. Node ini dihitung dalam jumlah minimum ComputeClass, yaitu lima node. Untuk dua node yang tersisa, GKE mencoba membuat node n2-standard-16 terlebih dahulu. Jika node n2-standard-16 tidak tersedia, GKE akan kembali ke node e2-standard-16.

Jika Anda mengaktifkan migrasi aktif ke node dengan prioritas lebih tinggi, GKE nantinya dapat mengganti hingga dua node e2-standard-16 dengan node n2-standard-16. Namun, GKE mempertahankan setidaknya tiga node e2-standard-16 untuk kapasitas minimum aturan prioritas kedua.

Jika Anda menetapkan kolom targetNodeCount dalam aturan prioritas kedua ke 6, GKE akan membuat enam node e2-standard-16. Keenam node ini memenuhi jumlah minimum ComputeClass, yaitu lima node, sehingga GKE tidak membuat node n2-standard-16 apa pun untuk kapasitas minimum.

Menyesuaikan konfigurasi sistem node

Anda dapat menyesuaikan parameter tertentu di kubelet dan kernel Linux menggunakan kolom nodeSystemConfig dalam spesifikasi ComputeClass. Anda dapat menentukan kolom ini dalam aturan prioritas apa pun yang menentukan seri mesin atau jenis mesin Compute Engine. Anda juga dapat menetapkan nilai global default untuk kolom konfigurasi sistem node apa pun yang dihilangkan dalam aturan prioritas dengan menambahkan kolom nodeSystemConfig ke kolom priorityDefaults di ComputeClass Anda.

Fitur ini tersedia di GKE versi 1.32.1-gke.1729000 dan yang lebih baru.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan label dan taint node

Dalam spesifikasi ComputeClass, kolom nodeLabels dan taints memungkinkan Anda menentukan konfigurasi yang cocok dengan node pool yang ada dan mengatur pembuatan node pool baru. Konfigurasi ini dapat diterapkan secara global dalam kolom nodePoolConfig untuk seluruh ComputeClass atau dicakupkan ke prioritas tertentu menggunakan kolom priority; namun, Anda harus memastikan bahwa label dan taint yang ditentukan di tingkat prioritas tidak tumpang tindih dengan yang ditetapkan secara global.

Fitur ini tersedia dalam:

Label node prioritas di GKE versi 1.33.2-gke.1111000 dan yang lebih baru.
Taint prioritas di GKE versi 1.33.4-gke.1350000 dan yang lebih baru.
Label dan taint node global di GKE versi 1.34.1-gke.3084002 dan yang lebih baru.

Selain label kustom, GKE otomatis menetapkan label sistem cloud.google.com/compute-class ke semua node yang disediakan untuk atau terkait dengan ComputeClass. Anda dapat memfilter dan mencantumkan node berdasarkan ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Untuk mengetahui informasi selengkapnya, lihat CustomResourceDefinition ComputeClass.

Mengonfigurasi taint arsitektur Arm default

Secara default, GKE menambahkan taint kubernetes.io/arch=arm64:NoSchedule ke semua node Arm, termasuk node yang dibuat untuk ComputeClass kustom. GKE hanya menjadwalkan workload yang memiliki toleransi untuk taint ini pada node Arm, yang membantu mencegah workload x86 berjalan pada arsitektur yang tidak kompatibel. Jika workload Anda kompatibel dengan x86 dan Arm, Anda dapat menonaktifkan taint default ini. Setiap workload yang memilih ComputeClass dapat berjalan di node Arm, meskipun workload tersebut tidak memiliki toleransi untuk arsitektur Arm.

Anda dapat memperbarui perilaku taint default di node pool Standard, dan dengan node yang dibuat untuk ComputeClass kustom. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi perilaku untuk node pool Standard, lihat Mengonfigurasi taint arsitektur Arm default.

Untuk mengubah perilaku default dan mengizinkan GKE menjadwalkan workload yang tidak memiliki toleransi yang sesuai ke node Arm yang dibuat untuk ComputeClass kustom, konfigurasikan ComputeClass Anda seperti yang ditunjukkan dalam contoh ini:

taintConfig:
  architectureTaintBehavior: NONE

Kolom ini memerlukan cluster yang menjalankan GKE versi 1.36.2-gke.1498000 atau yang lebih baru.

ComputeClass default untuk cluster dan namespace

Anda dapat mengonfigurasi GKE untuk menerapkan ComputeClass secara default ke Pod yang tidak memilih ComputeClass tertentu. Anda dapat menentukan ComputeClass default untuk namespace tertentu atau untuk seluruh cluster. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi cluster atau namespace dengan class default, lihat Menerapkan ComputeClass ke Pod secara default.

Node pool grup

Mulai GKE versi 1.32.2-gke.1359000, Anda dapat mengelompokkan beberapa node pool ke dalam satu unit logis yang disebut koleksi menggunakan kolom nodePoolGroup dalam spesifikasi ComputeClass Anda. Pengelompokan ini memungkinkan Anda menerapkan konfigurasi bersama di banyak node pool.

Koleksi multi-host TPU

Memerlukan GKE versi 1.31.2-gke.1518000 atau yang lebih baru. Hanya tersedia di TPU Trillium (v6e)

Anda dapat mengelompokkan deployment multi-host TPU untuk menetapkan Tujuan Tingkat Layanan (SLO) di semua node pool dalam koleksi. Untuk mengelompokkan node pool, tentukan nama grup di kolom nodePoolGroup. Semua node pool yang disediakan menggunakan ComputeClass ini termasuk dalam grup yang sama.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

Untuk informasi selengkapnya, lihat referensi berikut:

Konfigurasi node pool

Kolom nodePoolConfig dalam spesifikasi ComputeClass memungkinkan Anda menerapkan konfigurasi yang tercermin di semua node dalam node pool yang dibuat menggunakan class tersebut.

Menentukan jenis image

Anda dapat menentukan sistem operasi dasar untuk node di node pool menggunakan kolom imageType. Kolom ini memungkinkan Anda memilih jenis image untuk node pool yang akan dijalankan di node. Jika Anda menghapus kolom ini, nilai defaultnya adalah cos_containerd. Contoh berikut menunjukkan cara menentukan imageType di ComputeClass Anda:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

Untuk mengetahui informasi selengkapnya, lihat Image node.

Akun layanan

Kolom serviceAccount menentukan akun layanan Google Cloud yang digunakan oleh node dalam node pool yang dikelola oleh ComputeClass. Contoh berikut menunjukkan cara menentukan serviceAccount di ComputeClass Anda:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

Untuk mengetahui informasi selengkapnya, lihat Tentang akun layanan di GKE.

Menentukan jenis workload untuk SLO TPU

Mulai GKE versi 1.32.2-gke.1359000, Anda dapat menentukan Tujuan Tingkat Layanan (SLO) untuk workload TPU menggunakan kolom workloadType dalam nodePoolConfig. Nilai di kolom ini memberi tahu GKE tujuan penggunaan resource TPU. Kolom workloadType mendukung nilai berikut:

HIGH_AVAILABILITY: gunakan nilai ini untuk workload yang berfokus pada ketersediaan, seperti penayangan inferensi, untuk membatasi dan menyederhanakan gangguan.
HIGH_THROUGHPUT: gunakan nilai ini untuk tugas batch atau pelatihan yang memerlukan semua infrastruktur yang mendasarinya untuk berjalan hampir sepanjang waktu agar dapat membuat progres. Nilai ini hanya dapat digunakan jika nodePoolGroup juga ditentukan.

Contoh berikut menentukan ComputeClass untuk koleksi TPU multi-host yang dioptimalkan untuk workload inferensi ketersediaan tinggi.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

Untuk informasi selengkapnya, lihat referensi berikut:

Konfigurasi sandbox

Memerlukan GKE versi 1.36.2-gke.1368000 atau yang lebih baru

Anda dapat mengisolasi workload dari kernel host node dengan menjalankan Pod di sandbox menggunakan GKE Sandbox. Di ComputeClass, Anda dapat mengaktifkan GKE Sandbox dan memilih jenis sandbox untuk node menggunakan kolom nodePoolConfig.sandbox. Jenis sandbox berikut didukung:

gvisor: memerlukan GKE versi 1.36.2-gke.1368000 atau yang lebih baru.
microvm: memerlukan GKE versi 1.37.0-gke.4713000 atau yang lebih baru dan node yang menggunakan virtualisasi bertingkat.

Untuk mengetahui informasi selengkapnya tentang fitur, batasan, dan persyaratan jenis sandbox ini, lihat Tentang GKE Sandbox.

Untuk menggunakan ComputeClass guna mengaktifkan dan meminta sandbox, lihat Mengisolasi workload menggunakan GKE Sandbox.

Konfigurasi metadata instance

Memerlukan GKE versi 1.36.2-gke.1498000 atau yang lebih baru.

Kolom instanceMetadata dalam spesifikasi ComputeClass memungkinkan Anda menambahkan key-value pair metadata kustom langsung ke instance VM Compute Engine yang disediakan untuk node pool Anda oleh Autoscaler Cluster atau Node Auto-provisioning. Hal ini sama dengan menentukan flag --metadata saat membuat node pool secara manual dengan Google Cloud CLI.

Konfigurasi metadata instance kustom menggunakan ComputeClass hanya didukung pada cluster mode GKE Standard (spec.autopilot.enabled: false).

Anda dapat menentukan instanceMetadata di dua tempat dalam ComputeClass:

Konfigurasi global (spec.nodePoolConfig.instanceMetadata): menerapkan key-value pair metadata kustom secara global ke semua node pool dan VM baru yang dibuat oleh ComputeClass.
Penggantian khusus prioritas (spec.priorities[].instanceMetadata): menerapkan key-value pair metadata kustom hanya saat GKE menyediakan node menggunakan prioritas tertentu dalam hierarki.

Jika kunci metadata yang sama ditentukan di nodePoolConfig.instanceMetadata dan priorities[].instanceMetadata, nilai yang ditentukan di priorities[].instanceMetadata akan menggantikan nilai global.

Aturan skema dan validasi

Saat menentukan instanceMetadata, patuhi batasan validasi berikut:

Jenis: key-value pair yang disusun sebagai map (map[string]string).
Batas ukuran:
- Ukuran maksimum nilai metadata individual adalah 32 KB (32.768 byte).
- Ukuran gabungan maksimum semua key-value pair metadata di seluruh resource ComputeClass tidak boleh melebihi 512 KB (524.288 byte).
Batas dan format kunci:
- Anda dapat menentukan maksimum 32 key-value pair metadata kustom per ComputeClass.
- Kunci harus kurang dari 128 karakter dan hanya boleh berisi karakter alfanumerik, tanda hubung (-), dan garis bawah (_).
Kunci yang dicadangkan: GKE dan Compute Engine mencadangkan kunci metadata sistem tertentu yang diperlukan untuk mengelola operasi cluster (seperti kube-env, user-data, startup-script, dan cluster-name). Anda tidak dapat mengganti atau menentukan kunci metadata sistem yang dicadangkan.
Imutabilitas pada node pool yang ada: mengubah instanceMetadata pada ComputeClass yang ada hanya berlaku saat GKE menyediakan node pool baru (saat nodePoolAutoCreation diaktifkan). Node pool dan VM yang ada tidak diubah secara retroaktif.

Contoh berikut menunjukkan cara mengonfigurasi metadata instance global di semua node pool dan penggantian metadata khusus prioritas:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

Mengonfigurasi batas penskalaan otomatis

Tersedia di GKE versi 1.36.2-gke.2064000 dan yang lebih baru.

Secara default, GKE menyediakan node baru untuk ComputeClass hingga batas penskalaan otomatis cluster secara keseluruhan. Untuk menerapkan batas resource yang lebih ketat untuk ComputeClass tertentu, seperti membatasi jumlah maksimum GPU, CPU, atau total node yang dapat disediakan untuk ComputeClass, Anda dapat menerapkan resource kustom CapacityQuota.

Untuk mengetahui informasi selengkapnya, baca artikel Mengonfigurasi batas resource terperinci.

Konfigurasi Shielded GKE Node

Memerlukan GKE versi 1.36.3-gke.1244000 atau yang lebih baru

Untuk mengonfigurasi fitur Shielded GKE Node, seperti Booting Aman dan Pemantauan Integritas, untuk node pool yang dibuat otomatis dan dikelola oleh ComputeClass, tentukan kolom shieldedInstanceConfig di bagian blok nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig).

Nilai default untuk shieldedInstanceConfig bergantung pada mode cluster dan konfigurasi ComputeClass Anda:

Dalam cluster mode Standard: saat shieldedInstanceConfig diinisialisasi selama rekonsiliasi nodePoolAutoCreation, kolom enableIntegrityMonitoring ditetapkan secara default ke true dan kolom enableSecureBoot ditetapkan secara default ke false, kecuali jika Anda mengonfigurasinya secara eksplisit.
Di cluster Autopilot (atau saat spec.autopilot.enabled adalah true di ComputeClass): kolom enableSecureBootdan enableIntegrityMonitoring ditetapkan secara default ke true dan tidak dapat dinonaktifkan.

Contoh berikut menunjukkan cara mengonfigurasi kolom shieldedInstanceConfig di dalam blok nodePoolAutoCreation untuk mengaktifkan fitur Shielded GKE Node di seluruh node pool yang dibuat secara otomatis:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

Meminta ComputeClass dalam workload

Untuk menggunakan ComputeClass kustom, Pod Anda harus secara eksplisit meminta ComputeClass tersebut dengan menggunakan nodeSelector dalam spesifikasi Pod. Anda dapat menetapkan ComputeClass sebagai default untuk namespace Kubernetes tertentu. Pod dalam namespace tersebut menggunakan ComputeClass tersebut, kecuali jika Pod meminta ComputeClass yang berbeda.

Misalnya, manifes berikut meminta ComputeClass cost-optimized:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Pemilih node untuk label node sistem

GKE menambahkan label sistem ke node untuk mengidentifikasi node berdasarkan kriteria seperti jenis mesin, akselerator hardware yang terpasang, atau jenis boot disk. Label sistem ini memiliki salah satu awalan berikut di kunci label:

k8s.io
cloud.google.com
gke.io
node.kubernetes.io/instance-type

Di GKE versi 1.32.3-gke.1499000 dan yang lebih baru, Anda dapat men-deploy workload yang menggunakan pemilih node untuk memilih label sistem dan ComputeClass secara bersamaan. Jika Anda memilih label sistem di Pod yang memilih ComputeClass, pastikan Pod tersebut dijadwalkan seperti yang diharapkan. Konflik antara konfigurasi ComputeClass dan pemilih node di Pod dapat menyebabkan masalah seperti berikut:

GKE tidak dapat membuat node yang menggunakan konfigurasi prioritas tertinggi untuk ComputeClass.
Pod tetap dalam status Pending.

GKE juga menolak Pod yang memilih label sistem yang memiliki kolom terkait dalam spesifikasi ComputeClass. Saat Anda menggunakan ComputeClass, perbarui workload Anda untuk menghapus label berikut dari pemilih node dan konfigurasikan kolom yang sesuai di ComputeClass yang Anda buat:

Label node	Kolom `ComputeClass`
`cloud.google.com/machine-family`	`priorities.machineFamily`
`cloud.google.com/machine-type`	`priorities.machineType`
`cloud.google.com/gke-spot`	`priorities.spot`
`cloud.google.com/gke-accelerator`	`priorities.gpu.type`
`cloud.google.com/gke-gpu-driver-version`	`priorities.gpu.driverVersion`
`cloud.google.com/reservation-name`	`priorities.reservations.specific.name`
`cloud.google.com/reservation-project`	`priorities.reservations.specific.project`
`cloud.google.com/reservation-affinity`	`priorities.reservations.affinity`
`cloud.google.com/gke-ephemeral-storage-local-ssd`	`priorities.storage.localSSDCount`
`cloud.google.com/gke-boot-disk`	`priorities.storage.bootDiskType`
`cloud.google.com/gke-boot-disk-size`	`priorities.storage.bootDiskSize`
`cloud.google.com/gke-node-pool-group-name`	`nodePoolGroup.name`
`cloud.google.com/gke-workload-type`	`nodePoolConfig.workloadType`
`node.kubernetes.io/instance-type`	`priorities.machineType`

Memantau penggunaan ComputeClass

Anda dapat memantau interaksi autoscaler cluster dengan ComputeClasses menggunakan metrik Cloud Monitoring. Metrik seperti kubernetes.io/autoscaler/cluster_pending_pods_per_ccc, kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc, dan kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc melacak Pod yang tertunda, upaya penyediaan node, dan kegagalan penyediaan. Metrik ini tersedia di GKE versi 1.37 dan yang lebih baru.

Untuk mengetahui informasi mendetail tentang cara membuat kueri metrik ini dan menafsirkan label, lihat Melihat peristiwa dan metrik autoscaler cluster.

Batasan

Nama ComputeClass tidak boleh diawali dengan gke atau autopilot (dicadangkan untuk ComputeClass sistem).
Cluster tertentu memiliki tingkat pembuatan dan penghapusan Pod yang tinggi, sehingga meningkatkan waktu evaluasi untuk autoscaler cluster. Selama operasi penskalaan, autoscaler cluster mungkin tidak memiliki waktu untuk mengevaluasi aturan prioritas berikutnya di ComputeClass sebelum periode backoff untuk aturan prioritas sebelumnya berakhir. Akibatnya, Pod mungkin tetap dalam status Pending. Untuk mengurangi masalah ini, kurangi frekuensi pembuatan dan penghapusan Pod, misalnya dengan menonaktifkan migrasi aktif untuk ComputeClass.

Langkah berikutnya

Pelajari praktik terbaik untuk ComputeClasses.
Pelajari cara mengontrol atribut node yang diskalakan otomatis dengan ComputeClass kustom.
Pelajari lebih lanjut ComputeClass Balanced dan Penyebaran Skala di cluster Autopilot.
Pelajari cara mengonfigurasi pembuatan otomatis node pool.
Pelajari lebih lanjut penskalaan otomatis cluster GKE.
Pelajari cara memilih class komputasi untuk Pod Autopilot.
Memecahkan masalah ComputeClass kustom.

Tentang ComputeClass kustom Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Ringkasan ComputeClasses

Manfaat ComputeClass kustom

Kasus penggunaan untuk ComputeClass kustom

Cara kerja ComputeClass kustom

Melihat definisi resource kustom lengkap

Merencanakan ComputeClass kustom

Memilih prioritas komputasi penggantian

Skor aturan prioritas

Properti node tingkat atas untuk aturan prioritas

Konfigurasi machineFamily

Konfigurasi machineType

Konfigurasi GPU

Konfigurasi TPU

Zona AI target

Konfigurasi jaringan DRANET

Cara GKE membuat node menggunakan aturan prioritas

Nilai default untuk aturan prioritas

Node pool GKE Standard dan ComputeClass

Mengonfigurasi node pool yang dibuat secara manual untuk penggunaan ComputeClass

Pembuatan otomatis node pool dan ComputeClass

Menargetkan node pool tertentu dalam definisi ComputeClass

Menentukan perilaku penskalaan jika tidak ada aturan prioritas yang berlaku

Meminta kebijakan penempatan

Menetapkan parameter penskalaan otomatis untuk konsolidasi node

Migrasi aktif

Migrasi aktif ke node prioritas lebih tinggi

Migrasi aktif untuk menjalankan Pod DaemonSet yang tidak dapat dijadwalkan

Menggunakan pemesanan Compute Engine

Menggunakan pemesanan di node pool yang dibuat secara manual

Membuat node pool secara otomatis untuk menggunakan pemesanan

Menggunakan blok pemesanan tertentu

Jumlah node minimum

Kapasitas minimum untuk ComputeClass dan aturan prioritasnya

Menyesuaikan konfigurasi sistem node

Menentukan label dan taint node

Mengonfigurasi taint arsitektur Arm default

ComputeClass default untuk cluster dan namespace

Node pool grup

Koleksi multi-host TPU

Konfigurasi node pool

Menentukan jenis image

Akun layanan

Menentukan jenis workload untuk SLO TPU

Konfigurasi sandbox

Konfigurasi metadata instance

Aturan skema dan validasi

Mengonfigurasi batas penskalaan otomatis

Konfigurasi Shielded GKE Node

Meminta ComputeClass dalam workload

Pemilih node untuk label node sistem

Memantau penggunaan ComputeClass

Batasan

Langkah berikutnya

Tentang ComputeClass kustom