Kubernetes Autoscaling Strategies untuk Cost Optimization: Panduan Lengkap 2026

Konfigurasi Cluster Autoscaler untuk Efisiensi Biaya

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: cluster-autoscaler
        command:
        - ./cluster-autoscaler
        - --scale-down-utilization-threshold=0.5
        - --scale-down-unneeded-time=5m
        - --scale-down-delay-after-add=10m
        - --max-graceful-termination-sec=600
        - --skip-nodes-with-local-storage=false
        - --expander=least-waste

Parameter penting untuk cost optimization:

• scale-down-utilization-threshold: 0.5 — Node akan dianggap underutilized jika utilisasi di bawah 50%, memungkinkan penghapusan node yang tidak efisien
• scale-down-unneeded-time: 5m — Node harus underutilized selama 5 menit sebelum dihapus, mencegah penghapusan yang terlalu agresif
• expander: least-waste — Memilih node group yang paling efisien (paling sedikit waste resource) saat melakukan scale up

KEDA: Autoscaling Berbasis Event

KEDA (Kubernetes Event-driven Autoscaling) adalah tool autoscaling yang dirancang untuk skenario di mana scaling tidak bergantung pada CPU atau memory, melainkan pada event atau metric eksternal seperti queue depth, Kafka lag, atau schedule tertentu. KEDA sangat penting untuk workloads yang memiliki pola traffic tidak terprediksi atau event-driven.

Kapan Menggunakan KEDA?

KEDA sangat cocok untuk berbagai skenario yang tidak bisa ditangani oleh HPA konvensional:

• Queue-based workloads — Message queue (RabbitMQ, SQS, Redis Streams) yang perlu diproses sesuai kedalaman antrian
• Event-driven architectures — Kafka consumers, event processors yang harus merespons event masuk
• Scheduled scaling — Batch jobs yang hanya berjalan pada waktu tertentu, menghemat biaya di luar jam operasional
• Scale-to-zero — Workloads yang tidak selalu aktif, menghemat biaya komputasi saat tidak ada request yang harus diproses

Contoh KEDA ScaledObject untuk RabbitMQ

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      host: amqp://rabbitmq.default.svc:5672
      queueLength: "5"
  - type: cron
    metadata:
      timezone: Asia/Jakarta
      start: 0 8 * * 1-5
      end: 0 17 * * 1-5
      desiredReplicas: "3"

Dengan konfigurasi di atas, consumer hanya aktif saat ada pesan di queue atau pada jam kerja (08:00-17:00 WIB). Di luar waktu tersebut, pod akan scale to zero dan tidak mengonsumsi biaya compute sama sekali. Pendekatan ini sangat efektif untuk batch processing atau workloads yang tidak memerlukan ketersediaan 24/7.

Karpenter: Node Provisioning yang Lebih Cerdas

Karpenter adalah node provisioner yang lebih fleksibel dibandingkan Cluster Autoscaler. Karpenter langsung memesan compute capacity (instance) dari cloud provider berdasarkan kebutuhan pod, tanpa harus melalui node group yang sudah didefinisikan sebelumnya. Arsitektur ini memberikan kontrol lebih granular terhadap jenis instance dan strategi penghematan biaya.

Perbedaan Karpenter vs Cluster Autoscaler

Konfigurasi Karpenter untuk Cost Optimization

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.k8s.instance.capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s/instance-size
        operator: In
        values: ["medium", "large", "xlarge"]
  limits:
    cpu: 100
    memory: 200Gi
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 60s

Strategi cost optimization dengan Karpenter:

• Spot instances — Menggunakan spot instances yang harganya 60-90% lebih murah dari on-demand, sangat efektif untuk workloads fault-tolerant
• Consolidation — Secara otomatis menggabungkan pod ke node yang lebih sedikit dan menghapus node yang tidak terpakai, mengurangi biaya idle capacity
• Right-sizing instances — Karpenter memilih tipe instance yang paling efisien berdasarkan kebutuhan pod aktual, menghindari over-provisioning di level node

Strategi Kombinasi Autoscaling untuk Optimalisasi Biaya

