Penskalaan otomatis Pod vertikal

Autopilot Standard

Halaman ini menjelaskan cara menganalisis dan mengoptimalkan alokasi resource untuk meningkatkan efisiensi workload di Google Kubernetes Engine (GKE) menggunakan penskalaan otomatis Pod vertikal. Dengan menganalisis penggunaan resource workload Anda dari waktu ke waktu, Anda bisa mendapatkan rekomendasi pengoptimalan dan menyesuaikan permintaan dan batas CPU serta memori untuk container dalam Pod secara otomatis.

Di halaman ini, Anda akan mempelajari cara kerja penskalaan otomatis Pod vertikal, manfaat dan batasannya, praktik terbaik untuk menggunakannya, serta mengakses referensi API untuk resource kustom VerticalPodAutoscaler dan jenis terkait.

Halaman ini ditujukan bagi Operator dan Developer yang menyediakan dan mengonfigurasi resource cloud, men-deploy workload, dan mengelola penskalaan aplikasi. Untuk mempelajari peran umum lebih lanjut, lihat Peran dan tugas pengguna GKE umum.

Sebelum membaca halaman ini, pastikan Anda memahami permintaan dan batas resource di Kubernetes.

Untuk kebutuhan penskalaan cepat sebagai respons terhadap penggunaan resource yang tiba-tiba, gunakan Horizontal Pod Autoscaler.

Untuk mempelajari praktik terbaik penskalaan otomatis, lihat Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE.

Alasan menggunakan penskalaan otomatis Pod vertikal

Penskalaan otomatis Pod vertikal memberikan manfaat berikut:

• Menetapkan batas dan permintaan resource yang tepat untuk workload Anda akan meningkatkan stabilitas dan efisiensi biaya. Jika ukuran resource Pod lebih kecil dari workload yang diperlukan, aplikasi dapat di-throttle atau dapat gagal karena error kehabisan memori. Jika ukuran resource terlalu besar, Anda akan mengalami pemborosan dan oleh karena itu, tagihan akan lebih besar.
• Node cluster digunakan secara efisien karena Pod hanya menggunakan apa yang dibutuhkannya.
• Pod dijadwalkan ke node yang memiliki resource yang sesuai.
• Anda tidak perlu menjalankan tugas benchmark yang memakan waktu untuk menentukan nilai yang benar untuk permintaan CPU dan memori.
• Anda dapat mengurangi waktu pemeliharaan karena autoscaler dapat menyesuaikan permintaan CPU dan memori dari waktu ke waktu tanpa Anda perlu melakukan tindakan apa pun.
• Penskalaan otomatis Pod vertikal berfungsi paling optimal dengan workload homogen yang berjalan lama.

Penskalaan otomatis Pod vertikal GKE memberikan manfaat berikut dibandingkan autoscaler Kubernetes open source:

• Mempertimbangkan ukuran node maksimum dan kuota resource saat menentukan target rekomendasi.
• Memberi tahu autoscaler cluster untuk menyesuaikan kapasitas cluster.
• Menggunakan data historis, termasuk metrik yang dikumpulkan sebelum Anda mengaktifkan VerticalPodAutoscaler.
• Menjalankan Pod VerticalPodAutoscaler sebagai proses bidang kontrol, bukan deployment pada node pekerja.

Cara kerja penskalaan otomatis Pod vertikal

Penskalaan otomatis Pod vertikal dapat digunakan untuk menganalisis dan menetapkan resource CPU dan memori yang diperlukan oleh Pod. Daripada menetapkan permintaan dan batas CPU terbaru serta permintaan dan batas memori untuk container di Pod, Anda dapat mengonfigurasi penskalaan otomatis Pod vertikal guna memberikan nilai yang direkomendasikan untuk permintaan CPU dan memori serta batas yang bisa digunakan untuk mengupdate Pod secara manual, atau Anda dapat mengonfigurasi penskalaan otomatis Pod vertikal agar otomatis mengupdate nilai tersebut.

Penskalaan otomatis Pod vertikal diaktifkan secara default di cluster Autopilot.

Hubungan dengan VerticalPodAutoscaler open source Kubernetes

