Tentang buffer kapasitas

Buffering kapasitas membantu Anda mengurangi latensi startup Pod untuk workload Google Kubernetes Engine (GKE) dengan memungkinkan Anda mendeklarasikan tingkat buffering kapasitas aktif atau standby secara proaktif di cluster. Dengan mendeklarasikan kapasitas cadangan lebih awal, Anda dapat memulai workload lebih cepat dengan cara yang hemat biaya.

Dokumen ini menjelaskan cara kerja buffering kapasitas. Untuk mempelajari cara mengaktifkan dan menggunakan buffering kapasitas, lihat Mengonfigurasi buffering kapasitas.

Kapan harus menggunakan buffering kapasitas

Gunakan buffering kapasitas untuk aplikasi yang sensitif terhadap latensi saat memulai dan perlu diskalakan dengan cepat. Saat Anda mengalami peningkatan traffic yang tiba-tiba, buffer aktif menyediakan kapasitas yang telah disediakan sebelumnya dan dirancang untuk penskalaan latensi rendah. Saat Anda mengalami peningkatan traffic yang berkelanjutan, buffer standby menyediakan penjadwalan Pod dengan biaya yang lebih terjangkau daripada pra-penyediaan.

Buffering kapasitas memberikan manfaat berikut:

  • Meminimalkan latensi penskalaan: buffer aktif menyediakan node yang berjalan, yang membantu meminimalkan latensi. Buffer standby dapat melanjutkan dengan cepat, sehingga memberikan ketersediaan kapasitas yang lebih cepat daripada node baru dengan biaya yang lebih rendah dibandingkan dengan buffer aktif.
  • Penyediaan berlebihan yang hemat biaya: buffering kapasitas membantu Anda mempertahankan jaring pengaman. Untuk workload berskala besar, pendekatan ini sering kali lebih hemat biaya daripada metode penyediaan berlebihan lainnya, seperti menurunkan target pemanfaatan horizontal Pod autoscaler (HPA), yang dapat meningkatkan kapasitas tidak ada aktivitas secara linear seiring pertumbuhan cluster Anda.
  • Memenuhi persyaratan workload: Anda memiliki kontrol penuh atas konfigurasi buffering kapasitas. Opsi Anda mencakup menggabungkan daemonset kustom untuk memuat gambar terlebih dahulu, menyesuaikan waktu startup, dan mengontrol ukuran buffer agar sesuai dengan kebutuhan Anda.

Sebaiknya gunakan buffering kapasitas untuk workload yang sensitif terhadap latensi dan memerlukan peningkatan skala yang cepat, seperti agen AI, inferensi AI, aplikasi retail selama acara diskon, atau server game selama aktivitas pemain mencapai puncaknya.

Cara kerja buffering kapasitas

Terapkan buffering kapasitas menggunakan resource kustom CapacityBuffer Kubernetes untuk menentukan buffer kapasitas cadangan. Autoscaler cluster GKE memantau resource CapacityBuffer dan memperlakukannya sebagai permintaan yang tertunda untuk membantu memastikan bahwa kapasitas cadangan tersedia. Jika cluster Anda tidak memiliki kapasitas yang cukup untuk memenuhi permintaan resource yang ditentukan dalam buffer, autoscaler cluster akan menyediakan node tambahan.

Saat workload ditingkatkan skalanya, GKE akan menjadwalkan Pod yang tertunda pada kapasitas yang tersedia dalam urutan prioritas berikut:

  1. Menjalankan node dalam buffer aktif
  2. Menjalankan node dalam buffer standby yang belum ditangguhkan
  3. Node yang ditangguhkan dalam buffer standby
  4. Node yang baru disediakan

Untuk menjadwalkan Pod yang tertunda secepat mungkin, GKE menggunakan kapasitas buffer yang tersedia sebelum menyediakan node baru. Prioritas ini berlaku meskipun aturan berprioritas lebih tinggi di ComputeClass kustom akan menyediakan node baru.

Kapasitas buffer tidak dibatasi untuk workload yang direferensikan di kolom scalableRef. Setiap Pod yang tertunda yang batasan penjadwalannya, seperti pemilih node, toleransi, dan permintaan resource, cocok dengan konfigurasi node buffer dapat mengklaim kapasitas tersebut. Untuk memesan buffering kapasitas bagi workload tertentu, konfigurasikan pemisahan workload dengan menambahkan toleransi dan pemilih node (atau afinitas node) yang cocok ke workload dan buffering kapasitas. Untuk mengetahui petunjuknya, lihat Mendedikasikan buffering kapasitas untuk workload tertentu.

