Praktik terbaik untuk ComputeClass

Platform engineer dapat menggunakan ComputeClasses kustom untuk mengonfigurasi setelan node dan prioritas penggantian secara deklaratif yang digunakan Google Kubernetes Engine (GKE) untuk membuat node selama penskalaan otomatis. Anda dapat membuat ComputeClass berdasarkan strategi dan persyaratan workload tertentu. Dokumen ini memberikan praktik terbaik untuk mendesain dan mengimplementasikan ComputeClass di cluster Anda. Anda seharusnya sudah memahami ComputeClass kustom. Untuk ringkasan gabungan dari semua praktik terbaik GKE, lihat Praktik terbaik untuk GKE.

Desain ComputeClass

Bagian berikut memberikan praktik terbaik untuk mendesain dan menerapkan ComputeClass di cluster Anda berdasarkan sasaran seperti memaksimalkan fleksibilitas, efisiensi, ketersediaan, dan performa kapasitas komputasi. ComputeClass berfungsi dengan node pool yang dibuat secara manual dan dibuat secara otomatis.

Mendesain setiap ComputeClass berdasarkan strategi

Desain setiap ComputeClass untuk memenuhi sasaran tertentu bagi workload, tim, atau organisasi Anda. Gunakan perilaku penggantian ComputeClass dan kemampuan untuk memilih node pool yang dibuat secara manual dan kreasi otomatis untuk memprioritaskan hasil tertentu, seperti mengurangi overhead manual atau meningkatkan performa penjadwalan. Bagian berikut menjelaskan strategi umum.

Meningkatkan ketersediaan resource dan mengurangi overhead manual

Untuk mendelegasikan pembuatan node pool ke GKE, gunakan hanya node pool yang dibuat otomatis di ComputeClass Anda. Autoscaler mengonfigurasi node berdasarkan ketersediaan hardware, persyaratan resource Pod, dan kapasitas zona. Strategi ini menghilangkan kebutuhan untuk membuat dan menyesuaikan node pool secara manual dan dapat mengurangi biaya yang terkait dengan kapasitas node yang tidak digunakan dan tidak ada aktivitas.

Meningkatkan performa penjadwalan dan menyesuaikan node

Untuk menyesuaikan node prioritas tertinggi dan mengurangi latensi penjadwalan, gunakan campuran node pool yang dibuat secara manual dan otomatis di ComputeClass Anda. Strategi hibrid ini mengurangi frekuensi Pod menunggu GKE membuat node pool baru. Karena node pool dengan prioritas tertinggi dibuat secara manual, Anda dapat menyesuaikan hardware untuk memenuhi persyaratan Pod Anda dengan tepat.

Strategi hybrid melibatkan jenis node pool berikut berdasarkan urutan prioritas di ComputeClass:

  1. Node pool yang dibuat secara manual: node pool ini memiliki spesifikasi persis yang Anda inginkan untuk menjalankan sebagian besar Pod. Konfigurasikan node pool ini dengan label node, taint node, pemesanan kapasitas, atau konfigurasi khusus seperti parameter kubelet. Buat node pool ini dengan jumlah node sebanyak yang Anda perkirakan akan dibutuhkan oleh Pod Anda. Di ComputeClass Anda, tetapkan prioritas tertinggi ke node pool ini.
  2. Node pool yang dibuat otomatis: sebagai tindakan penggantian, gunakan ComputeClass untuk meminta node pool tambahan yang masih dioptimalkan untuk Pod Anda. Tetapkan prioritas yang lebih rendah untuk node pool yang dibuat otomatis ini daripada node pool yang Anda buat secara manual.

ComputeClass berikut menggunakan strategi hybrid ini:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

Saat Anda men-deploy workload yang menggunakan ComputeClass ini, GKE akan menempatkan Pod di node yang tersedia di manual-pool1. GKE hanya membuat node pool baru jika node pool yang dibuat secara manual tidak memiliki kapasitas yang tersedia. Latensi penjadwalan akan berkurang saat jumlah node yang ada di node pool yang dibuat secara manual meningkat, karena GKE tidak perlu membuat node baru sesering itu.