Penskalaan otomatis Pod vertikal GKE didasarkan pada API VerticalPodAutoscaler Kubernetes open source, tetapi merupakan penerapan terpisah yang unik untuk GKE. Implementasi GKE dirancang untuk skala dengan recommender-nya sendiri, tetapi mempertahankan jenis dan kolom VerticalPodAutoscaler API yang sama yang ditentukan dalam versi open source.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi Kubernetes untuk penskalaan otomatis Pod vertikal.

Mode penskalaan otomatis Pod vertikal

Anda dapat mengonfigurasi cara penskalaan otomatis Pod vertikal menerapkan perubahan resource dengan menerapkan mode update yang berbeda.

Mode Auto (Recreate)

Catatan: Mode Recreate dan Auto menggunakan perilaku yang sama. Mode update Auto adalah mode default jika kolom updateMode tidak ditentukan dalam objek VerticalPodAutoscaler.

Dalam mode Recreate, penskalaan otomatis Pod vertikal akan mengeluarkan Pod jika perlu mengubah permintaan resource Pod. Pengusiran diperlukan karena, karena keterbatasan Kubernetes dalam versi sebelum 1.33, satu-satunya cara untuk mengubah permintaan resource pada Pod yang berjalan adalah dengan membuatnya ulang.

Untuk membatasi jumlah pembuatan ulang Pod, gunakan Anggaran gangguan Pod . Untuk memastikan bahwa cluster Anda dapat menangani ukuran baru workload, gunakan autoscaler cluster dan penyediaan otomatis node.

Penskalaan otomatis Pod vertikal memberi tahu autoscaler cluster sebelum update, dan menyediakan resource yang diperlukan untuk beban kerja yang diubah ukurannya sebelum membuat ulang workload, untuk meminimalkan waktu gangguan.

Mode Initial

Dengan Initial diaktifkan, penskalaan otomatis Pod vertikal hanya menetapkan permintaan resource saat pembuatan Pod dan tidak pernah mengubahnya nanti.

Mode InPlaceOrRecreate

Pratinjau

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

Mode InPlaceOrRecreate bertujuan untuk mengurangi gangguan layanan dengan mencoba mengupdate resource Pod tanpa membuat ulang Pod.

Untuk menggunakan mode InPlaceOrRecreate, tetapkan kolom spec.updatePolicy.updateMode ke "InPlaceOrRecreate" dalam objek VerticalPodAutoscaler Anda. Mode ini mengandalkan pada kolom resizePolicy yang ditentukan dalam manifes workload Anda untuk menentukan apakah perubahan resource memerlukan mulai ulang. Jika kolom resizePolicy tidak ditentukan, kolom tersebut secara default adalah NotRequired untuk CPU dan memori, yang berarti update di tempat akan dicoba.

Jika container dihentikan karena peristiwa OOM (Out of Memory), penskalaan otomatis Pod vertikal dalam mode InPlaceOrRecreate akan bertindak serupa dengan mode Auto: penskalaan otomatis Pod vertikal akan belajar dari kegagalan. Setelah Pod dibuat ulang karena error, penskalaan otomatis Pod vertikal menerapkan rekomendasi yang mencakup buffer keamanan (biasanya 20% memori tambahan atau 100 MB, mana saja yang lebih besar) untuk mencegah pengulangan error OOM segera.

Mode InPlaceOrRecreate tersedia dengan Kubernetes versi 1.34.0-gke.2201000 dan yang lebih baru.

Skenario penggantian untuk mode InPlaceOrRecreate

Jika penskalaan otomatis Pod vertikal menentukan bahwa update di tempat tidak memungkinkan, penskalaan otomatis Pod vertikal akan kembali ke perilaku mode Recreate, yang mengeluarkan dan membuat ulang Pod untuk menerapkan perubahan. Beberapa skenario umum saat penskalaan otomatis Pod vertikal melakukan penggantian dengan pembuatan ulang meliputi:

• Kapasitas node tidak mencukupi: permintaan resource yang diperbarui melebihi kapasitas yang dapat dialokasikan dari node saat ini, dan update tidak dapat dijadwalkan di tempat ("tidak dapat dilakukan" atau "ditangguhkan" selama lebih dari waktu tunggu).
• Perubahan kelas QoS: pembaruan resource akan mengubah kelas Kualitas Layanan (QoS) Pod, misalnya dari Burstable menjadi Guaranteed.
• Kebijakan RestartContainer: kolom resizePolicy Pod disetel ke RestartContainer untuk resource yang coba diubah oleh penskalaan otomatis Pod vertikal.
• Waktu tunggu habis: permintaan update di tempat tetap dalam status menunggu terlalu lama.