Untuk hasil terbaik, gunakan kombinasi beberapa autoscaler yang saling melengkapi. Setiap kombinasi memiliki karakteristik tersendiri dan cocok untuk jenis workloads tertentu. Berikut adalah strategi kombinasi yang efektif berdasarkan pengalaman produksi di berbagai organisasi cloud-native.

Strategi 1: HPA + VPA (Right-Sizing + Horizontal Scaling)

Kombinasi ini memastikan setiap pod memiliki resource yang tepat (VPA) dan jumlah replika yang sesuai dengan load (HPA). VPA berjalan dalam mode "Off" atau "Initial" untuk menghindari konflik dengan HPA. Pendekatan ini ideal untuk stateless microservices yang memiliki pola traffic prediktif tetapi memerlukan resource yang tepat sasaran.

Strategi 2: HPA + KEDA (Reactive + Event-Driven)

Untuk workloads yang memiliki dua jenis scaling signal: traffic HTTP (HPA) dan queue depth (KEDA). Keduanya bisa berjalan bersama tanpa konflik karena menangani dimensi scaling yang berbeda. Kombinasi ini sangat cocok untuk arsitektur microservices yang melayani both synchronous API requests dan asynchronous message processing.

Strategi 3: Karpenter + VPA (Node Efficiency + Pod Right-Sizing)

Karpenter memastikan node yang dipilih paling efisien, sementara VPA memastikan pod menggunakan resource node tersebut secara optimal. Kombinasi ini bisa menghemat 40-60% biaya compute karena mengoptimasi dari level node hingga level pod secara bersamaan.

Strategi 4: Full Stack (HPA + VPA + Karpenter + KEDA)

Untuk arsitektur microservices kompleks, semua autoscaler bisa berjalan bersama dengan pembagian tanggung jawab yang jelas. Pastikan tidak ada konflik antar autoscaler dengan mengikuti prinsip "one tool per dimension" — satu tool untuk setiap dimensi scaling yang berbeda.

Best Practices untuk Cost Optimization

1. Monitor dan Analisis Utilisasi — Gunakan tools seperti Prometheus + Grafana untuk memantau pola resource utilization sebelum mengonfigurasi autoscaling. Tanpa data yang akurat, autoscaling hanya menambah kompleksitas tanpa manfaat biaya yang signifikan
2. Set Resource Requests yang Tepat — Gunakan VPA rekomendasi sebagai baseline untuk resource requests. Jangan over-provision berdasarkan perkiraan — gunakan data historis untuk membuat keputusan yang terukur
3. Konfigurasi Scale-Down yang Agresif — Pastikan aplikasi bisa handle scale down tanpa downtime. Gunakan PDB (PodDisruptionBudget) untuk menjaga availability selama proses pengurangan pod
4. Manfaatkan Spot Instances — Untuk workloads yang fault-tolerant, spot instances bisa mengurangi biaya hingga 90%. Pastikan aplikasi memiliki graceful shutdown handling dan retry mechanism yang proper
5. Implementasi Cluster Autoscaler atau Karpenter — Pastikan node yang tidak terpakai dihapus otomatis untuk menghindari pembayaran resource idle yang tidak diperlukan
6. Gunakan Namespace-Based Resource Quotas — Batasi penggunaan resource per namespace untuk mencegah runaway costs pada environment yang shared
7. Regular Right-Sizing Reviews — Jalankan VPA dalam mode recommendation secara berkala dan update resource requests berdasarkan data aktual, bukan asumsi awal saat deployment pertama

Studi Kasus: Penghematan Biaya dengan Autoscaling

Sebuah perusahaan SaaS dengan 50 microservices di GKE mengalami biaya cloud $45,000/bulan. Setelah implementasi strategi autoscaling yang komprehensif, mereka berhasil mencapai penghematan signifikan:

Tiga perubahan utama yang dilakukan:

1. Mengimplementasikan HPA dengan target CPU 60% dan scale-down agresif (300 detik stabilization window) untuk merespons perubahan traffic secara real-time
2. Menjalankan VPA dalam mode recommendation untuk right-sizing semua service (rata-rata reduksi 40% resource requests) yang mengeliminasi over-provisioning
3. Mengganti node group on-demand dengan Karpenter yang menggunakan 70% spot instances untuk workload production yang telah dikonfigurasi dengan graceful shutdown