Menentukan perilaku penskalaan upaya terakhir secara eksplisit

Kolom whenUnsatisfiable mengontrol apa yang terjadi jika GKE tidak dapat memenuhi persyaratan aturan prioritas apa pun di ComputeClass. Untuk menghindari perilaku yang tidak terduga setelah upgrade versi, tentukan nilai untuk kolom ini secara eksplisit di setiap ComputeClass. Menetapkan nilai akan membantu pengguna ComputeClass mengetahui apa yang diharapkan saat mereka memilih ComputeClass tersebut dalam workload. Nilai yang direkomendasikan untuk kolom ini bergantung pada jenis workload, sebagai berikut:

  • Workload tujuan umum: jika workload Anda dapat berjalan di deret mesin apa pun, tentukan nilai ScaleUpAnyway. Jika node yang cocok dengan aturan prioritas di ComputeClass tidak tersedia, GKE akan meningkatkan skala node yang menggunakan seri mesin default cluster.
  • Workload yang memerlukan hardware khusus: untuk akselerator atau workload komputasi berperforma tinggi yang bergantung pada hardware tertentu, seperti GPU atau seri mesin Compute Engine tertentu, tentukan nilai DoNotScaleUp. Jika node yang cocok dengan aturan prioritas di ComputeClass tidak tersedia, Pod akan tetap dalam status Pending hingga resource tersedia. Pendekatan ini mencegah Pod berjalan di hardware yang tidak kompatibel.

Untuk mengetahui informasi selengkapnya, lihat Menentukan perilaku penskalaan saat tidak ada aturan prioritas yang berlaku.

Menetapkan ComputeClass default tingkat cluster untuk sebagian besar workload

Jika sebagian besar workload Anda memiliki persyaratan hardware yang sama, konfigurasikan ComputeClass default untuk cluster. GKE menerapkan ComputeClass default ke workload apa pun yang tidak secara eksplisit memilih ComputeClass. Dengan menetapkan ComputeClass default, operator aplikasi tidak perlu mengubah pemilih node atau meminta node pool dan hardware tertentu secara manual di setiap Pod. Jika Anda menetapkan ComputeClass default tingkat cluster, jangan tambahkan label dan taint node untuk ComputeClass lain ke node pool yang ada di cluster. Selama penjadwalan untuk ComputeClass default level cluster, GKE mengabaikan node pool apa pun yang memiliki label node atau taint node untuk ComputeClass lain.

Menetapkan ComputeClass default untuk namespace guna memisahkan tenant

Selain ComputeClass default tingkat cluster, Anda dapat menetapkan ComputeClass default untuk namespace tertentu. Jika Anda memiliki lingkungan multi-tenant atau ingin memisahkan workload yang berjalan di hardware khusus, konfigurasikan ComputeClass default untuk namespace tersebut. Untuk mencegah Pod sistem berjalan di hardware khusus seperti node GPU, tambahkan ComputeClass tujuan umum sebagai ComputeClass default untuk namespace sistem.

Menjalankan workload interaksi rendah dalam mode Autopilot

Jika Anda memiliki workload yang tidak memerlukan interaksi atau pengelolaan manual, jalankan workload tersebut dalam mode Autopilot menggunakan ComputeClass. Anda dapat mengaktifkan mode Autopilot di ComputeClass mana pun, bahkan saat Anda memiliki cluster Standard. GKE menjalankan workload yang memilih ComputeClass Autopilot pada node yang terkelola sepenuhnya yang menerapkan fitur keamanan, penskalaan, dan penagihan GKE Autopilot. Untuk mengetahui informasi selengkapnya, lihat Tentang workload mode Autopilot di GKE Standard.

Workload stateful

Bagian berikut memberikan praktik terbaik untuk mengurangi gangguan atau perilaku yang tidak terduga dalam workload stateful yang mengandalkan data persisten.

Menonaktifkan migrasi aktif

