Belajar Karpenter - Sejarah, Latar Belakang & Mengapa Membutuhkan Karpenter

#Pendahuluan

Di episode 0 kalian sudah menyiapkan lingkungan: cluster EKS, IAM role, dan controller Karpenter 1.14.0 yang berjalan di namespace karpenter. Sekarang saatnya bertanya hal yang paling mendasar: mengapa Karpenter harus ada? Kenapa Kubernetes yang sudah punya scheduler internal masih butuh alat lain untuk mengurus node?

Jawabannya terletak pada sejarah node autoscaling di Kubernetes. Alur cerita ini panjang, dari hari-hari provisioning manual, masa Cluster Autoscaler yang reaktif dan lambat, hingga lahirnya Karpenter di AWS pada 2020. Episode ini menelusuri perjalanan itu dan membedah tiga masalah besar yang ingin dipecahkan Karpenter: latensi provisioning, efisiensi biaya, dan kompleksitas operasional.

#Evolusi Node Autoscaling

Node autoscaling bukan konsep baru. Sejak awal, cluster Kubernetes butuh cara untuk menambah dan mengurangi kapasitas secara otomatis. Evolusinya bisa diringkas dalam garis waktu berikut:

Garis waktu node autoscaling

2020    Karpenter lahir di AWS, provisioning sub-detik hingga detik
2022    Karpenter di-donasikan ke kubernetes-sigs (open source)
2024    Karpenter v1.0 dirilis, API masuk kondisi GA
2026    Versi 1.14.0 mendukung Kubernetes 1.29-1.36

#Masa Provisioning Manual

Sebelum autoscaling matang, tim operasi menambah node secara manual: bikin instance EC2, pasang kubelet, daftarkan ke cluster, lalu menunggu scheduler menempatkan pod. Proses ini lambat, rawan salah, dan tidak bisa merespons lonjakan trafik mendadak. Di sinilah Cluster Autoscaler masuk.

#Cluster Autoscaler: Reaktif dan Berbasis Nodegroup

Cluster Autoscaler (CA) adalah pendekatan pertama yang populer. CA bekerja secara reaktif: ia memantau pod yang berstatus Pending, lalu menambahkan node pada nodegroup yang sudah ditentukan. Berikut karakteristik utamanya:

Reaktif — hanya bereaksi ketika ada pod yang benar-benar tidak bisa dijadwalkan.
Berbasis nodegroup — node hanya bisa ditambahkan dalam bentuk kelompok instance dengan template yang sudah ditentukan. Kalian tidak bisa meminta instance yang berbeda dari template nodegroup.
Lambat — menunggu ASG menambah kapasitas dan node ter-register memakan waktu beberapa menit.
Tanpa optimasi instance — CA tidak memikirkan ukuran instance paling pas untuk pod yang sedang mengantre.

Model ini bekerja untuk kasus sederhana, tapi mulai jebol di skala besar. Tim akhirnya membuat banyak nodegroup untuk menampung berbagai kebutuhan: yang kecil untuk burst, yang besar untuk memory-heavy, dan seterusnya. Hasilnya: biaya membengkak, utilasi rendah, dan konfigurasi makin rumit.

#Kelahiran Karpenter

Karpenter dikembangkan oleh AWS mulai tahun 2020 dengan tujuan mengubah cara node provisioning bekerja. Alih-alih berbasis nodegroup, Karpenter menghitung kebutuhan pod yang sedang mengantre lalu memilih instance yang paling optimal untuk kebutuhan itu — dan meluncurkannya langsung ke EC2.

Dua terobosan utama Karpenter:

Latensi provisioning sub-detik hingga detik — Karpenter berbicara langsung ke API EC2, tidak lewat layer ASG yang bertingkat. Node siap dipakai jauh lebih cepat.
Instance yang dipilih per pod, bukan per template — Karpenter memilih instance type terkecil yang masih cukup untuk kebutuhan pod (binpacking), termasuk opsi Spot untuk menekan biaya.

Pada 2022, AWS melepas Karpenter ke kubernetes-sigs, menjadikannya proyek open source yang dikelola komunitas. Dua tahun kemudian, pada 2024, Karpenter mencapai v1.0 — API v1 menjadi stabil dan versi beta yang lama dibuang. Sejak itu Karpenter terus berkembang; versi 1.14.0 yang kalian pasang di episode 0 mendukung Kubernetes 1.29 sampai 1.36.

#Masalah yang Diselesaikan Karpenter

#Latensi Provisioning

Ketika sebuah pod tidak bisa dijadwalkan, setiap detik keterlambatan adalah biaya operasional dan pengalaman pengguna yang buruk. CA bisa memakan waktu 2-5 menit hanya untuk menambah node. Karpenter mengurangi angka itu menjadi detik, bahkan sub-detik pada kasus tertentu, karena ia memanggil langsung layanan peluncuran instance EC2.

