Belajar GitOps dengan ArgoCD - Cost Optimization

#Pendahuluan

Di episode 32 sebelumnya organisasi sudah tersusun. Sekarang pertanyaan yang tidak bisa dihindari di setiap organisasi nyata: berapa biayanya? Biaya cloud tumbuh mengikuti cluster, dan cluster mengikuti aplikasi — dan tanpa disiplin, tagihan menjadi kejutan. Di dunia GitOps ada kabar baik: semua keputusan resource ada di Git, jadi optimasi biaya bisa di-review seperti perubahan kode biasa.

Episode ini membahas cost optimization dari tiga sudut: resource aplikasi, cluster, dan GitOps itu sendiri — lalu cara memantau dan mengalokasikan biaya. Ingat prinsip episode 25: ukur dulu, ubah satu hal, ukur lagi.

#Optimasi Resource

#Right-Sizing Aplikasi

Pemborosan terbesar biasanya bukan aplikasi yang kekurangan resource, melainkan yang meminta jauh di atas kebutuhan. Pod yang meminta 4 vCPU tetapi memakai 0.3 vCPU membuang ruang dan uang. Data dari kubectl top dan metrik pemakaian menunjukkan ketidaksesuaian request vs utilization:

kubectl top pods -n api --sort-by=cpu
kubectl top pods -n api --sort-by=memory
kubectl describe pod api-5d4b6c7d9-8xk2m -n api

Target yang sehat: pemanfaatan request CPU sekitar 60-80 persen dari rata-rata. Di bawah itu, kecilkan request; terus-menerus di atas 90 persen, perbesar.

#Requests dan Limits

Requests menentukan penjadwalan dan kuota; limits menentukan perlindungan dari throttling/OOM. Praktik baik: request yang realistis (dari pengukuran), limit yang melindungi (tidak membiarkan satu pod mengambil semuanya). Gunakan kuota namespace (episode 28) agar request yang boros tidak bisa menyebar.

#HPA dan VPA

• HPA (Horizontal) menambah/mengurangi replika berdasarkan metrik — efisien untuk beban yang berubah-ubah. Kombinasi HPA + request yang tepat menjaga klaster ramping saat sepi.
• VPA (Vertical) merekomendasikan request yang tepat berdasarkan pemakaian historis. Gunakan VPA dalam mode Recommender dulu — biarkan ia memberi saran, lalu terapkan secara manual (mode Auto bisa mengejutkan jika langsung dipakai).

VPA sebagai recommender

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
  namespace: api
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updateMode: "Off"

#Optimasi Cluster

#Node Pool Strategy

Cluster dengan satu node pool homogeneous membuang uang untuk workload yang tidak cocok. Pisahkan:

• Node pool umum — beban standar, on-demand.
• Node pool spot — beban yang tahan interupsi (batch, worker, non-kritis).
• Node pool burst — untuk lonjakan.

#Spot Instances

Spot instance bisa menghemat 60-90 persen biaya compute — dengan syarat workload tahan eviction. Di Kubernetes, spot node harus diberi label dan aplikasi yang memakainya harus sanggup restart: Deployment multi-replika dengan topologySpreadConstraints, disruptionBudget, dan state di luar pod (database tetap di node on-demand).

Pod anti-affinity untuk spot node

spec:
  template:
    spec:
      nodeSelector:
        node.kubernetes.io/lifecycle: spot
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname

#Cluster Autoscaling

Cluster autoscaler menambah node saat pod Pending karena resource, dan menghapus node yang menganggur. Ini jaring pengaman yang membuat optimasi aman: request yang terlalu kecil tidak lagi menyebabkan outage karena cluster menyesuaikan. Pasangkan dengan HPA untuk hasil terbaik: HPA mengatur replika, autoscaler mengatur node.

#Efisiensi Multi-Tenancy

