Pelajari cara kerja Horizontal Pod Autoscaler (HPA) Kubernetes untuk scaling Pod otomatis berdasarkan CPU, lengkap dengan contoh konfigurasi dan tips praktis.

Bayangkan aplikasi Anda tiba-tiba viral. Trafik melonjak sepuluh kali lipat dalam hitungan menit, dan server yang biasanya santai kini kewalahan menerima request. Tanpa mekanisme yang tepat, aplikasi bisa melambat, bahkan down total di saat yang paling krusial—ketika banyak calon pengguna baru sedang mencoba mengaksesnya.

Inilah alasan mengapa autoscaling menjadi salah satu fitur paling penting dalam ekosistem Kubernetes. Salah satu komponen utamanya adalah Horizontal Pod Autoscaler (HPA), sebuah controller bawaan Kubernetes yang secara otomatis menambah atau mengurangi jumlah Pod berdasarkan beban kerja aktual.

Bagi tim DevOps dan Sysadmin, memahami HPA bukan sekadar nice-to-have, melainkan kebutuhan dasar untuk menjaga aplikasi tetap responsif, efisien secara biaya, dan tahan terhadap lonjakan trafik. Artikel ini akan membahas secara lengkap cara kerja HPA, contoh konfigurasi, praktik terbaik, hingga kesalahan umum yang sering terjadi saat mengimplementasikannya.

Apa Itu Horizontal Pod Autoscaler (HPA)?

HPA adalah sebuah controller di Kubernetes yang bekerja secara otomatis menyesuaikan jumlah replika Pod pada sebuah Deployment, ReplicaSet, atau StatefulSet, berdasarkan metrik yang diamati—paling umum adalah penggunaan CPU, namun bisa juga memori, atau metrik kustom lain seperti jumlah request per detik.

Berbeda dengan Vertical Pod Autoscaler (VPA) yang menambah resource (CPU/memori) pada Pod yang sudah ada, HPA bekerja secara horizontal—menambah atau mengurangi jumlah Pod. Analoginya sederhana: jika VPA seperti memperbesar ukuran satu meja kasir agar bisa melayani lebih banyak transaksi, HPA seperti membuka lebih banyak konter kasir baru saat antrean memanjang, lalu menutupnya kembali saat sepi.

Bagaimana HPA Bekerja di Balik Layar

Secara garis besar, alur kerja HPA adalah sebagai berikut:

Pengumpulan metrik. HPA mengambil data penggunaan resource dari Metrics API. Untuk metrik CPU dan memori, data ini disediakan oleh komponen metrics-server yang harus terpasang di cluster. Untuk metrik kustom atau eksternal, HPA mengambil data melalui Custom Metrics API atau External Metrics API.
Perhitungan target replika. HPA controller memeriksa metrik ini secara periodik (default setiap 15 detik) dan menghitung jumlah replika ideal menggunakan rumus berikut: desiredReplicas = ceil( currentReplicas × ( currentMetricValue / desiredMetricValue ) ) Contoh: jika saat ini ada 4 Pod dengan rata-rata penggunaan CPU 80%, sementara target yang ditentukan adalah 50%, maka: desiredReplicas = ceil( 4 × (80 / 50) ) = ceil(6.4) = 7 HPA akan menambah jumlah Pod menjadi 7 agar rata-rata penggunaan CPU turun mendekati target 50%.
Penerapan perubahan. Setelah nilai target dihitung, HPA mengubah field replicas pada objek Deployment/ReplicaSet/StatefulSet yang menjadi targetnya. Kubernetes scheduler kemudian menjadwalkan Pod baru (saat scale up) atau menghentikan Pod (saat scale down).
Stabilization window. Untuk mencegah flapping (naik-turun replika terlalu cepat), HPA versi autoscaling/v2 menyediakan field behavior yang memungkinkan kita mengatur jeda waktu (stabilization window) dan batas kecepatan perubahan replika, baik saat scale up maupun scale down.

Contoh Kasus Nyata

Sebuah tim e-commerce menjalankan aplikasi checkout dengan 3 Pod dalam kondisi normal. Saat kampanye flash sale dimulai, trafik naik drastis dan penggunaan CPU rata-rata Pod melonjak dari 40% menjadi 95%. Berkat HPA yang dikonfigurasi dengan target CPU 60% dan maxReplicas: 20, dalam beberapa menit jumlah Pod otomatis bertambah menjadi 12–15 Pod, menjaga latensi checkout tetap stabil meski trafik melonjak lima kali lipat. Setelah flash sale selesai dan trafik kembali normal, HPA secara bertahap menurunkan jumlah Pod kembali ke kondisi baseline, sehingga biaya infrastruktur tidak membengkak.

