Panduan Lengkap Mengenai HPA v2

Dalam ekosistem komputasi awan modern, khususnya yang berbasis pada orkestrasi kontainer seperti Kubernetes, manajemen beban kerja dinamis adalah kunci utama untuk efisiensi biaya dan keandalan performa. Salah satu mekanisme paling penting untuk mencapai hal ini adalah Horizontal Pod Autoscaler (HPA). Artikel ini akan fokus mendalami versi kedua dari mekanisme ini, yaitu HPA v2, yang menawarkan fleksibilitas dan kapabilitas pemantauan yang jauh lebih unggul dibandingkan pendahulunya.

Apa yang Membuat HPA v2 Berbeda?

HPA (Horizontal Pod Autoscaler) adalah sumber daya Kubernetes yang dirancang untuk secara otomatis meningkatkan atau menurunkan jumlah replika Pod dalam Deployment, ReplicaSet, atau StatefulSet berdasarkan metrik yang teramati. Versi 1 (HPA v1) hanya mendukung penskalaan berbasis pemanfaatan CPU atau memori. Namun, kebutuhan aplikasi modern seringkali melampaui dua metrik dasar tersebut. Di sinilah HPA v2 mengambil peran sentral.

Perbedaan paling signifikan antara HPA v1 dan HPA v2 terletak pada dukungan metrik yang diperluas. HPA v2 memungkinkan pengguna untuk menentukan skala berdasarkan:

• Metrik berbasis CPU/Memori (seperti v1): Persentase penggunaan sumber daya.
• Metrik Objek (Object Metrics): Metrik yang terkait dengan objek Kubernetes tertentu (misalnya, panjang antrian pada Service Queue).
• Metrik Eksternal (External Metrics): Metrik apa pun yang berasal dari sumber eksternal, seperti sistem pemantauan pihak ketiga (Prometheus, Datadog, dll.), selama metrik tersebut dapat diakses oleh Metrics Server API yang diperluas.

Implementasi Metrik Kustom dengan HPA v2

Untuk memanfaatkan metrik kustom atau eksternal, kluster Kubernetes Anda memerlukan implementasi yang mendukung API metrik yang diperluas (Custom Metrics API dan External Metrics API). Biasanya, ini dicapai dengan menginstal Metrics Server yang telah dikonfigurasi untuk berkomunikasi dengan agregator metrik yang lebih canggih, seperti Prometheus Adapter.

Dalam spesifikasi YAML untuk HPA v2, bagian metrics menjadi jauh lebih kaya. Anda dapat mendefinisikan target rata-rata dari metrik tersebut. Sebagai contoh, jika aplikasi Anda adalah sistem antrian pesan, Anda mungkin ingin mempertahankan rata-rata 10 pesan per detik per Pod. HPA v2 akan secara aktif memantau metrik "pesan per detik" dan menyesuaikan jumlah Pod untuk mencapai target tersebut. Hal ini menghasilkan respons penskalaan yang jauh lebih akurat dan spesifik terhadap perilaku aplikasi sebenarnya, bukan sekadar beban CPU yang bersifat umum.

Stabilisasi dan Perilaku Penskalaan

HPA v2 juga memperkenalkan peningkatan signifikan dalam hal stabilitas penskalaan melalui pengaturan behavior. Salah satu masalah umum pada penskalaan otomatis adalah volatilitas yang tinggi (flapping)—di mana jumlah replika sering naik turun secara drastis karena fluktuasi metrik sesaat.

Dengan behavior, administrator dapat menetapkan:

1. Scale-Up Stabilization Window (atau Cooldown): Periode waktu di mana HPA tidak akan meningkatkan jumlah Pod, meskipun metrik sudah melebihi target. Ini mencegah lonjakan respons yang berlebihan.
2. Scale-Down Stabilization Window (atau Grace Period): Periode waktu tunggu sebelum HPA mengizinkan pengurangan jumlah Pod. Ini memberikan waktu bagi sistem untuk memastikan bahwa penurunan beban adalah tren berkelanjutan, bukan hanya penurunan sementara.

Pengaturan perilaku ini krusial untuk lingkungan produksi di mana perubahan replika yang terlalu cepat dapat menyebabkan latensi atau kegagalan layanan yang tidak perlu.

Perbandingan Konfigurasi (Ringkasan)

Jika HPA v1 hanya memiliki targetCPUUtilizationPercentage, HPA v2 menggunakan struktur metrics yang kompleks dan mendukung beberapa target sekaligus. Anda bisa menargetkan CPU pada 60% dan Antrian Pesan pada 10 pesan/detik secara bersamaan. HPA v2 kemudian akan menghitung seberapa banyak penskalaan diperlukan untuk memenuhi target TERKETAT (yang membutuhkan penskalaan terbesar).

Secara kesimpulan, adopsi HPA v2 adalah langkah penting dalam mengoptimalkan operasional kontainer di Kubernetes. Kemampuan untuk merespons metrik yang kaya dan mengelola perilaku penskalaan dengan lebih halus memungkinkan DevOps dan tim SRE untuk mencapai keseimbangan optimal antara ketersediaan layanan dan efisiensi pemanfaatan sumber daya kluster. Ini adalah fitur inti bagi aplikasi yang membutuhkan ketangguhan dan responsivitas tinggi di lingkungan cloud-native.