Buffer kapasitas membantu Anda mengurangi latensi startup Pod untuk workload Google Kubernetes Engine (GKE) dengan memungkinkan Anda secara proaktif mendeklarasikan tingkat buffer kapasitas aktif atau standby di cluster Anda. Dengan mendeklarasikan kapasitas cadangan sebelumnya, Anda dapat mencapai startup workload yang lebih cepat dengan cara yang hemat biaya.
Dokumen ini menjelaskan cara kerja buffer kapasitas. Untuk mempelajari cara mengaktifkan dan menggunakan buffer kapasitas, lihat Mengonfigurasi buffer kapasitas.
Kapan harus menggunakan buffer kapasitas
Gunakan buffer kapasitas untuk aplikasi yang sensitif terhadap latensi startup 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 siaga menyediakan penjadwalan Pod dengan biaya yang lebih terjangkau daripada pra-penyediaan.
Buffer kapasitas memberikan manfaat berikut:
- Meminimalkan latensi penskalaan: buffer aktif menyediakan node yang sedang berjalan, yang membantu meminimalkan latensi. Buffer siaga dilanjutkan dengan cepat, sehingga menyediakan ketersediaan kapasitas yang lebih cepat daripada node baru dengan biaya yang lebih rendah dibandingkan dengan buffer aktif.
- Penyediaan berlebih yang hemat biaya: buffer kapasitas membantu Anda mempertahankan jaring pengaman. Untuk workload berskala besar, pendekatan ini sering kali lebih hemat biaya daripada metode penyediaan berlebih lainnya, seperti menurunkan target pemanfaatan autoscaler Pod horizontal (HPA), yang dapat meningkatkan kapasitas idle secara linear seiring pertumbuhan cluster Anda.
- Memenuhi persyaratan beban kerja: Anda memiliki kontrol penuh atas konfigurasi buffer kapasitas. Opsi Anda mencakup penggabungan daemonset kustom untuk memuat gambar terlebih dahulu, menyesuaikan waktu mulai, dan mengontrol ukuran buffer agar sesuai dengan kebutuhan Anda.
Sebaiknya gunakan buffer kapasitas untuk workload yang sensitif terhadap latensi dan memerlukan penskalaan cepat, seperti agen AI, inferensi AI, aplikasi retail selama acara penjualan, atau server game selama aktivitas pemain mencapai puncaknya.
Cara kerja buffer kapasitas
Terapkan buffer kapasitas dengan menggunakan resource kustom CapacityBuffer Kubernetes untuk menentukan buffer kapasitas cadangan. Penskala otomatis cluster GKE memantau resource CapacityBuffer dan memperlakukannya sebagai permintaan tertunda untuk membantu memastikan ketersediaan kapasitas cadangan. Jika cluster Anda tidak memiliki kapasitas yang cukup untuk memenuhi permintaan resource yang ditentukan dalam buffer, autoscaler cluster akan menyediakan node tambahan.
Saat workload berprioritas tinggi di-scale up, GKE akan segera menjadwalkan workload pada kapasitas yang tersedia di buffer. Penjadwalan langsung ini berlaku untuk jumlah replika atau jumlah resource yang dicadangkan dalam buffer, sehingga menghindari penundaan umum yang terkait dengan penyediaan node. Saat workload menggunakan unit buffer, autoscaler cluster akan menyediakan node baru untuk mengisi ulang buffer.
Strategi buffer kapasitas
Anda dapat mengonfigurasi buffer kapasitas menggunakan berbagai strategi penyediaan berdasarkan persyaratan latensi dan biaya Anda.
Buffer aktif
Buffer aktif menyediakan node yang berjalan untuk penskalaan beban kerja latensi rendah yang sesuai dengan kapasitas yang dicadangkan. Karena node sudah berjalan, node memberikan latensi minimal untuk mengklaim Pod selama peristiwa penskalaan.
Buffer siaga
Buffer standby menyediakan node yang ditangguhkan. Strategi standby lebih hemat biaya daripada strategi aktif, tetapi memperkenalkan penundaan singkat untuk melanjutkan node sebelum menerima beban kerja.
Biaya dan harga
Penagihan untuk buffer kapasitas berbeda-beda, bergantung pada jenis buffer:
- Buffer aktif: Anda akan dikenai biaya tarif komputasi GKE standar untuk VM yang berjalan yang dikelola GKE untuk berfungsi sebagai kapasitas buffer aktif. Di Autopilot, tarif penagihan standar berbasis Pod berlaku untuk Pod yang berjalan.
- Buffer standby: saat instance VM ditangguhkan, Anda tidak membayar biaya komputasi (CPU atau memori). Anda akan dikenai biaya penyimpanan kecil (misalnya, disk booting VM) dan biaya untuk resource terkait seperti alamat IP eksternal statis. Saat GKE melanjutkan VM standby untuk menghosting workload, tarif penagihan berbasis Pod atau komputasi standar berlaku.
CRD CapacityBuffer
Untuk mengonfigurasi buffer kapasitas, Anda membuat CustomResourceDefinition (CRD) CapacityBuffer. Anda dapat mengonfigurasi buffer kapasitas untuk memenuhi kriteria yang berbeda:
- Replika tetap: tentukan jumlah tetap Pod buffer yang akan dibuat berdasarkan permintaan resource template Pod yang dirujuk. Konfigurasi ini adalah cara paling sederhana untuk membuat buffer dengan ukuran yang diketahui.
- Batas resource: tentukan total jumlah CPU dan memori yang harus dicadangkan buffer. Pengontrol menghitung jumlah Pod buffer yang akan dibuat berdasarkan permintaan resource template Pod yang dirujuk.
- Berbasis persentase: tentukan ukuran buffer sebagai persentase dari objek yang dapat diskalakan yang ada yang menentukan subresource skala (seperti Deployment, StatefulSet, ReplicaSet, atau Job). Ukuran buffer disesuaikan secara dinamis saat workload referensi diskalakan. Buffer kapasitas berbasis persentase hanya didukung untuk objek yang menerapkan subresource skala Kubernetes.
Untuk mengetahui informasi selengkapnya, lihat dokumentasi referensi CRD CapacityBuffer.
Praktik terbaik
Untuk mengoptimalkan efisiensi biaya dan responsivitas saat mengonfigurasi buffer kapasitas, gunakan rekomendasi berikut:
- Gunakan strategi standby-first yang hemat biaya: prioritaskan buffer standby jika workload Anda dapat menoleransi penundaan penskalaan singkat sekitar 30 detik. Strategi ini menghindari booting node dingin VM baru tanpa harus menanggung biaya penuh VM aktif.
- Gunakan buffer aktif untuk workload yang sensitif terhadap latensi: gunakan buffer aktif untuk workload yang tidak dapat mentoleransi waktu pelanjutan node saat waktu penjadwalan Pod harus serendah mungkin.
- Gunakan strategi hybrid 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 (membutuhkan waktu sekitar 30 detik), sementara node baru disediakan di latar belakang untuk mengisi kembali buffer standby. Penyiapan ini menyerap lonjakan awal dengan kapasitas aktif, dan mengakomodasi pertumbuhan berkelanjutan menggunakan kapasitas siaga yang lebih murah.
- Menentukan ukuran buffer aktif untuk burst awal: tentukan ukuran buffer aktif Anda untuk mencakup lonjakan replika awal yang tiba-tiba yang diperkirakan akan Anda temui, sebelum node buffer siaga dapat dilanjutkan.
- Menentukan ukuran buffer standby untuk beban berkelanjutan: tentukan buffer standby yang cukup untuk mencakup beban yang diperluas yang Anda perkirakan akan dihadapi, sehingga buffer dapat diisi ulang di latar belakang dari cold start. Buffer siaga berukuran memadai dapat mengurangi latensi penjadwalan Pod maksimum Anda menjadi waktu yang diperlukan untuk melanjutkan node, yaitu sekitar 30 detik. Saat buffer kapasitas mulai digunakan dan diisi ulang, node buffer baru akan bertransisi 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 siaga untuk mendapatkan hasil terbaik untuk workload tertentu. Jalankan simulasi perilaku penskalaan workload menggunakan simulator buffer GKE open source di https://github.com/gke-labs/buffers-simulator untuk menyetel aturan penentuan ukuran buffer dan mencapai target performa Anda.
- Mengurangi latensi cold start saat menskalakan workload dari nol: pasangkan workload yang
menskalakan ke dan dari nol menggunakan HPA (
minReplicas: 0) dengan buffer kapasitas. Saat permintaan meningkat dan workload di-scaling dari nol, GKE segera menjadwalkan Pod di node buffer yang sudah dipanaskan sebelumnya, bukan menunggu node komputasi baru disediakan.
Persyaratan dan batasan
Buffer kapasitas memiliki persyaratan dan batasan berikut:
- Buffer kapasitas tersedia untuk cluster GKE yang menjalankan versi 1.35.2-gke.1842000 atau yang lebih baru untuk buffer aktif, dan versi 1.36.0-gke.2253000 untuk buffer standby.
- Buffer kapasitas hanya mendukung workload yang menggunakan model penagihan berbasis node untuk node pool Standard dan node pool Autopilot yang memilih hardware tertentu. Buffer kapasitas tidak mendukung workload yang menggunakan model penagihan berbasis Pod.
- Pada cluster Standar, sebaiknya aktifkan node auto-provisioning. node auto-provisioning memungkinkan autoscaler cluster membuat node pool baru berdasarkan permintaan resource di CapacityBuffer Anda. Jika Anda tidak mengaktifkan node auto-provisioning, autoscaler cluster hanya menskalakan node pool yang ada.
- Buffer kapasitas aktif dan siaga dihitung dalam kuota Compute Engine.
- Jika dependensi konfigurasi CapacityBuffer (misalnya, PodTemplate) memilih ComputeClass kustom, dependensi harus menentukan toleransi, pemilih node, atau class runtime yang diperlukan untuk penjadwalan di node yang disediakan (misalnya, persyaratan untuk GKE Sandbox). Untuk mendapatkan petunjuk, lihat dokumentasi ComputeClass kustom.
Buffer siaga memiliki batasan tambahan berikut:
- Fitur ini didukung di cluster Standard dengan node auto-provisioning diaktifkan.
- Fitur ini didukung di cluster Autopilot yang menjalankan versi 1.36.0-gke.2853000 atau yang lebih baru.
- Node dengan GPU atau TPU terlampir tidak didukung.
- SSD lokal tidak didukung.
- Confidential Google Kubernetes Engine Nodes tidak didukung.
- Anda harus memahami batasan terkait operasi penangguhan dan pelanjutan Compute Engine.
Beberapa batasan utama meliputi:
- Node dengan disk yang dilindungi kunci enkripsi yang disediakan pelanggan (CSEK) tidak didukung.
- Node dengan memori lebih dari 208 GB tidak didukung.
- Instance bare metal tidak didukung.
- OS node harus mendukung sinyal tidur ACPI S3.
- Durasi proses penangguhan sebanding dengan ukuran memori.
- Kelanjutan bergantung pada ketersediaan resource pokok yang diperlukan untuk melanjutkan.
Langkah berikutnya
- Untuk mempelajari cara menerapkan buffer kapasitas, lihat Mengonfigurasi buffer kapasitas.