Hasil ini menunjukkan bahwa autoscaling bukan hanya tentang mengurangi biaya, tetapi juga tentang meningkatkan efisiensi operasional secara keseluruhan. Tim tidak lagi perlu melakukan capacity planning manual atau emergency scaling saat traffic spike.

Kesimpulan

Kubernetes autoscaling bukan sekadar fitur yang diaktifkan dengan konfigurasi default. Dengan memahami peran masing-masing autoscaler — HPA untuk jumlah replika, VPA untuk right-sizing, Cluster Autoscaler/Karpenter untuk node provisioning, dan KEDA untuk event-driven scaling — Anda dapat membangun arsitektur yang efisien secara biaya dan resilient terhadap perubahan traffic.

Kunci utama cost optimization adalah: mulai dari monitoring untuk memahami pola aktual, lalu right-sizing untuk memastikan resource yang dialokasikan sesuai kebutuhan, baru kemudian autoscaling untuk elastisitas. Tanpa data yang akurat tentang pola utilisasi aktual, autoscaling hanya akan membuat infrastruktur Anda lebih kompleks tanpa memberikan penghematan biaya yang signifikan.

Mulai dengan mengimplementasikan satu autoscaler pada satu waktu, ukur dampaknya terhadap biaya dan performa, lalu tambahkan autoscaler lain secara bertahap. Dengan pendekatan yang terukur, penghematan biaya 40-60% bukanlah hal yang mustahil untuk dicapai dalam implementasi Kubernetes di production environment. Jika Anda tertarik dengan topik cloud infrastructure lainnya, baca juga AI Agent Memory Systems: RAG vs Long-Term Memory vs Hybrid untuk memahami bagaimana sistem memori modern dirancang.

FAQ

Bagaimana cara memulai implementasi autoscaling di Kubernetes?

Mulai dengan memasang metrics server, lalu implementasikan HPA untuk service yang paling kritis. Setelah stabil, tambahkan VPA dalam mode recommendation untuk analisis right-sizing, kemudian pertimbangkan Cluster Autoscaler atau Karpenter untuk node-level scaling. Pastikan Anda memahami pola traffic sebelum mengonfigurasi threshold yang agresif.

Apakah KEDA menggantikan HPA?

Tidak, KEDA dan HPA menangani dimensi scaling yang berbeda. HPA fokus pada CPU/memory utilization, sementara KEDA menangani event-driven scaling seperti queue depth atau schedule. Keduanya bisa berjalan bersama tanpa konflik karena masing-masing memiliki domain tanggung jawab yang terpisah dan saling melengkapi.

Spot instances aman digunakan di production?

Ya, dengan konfigurasi yang tepat. Gunakan PodDisruptionBudget untuk memastikan availability, konfigurasi fallback ke on-demand jika spot terminated, dan pastikan aplikasi bisa handle graceful shutdown dalam waktu yang ditentukan cloud provider (biasanya 2 menit untuk AWS, 30 detik untuk GCP).

Bagaimana mencegah thrashing pada autoscaling?

Gunakan stabilizationWindowSeconds yang cukup besar untuk scale-down (minimal 300 detik), set maximum surge dan maximum unavailable yang terbatas, dan implementasikan cooldown period yang sesuai untuk aplikasi Anda. Monitoring yang baik juga penting untuk mendeteksi pola scaling yang tidak normal.

Seberapa sering harus melakukan right-sizing review?

Minimal sebulan sekali untuk workloads dengan pola traffic stabil, atau mingguan untuk workloads yang sering berubah. Gunakan VPA dalam mode "Off" untuk mendapatkan rekomendasi tanpa mengubah pod secara otomatis, sehingga Anda bisa meninjau dan menyetujui perubahan sebelum diterapkan ke production.

Sumber dan Referensi

• Kubernetes Documentation: Horizontal Pod Autoscaler — Dokumentasi resmi HPA dari Kubernetes project
• Kubernetes Cluster Autoscaler GitHub — Repository resmi Cluster Autoscaler dengan contoh konfigurasi
• KEDA Documentation — Dokumentasi lengkap KEDA untuk event-driven autoscaling
• Karpenter Documentation — Panduan konfigurasi Karpenter untuk node provisioning
• Kubernetes Autoscaling Guide by Atmosly — Panduan komprehensif HPA, VPA, dan Cluster Autoscaler