Belajar Karpenter - Best Practice & FinOps

#Pendahuluan

Di episode 14 kalian sudah mengamankan Karpenter dengan IAM minimal dan isolasi NodePool. Namun infrastruktur yang aman dan lancar bisa tetap boros. Di cloud, kecepatan provisioning Karpenter justru membuka peluang pemborosan baru: node dibuat terlalu cepat, dihapus terlalu lambat, atau instance family yang mahal dipakai untuk workload yang seharusnya bisa duduk di instance yang jauh lebih murah.

Episode ini menggabungkan dua hal: best practice kapasitas dan FinOps. Kalian akan belajar menyusun NodePool produksi dengan penyebaran multi-AZ, memanfaatkan kombinasi Spot dan On-Demand, menyelaraskan pembelian Reserved Instance dan Savings Plans, lalu mengukur dampak finansial Karpenter dengan alokasi biaya berbasis tag dan perbandingan sebelum-sesudah.

#Best Practice Multi-AZ

Jangan memusatkan workload di satu Availability Zone. Single AZ menciptakan dua masalah: risiko ketersediaan saat AZ terganggu, dan kapasitas yang sering kehabisan. Karpenter memilih AZ berdasarkan binpacking dan biaya, tetapi kalian harus memastikan semua AZ yang diinginkan tersedia sebagai kandidat.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - ap-southeast-1a
            - ap-southeast-1b
            - ap-southeast-1c
  disruption:
    consolidationPolicy: WhenUnderutilized

Perhatikan bahwa zone ap-southeast-1c mungkin memiliki kapasitas berbeda dari zone lain. Biarkan Karpenter memutuskan distribusi berdasarkan ketersediaan aktual, tetapi tetap sediakan tiga opsi agar kegagalan satu zone tidak menghentikan provisioning.

#Kombinasi Spot dan On-Demand

Spot bisa menghemat 60-90 persen dari harga on-demand, tetapi instance bisa dihentikan dengan notifikasi pendek. Strategi yang umum: workload stateless dan dapat di-interupsi duduk di Spot, sedangkan workload stateful dan kritis duduk di On-Demand. Karpenter memodelkan ini lewat capacity types di NodePool.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: hybrid
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

Jika nilai kapasitas di NodePool memuat spot dan on-demand, Karpenter tetap memprioritaskan Spot saat tersedia dan otomatis beralih ke on-demand saat kapasitas Spot kosong. Workload yang tidak boleh terganggu bisa dipisahkan ke NodePool on-demand saja, dengan taint dan toleration seperti pelajaran episode 14.

#Alignment dengan Reserved Instance dan Savings Plans

Diskon yang didapat dari Reserved Instance dan Savings Plans hanya berlaku jika instance yang kalian beli benar-benar dipakai. Karpenter tidak otomatis tahu pembelian komitmen kalian, sehingga ada risiko: instance dibeli untuk tipe m5.large, tetapi Karpenter memilih m5.xlarge dan diskon tidak tersentuh.

Pendekatan praktis untuk alignment:

• Identifikasi tipe instance yang stabil dan mendominasi beban kerja kalian.
• Beli Savings Plan EC2 Instance Family untuk fleksibilitas antar instance type.
• Batasi NodePool general ke family yang masuk dalam komitmen kalian, misalnya lewat node.kubernetes.io/instance-family.
• Tambahkan requirement instance size sebagai preferensi, bukan harga mati.

spec:
  template:
    spec:
      requirements:
        - key: node.kubernetes.io/instance-family
          operator: In
          values: ["m5", "m6i"]

#FinOps: Alokasi Biaya Berbasis Tag

Tag adalah kunci FinOps di AWS. Setiap node yang dibuat Karpenter bisa di-tag otomatis berdasarkan NodePool dan workload, lalu biaya dikelompokkan di Cost Explorer dan Cost and Usage Report. Pastikan tagging diaktifkan sejak awal, karena mengubah setelah node lama hilang berarti kehilangan data historis.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  tags:
    Project: my-platform
    Owner: platform-team
    CostCenter: 12345

Gabungkan tag statis di NodeClass dengan tag dinamis: eksportir biaya seperti Kubernetes Cost Allocation mengelompokkan biaya node ke namespace dan workload yang memakainya. Dengan begitu kalian bisa menjawab pertanyaan sederhana: aplikasi mana yang paling mahal dijalankan.

#Monitoring Konsolidasi untuk Penghematan

Konsolidasi adalah mesin penghematan Karpenter, dan harus dipantau untuk memastikan ia benar-benar bekerja. Metrik karpenter_consolidation_pods_evicted_total dan karpenter_consolidation_seconds_since_last dari episode 12 menjadi dasar laporan FinOps berkala.

# Rata-rata jumlah node sebelum dan sesudah konsolidasi
avg(karpenter_nodes_allocatable{resource="cpu"}) /
  sum(karpenter_nodes_allocatable{resource="cpu"})
 
# Lama waktu satu daur konsolidasi
histogram_quantile(0.95, rate(karpenter_consolidation_duration_seconds_bucket[5m]))

#Perbandingan Biaya Sebelum dan Sesudah

Untuk memvalidasi Karpenter, bandingkan biaya sebelum dan sesudah migrasi dalam periode yang setara. Lakukan dengan metodologi yang jujur: periode yang sama panjang, workload yang sebanding, dan tidak ada perubahan harga publik di antara keduanya.

#Penutup

Kapasitas yang optimal dan biaya yang terkendali adalah dua sisi mata uang yang sama dalam mengoperasikan Karpenter.

Inti yang harus dibawa pulang:

• Sebar multi-AZ: sediakan tiga AZ sebagai kandidat dan biarkan Karpenter memilih berdasarkan kapasitas dan biaya aktual.
• Spot dan On-Demand berbagi peran: stateless di Spot, kritis di On-Demand, dengan failover otomatis saat kapasitas Spot habis.
• Selaraskan komitmen: batasi family instance sesuai Reserved Instance dan Savings Plans, tanpa memaksakan satu tipe ke semua workload.
• Tag sejak awal: alokasi biaya per workload bergantung pada tag NodeClass yang konsisten dan ekspor biaya yang aktif.
• Ukur sebelum-sesudah secara adil: bandingkan biaya per unit workload dengan periode yang setara, bukan sekadar total bulanan.

Best practice dan FinOps membuat Karpenter menghemat biaya secara terukur. Tapi banyak tim masih berjalan dengan Cluster Autoscaler lama. Di episode 16 kita membahas Migrasi dari Cluster Autoscaler — kapan harus mengganti, strategi bertahap dengan coexistence, konversi nodegroup menjadi NodePool, perbedaan perilaku, dan pengelolaan downtime. Sampai jumpa!