Mode Off

Dalam mode Off, penskalaan otomatis Pod vertikal tidak otomatis menerapkan perubahan apa pun pada Pod. Anda tetap dapat melihat nilai yang direkomendasikan untuk permintaan dan batas CPU serta memori berdasarkan penggunaan historis, tetapi rekomendasi ini tidak diterapkan untuk Anda. Anda dapat menerapkan nilai yang direkomendasikan ke Pod secara manual, jika diperlukan.

Peningkatan startup CPU

Peningkatan startup CPU mempercepat startup aplikasi dan meningkatkan efisiensi biaya dengan meningkatkan permintaan CPU untuk sementara waktu selama inisialisasi dan mengubah ukurannya kembali ke tingkat dasar di tempat.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi peningkatan startup CPU, lihat Mempercepat startup aplikasi dengan peningkatan startup CPU.

Cara kerja peningkatan startup CPU

Peningkatan peluncuran CPU menghitung peningkatan resource sementara berdasarkan permintaan CPU dasar penampung Anda. Pod kembali ke tingkat permintaan dasar ini setelah fase startup.

Peningkatan ini meningkatkan permintaan dasar baik dengan pengali maupun jumlah tetap. Permintaan yang ditingkatkan ini tetap aktif hingga Pod siap, setelah itu GKE memulihkan permintaan CPU ke tingkat dasarnya.

Memahami siklus proses peningkat

Proses peningkatan startup terdiri dari tiga fase:

1. Fase penerimaan: selama penerimaan Pod, webhook penerimaan VPA mencegat permintaan dan menyuntikkan nilai CPU yang ditingkatkan sebelum GKE menjadwalkan Pod.
2. Fase startup: aplikasi diinisialisasi menggunakan alokasi CPU yang ditingkatkan untuk sementara waktu guna menghindari pembatasan inisialisasi.
3. Fase penghapusan peningkatan: setelah Pod mencapai status Ready dan periode durationSeconds telah berlalu, VPA akan menurunkan skala permintaan CPU di tempat ke nilai dasar.

Catatan: Pengupdate VPA memeriksa status Pod dalam siklus satu menit reguler untuk menangani penghapusan peningkatan. Karena evaluasi berkala ini, GKE mengukur periode durationSeconds dalam interval satu menit, yang berarti peningkatan dapat berlanjut hingga satu menit lebih lama dari yang dikonfigurasi.

Memilih mode update untuk workload yang dioptimalkan

Anda dapat mengonfigurasi peningkatan startup CPU dengan atau tanpa pengelolaan resource berkelanjutan VPA. Pengelolaan resource berkelanjutan VPA otomatis menyesuaikan permintaan resource Pod Anda setelah fase startup berakhir. Untuk memilih preferensi Anda, tetapkan kolom updateMode di objek VPA. Untuk mengetahui informasi selengkapnya tentang mode update VPA, lihat Mode penskalaan otomatis Pod Vertikal.

• updateMode: "Off": VPA hanya mengelola peningkatan awal selama penerimaan Pod (fase dalam pembuatan Pod) dan penurunan skala berikutnya setelah startup. Hal ini tidak mengubah permintaan resource kondisi stabil container Anda.
• updateMode: "Auto", "Recreate", atau "InPlaceOrRecreate": VPA mengelola peningkatan saat startup dan terus menyesuaikan permintaan resource Pod Anda secara otomatis berdasarkan penggunaan yang sedang berlangsung.

Cara penghitungan alokasi resource peningkat CPU

GKE menghitung permintaan CPU yang ditingkatkan sementara dengan cara berikut:

1. Tentukan CPU dasar: permintaan CPU dasar bergantung pada kolom VPA updateMode:

   • Auto, Recreate, atau InPlaceOrRecreate: permintaan CPU dasar adalah rekomendasi VPA. Jika tidak ada rekomendasi, GKE akan kembali ke permintaan CPU yang ditentukan dalam spesifikasi Pod.
   • Off: permintaan CPU dasar adalah nilai permintaan dari spesifikasi Pod.