Migrasi aktif secara otomatis memindahkan Pod ke node baru yang memiliki prioritas lebih tinggi di ComputeClass atau memiliki kapasitas untuk menjalankan Pod DaemonSet yang tidak terjadwal. Selama migrasi aktif, GKE menghentikan Pod pada node yang ada dan membuat Pod baru pada node dengan prioritas lebih tinggi. Jika Anda memiliki workload yang mengandalkan data di penyimpanan persisten lokal, memindahkan Pod ke node baru dapat menyebabkan gangguan karena Pod kehilangan akses ke data persisten. Untuk menghindari masalah ini, nonaktifkan migrasi aktif untuk ComputeClass yang ditujukan untuk workload stateful.

Meningkatkan keandalan penjadwalan menggunakan StorageClass

Gunakan StorageClass untuk meningkatkan keandalan penjadwalan untuk workload stateful dengan cara berikut:

  • Buat volume hanya setelah pembuatan Pod: jika Anda menggunakan penyediaan volume dinamis, tentukan nilai WaitForFirstConsumer di kolom volumeBindingMode di StorageClass. Mode binding volume ini mencegah pembuatan PersistentVolume hingga GKE membuat Pod yang menggunakan PersistentVolumeClaim yang sesuai. GKE menyediakan PersistentVolume di zona yang sama dengan node yang menjalankan Pod.
  • Gunakan StorageClass yang mendukung topologi: jika ComputeClass Anda mencakup beberapa generasi seri mesin, gunakan StorageClass yang mengaktifkan pemilihan jenis disk otomatis (parameters.type: dynamic) dan yang hanya menjadwalkan pada node yang mendukung jenis disk yang Anda tentukan. Misalnya, ComputeClass Anda beralih dari seri khusus Hyperdisk seperti C4, C4D, atau N4 ke seri Persistent Disk seperti N2 atau N2D selama batasan kapasitas zona. Anda dapat menggunakan StorageClass dynamic-rwo bawaan atau StorageClass kustom. Workload stateful Anda kemudian dapat melakukan failover di beberapa generasi instance Compute Engine, karena autoscaler cluster secara dinamis memilih jenis disk yang kompatibel (hyperdisk-balanced atau pd-balanced) untuk node pengganti yang disediakan.

Mendesain infrastruktur Anda untuk fleksibilitas, efisiensi, dan ketersediaan kapasitas komputasi

Bagian berikut memberikan praktik terbaik untuk meningkatkan fleksibilitas, efisiensi, dan ketersediaan kapasitas komputasi di ComputeClass, sehingga Pod Anda menghabiskan lebih sedikit waktu dalam status Pending.

Meminta seri mesin, bukan jenis mesin

Anda dapat meminta seri mesin Compute Engine atau jenis mesin tertentu dalam aturan prioritas ComputeClass. Kecuali jika Anda memiliki dependensi ketat pada jenis mesin tertentu, pilih seri mesin menggunakan kolom machineFamily. Selama operasi penskalaan, GKE dapat membuat node yang menggunakan jenis mesin yang layak dalam seri mesin tersebut, sehingga meningkatkan kemungkinan Pod Anda berjalan pada konfigurasi node yang paling Anda inginkan.

Menggunakan pemesanan kapasitas untuk hardware yang banyak diminati

Jika workload Anda mengandalkan hardware yang banyak diminati, seperti TPU atau GPU berperforma tinggi, buat pemesanan kapasitas Compute Engine untuk hardware tersebut dan gunakan pemesanan tersebut di ComputeClass Anda. Pemesanan kapasitas meningkatkan kemungkinan ketersediaan hardware di region atau zona Anda, yang membantu Anda meningkatkan fleksibilitas, efisiensi, dan ketersediaan kapasitas komputasi. Untuk menggunakan pemesanan di ComputeClass tanpa memengaruhi perilaku penggantian, gunakan afinitas pemesanan Specific atau AnyThenFail. Jika Anda menggunakan afinitas AnyBestEffort atau Automatic dan tidak ada kapasitas yang dipesan yang tersedia, Compute Engine mungkin akan mengabaikan aturan prioritas ComputeClass dan beralih ke hardware on-demand. Untuk mengetahui informasi selengkapnya, lihat Menggunakan resource zona yang dipesan.

