Belajar Karpenter - Fitur Stabil Terbaru (v1.14)

#Pendahuluan

Di episode 19 kalian sudah menyetel Karpenter untuk latency dan efisiensi binpacking. Namun tuning yang baik untuk versi sekarang belum tentu benar untuk versi berikutnya. Karpenter bergerak cepat, dan memahami arah rilisnya menentukan berapa banyak pekerjaan yang harus kalian lakukan saat upgrade.

Episode ini memetakan evolusi Karpenter dari v1.0 pada 2024 hingga v1.14.0 pada Juli 2026. Kita bedah API v1 yang menyingkirkan v1beta1, dukungan Kubernetes 1.29-1.36, lalu fitur-fitur yang menonjol: Static Capacity, NodeOverlay, drift detection untuk CA bundle, serta perbaikan scheduling dan disruption budgets.

#Evolusi Rilis: dari v1.0 ke v1.14

Karpenter mencapai stabilitas besar pertama pada v1.0 di tahun 2024. Sejak itu rilis minor datang secara teratur, dan masing-masing membawa perubahan nyata bagi pengguna.

#API v1 dan Akhir dari v1beta1

Karpenter v1.0 memperkenalkan API generasi baru: NodePool menggantikan Provisioner, dan NodeClaim menggantikan Machine. Sejak v1.1.0, apiVersion karpenter.sh/v1beta1 dihapus sepenuhnya — semua resource harus memakai karpenter.sh/v1.

Bagi kalian yang mengikuti seri ini, API v1 sudah dipakai sejak episode 3. Artinya, tidak ada migrasi mendadak. Tapi jika kalian mengambil alih kluster yang lebih tua, periksa apiVersion pada seluruh manifest:

kubectl get nodepools -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'
kubectl get nodes -o wide

Provider AWS juga mengikuti pola yang sama: EC2NodeClass memakai karpenter.k8s.aws/v1, menggantikan API beta dari generasi sebelumnya. Selalu samakan apiVersion manifest dengan versi CRD yang terpasang di kluster.

#Dukungan Kubernetes 1.29-1.36

Karpenter menjaga kompatibilitas dengan rentang versi Kubernetes tertentu. Di v1.14, rentang yang didukung adalah Kubernetes 1.29 sampai 1.36. Memahami rentang ini penting saat merencanakan upgrade kluster EKS.

Sebelum upgrade kluster:

1. Baca catatan rilis Karpenter untuk versi yang kalian pakai.
2. Pastikan versi kluster target masih berada dalam rentang dukungan.
3. Upgrade Karpenter lebih dulu bila diperlukan, lalu upgrade kluster.

#Static Capacity

Static Capacity adalah fitur yang memperlakukan kapasitas statis — bare metal, on-prem, atau node khusus — sebagai bagian dari NodePool yang sama. Karpenter tidak meluncurkan instance untuk kapasitas ini, tetapi tetap menjadwalkan workload ke sana berdasarkan requirements dan taint yang sama.

Fitur ini berada di balik feature gate StaticCapacity sejak v1.8.x. Node statis didaftarkan ke cluster dengan label yang cocok dengan requirement NodePool, dan Karpenter menghitungnya sebagai kapasitas yang tersedia. Ini menyempurnakan pendekatan static capacity yang kalian lihat di episode 17.

settings:
  featureGates:
    staticCapacity: true

#NodeOverlay

NodeOverlay adalah feature gate yang mengubah cara node terhubung ke jaringan kluster. Alih-alih setiap node mengambil IP dari CIDR VPC utama, node memakai CIDR overlay terpisah yang dikelola EKS. Manfaatnya: keterbatasan IP subnet tidak lagi menjadi hambatan pertumbuhan node, dan kapasitas IP bisa diprediksi terlepas dari jumlah instance.

Karena mode ini memengaruhi keputusan scheduling — Karpenter harus tahu resource tambahan dan penyesuaian harga yang muncul dari overlay — fitur ini masih alpha sejak v1.7.x. Uji di lingkungan staging dengan beban yang mewakili production sebelum diaktifkan.

#Drift Detection untuk CA Bundle (v1.12+)

Sejak v1.12, Karpenter mendeteksi drift ketika CA bundle yang dikirim ke node berubah. Sebelumnya, perubahan pada CA bundle di EC2NodeClass tidak memicu penggantian node — sehingga node yang sudah berjalan tetap memakai sertifikat lama. Kini hash NodeClass menyertakan CA bundle, dan Karpenter mengganti node yang tertinggal.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  userData: |
    #cloud-config
    write_files:
      - path: /etc/kubernetes/ca-bundle.crt
        content: |
          <base64-ca-bundle>

#Perbaikan Scheduling dan Disruption Budget

Versi v1.14 membawa perbaikan kualitas pada dua area inti. Di sisi scheduling, simulasi lebih efisien untuk kluster dengan banyak NodePool, dan keputusan binpacking lebih stabil sehingga pergantian instance yang tidak perlu berkurang.

Di sisi disruption budgets, kontrol menjadi lebih halus: budget bisa disetel per alasan — seperti Drifted, Empty, Underutilized — dan per jadwal waktu. Ini memungkinkan kluster membatasi drift pada jam sibuk dan memberi ruang lebih luas pada jam sepi, tanpa harus menonaktifkan disruption sepenuhnya.

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

#Strategi Upgrade yang Aman

Mengikuti rilis terbaru penting untuk perbaikan keamanan dan fitur, tetapi upgrade harus terkendali. Alur yang disarankan:

helm repo update
helm upgrade karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version v1.14.0 \
  --namespace karpenter \
  --reuse-values
kubectl get pods -n karpenter -o wide

Sebelum menjalankan: baca upgrade guide di karpenter.sh untuk versi tujuan, verifikasi apiVersion CRD yang dipakai manifest, uji di kluster staging, dan siapkan rencana rollback dengan versi Helm sebelumnya. Catatan rilis selalu mencantumkan perubahan yang tidak kompatibel ke belakang.

#Penutup

Mengikuti evolusi Karpenter berarti upgrade bukan lagi peristiwa menakutkan, melainkan rutinitas yang terencana.

Inti yang harus dibawa pulang:

• API v1 sudah mapan: sejak v1.1.0, v1beta1 tidak ada; manifest NodePool dan EC2NodeClass memakai karpenter.sh/v1 dan karpenter.k8s.aws/v1.
• Rentang Kubernetes jelas: v1.14 mendukung Kubernetes 1.29-1.36; rencanakan upgrade kluster dan Karpenter bersama.
• Fitur baru datang via feature gate: Static Capacity dan NodeOverlay masih alpha, jadi evaluasi di staging sebelum production.
• Drift kini mencakup CA bundle: v1.12+ mengganti node saat CA bundle berubah, menjaga kepercayaan terhadap sertifikat kluster.
• Budget disruption lebih presisi: per alasan dan per jadwal memberi kendali halus tanpa mematikan disruption.

Semua fitur ini akan berarti banyak di dunia nyata jika dirakit dengan benar. Di episode 21 kita membahas production-ready deployment — arsitektur multi-NodePool untuk general, spot, dan GPU, budget yang ketat, integrasi HPA dan KEDA, disaster recovery, hingga pipeline CI/CD dan GitOps. Sampai jumpa!