Tentang buffer kapasitas

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 siaga di cluster Anda. Dengan mendeklarasikan kapasitas cadangan lebih awal, 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 akan menyediakan kapasitas yang telah disediakan sebelumnya dan dirancang untuk penskalaan latensi rendah. Saat Anda mengalami peningkatan traffic yang berkelanjutan, buffer siaga akan menyediakan penjadwalan Pod dengan biaya yang lebih terjangkau daripada penyediaan awal.

Buffer kapasitas memberikan manfaat berikut:

  • Meminimalkan latensi penskalaan: buffer aktif menyediakan node yang berjalan, yang membantu meminimalkan latensi. Buffer siaga dilanjutkan dengan cepat, sehingga memberikan 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 skala besar, pendekatan ini sering kali lebih hemat biaya daripada metode penyediaan berlebih lainnya (misalnya, menurunkan target penggunaan HorizontalPodAutoscaler (HPA)), yang dapat meningkatkan kapasitas tidak ada aktivitas secara linear seiring pertumbuhan cluster Anda.
  • Memenuhi persyaratan workload: Anda memiliki kontrol penuh atas konfigurasi buffer kapasitas. Opsi Anda mencakup penggabungan daemonset kustom untuk memuat gambar terlebih dahulu, menyesuaikan waktu startup, dan mengontrol ukuran buffer agar sesuai dengan kebutuhan Anda.

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

Cara kerja buffer kapasitas

Terapkan buffer kapasitas dengan menggunakan resource kustom Kubernetes CapacityBuffer untuk menentukan buffer kapasitas cadangan. Autoscaler cluster GKE memantau resource CapacityBuffer dan memperlakukannya sebagai permintaan yang tertunda untuk membantu memastikan 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 berprioritas tinggi ditingkatkan skalanya, GKE akan segera menjadwalkan workload pada kapasitas yang tersedia dalam 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 strategi penyediaan yang berbeda berdasarkan persyaratan latensi dan biaya.

Buffer aktif

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

Buffer siaga

Buffer siaga menyediakan node yang ditangguhkan. Strategi siaga lebih hemat biaya daripada strategi aktif, tetapi memperkenalkan penundaan singkat untuk melanjutkan node sebelum menerima workload.

Biaya dan harga

Penagihan untuk buffer kapasitas berbeda-beda bergantung pada jenis buffer:

  • Buffer aktif: Anda akan dikenai tarif komputasi GKE standar untuk VM yang berjalan yang dikelola GKE untuk berfungsi sebagai kapasitas buffer aktif. Di Autopilot, tarif penagihan berbasis Pod standar berlaku untuk Pod yang berjalan.
  • Buffer siaga: saat instance VM ditangguhkan, Anda tidak membayar biaya komputasi (CPU atau memori). Anda akan dikenai biaya penyimpanan kecil (misalnya, disk boot VM) dan biaya untuk resource terkait seperti alamat IP eksternal statis. Saat GKE melanjutkan VM siaga untuk menghosting workload, tarif penagihan berbasis Pod atau komputasi standar akan berlaku.

CRD CapacityBuffer

Untuk mengonfigurasi buffer kapasitas, Anda membuat CapacityBuffer CustomResourceDefinition (CRD). Anda dapat mengonfigurasi buffer kapasitas untuk memenuhi kriteria yang berbeda:

  • Replika tetap: tentukan jumlah tetap Pod buffer 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: tentukan jumlah total CPU dan memori yang harus dicadangkan oleh buffer. Pengontrol menghitung jumlah Pod buffer yang akan dibuat berdasarkan permintaan resource dari template Pod yang direferensikan.
  • Berbasis persentase: tentukan ukuran buffer sebagai persentase dari objek yang ada yang dapat diskalakan yang menentukan subresource skala (seperti Deployment, StatefulSet, ReplicaSet, atau Job). Ukuran buffer akan 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 yang hemat biaya dan mengutamakan siaga: prioritaskan buffer siaga jika workload Anda dapat menoleransi penundaan peningkatan skala singkat sekitar 30 detik. Strategi ini menghindari booting node dingin VM baru tanpa harus mengeluarkan biaya penuh 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 hybrid untuk menyeimbangkan performa dan biaya: Gabungkan buffer aktif kecil dengan buffer siaga yang lebih besar untuk penyiapan yang hemat biaya. GKE memprioritaskan pengisian ulang buffer aktif dengan melanjutkan node dari buffer siaga (memerlukan waktu sekitar 30 detik), sementara node baru disediakan di latar belakang untuk mengisi ulang buffer siaga. Penyiapan ini menyerap lonjakan awal dengan kapasitas aktif, dan mengakomodasi pertumbuhan berkelanjutan menggunakan kapasitas siaga yang lebih murah.
  • Ukuran buffer aktif untuk lonjakan awal: tentukan ukuran buffer aktif Anda untuk mencakup lonjakan replika awal yang tiba-tiba yang Anda harapkan, sebelum node buffer siaga dapat dilanjutkan.
  • Ukuran buffer siaga untuk beban berkelanjutan: tentukan buffer siaga yang cukup untuk mencakup beban yang diperpanjang yang Anda harapkan, sehingga buffer dapat diisi ulang di latar belakang dari cold start. Buffer siaga yang berukuran cukup dapat menurunkan latensi penjadwalan Pod maksimum ke 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 ukuran buffer aktif dan siaga yang berbeda 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 menyempurnakan aturan ukuran buffer dan mencapai target performa Anda.

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 siaga.
  • Buffer kapasitas hanya mendukung workload yang menggunakan model penagihan berbasis node untuk node pool Standar dan node pool Autopilot yang memilih hardware tertentu. Buffer kapasitas tidak mendukung workload yang menggunakan model penagihan berbasis Pod.
  • Di 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 akan meningkatkan skala node pool yang ada.
  • Buffer kapasitas aktif dan siaga dihitung terhadap kuota Compute Engine.
  • Jika dependensi konfigurasi CapacityBuffer Anda (misalnya, PodTemplate) memilih ComputeClass kustom, dependensi tersebut harus menentukan toleransi, pemilih node, atau class runtime yang diperlukan untuk dijadwalkan di node yang disediakan (misalnya, persyaratan untuk GKE Sandbox). Untuk mengetahui petunjuknya, lihat dokumentasi ComputeClass kustom.

Buffer siaga memiliki batasan tambahan berikut:

  • Buffer siaga didukung di cluster Standard dengan node auto-provisioning diaktifkan.
  • Buffer siaga 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.
  • Node Google Kubernetes Engine Rahasia tidak didukung.
  • Anda harus memahami batasan terkait operasi penangguhan dan melanjutkan Compute Engine. Beberapa batasan utama mencakup hal berikut:
    • 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.
    • Panjang proses penangguhan sebanding dengan ukuran memori.
    • Kelanjutan bergantung pada kemampuan untuk mendapatkan resource dasar yang diperlukan untuk melanjutkan.

Langkah berikutnya