Belajar Karpenter - Migrasi dari Cluster Autoscaler

#Pendahuluan

Di episode 15 kalian sudah menyusun best practice kapasitas dan FinOps untuk Karpenter. Namun mungkin kalian bertanya: bagaimana kalau cluster masih memakai Cluster Autoscaler (CA)? Mengganti autoscaler node di cluster produksi terasa menakutkan — CA sudah berjalan lama, workload sudah menyesuaikan perilakunya, dan satu kesalahan bisa membuat seluruh cluster stuck tanpa node baru.

Episode ini membahas migrasi dari Cluster Autoscaler ke Karpenter secara sistematis. Kalian akan belajar kapan harus mengganti CA, menjalankan keduanya berdampingan, mengonversi nodegroup menjadi NodePool, memahami perbedaan perilaku scheduling, hingga mengelola downtime selama rollout.

#Kapan Harus Mengganti Cluster Autoscaler

Cluster Autoscaler berbasis node group: ia hanya menambah atau mengurangi jumlah instance dalam grup yang sudah ditentukan. Karpenter bekerja di level instance langsung, sehingga lebih fleksibel. Pertimbangkan migrasi ketika:

• Kecepatan penting: CA butuh menit untuk scale up karena menunggu node group; Karpenter meluncurkan instance dalam hitungan detik.
• Efisiensi biaya: CA tidak melakukan konsolidasi agresif; Karpenter menggabungkan workload dan memakai Spot secara luas.
• Kustomisasi instance: CA terbatas pada tipe instance dalam launch template; Karpenter memilih dari ratusan tipe.
• Oversight pengelolaan: node group adalah sumber daya AWS terpisah yang harus dirawat; NodePool dan NodeClass adalah Kubernetes native.

#Strategi Migrasi Bertahap dan Coexistence

Karpenter dan Cluster Autoscaler dapat hidup berdampingan di cluster yang sama selama satu kondisi terpenuhi: mereka tidak boleh mengelola node group yang sama. CA hanya memindahkan jumlah instance dalam node group tertentu, sementara Karpenter membuat node sendiri. Jika keduanya menyentuh node group yang sama, akan terjadi perang skala: CA menaikkan, Karpenter menurunkan.

kubectl scale deployment cluster-autoscaler \
  -n kube-system \
  --replicas=0

Strategi bertahap yang aman:

1. Instal Karpenter tanpa menghapus CA.
2. Buat NodePool dengan taint khusus yang tidak dipakai node group lama.
3. Pindahkan sebagian workload ke node Karpenter lewat toleration dan scheduling.
4. Setelah workload stabil, matikan CA dan biarkan node group lama mengecil.
5. Hapus node group dan hapus CA sepenuhnya.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: migration
spec:
  template:
    spec:
      taints:
        - key: karpenter.sh/migrated
          effect: NoSchedule
  disruption:
    consolidationPolicy: WhenUnderutilized

Pod yang dipindahkan menambahkan toleration karpenter.sh/migrated sehingga mereka dijadwalkan ke node Karpenter, sementara workload lain tetap berjalan di node group lama tanpa gangguan.

#Konversi Nodegroup Menjadi NodePool

Node group eksisting tidak otomatis dikelola Karpenter. Kalian harus merepresentasikan keinginan yang sama dalam bentuk NodePool dan NodeClass. Peta konversinya sederhana: keinginan instance type di node group menjadi requirements, dan launch template menjadi NodeClass.

Perhatikan bahwa Karpenter tidak mengenal konsep max size per NodePool secara eksplisit. Batas kapasitas ditegakkan lewat kombinasi limits pada resources, budget diskontinuitas, atau kebijakan tagging. Sesuaikan ekspektasi tim: perilaku ini lebih fleksibel tetapi butuh kontrol yang disiplin.

#Perbedaan Perilaku Scheduling

Karpenter dan CA berbeda secara fundamental dalam cara mereka melihat kapasitas. CA bertanya "apakah ada pod yang tidak bisa dijadwalkan, dan apakah node group bisa bertambah?", sedangkan Karpenter melakukan simulasi binpacking terhadap instance type sebelum memutuskan membuat node.

# Node dengan label managed oleh Karpenter
kubectl get nodes -l karpenter.sh/nodepool
 
# Node yang berasal dari node group eksisting
kubectl get nodes -l eks.amazonaws.com/nodegroup

Perbedaan ini berdampak nyata: Karpenter mengemas pod lebih rapat sehingga lebih sedikit node, memilih instance sesuai kebutuhan persis pod, dan tidak menunggu ketersediaan node group. Akibatnya, aplikasi yang mengandalkan penempatan deterministic harus diverifikasi ulang.

#Annotations cluster-autoscaler.kubernetes.io

Workload yang ditulis untuk CA sering membawa annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false" untuk mencegah eviction saat scale-down. Karpenter tidak membaca annotation ini. Sebagai gantinya, gunakan Pod Disruption Budget untuk mengatur pod yang tidak boleh diganggu saat konsolidasi.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

#Pengelolaan Downtime

Migrasi yang direncanakan dengan baik tidak membutuhkan downtime. Kunci utamanya adalah ketersediaan node baru sebelum menghapus yang lama: pastikan NodePool Karpenter sudah aktif dan workload baru siap, baru kemudian matikan CA dan mengecilkan node group.

Titik paling rawan adalah perbedaan terminationGracePeriodSeconds dan perilaku drain. CA dan Karpenter sama-sama melakukan drain, tetapi urutan dan prioritasnya berbeda. Uji di environment staging dengan beban yang mirip produksi, dan siapkan rollback dengan menyimpan konfigurasi CA asli.

#Penutup

Migrasi dari Cluster Autoscaler adalah proyek yang bisa berjalan mulus jika dilakukan bertahap dan dengan perlindungan yang tepat.

Inti yang harus dibawa pulang:

• Migrasi ketika nilai jelas: kecepatan, efisiensi biaya, atau fleksibilitas instance adalah alasan valid; tren bukan.
• Coexistence itu mungkin: Karpenter dan CA bisa berjalan bersama selama tidak mengelola node group yang sama.
• Konversi konsep secara sadar: node group menjadi NodePool, launch template menjadi NodeClass, dan max size menjadi kontrol budget.
• Ganti annotation CA dengan PDB: cluster-autoscaler.kubernetes.io/safe-to-evict tidak dibaca Karpenter, jadi audit dan konversi sebelum konsolidasi aktif.
• Rollback selalu tersedia: tahan node group kecil beberapa siklus rilis setelah migrasi sebagai jaring pengaman.

Migrasi selesai, dan Karpenter kini mengelola kapasitas utama. Tapi ada banyak fitur lanjutan yang belum dijelajahi. Di episode 17 kita membahas Fitur Lanjutan — static capacity dan node khusus seperti bare metal dan on-prem via NodeClass, lalu Karpenter di platform lain seperti AKS, EKS Anywhere, dan provider komunitas. Sampai jumpa!