Praktik terbaik untuk ComputeClass

Engineer platform 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 merancang dan menerapkan ComputeClass di cluster Anda. Anda seharusnya sudah memahami ComputeClass kustom. Untuk ringkasan gabungan semua praktik terbaik GKE, lihat Praktik terbaik untuk GKE.

Desain ComputeClass

Bagian berikut memberikan praktik terbaik untuk mendesain dan mengimplementasikan ComputeClass di cluster Anda berdasarkan sasaran seperti memaksimalkan ketersediaan dan performa. ComputeClass berfungsi dengan kumpulan node yang dibuat secara manual dan otomatis.

Desain setiap ComputeClass berdasarkan strategi

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

Meningkatkan ketersediaan dan mengurangi beban 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 meniadakan kebutuhan untuk membuat dan menyesuaikan node pool secara manual serta dapat mengurangi biaya yang terkait dengan kapasitas node yang tidak digunakan dan tidak aktif.

Meningkatkan performa penjadwalan dan menyesuaikan node

Untuk menyetel node prioritas tertinggi dan mengurangi latensi penjadwalan, gunakan campuran node pool yang dibuat secara manual dan otomatis di ComputeClass Anda. Strategi hibrida ini mengurangi frekuensi Pod menunggu GKE membuat node pool baru. Karena node pool prioritas tertinggi Anda dibuat secara manual, Anda dapat menyempurnakan hardware untuk memenuhi persyaratan Pod Anda secara 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 seperti yang Anda inginkan untuk menjalankan sebagian besar Pod Anda. Konfigurasi node pool ini dengan label node, taint node, reservasi kapasitas, atau konfigurasi khusus seperti parameter kubelet. Buat node pool ini dengan jumlah node sebanyak yang Anda perkirakan akan dibutuhkan Pod Anda. Di ComputeClass, 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 untuk node pool yang dibuat secara manual.

Contoh 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 menempatkan Pod pada node yang tersedia di manual-pool1. GKE membuat node pool baru hanya jika node pool yang dibuat secara manual tidak memiliki kapasitas yang tersedia. Latensi penjadwalan berkurang saat jumlah node yang ada di node pool yang dibuat secara manual meningkat, karena GKE tidak perlu membuat node baru sesering mungkin.

Menentukan perilaku penskalaan upaya terakhir secara eksplisit

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

  • Workload tujuan umum: jika workload Anda dapat berjalan di seri mesin apa pun, tentukan nilai ScaleUpAnyway. Jika node yang cocok dengan aturan prioritas di ComputeClass tidak tersedia, GKE akan menskalakan 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, konfigurasi 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 kumpulan node 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 tingkat cluster, GKE mengabaikan node pool apa pun yang memiliki label node atau taint node untuk ComputeClass lainnya.

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, maka konfigurasi 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 ComputeClasses. Anda dapat mengaktifkan mode Autopilot di ComputeClass mana pun, meskipun 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 di node yang ada dan membuat Pod baru di node berprioritas 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 beban kerja stateful.

Meningkatkan keandalan penjadwalan dengan 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 volumeBindingMode field dalam StorageClass. Mode pengikatan volume ini mencegah pembuatan PersistentVolume hingga setelah 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 (misalnya, C4 dan C3), gunakan StorageClass yang mengaktifkan pemilihan jenis disk otomatis dan yang menjadwalkan hanya pada node yang mendukung jenis disk yang Anda tentukan. Anda dapat menggunakan dynamic-rwo StorageClass bawaan atau StorageClass kustom. Workload stateful Anda kemudian dapat berjalan di beberapa generasi instance Compute Engine, karena penskala otomatis cluster secara dinamis memilih jenis disk yang kompatibel.

Ketersediaan

Bagian berikut memberikan praktik terbaik untuk meningkatkan ketersediaan 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 yang 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, yang meningkatkan kemungkinan Pod Anda berjalan pada konfigurasi node yang paling Anda sukai.

Menggunakan reservasi kapasitas untuk hardware yang banyak diminati

Jika workload Anda mengandalkan hardware yang banyak diminati, seperti TPU atau GPU berperforma tinggi, buat reservasi kapasitas Compute Engine untuk hardware tersebut dan gunakan reservasi tersebut di ComputeClass Anda. Pemesanan kapasitas meningkatkan kemungkinan hardware tersedia di wilayah atau zona Anda, sehingga membantu Anda meningkatkan kemampuan perolehan resource. Untuk menggunakan reservasi di ComputeClass tanpa memengaruhi perilaku penggantian, gunakan afinitas reservasi Specific atau AnyThenFail. Jika Anda menggunakan afinitas AnyBestEffort atau Automatic dan tidak ada kapasitas yang dipesan yang tersedia, Compute Engine mungkin melewati aturan prioritas ComputeClass dan kembali ke hardware sesuai permintaan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan resource zona yang dipesan.

Jangan menggunakan reservasi baru setidaknya selama satu jam

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

Keamanan

Bagian berikut memberikan praktik terbaik untuk meningkatkan keamanan ComputeClass di cluster Anda. Tindakan 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 pokok yang sama yang dapat membuat, mengubah, dan menghapus node di cluster Anda. Untuk mengontrol akses ke ComputeClass, gunakan kebijakan RBAC.

Membatasi ketersediaan ComputeClass berdasarkan namespace

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

  • Periksa semua kolom pilihan: workload dapat memilih ComputeClass dengan menggunakan kolom nodeSelector, nodeAffinity, atau tolerations dalam spesifikasi Pod. Untuk menghindari pemilihan ComputeClass yang tidak disengaja, periksa semua kolom ini dalam ekspresi ValidatingAdmissionPolicy Anda.
  • Periksa apakah ada pengabaian 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 beban kerja: konfigurasi matchConstraints kebijakan untuk mencakup semua resource pengontrol beban kerja (seperti Deployment, StatefulSet, DaemonSet, Job, dan CronJob). Jangan cakup pemeriksaan Anda hanya ke 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 menjadwalkan Pod sama sekali.

Misalnya, pertimbangkan ComputeClass yang hanya meminta instance on-demand. Jika Pod memilih ComputeClass tersebut dan memilih VM Spot dalam 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 juga memilih label node sistem. Untuk mengetahui informasi selengkapnya, lihat Pemilih node untuk label node sistem.

Menguji semua perubahan pada setelan penskalaan otomatis dan migrasi aktif

Setelan penskalaan otomatis dan migrasi 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 beban kerja penting dari pengusiran selama penskalaan.

Menguji update CRD ComputeClass sebelum upgrade cluster

GKE secara rutin mengupdate CustomResourceDefinition (CRD) ComputeClass 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 beban kerja dengan menggunakan panduan berikut:

Menggunakan PodDisruptionBudgets 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 agar tersedia. Selama migrasi aktif, jika penghentian Pod melanggar anggaran tersebut, GKE tidak akan menghentikan Pod. Tentukan PodDisruptionBudgets untuk workload seperti berikut:

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

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

Melindungi workload penting dari pengusiran

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 mengeliminasi Pod selama operasi penskalaan otomatis. Gunakan anotasi ini untuk melindungi Pod yang tidak dapat mentoleransi gangguan, seperti workload stateful instance tunggal dan Tugas batch yang berjalan lama.

Ringkasan praktik terbaik

Dokumen ini memiliki praktik terbaik berikut untuk ComputeClass:

Langkah berikutnya