2. Menghitung CPU yang di-boost: penghitungan bergantung pada metode penghitungan yang Anda tentukan di kolom type konfigurasi boost:

   • Factor: menerapkan pengganda ke permintaan CPU dasar:

     CPU yang ditingkatkan  =  CPU dasar  ×  factor

   • Quantity: menambahkan jumlah CPU absolut ke permintaan CPU dasar:

     CPU yang ditingkatkan  =  CPU dasar  +  quantity

Permintaan CPU akhir bergantung pada mode cluster Anda:

• Cluster standar: permintaan CPU akhir adalah nilai CPU yang di-boost.
• Cluster Autopilot: permintaan CPU akhir adalah nilai CPU yang ditingkatkan, yang dibatasi oleh CPU maksimum yang diizinkan untuk memori Pod yang dialokasikan.

Memahami perilaku batas CPU selama peningkatan

Cara GKE menangani batas CPU bergantung pada setelan controlledValues di containerResourcePolicy Anda:

• RequestsAndLimits (Default): GKE meningkatkan permintaan dan batas CPU, dengan mempertahankan rasio aslinya untuk mempertahankan kelas Quality of Service (QoS) container.
• RequestsOnly: GKE hanya meningkatkan permintaan CPU. GKE membatasi permintaan yang di-boost tepat di bawah batas CPU yang ditentukan untuk mempertahankan QoS.

Pertimbangan untuk cluster Autopilot

Karena GKE Autopilot menerapkan rentang rasio CPU terhadap memori dan ukuran Pod minimum tertentu, GKE mengevaluasi peningkatan selama penerimaan Pod untuk memastikan kepatuhan. Peningkatan dapat diubah atau diabaikan dalam skenario berikut:

• Nilai minimum Autopilot: Jika permintaan yang ditingkatkan berada di bawah persyaratan CPU minimum untuk workload Autopilot (misalnya, 50 m untuk Pod Tujuan Umum), GKE tidak akan menerapkan peningkatan dan akan menerapkan nilai minimum standar.
• Pembatasan rasio (peningkatan sebagian atau dilewati): jika permintaan CPU yang ditingkatkan akan melampaui rentang rasio CPU ke memori yang diperlukan, GKE akan membatasi peningkatan ke nilai tertinggi yang sesuai dengan memori yang dialokasikan. Jika permintaan Pod asli sudah menggunakan rasio CPU ke memori maksimum yang diizinkan, GKE akan melewati peningkatan untuk menghindari pengubahan ukuran memori.
• Scale-Out ComputeClass: Scale-Out ComputeClass menerapkan rasio 1:4 (CPU:Memori) yang ketat. Mencoba meningkatkan CPU pada Pod Scale-Out tanpa meningkatkan memorinya dapat menyebabkan GKE mengabaikan peningkatan tersebut.

Praktik terbaik: Untuk workload Autopilot, pastikan Anda mengalokasikan memori dasar yang cukup dalam spesifikasi Pod untuk mendukung rasio CPU yang ditingkatkan. Jika Anda mengandalkan peningkatan kualitas startup, hindari penggunaan Scale-Out ComputeClass.

Kebijakan resource

Anda dapat menggunakan ContainerResourcePolicy untuk menyesuaikan cara penskalaan otomatis Pod vertikal membuat rekomendasi untuk container tertentu. Kebijakan ini memungkinkan Anda menetapkan batasan dan mengontrol resource mana yang diskalakan.

Batas minimum dan maksimum

Anda dapat menentukan nilai resource minimum (minAllowed) dan maksimum (maxAllowed) untuk container.

• minAllowed: penskalaan otomatis Pod vertikal tidak akan merekomendasikan nilai yang lebih rendah dari batas ini. Batas ini berguna karena membantu memastikan tingkat performa dasar atau memenuhi persyaratan khusus aplikasi.
• maxAllowed: penskalaan otomatis Pod vertikal tidak akan merekomendasikan nilai yang lebih tinggi dari batas ini. Batas ini berguna untuk mengontrol biaya atau mencegah satu penampung menggunakan terlalu banyak resource node.

Resource yang dikontrol

Secara default, penskalaan otomatis Pod vertikal menghitung rekomendasi untuk CPU dan memori. Anda dapat menggunakan kolom controlledResources untuk menentukan resource mana yang akan di-autoskalakan. Misalnya, Anda dapat mengonfigurasi autoscaler untuk memberikan rekomendasi hanya untuk memori, sehingga permintaan CPU tidak berubah.