Materi Praktis: Konfigurasi HPA

Prasyarat

Sebelum menerapkan HPA berbasis CPU/memori, pastikan:

metrics-server sudah terpasang di cluster (kubectl top pods harus bisa menampilkan data).
Setiap container pada Pod target memiliki resource requests untuk CPU (dan/atau memori) yang didefinisikan. Tanpa requests, HPA tidak bisa menghitung persentase utilisasi.

Contoh Konfigurasi HPA Lengkap (YAML)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 75
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

Penjelasan singkat konfigurasi di atas:

minReplicas dan maxReplicas membatasi rentang jumlah Pod agar tidak scale down ke nol atau scale up tanpa batas.
metrics di atas menggabungkan dua sinyal, CPU dan memori—HPA akan mengambil nilai replika terbesar dari hasil perhitungan tiap metrik.
behavior.scaleUp mempercepat respons saat beban naik (menambah maksimal 4 Pod per menit dengan jeda 30 detik).
behavior.scaleDown membuat proses penurunan lebih hati-hati (stabilization window 5 menit) agar tidak terlalu cepat menutup Pod saat trafik sempat turun sesaat.

Cara Cepat via `kubectl`

Untuk kebutuhan sederhana, HPA berbasis CPU juga bisa dibuat langsung lewat command line tanpa menulis YAML:

kubectl autoscale deployment web-app \
  --cpu-percent=60 \
  --min=3 \
  --max=20 \
  -n production

Untuk memantau status HPA secara real-time:

kubectl get hpa web-app-hpa -n production --watch

Kolom TARGETS pada output akan menunjukkan perbandingan nilai metrik aktual terhadap target, misalnya 72%/60%, yang berarti HPA sedang dalam proses menambah replika.

Tutorial Step-by-Step: Implementasi HPA dari Nol

Pastikan metrics-server terpasang. kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Tambahkan resource requests pada Deployment jika belum ada, misalnya cpu: 200m dan memory: 256Mi.
Deploy aplikasi menggunakan Deployment biasa.
Buat manifest HPA seperti contoh YAML di atas, lalu terapkan: kubectl apply -f web-app-hpa.yaml
Uji dengan load testing menggunakan tools seperti hey, k6, atau Apache Bench untuk mensimulasikan lonjakan trafik.
Pantau perilaku scaling dengan kubectl get hpa --watch dan kubectl get pods --watch secara bersamaan di dua terminal.
Evaluasi dan sesuaikan nilai target utilisasi serta behavior berdasarkan hasil observasi—apakah scaling terlalu agresif, terlalu lambat, atau sudah pas.

Kesalahan yang Sering Terjadi

1. Tidak mendefinisikan resource requests.

Penyebab: developer lupa atau menganggap tidak penting.
Dampak: HPA tidak bisa menghitung persentase utilisasi karena tidak ada baseline, sehingga status HPA menampilkan <unknown>.
Solusi: selalu definisikan resources.requests.cpu (dan memori jika relevan) pada setiap container.

2. metrics-server belum terpasang atau bermasalah.

Penyebab: cluster baru atau environment self-managed yang belum menyertakan komponen ini secara default.
Dampak: HPA tidak mendapat data metrik sama sekali.
Solusi: verifikasi dengan kubectl top pods; jika error, cek instalasi dan konfigurasi TLS pada metrics-server.

3. minReplicas dan maxReplicas terlalu sempit atau sama.

Penyebab: konfigurasi copy-paste tanpa disesuaikan.
Dampak: HPA praktis tidak berfungsi karena tidak ada ruang untuk scaling.
Solusi: tentukan rentang yang realistis sesuai kapasitas cluster dan pola trafik historis.

4. Target utilisasi terlalu tinggi atau terlalu rendah.

Penyebab: nilai target dipilih asal tanpa mempertimbangkan karakteristik aplikasi.
Dampak: target terlalu tinggi membuat scaling terlambat merespons lonjakan; target terlalu rendah membuat scaling terlalu sering terjadi (boros resource).
Solusi: lakukan load testing untuk menemukan titik utilisasi optimal, biasanya di kisaran 50–70%.

5. Mengabaikan efek flapping.

Penyebab: tidak mengatur behavior.scaleDown.stabilizationWindowSeconds.
Dampak: jumlah Pod naik-turun terus-menerus saat trafik fluktuatif, membebani scheduler dan mengganggu stabilitas.
Solusi: atur stabilization window yang lebih panjang untuk scale down dibanding scale up.

6. Menggunakan HPA dan VPA bersamaan pada metrik yang sama tanpa koordinasi.

