Gambaran umum penskalaan Azure Kubernetes Service (AKS) — HPA, VPA, Cluster Autoscaler, dan KEDA

Saat menjalankan aplikasi di Azure Kubernetes Service (AKS), Anda dapat menskalakan pod, sumber daya pod, simpul, atau beban kerja berbasis peristiwa agar sesuai dengan perubahan permintaan. AKS mendukung penskalaan manual, Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), Cluster Autoscaler, Kubernetes Event-driven Autoscaling (KEDA), node autoprovisioning, dan burst scaling dengan Azure Container Instances (ACI).

Pilih metode penskalakan yang tepat

Metode penskalakan	Paling cocok untuk	Metrik utama	Guide
Autoscaler Pod Horizontal (HPA)	Beban kerja tanpa status atau dapat dipartisi dengan permintaan variabel	Pemanfaatan CPU, RPS, kedalaman antrean	Kapan saya harus menggunakan Horizontal Pod Autoscaling (HPA) di Kubernetes?
Vertical Pod Autoscaler (VPA)	Beban kerja yang tidak dapat diparalelkan; menyesuaikan permintaan sumber daya pod secara tepat	Penggunaan sumber daya CPU/memori	Gunakan Autoscaler Pod Vertikal di AKS
Autoscaler Kluster	Kapasitas tingkat node ketika pod tetap Tertunda	Pod yang tertunda	Gunakan Cluster Autoscaler di AKS
Penyediaan otomatis simpul (NAP)	Beban kerja tertunda yang membutuhkan kapasitas VM yang berukuran tepat	Kebutuhan sumber daya pod yang tertunda	Gambaran umum provisi otomatis node
KEDA	Beban kerja berbasis peristiwa; penskalaan ke nol diperlukan	Panjang antrean, tumpukan kejadian	Gambaran umum add-on KEDA
Penskalaan ledakan ACI	Beban kerja Linux dengan lonjakan permintaan yang mencapai batasan node virtual	Lonjakan permintaan	Membuat simpul virtual dengan Azure Container Instances

Kapan menggunakan setiap metode penskalakan

Gunakan HPA saat beban kerja Anda dapat menjalankan beberapa replika yang identik dan permintaan berfluktuasi berdasarkan CPU, memori, atau tingkat permintaan.
Gunakan VPA saat beban kerja Anda tidak dapat menskalakan secara horizontal (tidak dapat diparalelkan) atau Anda perlu mengukur permintaan sumber daya dengan tepat untuk penjadwalan yang lebih baik.
Gunakan Cluster Autoscaler saat Anda memiliki pool node yang telah ditetapkan sebelumnya dan perlu menambahkan atau menghapus node berdasarkan kebutuhan pod yang tertunda.
Gunakan NAP saat Anda menginginkan pemilihan SKU VM otomatis dan provisi simpul tanpa mengonfigurasi kumpulan simpul secara manual.
Gunakan KEDA saat penskalakan harus merespons peristiwa eksternal (antrean, aliran, pesan) atau Anda memerlukan kemampuan skala-ke-nol.
Gunakan penskalaan ledakan ACI saat Anda membutuhkan ekspansi kapasitas yang cepat untuk beban kerja Linux tanpa menunggu provisi VM (biasanya 2-5 menit).

Rekomendasi cepat

Untuk sebagian besar beban kerja produksi, mulailah dengan AKS Automatic, yang melakukan pra-konfigurasi NAP, VPA, dan KEDA. Di AKS Standard, Anda mengaktifkan dan mengonfigurasi fitur-fitur ini secara eksplisit.

Menskalakan pod atau simpul secara manual

Anda dapat menskalakan replika dan simpul pod secara manual untuk menguji bagaimana aplikasi Anda merespons perubahan sumber daya yang tersedia atau untuk mempertahankan jumlah kapasitas tetap. Untuk menskalakan secara manual, tentukan jumlah replika atau simpul yang diperlukan. Kubernetes kemudian membuat atau menghapus pod, sementara AKS menambahkan atau menghapus simpul dari kumpulan simpul yang berlaku.

Saat Anda mengurangi jumlah node, AKS memanggil API Azure Compute yang sesuai dengan tipe komputasi kluster tersebut. Untuk kluster yang dibangun di atas Virtual Machine Scale Sets, API Virtual Machine Scale Sets menentukan simpul mana yang akan dihapus. Untuk informasi selengkapnya, lihat FAQ tentang Virtual Machine Scale Sets.

Untuk memulai, lihat:

Horizontal Pod Autoscaler

