Tentang buffer kapasitas

Standard Autopilot

Pratinjau

Produk ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Buffer kapasitas membantu Anda mengurangi latensi startup Pod untuk workload Google Kubernetes Engine (GKE) dengan memungkinkan Anda mendeklarasikan tingkat buffer kapasitas aktif atau standby secara proaktif di cluster. 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 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.

Buffer kapasitas memberikan manfaat berikut:

• Meminimalkan latensi penskalaan: buffer aktif menyediakan node yang berjalan, yang membantu meminimalkan latensi. Buffer standby dapat dilanjutkan 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: buffer 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 buffer 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 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 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 buffer kapasitas bagi workload tertentu, konfigurasikan pemisahan workload dengan menambahkan toleransi dan pemilih node (atau afinitas node) yang cocok ke workload dan buffer kapasitas.

Saat workload menggunakan kapasitas dari buffer aktif, autoscaler cluster akan 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 buffer kapasitas

Anda dapat mengonfigurasi buffer kapasitas menggunakan berbagai strategi penyediaan berdasarkan persyaratan Anda terkait latensi dan biaya.

Buffer aktif

Buffer aktif menyediakan node yang berjalan untuk penskalaan workload latensi rendah yang sesuai dengan kapasitas yang dipesan. Karena sudah berjalan, node 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

Buffer kapasitas disediakan tanpa biaya tambahan selain biaya komputasi berbasis node standar, yang berlaku untuk node pool Standard dan workload Autopilot yang memilih hardware tertentu. Buffer 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 dan dikelola GKE untuk berfungsi sebagai kapasitas buffer aktif.
• Buffer standby: saat instance VM ditangguhkan, Anda tidak 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 buffer kapasitas, buat CapacityBuffer CustomResourceDefinition (CRD). Anda dapat mengonfigurasi buffer 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 buffer 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. Buffer 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 buffer 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.
• Tentukan 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 Anda ke waktu yang diperlukan untuk melanjutkan node, yaitu sekitar 30 detik. Saat buffer kapasitas mulai digunakan dan diisi ulang, node buffer 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 buffer kapasitas. Saat permintaan meningkat dan workload ditingkatkan skalanya dari nol, GKE segera menjadwalkan Pod pada node buffer yang telah dihangatkan, alih-alih menunggu node komputasi baru disediakan.
• Pertimbangkan profil penskalaan otomatis optimize-utilization di cluster Standard: karena buffer 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 perkiraan 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 ditingkatkan skalanya 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 30 detik pertama lonjakan.
• 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 melewati 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.

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.
• 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.
• Buffer 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 di node yang disediakan (misalnya, persyaratan untuk GKE Sandbox). Untuk mengetahui petunjuknya, lihat dokumentasi ComputeClass kustom.

Buffer standby memiliki batasan tambahan berikut:

• Fitur ini didukung di cluster Standard dengan pembuatan otomatis node pool diaktifkan.
• Fitur ini didukung di cluster Autopilot yang menjalankan versi 1.36.0-gke.2853000 atau yang lebih baru.
• Node dengan GPU atau TPU yang terpasang tidak didukung.
• SSD lokal tidak didukung.
• Meskipun buffer standby mendukung kunci enkripsi yang dikelola pelanggan (CMEK) untuk penyimpanan node, memori node dienkripsi menggunakan Google-owned and Google-managed encryption keys selama penangguhan.
• Confidential Google Kubernetes Engine Nodes tidak didukung.
• Buffer standby hanya mendukung image node Ubuntu dan Container-Optimized OS GKE. Node Windows Server tidak didukung. Jika menggunakan sistem operasi node kustom, Anda harus memastikan bahwa OS tersebut mendukung operasi penangguhan dan pelanjutan Compute Engine.
• Anda harus memahami batasan terkait operasi penangguhan dan melanjutkan Compute Engine. Beberapa batasan utama mencakup:
  • 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.

Penting: Melanjutkan node standby memerlukan kapasitas Compute Engine zonal yang tersedia untuk jenis mesin node dan pembuatan platform CPU tertentu (seperti dalam seri mesin E2 atau N2). Selain itu, Spot VM yang ditangguhkan tidak dapat dikonversi menjadi VM on-demand saat dilanjutkan.

Langkah berikutnya

• Untuk mempelajari cara menerapkan buffer kapasitas, lihat Mengonfigurasi buffer kapasitas.