Belajar Karpenter - Fitur Lanjutan

#Pendahuluan

Di episode 16 kalian sudah berhasil memigrasi cluster dari Cluster Autoscaler dan memahami perbedaan perilakunya. Namun Karpenter bukan hanya autoscaler untuk node EC2 standar. Ada beban kerja yang membutuhkan mesin khusus — bare metal untuk lisensi dan kontrol penuh, atau kapasitas on-prem yang sudah dibeli dan tidak bisa diabaikan. Ada juga organisasi yang tidak berada di AWS sama sekali.

Episode ini membuka fitur lanjutan Karpenter dari dua arah. Pertama, static capacity dan special nodes: bagaimana NodeClass mengelola node bare metal dan on-prem. Kedua, ekosistem lintas platform: Karpenter di AKS, EKS Anywhere, dan peran provider komunitas yang memperluas Karpenter melampaui AWS.

#Static Capacity: Node Statis dan Kustom

Selama ini kita membahas node yang diluncurkan on-demand. Namun ada skenario di mana kapasitas sudah ada secara fisik: bare metal yang dibeli untuk lisensi, atau server on-prem yang sudah terpasang. Karpenter mendukung skenario ini dengan memperlakukan node statis sebagai bagian dari ekosistem NodePool.

Konsep kuncinya: Karpenter tidak meluncurkan instance untuk static capacity, tetapi ia tetap mengelola siklus hidup scheduling-nya. Node statis didaftarkan dengan label dan taint yang sama seperti node lain, sehingga Karpenter bisa menjadwalkan workload ke sana dan menghormati taint yang dimilikinya.

#Bare Metal di AWS

AWS menyediakan instance bare metal seperti m5.metal dan c6i.metal untuk workload yang menuntut akses langsung ke hardware, lisensi yang terikat per-socket, atau kebutuhan virtualisasi tertentu. Instance metal juga membuka akses ke fitur seperti SR-IOV dan kontrol NMI yang tidak tersedia di instance virtual.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: metal
spec:
  template:
    spec:
      taints:
        - key: workload-type
          value: metal
          effect: NoSchedule
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m5.metal", "c6i.metal"]
  disruption:
    consolidationPolicy: WhenUnderutilized

#Mengelola Kapasitas On-Prem

Untuk kapasitas on-prem, Karpenter memakai mekanisme yang sama: node didaftarkan ke cluster dengan label yang cocok dengan requirement NodePool, dan Karpenter menganggapnya sebagai kapasitas yang tersedia. Yang berbeda adalah siapa yang meluncurkan node — bukan Karpenter, melainkan tooling on-prem seperti metal provisioning atau OpenStack.

kubectl label node prem-01 \
  node.kubernetes.io/instance-type=on-prem-general \
  topology.kubernetes.io/zone=onprem-a \
  karpenter.sh/registered=true
 
kubectl taint nodes prem-01 workload-type=onprem:NoSchedule

Setelah node terdaftar, buat NodePool dengan requirement yang cocok dan toleration yang sesuai. Karpenter akan menjadwalkan workload ke node on-prem tersebut bersama node cloud, dengan preferensi yang kalian tentukan lewat weight.

#Karpenter di AKS

Karpenter resmi mendukung AKS (Azure Kubernetes Service) sejak v1.0. Konsep NodePool dan NodeClaim sama, tetapi kapasitas dibangun oleh provider Azure. AzureNodeClass menggantikan EC2NodeClass, dengan pengaturan seperti image, userData, dan pod identity.

apiVersion: karpenter.azure.com/v1alpha2
kind: AzureNodeClass
metadata:
  name: default
spec:
  image:
    id: /subscriptions/SUBSCRIPTION/resourceGroups/RG/providers/Microsoft.Compute/images/aks-ubuntu
  userData: |
    #cloud-config
    runcmd:
      - echo "node karpenter aks" > /etc/motd

NodePool di AKS menambahkan pilihan VM size dan sku family melalui requirement Azure, misalnya key seperti kubernetes.azure.com/sku-family. Perilaku konsolidasi, drift, dan disruption sama dengan di AWS, sehingga pengetahuan kalian dari episode-episode sebelumnya langsung terpakai.

#EKS Anywhere

EKS Anywhere membawa API dan tooling EKS ke datacenter kalian sendiri. Karena cluster EKS Anywhere juga merupakan Kubernetes, Karpenter dapat diinstal di sana. Namun cloud provider-nya bukan AWS — kapasitas datang dari vSphere atau bare metal lokal, dan Karpenter perlu provider yang memahami sumber daya tersebut.

Di lingkungan EKS Anywhere, NodePool tetap mengatur keinginan scheduling, tetapi pembuatan node bergantung pada provider yang tersedia. Praktik terbaiknya: gunakan Karpenter untuk konsolidasi dan penjadwalan workload, sambil membiarkan provisioning fisik ditangani tooling yang sudah ada.

#Provider Komunitas

Ekosistem Karpenter tumbuh lewat provider komunitas. Ini adalah implementasi cloud provider di luar resmi yang memungkinkan Karpenter berjalan di platform lain. Karpenter Core dirancang agar pembuatan dan pemeliharaan node didelegasikan ke provider, sehingga komunitas bisa menambah dukungan untuk platform baru.

Sebelum mengadopsi provider non-resmi, lakukan uji beban di environment terpisah dan perhatikan kontrak antar versi. Karpenter Core berubah cepat, dan provider yang tertinggal bisa membuat cluster kalian tidak bisa scaling hingga upgrade dilakukan.

#Penutup

Fitur lanjutan memperluas Karpenter dari autoscaler node EC2 menjadi framework scheduling kapasitas lintas platform.

Inti yang harus dibawa pulang:

• Static capacity itu sah: bare metal dan node on-prem bisa dikelola bersama node cloud lewat label, taint, dan toleration yang konsisten.
• Bare metal butuh isolasi: taint NodePool dan toleration pod khusus mencegah workload biasa membuang biaya di instance metal.
• AKS resmi didukung: AzureNodeClass dan requirement VM size membuat pola Karpenter yang sama berlaku di Azure.
• EKS Anywhere bisa memakai Karpenter: cluster EKS di datacenter tetap bisa dijadwalkan, dengan provisioning fisik ditangani tooling lokal.
• Provider komunitas butuh kehati-hatian: periksa kematangan dan ritme pembaruan sebelum mengadopsi provider non-resmi.

Karpenter kini bukan lagi sekadar autoscaler, melainkan fondasi scheduling kapasitas yang lengkap. Tapi saat semuanya berjalan otomatis, kalian akan butuh kemampuan untuk mencari tahu mengapa sesuatu tidak berjalan. Di episode 18 kita membahas Troubleshooting — membaca log controller, kondisi NodeClaim dan NodePool, validasi webhook, serta masalah umum seperti kuota instance habis, Spot capacity kosong, dan pod yang tak kunjung terjadwal. Sampai jumpa!