Saat workload menggunakan kapasitas dari buffer aktif, autoscaler cluster mengisi ulang buffer aktif dengan melanjutkan node dari buffer standby yang kompatibel jika ada, atau dengan menyediakan node baru. Saat workload atau buffer aktif menggunakan node dari buffer standby, autoscaler cluster akan mengisi ulang buffer standby dengan menyediakan dan menangguhkan node baru. Saat workload Anda menurunkan skala dan node menjadi kurang dimanfaatkan, autoscaler cluster akan menghapus node yang berjalan berlebih setelah periode stabilisasi penurunan skala, bukan menangguhkannya kembali ke buffer standby. Untuk mengisi ulang buffer standby, GKE menyediakan dan menangguhkan node baru secara terpisah.

Strategi buffering kapasitas

Anda dapat mengonfigurasi buffering kapasitas menggunakan berbagai strategi penyediaan berdasarkan persyaratan Anda untuk latensi dan biaya.

Buffer aktif

Buffer aktif menyediakan node yang berjalan untuk penskalaan workload dengan latensi rendah yang sesuai dengan kapasitas yang dipesan. Karena sudah berjalan, node ini memberikan latensi minimal untuk mengklaim Pod selama peristiwa peningkatan skala.

Buffer standby

Buffer standby menyediakan node yang ditangguhkan. Strategi standby lebih hemat biaya daripada strategi aktif, tetapi menimbulkan sedikit penundaan untuk melanjutkan node sebelum menerima workload.

Biaya dan harga

Buffering kapasitas disediakan tanpa biaya tambahan selain biaya komputasi berbasis node standar, yang berlaku untuk node pool Standard dan workload Autopilot yang memilih hardware tertentu. Buffering kapasitas tidak mendukung model penagihan berbasis Pod.

Penagihan untuk node yang mendasarinya berbeda-beda, bergantung pada jenis buffer:

  • Buffer aktif: Anda akan dikenai tarif komputasi berbasis node standar untuk VM yang berjalan yang dikelola GKE untuk berfungsi sebagai kapasitas buffer aktif.
  • Buffer standby: saat instance VM ditangguhkan, Anda tidak perlu membayar biaya komputasi (CPU atau memori). Anda akan dikenai biaya penyimpanan kecil (misalnya, boot disk VM dan status memori yang disimpan) serta biaya untuk resource terkait seperti alamat IP eksternal statis. Saat GKE melanjutkan VM standby untuk menghosting workload, tarif komputasi berbasis node standar akan berlaku. Untuk mengetahui informasi selengkapnya, lihat Harga instance yang ditangguhkan.

CRD CapacityBuffer

Untuk mengonfigurasi buffering kapasitas, buat CustomResourceDefinition (CRD) CapacityBuffer. Anda dapat mengonfigurasi buffering kapasitas untuk memenuhi berbagai kriteria:

  • Replika tetap: menentukan jumlah tetap Pod buffering yang akan dibuat berdasarkan permintaan resource dari template Pod yang direferensikan. Konfigurasi ini adalah cara paling sederhana untuk membuat buffer dengan ukuran yang diketahui.
  • Batas resource: menentukan jumlah total CPU dan memori yang harus dicadangkan oleh buffer. Pengontrol menghitung jumlah Pod buffering yang akan dibuat berdasarkan permintaan resource dari template Pod yang direferensikan.
  • Berbasis persentase: tentukan ukuran buffer sebagai persentase dari objek skalabel yang ada yang menentukan subresource skala (seperti Deployment, StatefulSet, ReplicaSet, atau Job). Ukuran buffer disesuaikan secara dinamis seiring skala workload referensi. Buffering kapasitas berbasis persentase hanya didukung untuk objek yang mengimplementasikan subresource skala Kubernetes.

Anda dapat menggabungkan opsi ini, misalnya dengan menetapkan replicas dan percentage sehingga GKE menggunakan nilai yang lebih besar sebagai batas minimum, dan dengan menetapkan limits sebagai batas atas.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi referensi CRD CapacityBuffer.

Praktik terbaik