Batasan

• Untuk menggunakan penskalaan otomatis Pod vertikal dengan penskalaan Pod horizontal, gunakan penskalaan Pod multidimensi. Anda juga dapat menggunakan penskalaan otomatis Pod vertikal dengan penskalaan otomatis Pod horizontal pada metrik kustom dan eksternal.
• Penskalaan otomatis Pod vertikal belum siap digunakan untuk workload berbasis JVM karena visibilitas yang terbatas ke penggunaan memori aktual workload.
• Di GKE versi 1.35.1 dan yang lebih lama, penskalaan otomatis Pod vertikal memiliki setelan default dua replika minimum untuk Deployment guna mengganti Pod dengan nilai resource yang direvisi. Pada versi 1.35.2 dan yang lebih baru, defaultnya adalah satu replika minimum. Di versi 1.22 dan yang lebih baru, Anda dapat mengganti setelan ini dengan menentukan nilai untuk kolom minReplicas di kolom PodUpdatePolicy.
• Jika Anda menggunakan mode update InPlaceOrRecreate pada penskalaan otomatis Pod vertikal dan update di tempat tidak memungkinkan (misalnya, saat meningkatkan skala Pod di luar kapasitas node), penskalaan otomatis Pod vertikal akan mengeluarkan dan membuat ulang Pod untuk menerapkan rekomendasi. Pengusiran dan pembuatan ulang terjadi bahkan untuk Pod yang memiliki kolom resizePolicy yang ditetapkan dalam spesifikasinya untuk menghindari pembuatan ulang. Perilaku ini terjadi untuk permintaan pengubahan ukuran Autopilot, termasuk saat menerapkan batasan rasio CPU:memori dan resource minimum.
• Penskalaan otomatis Pod vertikal memerlukan objek workload yang mengelola Pod, seperti Deployment, StatefulSet, ReplicaSet, atau ReplicationController. Anda tidak dapat menggunakan penskalaan otomatis Pod vertikal dengan Pod mandiri karena pengontrol workload diperlukan untuk mengelola proses pembuatan ulang Pod.

Praktik terbaik

• Batasi jumlah objek VerticalPodAutoscaler. Untuk menghindari gangguan update cluster, Anda harus mempertahankan jumlah objek VerticalPodAutoscaler per cluster di bawah 1.000.
• Penskalaan otomatis Pod vertikal berfungsi paling optimal dengan workload homogen yang berjalan lama.
  • Berjalan lama: workload yang berjalan selama minimal 24 jam. Penskalaan otomatis Pod vertikal memerlukan data historis dalam jumlah yang signifikan untuk menghasilkan rekomendasi dengan tingkat keyakinan yang tinggi. Dalam mode Auto atau Recreate, update biasanya terjadi setelah Pod berusia minimal 24 jam, yang membantu mencegah seringnya Pod dimulai ulang dan churn.
  • Homogen: pod yang ditargetkan oleh satu objek VerticalPodAutoscaler (seperti semua replika dalam Deployment) harus menunjukkan pola konsumsi resource yang serupa. Penskalaan otomatis Pod vertikal membuat rekomendasi dengan menggabungkan data penggunaan di semua Pod target. Jika replika Anda memiliki penggunaan yang heterogen, misalnya beberapa Pod tidak digunakan dan yang lain sangat terbebani, penskalaan otomatis Pod vertikal dapat memberikan rekomendasi yang terlalu banyak menyediakan Pod yang tidak digunakan atau kurang menyediakan Pod yang sibuk.
• Gunakan penskalaan otomatis Pod horizontal untuk workload dengan lonjakan permintaan yang tiba-tiba. Penskalaan otomatis Pod vertikal dirancang untuk penyesuaian ukuran steady-state dan bukan solusi untuk lonjakan resource yang tiba-tiba dan berdurasi singkat. Untuk workload dengan fluktuasi traffic atau permintaan CPU atau memori yang cepat, gunakan horizontal Pod autoscaler sebagai gantinya.
• Manfaatkan perlindungan OOM. Meskipun penskalaan otomatis Pod vertikal bersifat reaktif, penskalaan ini mencakup perlindungan otomatis terhadap peristiwa Kehabisan Memori (OOM). Jika Pod OOMKilled, penskalaan otomatis Pod vertikal akan segera mengamati peristiwa tersebut dan meningkatkan rekomendasi memori sekitar 20% (atau 100 MB, mana saja yang lebih besar) untuk meningkatkan stabilitas saat Pod dibuat ulang. Untuk mengetahui informasi selengkapnya tentang peristiwa OOM, lihat Memecahkan masalah peristiwa OOM.