Satu cluster multi-tenant (episode 28) lebih murah daripada banyak cluster kecil: node idle terisi workload lain. Kerugiannya adalah kompleksitas isolasi — trade-off yang harus dihitung per organisasi, bukan diasumsikan.

#Efisiensi GitOps Itu Sendiri

ArgoCD juga menelan resource. Optimasinya (episode 25) adalah optimasi biaya:

• Sync frequency tuning — reconcile tiap 3 menit untuk semua aplikasi boros. Aplikasi non-kritis bisa 10-30 menit. Lebih jarang reconcile = lebih sedikit CPU controller.
• Repository size optimization — repo besar membuat kloning berat. Pisahkan manifest yang jarang berubah, pakai shallow clone (--depth 1).
• Cache optimization — Redis cache mencegah re-render manifest berulang; pastikan TTL tidak terlalu pendek untuk repo yang jarang berubah.
• Network efficiency — webhook (episode 30) menggantikan polling; batasi concurrency Git (ARGOCD_GIT_CONCURRENCY) agar repo server tidak over-provisioned.

Reconcile jarang untuk aplikasi non-kritis

metadata:
  annotations:
    argocd.argoproj.io/reconcile-period: 20m
spec:
  ...

#Monitoring Biaya

Biaya yang tidak diukur tidak bisa dioptimalkan. Empat lapis monitoring:

#Cost Allocation Tags

Label resource adalah dasar semuanya — sejak awal (episode 28): team=, environment=, tenant=, app=. Cloud provider membaca label ini untuk laporan biaya. Label yang tidak disiplin = biaya yang tidak bisa diatribusikan.

#Usage Tracking

Integrasikan metrik Kubernetes dengan data biaya. Tools seperti OpenCost membaca resource request dan pemakaian aktual, lalu menghitung biaya per namespace/deployment dari harga provider. Kombinasikan dengan metrik ArgoCD (episode 22) untuk melihat biaya per aplikasi.

#Chargeback vs Showback

• Chargeback — tagihan nyata ke unit bisnis; mendorong akuntabilitas, tetapi butuh data akurat dan bisa memicu politik.
• Showback — laporan pemakaian tanpa tagihan; cukup untuk mengubah perilaku dan lebih mudah dimulai. Mulai dari showback, naik ke chargeback saat data sudah dipercaya.

#Cost Anomaly Detection

Anomali biaya biasanya pertanda masalah: aplikasi yang stuck CrashLoopBackOff (restart terus = compute terbuang), node pool yang tidak pernah menyusut, atau sync yang menggila. Alert sederhana bisa menyelamatkan ribuan dolar:

groups:
  - name: cost
    rules:
      - alert: DailyCostSpike
        expr: sum(increase(cost_daily[1d])) / sum(increase(cost_daily[7d])) > 1.5

#Penutup

Episode ini memetakan optimasi biaya: right-sizing aplikasi dengan data pemakaian nyata, request/limit yang disiplin, HPA dan VPA, strategi node pool dengan spot instance dan cluster autoscaling, efisiensi multi-tenancy, efisiensi GitOps melalui tuning sync frequency, ukuran repo, cache, dan jaringan, serta monitoring biaya dengan cost allocation tags, usage tracking, showback/chargeback, dan deteksi anomali.

Poin yang harus kalian bawa:

• Ukur utilization dulu; right-sizing di bawah 60 persen adalah pemborosan.
• VPA Recommender memberi saran; terapkan setelah diverifikasi.
• Spot instance hemat besar, tetapi hanya untuk workload yang tahan interupsi.
• Optimasi GitOps (sync frequency, cache) adalah optimasi biaya yang halus tapi nyata.
• Label yang disiplin sejak awal membuat seluruh monitoring biaya mungkin.

Biaya sudah terkendali. Saatnya memastikan semua siap sebelum benar-benar meluncur ke produksi. Di episode 34 selanjutnya kita membahas production deployment checklist — checklist pra-produksi, praktik operasional, jebakan umum, dan operasi hari-ke-dua. Sampai jumpa di episode 34!