Jangan menggunakan reservasi baru selama minimal satu jam

Autoscaler cluster menyimpan informasi tentang pemesanan kapasitas dalam cache. Saat Anda membuat pemesanan kapasitas baru, autoscaler mungkin memerlukan waktu hingga satu jam untuk menemukan pemesanan tersebut. Setelah membuat pemesanan, tunggu setidaknya satu jam sebelum Anda menggunakan pemesanan tersebut dalam workload. Jika Anda men-deploy workload yang menggunakan pemesanan sebelum autoscaler menyimpan pemesanan di cache, operasi penskalaan otomatis mungkin akan gagal.

Keamanan

Bagian berikut memberikan praktik terbaik untuk meningkatkan keamanan ComputeClass di cluster Anda. Langkah-langkah ini penting karena ComputeClass dapat digunakan untuk membuat dan mengonfigurasi node yang menggunakan hardware yang mahal atau memiliki ketersediaan terbatas. Penyalahgunaan yang disengaja atau tidak disengaja dapat mengakibatkan gangguan workload, biaya penggunaan resource yang tidak direncanakan, dan kehabisan kuota.

Membatasi akses API ke konfigurasi ComputeClass

Workload dapat menggunakan ComputeClass untuk membuat node yang menjalankan hardware khusus, termasuk GPU dan TPU. Batasi akses untuk membuat, mengubah, dan menghapus ComputeClass ke akun utama yang sama yang dapat membuat, mengubah, dan menghapus node di cluster Anda. Untuk mengontrol akses ke ComputeClasses, gunakan kebijakan RBAC.

Membatasi ketersediaan ComputeClass menurut namespace

Pelanggan GKE sering kali memisahkan tim atau jenis workload yang berbeda berdasarkan namespace Kubernetes. ComputeClass adalah resource cakupan cluster, yang berarti bahwa workload apa pun di namespace mana pun dapat memilih ComputeClass apa pun secara default. Untuk menghindari penyalahgunaan yang disengaja atau tidak disengaja, gunakan ValidatingAdmissionPolicies untuk mengontrol kumpulan ComputeClass yang dapat dipilih oleh workload di setiap namespace. Misalnya, Anda dapat mencegah Pod di namespace frontend web agar tidak dapat memilih ComputeClass yang membuat akselerator. Pastikan ValidatingAdmissionPolicies Anda memeriksa konfigurasi umum berikut:

  • Memeriksa semua kolom pilihan: workload dapat memilih ComputeClass dengan menggunakan kolom nodeSelector, nodeAffinity, atau tolerations dalam spesifikasi Pod. Untuk menghindari pemilihan ComputeClass yang tidak diinginkan, periksa semua kolom ini dalam ekspresi ValidatingAdmissionPolicy Anda.
  • Periksa bypass toleransi karakter pengganti: blokir atau validasi toleransi karakter pengganti secara eksplisit (misalnya, toleransi operator: Exists tanpa kunci). Pemilih karakter pengganti ini dapat mencakup sebagian besar taint node, termasuk taint ComputeClass.
  • Periksa semua pengontrol workload: konfigurasikan matchConstraints kebijakan untuk mencakup semua resource pengontrol workload (seperti Deployment, StatefulSet, DaemonSet, Job, dan CronJob). Jangan batasi pemeriksaan Anda hanya pada resource Pod.

Untuk mengetahui informasi selengkapnya, lihat Membatasi akses untuk mengubah dan memilih ComputeClass.

Keandalan

Bagian berikut memberikan praktik terbaik untuk meningkatkan keandalan penskalaan otomatis dan migrasi Pod untuk ComputeClass, yang mengurangi risiko gangguan atau Pod yang macet.

Mencegah penggunaan pemilih node yang bertentangan