Referensi API

Ini adalah referensi API v1. Kami sangat merekomendasikan penggunaan API versi ini.

VerticalPodAutoscaler v1 autoscaling.k8s.io

Kolom
	TypeMeta Grup, versi, dan jenis API.
metadata	ObjectMeta Metadata objek standar.
spec	VerticalPodAutoscalerSpec Perilaku VerticalPodAutoscaler.
status	VerticalPodAutoscalerStatus Status VerticalPodAutoscaler yang terakhir diamati.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

Kolom
targetRef	CrossVersionObjectReference Referensi ke pengontrol yang mengelola kumpulan Pod untuk dikontrol autoscaler, misalnya Deployment atau StatefulSet. You can point a VerticalPodAutoscaler ke pengontrol mana pun yang memiliki subresource Scale. Biasanya, VerticalPodAutoscaler mengambil kumpulan Pod dari ScaleStatus pengontrol. Untuk beberapa pengontrol yang biasa digunakan, misalnya DaemonSet, VerticalPodAutoscaler akan mengambil kumpulan Pod dari spesifikasi pengontrol.
updatePolicy	PodUpdatePolicy Menentukan apakah update yang direkomendasikan akan diterapkan saat Pod dimulai, dan apakah update yang direkomendasikan akan diterapkan selama masa pakai Pod.
resourcePolicy	PodResourcePolicy Menentukan kebijakan tentang cara permintaan CPU dan memori disesuaikan untuk setiap container. Kebijakan resource dapat digunakan untuk menetapkan batasan pada rekomendasi untuk setiap penampung. Jika tidak ditentukan, autoscaler akan menghitung resource yang direkomendasikan untuk semua container di Pod, tanpa batasan tambahan.
recommenders	VerticalPodAutoscalerRecommenderSelector array Pemberi rekomendasi yang bertanggung jawab untuk membuat rekomendasi untuk objek VPA ini. Biarkan kosong untuk menggunakan pemberi rekomendasi default yang disediakan oleh GKE. Jika tidak, daftar dapat berisi satu entri untuk pemberi rekomendasi alternatif yang diberikan pengguna. Didukung sejak GKE 1.22.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

Kolom
	TypeMeta Grup, versi, dan jenis API.
metadata	ObjectMeta Metadata objek standar.
items	VerticalPodAutoscaler array Daftar objek VerticalPodAutoscaler.

PodUpdatePolicy v1 autoscaling.k8s.io

Kolom
updateMode	string Menentukan apakah update yang direkomendasikan akan diterapkan saat Pod dimulai, dan apakah update yang direkomendasikan akan diterapkan selama masa pakai Pod. Nilai yang memungkinkan adalah sebagai berikut: "Off": update yang direkomendasikan dibuat, tetapi tidak diterapkan secara otomatis ke Pod. "Initial": update yang direkomendasikan hanya diterapkan saat Pod pertama kali dimulai. Update yang terjadi saat Pod sudah berjalan tidak akan diterapkan secara otomatis. "Recreate": update yang direkomendasikan diterapkan dengan membuat ulang Pod. Pod yang ada akan dihentikan, dan Pod baru dengan konfigurasi yang diupdate akan dibuat. "Auto": nilai default yang pada dasarnya menerapkan mode "Recreate". "InPlaceOrRecreate": update yang direkomendasikan diterapkan tanpa membuat ulang Pod, jika memungkinkan.
minReplicas	int32 Jumlah minimum replika yang harus aktif untuk mencoba penghapusan Pod (menunggu pemeriksaan lain seperti Anggaran Gangguan Pod). Hanya nilai positif yang diizinkan. Defaultnya adalah 1 di GKE versi 1.35.2 dan yang lebih baru, serta 2 di versi 1.35.1 dan yang lebih lama. Didukung sejak GKE 1.22.

PodResourcePolicy v1 autoscaling.k8s.io

