Belajar Karpenter - Production-Ready Deployment

#Pendahuluan

Di episode 20 kalian sudah mengenal fitur terbaru Karpenter v1.14 dan cara mengupgradenya dengan aman. Fitur adalah bahan baku; production membutuhkan arsitektur. Episode ini merakit semua pengetahuan kalian menjadi deployment yang layak dipakai tim sungguhan.

Kita mulai dari arsitektur NodePool: memisahkan general, spot, dan GPU. Lalu budget yang ketat, integrasi HPA dan KEDA untuk skala pod dengan Karpenter untuk skala node, dan disaster recovery. Terakhir, cara mengelola semuanya lewat Helm, CI/CD, GitOps, dan monitoring.

#Arsitektur Multi-NodePool di Production

Satu NodePool untuk semua workload jarang menjadi pilihan terbaik. Kebutuhan berbeda — latency, biaya, dan hardware khusus — sebaiknya dipisah agar kebijakan disruption tidak saling menahan: general memakai on-demand untuk workload utama, spot untuk beban toleran interruption, dan gpu untuk workload yang benar-benar butuh akselerator.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m6i.xlarge", "m6i.2xlarge", "m6i.4xlarge"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    budgets:
      - nodes: "20%"

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      taints:
        - key: workload-type
          value: gpu
          effect: NoSchedule
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g4dn.xlarge", "g5.xlarge"]
  disruption:
    consolidationPolicy: WhenEmpty
    ttlSecondsAfterEmpty: 900

Workload GPU menambahkan toleration untuk taint workload-type: gpu. Dengan begitu hanya pod yang memang butuh GPU yang duduk di instance mahal, sementara workload biasa tetap berada di NodePool general.

#Budget yang Ketat

Di production, disruption harus dibatasi secara eksplisit. Budget ketat mencegah Karpenter membongkar terlalu banyak node dalam satu waktu dan menjaga kapasitas minimum kluster: batasi persentase node yang boleh diproses, batasi drift pada jam kerja, dan beri ruang lebih luas di akhir pekan untuk rotasi AMI.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted
        schedule: "0 9 * * mon-fri"
      - nodes: "50%"
        reasons:
          - Drifted

#HPA dan KEDA: Skala di Tingkat Pod

Karpenter mengatur node, bukan replika. Skala replika adalah tugas Horizontal Pod Autoscaler dan KEDA. HPA menambah replika berdasarkan metrik seperti CPU dan memori; KEDA memperluasnya ke metrik event-driven — panjang antrian SQS, lag konsumen Kafka, atau jumlah pesan di queue.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Keda memakai ScaledObject yang menunjuk ke sumber event. Replika bertambah ketika antrian menumpuk dan menyusut ketika antrian kosong — jauh lebih responsif dibanding menunggu CPU naik.

#Integrasi HPA dan Karpenter

Kedua mekanisme bekerja dalam satu loop yang saling melengkapi. Ketika trafik naik, HPA menambah replika. Pod baru mungkin tidak muat di node yang ada, sehingga Karpenter membuat NodeClaim baru. Ketika trafik turun, HPA memangkas replika, node menjadi kosong, dan konsolidasi membongkarnya.

Agar loop ini sehat, tetapkan request resource yang realistis agar perhitungan HPA dan binpacking akurat, beri batas maxReplicas yang masuk akal, dan pantau karpenter_pods_startup_duration_seconds — latensi end-to-end dari pod pending sampai running.

#Disaster Recovery

Karpenter sendiri tidak menyimpan data — ia merekonstruksi state dari kluster. DR Karpenter berpusat pada dua hal: kemampuan kluster dipulihkan, dan manifest yang menciptakannya kembali. Simpan semua NodePool dan EC2NodeClass di Git, backup state kluster dengan tool seperti Velero untuk workload stateful, dan verifikasi berkala bahwa kluster baru di region cadangan bisa menciptakan node dari NodePool yang sama.

#Versi Helm dan Upgrade yang Aman

Manajemen versi dimulai dari Helm. Karpenter dirilis sebagai chart OCI di registry public.ecr.aws/karpenter/karpenter. Pasan versi secara eksplisit dan jangan pernah memakai tag terbaru di production.

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version v1.14.0 \
  --namespace karpenter --create-namespace \
  --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::123456789012:role/KarpenterControllerRole \
  --wait

Prosedur upgrade: baca upgrade guide dan catatan rilis, uji di staging, periksa apiVersion CRD yang dipakai manifest, lalu upgrade dengan --wait dan pantau kondisi pods serta NodeClaim.

#CI/CD dan GitOps

NodePool dan EC2NodeClass sebaiknya tidak diterapkan manual. Dengan GitOps, Git menjadi satu-satunya sumber kebenaran. Argo CD atau Flux menyinkronkan perubahan ke kluster secara otomatis: perubahan lewat pull request, pipeline menjalankan validasi dan dry-run ke staging, lalu promote ke production — semuanya tercatat di history Git untuk audit dan rollback instan.

#Monitoring Berkelanjutan

Monitoring production bukan hanya melihat dashboard, melainkan menetapkan alarm. Karpenter mengekspos metrik di endpoint /metrics, dan Grafana menyediakan dashboard resmi. Alarm yang paling bernilai: karpenter_cloudprovider_errors_total naik menandakan API cloud bermasalah, karpenter_pods_startup_duration_seconds membengkak menandakan provisioning melambat, dan NodeClaim yang gagal berulang kali menandakan konfigurasi atau kuota bermasalah.

Cek rutin kondisi kluster dengan kubectl get nodeclaims -o yaml dan kubectl logs -n karpenter deploy/karpenter --tail=100. Dengan alarm yang tepat, masalah terdeteksi sebelum pengguna merasakan dampaknya.

#Penutup

Production-ready adalah sikap, bukan satu konfigurasi: memisahkan beban kerja, membatasi risiko, mengotomasi perubahan, dan memantau hasilnya.

Inti yang harus dibawa pulang:

• Pisahkan NodePool: general, spot, dan GPU dengan taint serta toleration menjaga biaya dan stabilitas.
• Budget ketat melindungi kluster: batasi persentase dan alasan disruption, sesuaikan dengan pengamatan.
• HPA, KEDA, dan Karpenter bekerja bersama: skala pod memicu skala node; requests yang realistis menjaga loop tetap akurat.
• GitOps dan versi Helm adalah fondasi: versi eksplisit, review, dan sinkronisasi otomatis membuat perubahan terukur dan bisa diputar balik.
• Monitoring tanpa alarm hanyalah dashboard: alarm pada cloudprovider error dan latency provisioning memperingatkan sebelum dampak terasa.

Kalian kini memiliki seluruh keahlian untuk mengoperasikan Karpenter di production. Di episode terakhir kita melihat peta lengkapnya: membandingkan Karpenter dengan Cluster Autoscaler, Cast AI, KubeFin, dan solusi platform-cost, merangkum perjalanan episode 0 sampai 21, serta menutup dengan checklist dan arah masa depan. Sampai jumpa di episode pamungkas!