Untuk mengoptimalkan efisiensi biaya dan responsivitas saat mengonfigurasi buffering kapasitas, gunakan rekomendasi berikut:

  • Gunakan strategi standby-first yang hemat biaya: prioritaskan buffer standby jika workload Anda dapat menoleransi penundaan peningkatan skala singkat sekitar 30 detik. Strategi ini menghindari cold boot node VM baru tanpa harus mengeluarkan biaya penuh untuk VM aktif.
  • Gunakan buffer aktif untuk workload yang sensitif terhadap latensi: gunakan buffer aktif untuk workload yang tidak dapat menoleransi waktu melanjutkan node saat waktu penjadwalan Pod harus serendah mungkin.
  • Gunakan strategi hibrid untuk menyeimbangkan performa dan biaya: Gabungkan buffer aktif kecil dengan buffer standby yang lebih besar untuk penyiapan yang hemat biaya. GKE memprioritaskan pengisian ulang buffer aktif dengan melanjutkan node dari buffer standby (memerlukan waktu sekitar 30 detik), sementara node baru disediakan di latar belakang untuk mengisi ulang buffer standby. Penyiapan ini menyerap lonjakan awal dengan kapasitas aktif, dan mengakomodasi pertumbuhan berkelanjutan menggunakan kapasitas standby berbiaya lebih rendah.
  • Menentukan ukuran buffer aktif untuk burst awal: tentukan ukuran buffer aktif Anda untuk mencakup lonjakan replika mendadak awal yang diperkirakan akan Anda alami, sebelum node buffer standby dapat dilanjutkan.
  • Menentukan ukuran buffer standby untuk beban berkelanjutan: tentukan buffer standby yang cukup untuk menutupi beban yang diperpanjang yang diperkirakan akan Anda hadapi, sehingga buffer dapat diisi ulang di latar belakang dari cold start. Buffer standby berukuran cukup dapat menurunkan latensi penjadwalan Pod maksimum ke waktu yang diperlukan untuk melanjutkan node, yaitu sekitar 30 detik. Saat buffering kapasitas mulai digunakan dan diisi ulang, node buffering baru akan beralih ke status aktif sebelum ditangguhkan. Strategi ini membantu meningkatkan kapasitas aktif selama beban yang berkepanjangan.
  • Gunakan simulator buffer: bereksperimenlah dengan berbagai ukuran buffer aktif dan standby untuk mendapatkan hasil terbaik bagi workload spesifik Anda. Jalankan simulasi perilaku penskalaan workload menggunakan simulator buffer GKE open source di https://github.com/gke-labs/buffers-simulator untuk menyesuaikan aturan ukuran buffer dan mencapai target performa Anda.
  • Mengurangi latensi cold-start saat menskalakan workload dari nol: pasangkan workload yang diskalakan ke dan dari nol menggunakan HPA (minReplicas: 0) dengan buffering kapasitas. Saat permintaan meningkat dan workload ditingkatkan dari nol, GKE segera menjadwalkan Pod pada node buffer yang telah diaktifkan, alih-alih menunggu node komputasi baru disediakan.
  • Pertimbangkan profil penskalaan otomatis optimize-utilization di cluster Standard: karena buffering kapasitas sudah mempertahankan kapasitas cadangan, Anda dapat mengonfigurasi profil penskalaan otomatis optimize-utilization (--autoscaling-profile=optimize-utilization) sehingga autoscaler cluster memperkecil skala node yang kurang dimanfaatkan dengan lebih cepat setelah permintaan turun. Profil ini juga mengemas Pod dengan lebih rapat ke node, jadi evaluasi apakah pengemasan bin yang lebih rapat sesuai dengan persyaratan ketersediaan workload Anda sebelum mengaktifkannya.

Menghitung ukuran buffer

Saat menggabungkan buffer aktif dengan buffer standby, Anda dapat memperkirakan jumlah replika buffer, atau Pod buffer simulasi, yang diperlukan untuk menyerap lonjakan traffic. Hitung estimasi ini menggunakan tingkat peningkatan skala yang diharapkan dalam Pod per detik, latensi melanjutkan node standby, dan latensi pembuatan node cold. Latensi ini bervariasi menurut seri mesin VM dan konfigurasi node. Misalnya, latensi melanjutkan node standby biasanya 30 hingga 35 detik, dan latensi pembuatan node baru biasanya 60 hingga 120 detik, bergantung pada seri mesin. Untuk mengukur latensi sebenarnya untuk cluster Anda, lihat Memantau metrik latensi startup.

  1. Hitung ukuran buffer aktif Anda untuk mencakup Pod yang dibuat saat node standby dilanjutkan:

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. Hitung ukuran buffer standby untuk mencakup Pod yang tersisa yang dibuat saat node cold baru selesai disediakan:

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Misalnya, jika workload Anda meningkat pada 2 Pod per detik, node standby memerlukan waktu 30 detik untuk melanjutkan, dan node cold baru memerlukan waktu 90 detik untuk penyediaan:

  • Buffer aktif Anda memerlukan \( 2 \times 30 = 60 \) replika untuk menyerap lonjakan 30 detik pertama.
  • Buffer standby Anda memerlukan replika \( (2 \times 90) - 60 = 120 \) untuk mencakup 60 detik yang tersisa, sementara autoscaler cluster menyediakan node cold baru di latar belakang untuk mengisi ulang buffer Anda. Jika lonjakan berlanjut setelah 90 detik dengan kecepatan yang sama, node yang diisi ulang tersebut siap melayani Pod yang masuk tanpa waktu tunggu.