Penyebab: mengira keduanya saling melengkapi tanpa memahami potensi konflik.
Dampak: kedua controller bisa saling “berebut” menyesuaikan resource, menyebabkan perilaku scaling yang tidak stabil.
Solusi: jika ingin menggabungkan keduanya, gunakan VPA dalam mode Off/rekomendasi saja untuk CPU, sementara HPA yang mengambil aksi scaling horizontal.

Tips dan Rekomendasi

Gunakan metrik kustom (misalnya jumlah request per detik via Prometheus Adapter) untuk aplikasi yang polanya tidak selalu berkorelasi linear dengan CPU, seperti aplikasi I/O-bound.
Kombinasikan HPA dengan Cluster Autoscaler agar node baru otomatis tersedia saat HPA membutuhkan kapasitas lebih dari yang tersedia di cluster.
Selalu uji perilaku HPA di lingkungan staging sebelum diterapkan ke production, khususnya untuk memvalidasi behavior.scaleUp dan scaleDown.
Pantau metrik HPA melalui dashboard seperti Grafana untuk melihat tren historis scaling dan mendeteksi anomali lebih awal.
Untuk workload dengan pola trafik yang sangat dapat diprediksi (misalnya jam kerja kantor), pertimbangkan kombinasi dengan scheduled scaling menggunakan CronJob atau tools tambahan seperti KEDA.

Kesimpulan

Horizontal Pod Autoscaler adalah salah satu fitur inti Kubernetes yang memungkinkan aplikasi tetap responsif secara otomatis saat trafik naik maupun turun, tanpa perlu campur tangan manual dari tim operasional. Dengan memahami cara kerja rumus perhitungan replika, menyiapkan metrics-server dengan benar, mendefinisikan resource requests, serta mengatur behavior scaling secara bijak, tim DevOps dapat membangun sistem yang efisien secara biaya sekaligus tangguh menghadapi lonjakan trafik mendadak.

Poin penting yang perlu diingat:

HPA menyesuaikan jumlah Pod, bukan ukuran resource satu Pod (itu tugas VPA).
Resource requests wajib didefinisikan agar HPA berfungsi.
Stabilization window mencegah flapping yang merugikan.
Kombinasi HPA dengan Cluster Autoscaler memberikan skalabilitas end-to-end.

Sudah pernah mencoba mengonfigurasi HPA di cluster Kubernetes Anda?

Bagikan pengalaman atau kendala yang Anda temui di kolom komentar di bawah! Jika artikel ini bermanfaat, jangan ragu untuk membagikannya ke rekan tim DevOps Anda, dan jelajahi juga artikel terkait lainnya seputar Kubernetes, Cluster Autoscaler, dan monitoring infrastruktur di website ini.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan utama antara HPA dan VPA di Kubernetes? Jawaban: HPA menambah atau mengurangi jumlah Pod (scaling horizontal), sedangkan VPA menyesuaikan alokasi CPU dan memori pada Pod yang sudah ada (scaling vertikal). Keduanya bisa saling melengkapi jika dikonfigurasi dengan hati-hati.

Pertanyaan: Apakah HPA bisa bekerja tanpa metrics-server? Jawaban: Untuk metrik CPU dan memori standar, metrics-server wajib terpasang. Namun untuk metrik kustom atau eksternal, HPA bisa menggunakan sumber lain seperti Prometheus Adapter melalui Custom Metrics API.

Pertanyaan: Berapa lama waktu yang dibutuhkan HPA untuk menambah Pod baru? Jawaban: Secara default HPA mengevaluasi metrik setiap 15 detik, namun waktu total hingga Pod baru benar-benar siap melayani trafik juga dipengaruhi oleh waktu startup container dan readiness probe.

Pertanyaan: Apakah HPA bisa digunakan pada StatefulSet? Jawaban: Ya, HPA mendukung scaling pada Deployment, ReplicaSet, maupun StatefulSet, selama scaleTargetRef diarahkan ke resource yang sesuai.

Pertanyaan: Bagaimana cara mencegah HPA melakukan scaling terlalu sering (flapping)? Jawaban: Gunakan field behavior pada autoscaling/v2 untuk mengatur stabilizationWindowSeconds, terutama pada proses scale down, agar perubahan jumlah Pod lebih terkendali.

Bagaimana pengalaman Anda menerapkan Horizontal Pod Autoscaler di cluster Kubernetes sendiri?

Tulis di kolom komentar, diskusikan tantangan yang Anda hadapi, dan bagikan artikel ini kepada rekan tim yang sedang belajar Kubernetes. Jangan lupa jelajahi artikel-artikel lain seputar DevOps, Cloud Computing, dan Infrastruktur IT di website ini, serta ikuti terus update konten terbaru agar tidak ketinggalan tips dan tutorial praktis lainnya!