#Efisiensi Biaya

Karpenter menekan biaya lewat tiga mekanisme:

Binpacking — memilih instance type terkecil yang masih bisa menampung pod. Tidak ada lagi instance m5.xlarge yang hanya berisi satu pod kecil.
Spot instances — memanfaatkan kapasitas Spot dengan penanganan interruption otomatis lewat NodeClaim.
Consolidation — menghapus node yang tidak efisien dan memindahkan podnya ke node yang lebih optimal, termasuk menggabungkan beberapa node menjadi satu.

#Simplisitas

Satu controller Karpenter menggantikan puluhan nodegroup dan ASG beserta autoscaler-nya. Kalian tidak lagi mengelola template instance di mana-mana; cukup definisikan NodePool sebagai kebijakan, dan Karpenter mengurus sisanya.

#Mengamati Pod yang Tidak Terjadwalkan

Untuk benar-benar merasakan perbedaan CA dan Karpenter, tidak ada cara yang lebih baik daripada mengamati langsung. Ketika cluster kekurangan kapasitas, pod akan mengantre dengan status Pending. Peristiwa ini bisa dilihat lewat events:

Melihat pod yang mengantre

kubectl get events --sort-by=.lastTimestamp | tail -20
kubectl get pods --field-selector=status.phase=Pending -A

Perhatikan FailedScheduling di kolom reason — itulah saat controller autoscaling mulai bekerja. Di cluster yang memakai Cluster Autoscaler, jeda antara event ini dan node yang siap biasanya beberapa menit. Dengan Karpenter yang akan kalian pasang di episode 3, bandingkan sendiri waktunya; perbedaannya terasa nyata ketika node sudah siap dalam hitungan detik.

Tip

kubectl get events --sort-by=.lastTimestamp adalah kebiasaan debug paling berguna yang bisa kalian tanam sejak sekarang. Event FailedScheduling menjadi bukti tertulis bahwa pod butuh kapasitas baru — dan itulah pemicu utama Karpenter yang akan kita bedah di episode 2.

#Karpenter vs Pendekatan Lain

Aspek	Cluster Autoscaler	Karpenter
Model	Nodegroup/ASG eksplisit	Kebijakan berbasis kebutuhan pod
Kecepatan	Menit	Detik hingga sub-detik
Pemilihan instance	Template nodegroup tetap	Optimal per pod (binpacking)
Spot	Manual, per nodegroup	Terintegrasi, bisa per NodePool
Konsolidasi	Tidak ada	Bawaan lewat disruption
Biaya operasional	Banyak nodegroup	Satu controller

Selain CA, ada juga pendekatan komersial seperti Cast AI yang menawarkan optimasi biaya dan manajemen node sebagai layanan. Perbandingan mendalam antara Karpenter, CA, dan Cast AI akan kita bahas khusus di episode 22 series ini.

Note

Karpenter juga tersedia untuk cloud lain. Konsep NodePool dan NodeClass bersifat generik — di Azure ia memakai NodeClass versi Azure, di AWS memakai EC2NodeClass. Selama series ini kita fokus pada implementasi AWS karena itu yang paling matang dan paling banyak dipakai di production.

#Penutup

Episode ini menjelaskan mengapa Karpenter lahir dan masalah apa yang ia pecahkan. Karpenter adalah jawaban atas keterbatasan Cluster Autoscaler yang reaktif, lambat, dan berbasis nodegroup. Lahir di AWS pada 2020, didonasikan ke kubernetes-sigs pada 2022, dan mencapai v1.0 pada 2024, Karpenter menawarkan provisioning sub-detik, pemilihan instance optimal, binpacking, dukungan Spot, dan konsolidasi otomatis.

Inti yang harus dibawa pulang:

CA reaktif dan berbasis nodegroup — lambat dan tidak fleksibel untuk kebutuhan heterogen.
Karpenter berbasis kebutuhan — instance dipilih berdasarkan apa yang diminta pod, bukan template tetap.
Tiga masalah utama — latensi, biaya, dan kompleksitas adalah alasan Karpenter dibangun.
Sejarah terbuka — Karpenter menjadi open source di kubernetes-sigs dan mencapai API stabil v1 pada 2024.
Mekanisme biaya — binpacking, Spot, dan consolidation adalah senjata utama penghematan.

Di episode 2 kita akan membongkar arsitektur Karpenter: bagaimana controller mendengarkan pod yang tidak terjadwalkan, memilih NodePool yang cocok, dan memanggil cloud provider untuk meluncurkan node. Konsep NodePool dan NodeClass akan menjadi bahasa bersama untuk semua episode praktik berikutnya. Sampai jumpa!