Gunakan HPA saat beban kerja Anda dapat menjalankan beberapa replika identik dan permintaan berfluktuasi. Ini melakukan penskalaan berdasarkan CPU atau memori, metrik aplikasi (permintaan per detik, latensi), atau metrik antrean eksternal dan backlog. Ketika replika mungkin melebihi kapasitas simpul yang ada, gunakan kemampuan NAP yang telah dikonfigurasi sebelumnya di AKS Otomatis atau konfigurasikan Autoscaler Kluster atau NAP di Standar AKS.

Jangan gunakan HPA dan VPA pada metrik CPU atau memori yang sama. Untuk menggunakan kedua penskala otomatis, gunakan VPA dalam mode rekomendasi atau konfigurasikan HPA untuk menggunakan metrik kustom yang berbeda.

Pelajari lebih lanjut: Kapan saya harus menggunakan Horizontal Pod Autoscaling (HPA) di Kubernetes?

Lihat juga: Gunakan Vertical Pod Autoscaler di AKS untuk menyesuaikan permintaan CPU dan memori pod agar sesuai kebutuhan.

Autoscaler Vertikal Pod

Penskala Otomatis Pod Vertikal menganalisis CPU pod dan penggunaan memori dan merekomendasikan atau menerapkan permintaan sumber daya yang sesuai. Gunakan VPA untuk beban kerja ukuran yang tepat yang tidak dapat diskalakan secara efisien dengan menambahkan replika atau untuk meningkatkan penjadwalan dan pemanfaatan sumber daya.

Bergantung pada mode pembaruannya, VPA dapat menerapkan rekomendasi ketika pod dibuat atau dikeluarkan dan dibuat ulang pod dengan permintaan sumber daya yang diperbarui. Tinjau persyaratan ketersediaan beban kerja sebelum mengizinkan VPA menerapkan perubahan secara otomatis.

Untuk memulai, lihat Menggunakan Autoscaler Pod Vertikal di AKS.

Autoscaler Kluster

Cluster Autoscaler menyesuaikan jumlah node dalam pool node sesuai dengan kebutuhan penjadwalan pod. Menambahkan simpul ketika pod tidak dapat dijadwalkan karena kapasitas simpul tidak mencukupi dan menghapus simpul yang kurang dimanfaatkan ketika beban kerjanya dapat berjalan di tempat lain.

Cluster Autoscaler umumnya digunakan dengan HPA. HPA menyesuaikan jumlah replika pod berdasarkan permintaan beban kerja, sementara Cluster Autoscaler menyesuaikan kapasitas node untuk mengakomodasi pod tersebut.

Untuk memulai, lihat Menggunakan Autoscaler Kluster di AKS.

Peristiwa peluasan skala

Jika kumpulan simpul tidak memiliki sumber daya komputasi yang memadai untuk pod, pod tetap berstatus Pending. Ketika Cluster Autoscaler mendeteksi pod yang tidak dapat ditempatkan karena keterbatasan sumber daya pada kumpulan node, Cluster Autoscaler menambah jumlah node dalam kumpulan node. Kubernetes menjadwalkan pod yang tertunda setelah simpul baru diprovisikan dan menjadi siap.

Penyediaan simpul berbasis VM dapat memakan waktu beberapa menit. Untuk beban kerja dengan lonjakan permintaan mendadak, pertimbangkan penggunaan node virtual dan Azure Container Instances.

Peristiwa penyempurnaan skala

Cluster Autoscaler memantau simpul yang kurang dimanfaatkan dan menentukan apakah pod-podnya dapat berjalan di simpul lain. Ketika node tidak lagi diperlukan, Kubernetes menjadwalkan ulang pod-nya dan AKS menghapus simpul dari kumpulan simpul.

Operasi scale-in dapat mengganggu beban kerja saat pod berpindah di antara node. Jalankan beberapa replika pod dan konfigurasikan kontrol ketersediaan yang sesuai untuk meminimalkan gangguan.

Autoscaling berbasis Peristiwa Kubernetes

Autoscaling Berbasis Peristiwa Kubernetes (KEDA) adalah komponen sumber terbuka yang menyesuaikan skala beban kerja berdasarkan peristiwa. KEDA memperluas Kubernetes dengan sumber daya kustom, termasuk ScaledObject, yang menjelaskan bagaimana beban kerja harus merespons sumber atau metrik peristiwa.

KEDA berguna untuk beban kerja yang memproses antrean, aliran, pesan, atau backlog peristiwa lainnya. Ini dapat menskalakan beban kerja menjadi nol saat tidak ada event yang tersedia dan meningkatkan jumlah replika saat backlog bertambah.

Jangan gabungkan KEDA ScaledObject dengan HPA terpisah untuk beban kerja yang sama. KEDA membuat dan menggunakan HPA secara internal, sehingga autoscaler akan bersaing satu sama lain.

Untuk memulai, lihat gambaran umum add-on KEDA.