Kolom
containerPolicies	ContainerResourcePolicy array Array kebijakan resource untuk container individual. Hanya boleh ada maksimal satu entri untuk setiap container yang diberi nama dan secara opsional, satu entri karakter pengganti dengan `containerName = '*'`, yang menangani semua container yang tidak memiliki kebijakan individual.

ContainerResourcePolicy v1 autoscaling.k8s.io

Kolom
containerName	string Nama container tempat kebijakan diterapkan. Jika tidak ditentukan, kebijakan tersebut akan berfungsi sebagai kebijakan default.
mode	ContainerScalingMode Menentukan apakah update yang direkomendasikan diterapkan ke container saat dimulai, dan apakah update yang direkomendasikan diterapkan selama masa pakai container. Nilai yang mungkin adalah "Off" dan "Auto". Setelan defaultnya adalah "Auto" jika Anda tidak menentukan nilai.
minAllowed	ResourceList Menentukan permintaan CPU dan permintaan memori minimum yang diizinkan untuk container. Secara default, tidak ada batas minimum yang diterapkan.
maxAllowed	ResourceList Menentukan permintaan CPU dan permintaan memori maksimum yang diizinkan untuk container. Secara default, tidak ada batas maksimum yang diterapkan.
controlledResources	[]ResourceName Menentukan jenis rekomendasi yang akan dihitung (dan mungkin diterapkan) oleh VerticalPodAutoscaler. Jika kosong, default dari [ResourceCPU, ResourceMemory] akan digunakan.

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

Kolom
name	string Nama pemberi rekomendasi yang bertanggung jawab membuat rekomendasi untuk objek ini.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

Kolom
recommendation	RecommendedPodResources Permintaan CPU dan memori yang direkomendasikan terkini.
conditions	VerticalPodAutoscalerCondition array Menjelaskan status VerticalPodAutoscaler saat ini.

RecommendedPodResources v1 autoscaling.k8s.io

Kolom
containerRecommendations	RecommendedContainerResources array Array rekomendasi resource untuk setiap penampung.

RecommendedContainerResources v1 autoscaling.k8s.io

Kolom
containerName	string Nama container yang diterapkan oleh rekomendasi.
target	ResourceList Permintaan CPU dan permintaan memori yang direkomendasikan untuk container.
lowerBound	ResourceList Permintaan CPU dan permintaan memori minimum yang direkomendasikan untuk container. Jumlah ini tidak dijamin cukup untuk membuat aplikasi menjadi stabil. Menjalankan dengan permintaan CPU dan memori yang lebih kecil cenderung memiliki dampak signifikan terhadap performa atau ketersediaan.
upperBound	ResourceList Permintaan CPU dan permintaan memori maksimum yang direkomendasikan untuk container. Permintaan CPU dan memori yang lebih tinggi dari nilai ini cenderung sia-sia.
uncappedTarget	ResourceList Rekomendasi resource terbaru yang dihitung oleh autoscaler, berdasarkan penggunaan resource sebenarnya, tidak memperhitungkan ContainerResourcePolicy. Jika penggunaan resource yang sebenarnya menyebabkan target melanggar ContainerResourcePolicy, nilai ini mungkin berbeda dengan rekomendasi terbatas. Kolom ini tidak memengaruhi penetapan resource yang sebenarnya. Kolom ini hanya digunakan sebagai indikasi status.

VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

Kolom
type	VerticalPodAutoscalerConditionType Jenis kondisi yang dijelaskan. Nilai yang mungkin adalah "RecommendationProvided", "LowConfidence", "NoPodsMatched", dan "FetchingHistory".
status	ConditionStatus Status kondisi. Nilai yang mungkin adalah True (Benar), False (Salah), dan Unknown (Tidak diketahui).
lastTransitionTime	Time Terakhir kali kondisi melakukan transisi dari satu status ke status lainnya.
reason	string Alasan untuk transisi terakhir dari satu status ke status lainnya.
message	string String yang dapat dibaca manusia yang memberikan detail tentang transisi terakhir dari satu status ke status lainnya.

Langkah berikutnya

• Pelajari cara mengonfigurasi Penskalaan Otomatis Pod Vertikal.
• Pelajari cara mempercepat peluncuran aplikasi menggunakan peningkatan startup CPU.
• Pelajari penskalaan otomatis Pod Horizontal lebih lanjut.
• Pelajari Autoscaler cluster lebih lanjut.