Untuk menguji estimasi ini terhadap pola penskalaan workload Anda, jalankan simulasi dengan simulator buffer GKE.

Skalabilitas

Buffering kapasitas tidak memiliki batas ketat, tetapi melebihi skala yang direkomendasikan dapat memperlambat penyediaan node dan penjadwalan Pod. Replika buffer adalah Pod buffer simulasi yang kapasitasnya dicadangkan oleh buffer, bukan node. Untuk performa yang andal, pastikan cluster Anda tetap berada dalam panduan berikut:

Skala buffering kapasitas yang direkomendasikan per cluster
Jenis buffer Total replika buffer per cluster Buffer per cluster
Buffer aktif Hingga 7.000 Hingga 100
Buffer standby Hingga 5.000 Maksimum 25 orang

Untuk buffer aktif dan standby, hindari membuat banyak buffer yang masing-masing memerlukan node pool terpisah, seperti buffer yang menggunakan ComputeClasses yang berbeda atau setelan pemisahan workload yang berbeda. Saat menyediakan node baru, autoscaler cluster meningkatkan skala satu node pool dalam satu waktu, sehingga memerlukan lebih banyak waktu untuk mengisi dan mengisi ulang buffer dengan node baru saat Anda menambahkan lebih banyak buffer. Batasan ini tidak berlaku untuk melanjutkan node yang ditangguhkan di buffer standby.

Persyaratan dan batasan

Buffering kapasitas memiliki persyaratan dan batasan berikut:

  • Buffering kapasitas tersedia untuk cluster GKE yang menjalankan versi 1.37.1-gke.3020000 atau yang lebih baru.
  • Buffering kapasitas hanya mendukung workload yang menggunakan model penagihan berbasis node untuk node pool Standard dan node pool Autopilot yang memilih hardware tertentu. Buffering kapasitas tidak mendukung workload yang menggunakan model penagihan berbasis Pod.
  • Di cluster Standard, sebaiknya aktifkan pembuatan otomatis node pool. Pembuatan otomatis node pool memungkinkan autoscaler cluster membuat node pool baru berdasarkan permintaan resource di CapacityBuffer Anda. Jika Anda tidak mengaktifkan pembuatan otomatis node pool, autoscaler cluster hanya akan meningkatkan skala node pool yang ada.
  • Buffering kapasitas aktif dan standby menggunakan kuota secara berbeda:
    • Node yang berjalan dalam buffer aktif mengurangi kuota Compute Engine vCPU, memori, disk, dan alamat IP Anda.
    • Node yang ditangguhkan dalam buffer standby tidak mengurangi kuota vCPU atau memori Compute Engine saat ditangguhkan. Namun, VM tersebut terus menggunakan kuota alamat IP dan kuota disk, termasuk kuota Persistent disk standard (GB) yang digunakan untuk menyimpan memori VM yang ditangguhkan.
    • Di Kubernetes, unit buffer standby yang aktif dan ditangguhkan diperhitungkan dalam kuota resource Kubernetes di namespace Anda seolah-olah Pod buffer sedang berjalan.
  • Jika dependensi konfigurasi CapacityBuffer Anda (misalnya, PodTemplate) memilih ComputeClass kustom, dependensi tersebut harus menentukan toleransi, pemilih node, atau class runtime yang diperlukan untuk menjadwalkan pada node yang disediakan (misalnya, persyaratan untuk GKE Sandbox). Untuk mengetahui petunjuknya, lihat dokumentasi ComputeClass kustom.

Buffer standby memiliki batasan tambahan berikut:

Langkah berikutnya