Pemetaan otomatis simpul

Penyediaan otomatis node (NAP) menggunakan proyek sumber terbuka Karpenter untuk menyediakan dan mengelola node sesuai dengan kebutuhan pod yang tertunda. NAP memilih SKU mesin virtual dan jumlah node yang sesuai untuk memenuhi permintaan beban kerja secara real-time.

NAP dimulai dengan sekumpulan SKU VM yang diizinkan dan memilih kapasitas untuk beban kerja yang tertunda. Anda dapat menentukan batas sumber daya dan preferensi penjadwalan untuk mengontrol bagaimana ia menyediakan simpul dan mendistribusikan beban kerja.

Skalabilitas dan perlindungan bidang kontrol

AKS secara otomatis menskalakan komponen sarana kontrol berdasarkan ukuran kluster dan pemanfaatan sumber daya server API. Panduan ini berlaku untuk AKS Automatic dan AKS Standard. Gunakan tingkat harga Standar atau Premium untuk beban kerja produksi atau dalam skala besar.

Kubernetes memiliki amplop skala multidirmensional di mana setiap jenis sumber daya menempatkan tuntutan yang berbeda pada sarana kontrol. Misalnya, resource Secret sering dipantau oleh beberapa controller dan pod yang membuat panggilan awal LIST, sehingga menimbulkan beban control plane yang lebih besar dibandingkan resource yang lebih jarang dipantau. Meningkatkan skala secara besar-besaran pada satu dimensi dapat mengurangi kapasitas pada dimensi lainnya. Misalnya, menjalankan ratusan ribu pod dapat mengurangi tingkat mutasi pod yang didukung sarana kontrol. Untuk rekomendasi, lihat Praktik terbaik klien Kubernetes untuk kluster AKS skala besar.

Untuk memeriksa apakah sarana kontrol telah ditingkatkan skalanya large-cluster-control-plane-scaling-status , periksa ConfigMap:

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Kehadiran ConfigMap ini mengonfirmasi bahwa AKS meningkatkan skala sarana kontrol.

Perlindungan sarana kontrol

Jika penskalaan otomatis server API tidak dapat menstabilkannya saat beban tinggi, AKS dapat menerapkan pelindung server API terkelola. Mekanisme perlindungan terakhir ini membatasi laju permintaan klien non-sistem untuk mencegah bidang kontrol menjadi tidak responsif. Panggilan ke server API yang kritis bagi sistem dari komponen seperti kubelet tetap berfungsi.

Untuk menentukan apakah penjaga server API terkelola telah diterapkan, periksa aks-managed-apiserver-guardFlowSchema dan PriorityLevelConfiguration:

kubectl get flowschemas
kubectl get prioritylevelconfigurations

Penjaga aktif saat aks-managed-apiserver-guard muncul di kedua output perintah.

Jika sumber daya ini ada, lihat panduan pemecahan masalah api server dan etcd untuk panduan mitigasi.

Luapkan ke Azure Container Instances (ACI)

Anda dapat mengintegrasikan AKS dengan Azure Container Instances untuk menangani peningkatan permintaan yang cepat. Penskalaan otomatis pod dapat membuat lebih banyak replika daripada yang dapat didukung oleh pool node yang ada, sementara penyediaan node tambahan berbasis VM dapat memakan waktu beberapa menit. ACI menyediakan kapasitas komputasi tanpa memerlukan simpul VM tambahan.

Simpul virtual (simpul Kubernetes virtual yang didukung ACI) mendukung pod dan simpul Linux dan memerlukan kluster AKS yang menggunakan jaringan Azure CNI. Mereka tidak mendukung beberapa skenario umum, termasuk rentang IP resmi server API, volume persisten, dan klaim volume persisten, IPv6, dan identitas terkelola yang melekat pada simpul virtual. Tinjau batasan simpul virtual sebelum menggunakan penskalaan burst ACI.

Komponen simpul virtual AKS didasarkan pada Kubelet Virtual dan menyajikan ACI sebagai simpul Kubernetes virtual. Kubernetes dapat menjadwalkan pod yang memenuhi syarat melalui simpul virtual untuk berjalan sebagai instans kontainer ACI alih-alih langsung pada simpul VM AKS.

Simpul virtual menggunakan subnet lain di jaringan virtual yang sama dengan kluster AKS. Konfigurasi ini menyediakan konektivitas jaringan privat antara AKS dan ACI sambil memungkinkan ACI bertindak sebagai ekstensi logis kluster.

Gunakan sumber daya berikut untuk mengimplementasikan metode penskalakan yang sesuai dengan beban kerja Anda:

Untuk informasi selengkapnya tentang konsep inti Kubernetes dan AKS, lihat:

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-08-15