Google Kubernetes Engine (GKE) menyediakan beberapa strategi yang membantu Anda mengurangi latensi startup Pod saat workload Anda di-scale up. Dengan mengurangi penundaan dalam penyediaan node, penarikan image container, dan inisialisasi aplikasi, Anda dapat membantu meningkatkan responsivitas layanan selama lonjakan traffic dan menyeimbangkan biaya infrastruktur.
Gunakan dokumen ini untuk membandingkan strategi pengurangan latensi startup GKE di seluruh siklus proses startup Pod dan memilih satu strategi atau kombinasi bertingkat yang sesuai dengan persyaratan workload Anda.
Memahami siklus proses startup Pod
Saat workload di-scale up di GKE dan node yang ada tidak memiliki kapasitas yang dapat dialokasikan yang cukup untuk Pod baru, latensi startup end-to-end mencakup tiga tahap berurutan:
- Selama tahap penyediaan node dan penjadwalan Pod, autoscaler cluster menyediakan VM Compute Engine baru, melakukan inisialisasi node, dan mendaftarkannya ke bidang kontrol sehingga scheduler Kubernetes dapat menempatkan Pod yang tertunda.
- Selama tahap pengambilan image container, komponen
kubeletpada node akan mendownload dan mengekstrak image container yang diperlukan oleh Pod dari Container Registry Anda. - Selama tahap inisialisasi aplikasi, runtime container memulai proses aplikasi, memuat dependensi atau bobot model ke dalam memori, dan meneruskan pemeriksaan startup dan kesiapan Kubernetes.
Berbagai fitur GKE menargetkan tahap tertentu dalam siklus proses ini. Untuk mengetahui tahap mana yang paling berkontribusi pada waktu startup workload Anda, lihat Memantau metrik latensi startup.
Membandingkan strategi pengurangan latensi startup
Tabel berikut membandingkan strategi pengurangan latensi startup GKE di seluruh siklus proses startup Pod:
| Strategi | Tahap siklus proses | Profil latensi | Profil biaya dan kuota | Mode cluster dan dukungan hardware | Paling cocok untuk |
|---|---|---|---|---|---|
| Buffer kapasitas aktif (Pratinjau) | Penyediaan node dan penjadwalan Pod | Penjadwalan Pod langsung karena node sudah berjalan. |
Tarif komputasi berbasis node standar untuk menjalankan VM. Menggunakan kuota vCPU, memori, disk, dan alamat IP Compute Engine, serta kuota resource Kubernetes di namespace. |
Cluster Standard, dan cluster Autopilot dengan ComputeClass kustom (penagihan berbasis node). Mendukung CPU, GPU, dan TPU. |
Menyerap lonjakan traffic mendadak dan menskalakan workload GPU, TPU, atau CPU yang sensitif terhadap latensi. |
| Buffer kapasitas standby (Pratinjau) | Penyediaan node dan penjadwalan Pod | Melanjutkan node yang ditangguhkan dalam waktu sekitar 30 hingga 35 detik, yang lebih cepat daripada menyediakan node baru. |
Tidak ada biaya komputasi VM saat ditangguhkan. Menimbulkan biaya penyimpanan Persistent Disk untuk disk boot dan status memori yang disimpan. Menggunakan kuota disk dan alamat IP saat ditangguhkan, ditambah kuota resource Kubernetes di namespace. |
Cluster Standard (dengan node auto-provisioning) dan cluster Autopilot dengan ComputeClass kustom. Hanya mendukung CPU (tanpa GPU, TPU, atau SSD Lokal). |
Mempertahankan kapasitas burst yang hemat biaya untuk pertumbuhan traffic yang berkelanjutan. |
| Node yang dimulai dengan cepat | Penyediaan node dan penjadwalan Pod | Mengurangi waktu startup node dingin berdasarkan upaya terbaik dengan menggunakan hardware yang telah diinisialisasi sebelumnya. | Disediakan tanpa biaya tambahan. |
Cluster Autopilot dan workload Autopilot di cluster Standard. Mendukung seri mesin GPU dan tujuan umum yang memenuhi syarat tanpa SSD Lokal atau Spot VM. |
Mempercepat penyediaan node dasar dengan nol konfigurasi atau biaya kapasitas tidak aktif. |
| Pod placeholder berprioritas rendah | Penyediaan node dan penjadwalan Pod | Penjadwalan Pod segera setelah mengeluarkan Pod placeholder dengan prioritas lebih rendah. |
Tarif komputasi standar untuk menjalankan node. Memerlukan Deployment dan pengelolaan PriorityClass secara manual. |
Cluster Standard dan Autopilot. | Mencadangkan kapasitas cadangan pada cluster yang menggunakan penagihan berbasis Pod atau versi yang lebih lama dari 1.35. |
| Streaming image | Penarikan image container | Memungkinkan container dimulai tanpa menunggu seluruh image didownload. |
Disediakan tanpa biaya tambahan. Memerlukan Artifact Registry atau repositori Docker Hub yang memenuhi syarat. |
Cluster Autopilot (diaktifkan secara default) dan Standard. | Mengurangi waktu pull image untuk image container berukuran besar. |
| Boot disk sekunder | Pull image container | Melampirkan Persistent Disk yang sudah diisi data ke node baru secara paralel dengan penyediaan node. | Ditagih untuk Persistent Disk yang terpasang di setiap node dan penyimpanan image disk. | Cluster Standard dan Autopilot. | Melakukan pramuat image container besar atau set data statis seperti bobot model machine learning. |
| Snapshot pod | Inisialisasi aplikasi | Memulihkan replika Pod baru langsung dari checkpoint tersimpan dari memori proses dan status sistem file. | Dikenai biaya untuk penyimpanan snapshot di Cloud Storage. |
Cluster Standard dan Autopilot yang menjalankan Pod di GKE Sandbox. Mendukung jenis mesin CPU dan GPU yang memenuhi syarat (tanpa TPU). |
Melewati inisialisasi yang panjang untuk model inferensi AI dan aplikasi dengan rutin startup yang berat. |
| Peningkatan CPU saat startup (Pratinjau) | Inisialisasi aplikasi | Meningkatkan permintaan dan batas CPU untuk sementara selama startup Pod, lalu mengubah ukurannya di tempat. | Menggunakan kapasitas CPU node tambahan untuk sementara selama periode startup. | Cluster Standard dan Autopilot dengan penskalaan otomatis Pod vertikal diaktifkan. | Mempercepat inisialisasi yang terikat CPU untuk runtime seperti Java, Python, atau Node.js. |
Memilih strategi menurut tahap startup Pod
Bagian berikut menjelaskan opsi yang tersedia untuk setiap tahap siklus proses startup Pod.
Mempercepat penyediaan node dan penjadwalan Pod
Jika Pod yang tertunda tidak dapat dimuat di node yang ada, menunggu node baru untuk melakukan booting sering kali menjadi kontributor terbesar terhadap latensi peningkatan skala. Anda dapat mengurangi atau menghilangkan penundaan ini menggunakan strategi berikut:
- Gunakan buffer kapasitas untuk memesan kapasitas node cadangan secara deklaratif:
- Konfigurasi buffer aktif (strategi
buffer.x-k8s.io/active-capacity) agar node yang telah disediakan sebelumnya tetap berjalan dan siap menjadwalkan Pod dengan segera. Buffer aktif mendukung workload CPU, GPU, dan TPU. - Konfigurasikan buffer standby (strategi
buffer.gke.io/standby-capacity) untuk menjaga node CPU yang telah disediakan sebelumnya dalam status ditangguhkan. Saat workload di-scale up, GKE melanjutkan node standby dalam waktu sekitar 30 hingga 35 detik, sehingga menghindari biaya komputasi penuh untuk menjalankan VM yang tidak ada aktivitas.
- Konfigurasi buffer aktif (strategi
- Mengandalkan node yang dimulai dengan cepat untuk pra-inisialisasi hardware otomatis dengan upaya terbaik pada workload Autopilot dan seri mesin GPU yang memenuhi syarat. Saat menyediakan node baru untuk workload yang memenuhi syarat, GKE akan otomatis menggunakan node mulai cepat. Hal ini mencakup node yang dibuat untuk mengisi ulang buffer kapasitas pada ComputeClass kustom Autopilot yang kompatibel.
- Deploy Pod placeholder prioritas rendah dengan PriorityClasses Kubernetes jika workload Anda menggunakan model penagihan berbasis Pod Autopilot atau berjalan di GKE versi sebelum 1.35. Untuk cluster yang menggunakan penagihan berbasis node pada versi GKE yang didukung, sebaiknya gunakan buffer kapasitas deklaratif karena tidak memerlukan pengelolaan Deployment placeholder atau loop pengeluaran Pod.
Mempercepat penarikan image container
Setelah penjadwal menempatkan Pod di node, node harus menarik image container sebelum memulai container. Anda dapat mengurangi latensi pengambilan image menggunakan strategi berikut:
- Aktifkan Streaming image agar container dapat dimulai segera setelah file yang diperlukan di-streaming melalui jaringan, sementara sisa image didownload di latar belakang. Cluster Autopilot mengaktifkan streaming Image secara default untuk image yang memenuhi syarat di Artifact Registry.
- Konfigurasikan boot disk sekunder untuk melakukan pramuat lapisan dasar container besar atau set data statis ke disk image kustom. Saat membuat node, GKE akan memasang Persistent Disk yang dibuat dari disk image Anda secara paralel dengan penyediaan node.
- Jalankan DaemonSet untuk melakukan pramuat image container pada buffer standby selama
jendela inisialisasi node (anotasi
buffer.gke.io/standby-capacity-init-time). Sebelum GKE menangguhkan node standby, DaemonSet akan menarik image workload Anda ke boot disk node sehingga image sudah di-cache saat node dilanjutkan.
Mempercepat inisialisasi aplikasi
Bahkan setelah node berjalan dan image container tersedia, aplikasi dapat memerlukan waktu yang signifikan untuk memuat framework, mengompilasi kode just-in-time (JIT), atau memuat bobot model ke dalam memori. Anda dapat mengurangi waktu inisialisasi dengan menggunakan strategi berikut:
- Konfigurasi snapshot Pod untuk merekam checkpoint status memori dan sistem file Pod yang sedang berjalan di GKE Sandbox. Saat workload Anda diskalakan secara horizontal, GKE akan memulihkan replika baru dari snapshot di Cloud Storage sehingga Pod melanjutkan eksekusi dari titik pengambilan snapshot, bukan melakukan inisialisasi dari status baru.
- Konfigurasi peningkatan CPU startup di VerticalPodAutoscaler untuk mengalokasikan
CPU tambahan ke Pod selama penerimaan dan inisialisasi. Setelah
Pod mencapai status
Readydan durasi peningkatannya yang dikonfigurasi berakhir, GKE akan menurunkan kembali permintaan CPU Pod ke tingkat dasarnya di tempat tanpa memulai ulang penampung.
Gabungkan strategi untuk pengoptimalan menyeluruh
Karena strategi ini beroperasi pada berbagai tahap siklus proses startup Pod, Anda dapat melapisinya untuk mengoptimalkan waktu peningkatan skala end-to-end:
- Gabungkan buffer kapasitas aktif kecil dengan buffer kapasitas siaga yang lebih besar. Selama lonjakan traffic yang tiba-tiba, buffer aktif akan segera menyerap burst awal Pod. Sementara itu, GKE melanjutkan node dari buffer standby dalam waktu sekitar 30 hingga 35 detik untuk mengisi ulang buffer aktif dan menangani pertumbuhan berkelanjutan. Di latar belakang, autoscaler cluster menyediakan dan menangguhkan node baru untuk mengisi ulang buffer standby.
- Untuk buffer kapasitas standby, aktifkan streaming Image atau pemuatan awal image container menggunakan DaemonSet sebelum node ditangguhkan agar node tidak menghabiskan waktu mendownload image container besar saat dilanjutkan.
- Gabungkan peningkatan peluncuran CPU atau snapshot Pod di atas buffer kapasitas atau node yang diluncurkan cepat sehingga setelah GKE menjadwalkan Pod ke node yang telah disediakan atau diinisialisasi sebelumnya, Pod akan menghindari throttling CPU selama peluncuran atau dipulihkan langsung dari snapshot yang disimpan.
Untuk mengukur efek dari satu atau gabungan strategi pada workload Anda, lihat diagram Distribusi Latensi Startup Pod dan Latensi Siap Pertama Pod di Cloud Monitoring dan periksa log latensi penjadwalan di Cloud Logging. Untuk mengetahui petunjuknya, lihat Memantau metrik latensi startup.