Pemilih node di Pod Anda memengaruhi tempat GKE menempatkan Pod tersebut dan, dalam mode Autopilot atau dengan pembuatan otomatis node pool, dapat memicu pembuatan node pool baru di cluster Anda. Jika Anda memiliki Pod yang memilih ComputeClass dan menggunakan pemilih node untuk meminta node yang bertentangan dengan konfigurasi ComputeClass, GKE mungkin tidak akan menjadwalkan Pod sama sekali.

Misalnya, pertimbangkan ComputeClass yang hanya meminta instance on-demand. Jika Pod memilih ComputeClass tersebut dan memilih Spot VM di pemilih node, GKE tidak dapat menjadwalkan Pod karena ComputeClass dan pemilih node saling bertentangan. Untuk menghindari masalah ini, gunakan metode seperti ValidatingAdmissionPolicies untuk mencegah Pod yang memilih ComputeClass agar tidak memilih label node sistem juga. Untuk mengetahui informasi selengkapnya, lihat Pemilih node untuk label node sistem.

Menguji semua perubahan pada setelan migrasi dan penskalaan otomatis yang aktif

Setelan migrasi dan penskalaan otomatis yang aktif di ComputeClass secara langsung memengaruhi seberapa sering GKE menghentikan Pod Anda untuk melakukan tugas seperti memindahkan Pod ke hardware yang lebih disukai dan menggabungkan node yang kurang dimanfaatkan. Modifikasi pada setelan ini di ComputeClass yang ada dapat menyebabkan gangguan workload yang tidak terduga. Sebelum menerapkan modifikasi apa pun pada setelan ini di ComputeClass yang ada, uji perubahan di lingkungan staging. Anda juga dapat menggunakan anotasi untuk melindungi workload penting dari pengeluaran selama penskalaan.

Menguji update CRD ComputeClass sebelum upgrade cluster

GKE mengupdate CustomResourceDefinition (CRD) ComputeClass secara berkala untuk menambahkan kolom, mengubah perilaku kolom, dan memperbaiki masalah. Penambahan dan modifikasi kolom biasanya berlaku di versi GKE tertentu. Sebelum mengupgrade cluster produksi ke versi minor atau versi patch baru, periksa apakah perubahan pada CRD menyebabkan masalah workload dengan menggunakan panduan berikut:

Menggunakan PodDisruptionBudget untuk meningkatkan ketersediaan workload

Operasi ComputeClass yang menyebabkan penghapusan Pod, seperti migrasi aktif, mematuhi PodDisruptionBudgets yang dikonfigurasi. Misalnya, Anda dapat mengonfigurasi Deployment inferensi agar memiliki PodDisruptionBudget yang memerlukan lebih dari 70% Pod tersedia. Selama migrasi aktif, jika pengeluaran Pod melanggar anggaran tersebut, GKE tidak akan mengeluarkan Pod. Tentukan PodDisruptionBudget untuk workload seperti berikut:

  • Workload stateless, seperti Deployment inferensi.
  • Workload stateful yang direplikasi, seperti aplikasi database dengan ketersediaan tinggi.

Jangan mengandalkan PodDisruptionBudget untuk melindungi workload yang perlu dijalankan hingga selesai, hanya memiliki satu instance, atau mengandalkan data persisten lokal. Tentukan anggaran yang menyeimbangkan antara ketersediaan workload dan memungkinkan fungsi seperti upgrade selesai.

Melindungi workload penting dari pengosongan

Jika Anda memiliki workload yang setiap Pod-nya harus berjalan hingga selesai sebelum dihentikan, tambahkan anotasi cluster-autoscaler.kubernetes.io/safe-to-evict: "false" ke spesifikasi Pod. Anotasi ini mencegah GKE mengeluarkan Pod selama operasi penskalaan otomatis. Gunakan anotasi ini untuk melindungi Pod yang tidak dapat menoleransi gangguan, seperti workload stateful instance tunggal dan Tugas batch yang berjalan lama.

Ringkasan praktik terbaik

Dokumen ini berisi praktik terbaik berikut untuk ComputeClass:

Langkah berikutnya