Belajar Karpenter - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian sudah memahami mengapa Karpenter ada: menggantikan model nodegroup yang reaktif dan lambat dengan provisioning yang cepat, efisien, dan sederhana. Sekarang saatnya melihat bagaimana Karpenter bekerja di balik layar.

Episode ini membedah arsitektur inti Karpenter: alur dari pod yang tidak terjadwalkan sampai node siap dipakai, dua konsep kunci yang akan menemani kita sepanjang series — NodePool dan NodeClass — serta komponen CRD dan label yang menjadi "bahasa" Karpenter.

#Cara Kerja di Balik Layar

Karpenter berjalan sebagai controller di dalam cluster. Ia bukan bagian dari control plane, melainkan deployment biasa yang bisa kalian lihat di namespace karpenter. Alurnya seperti ini:

Pod tidak terjadwalkan (Pending / Unschedulable)
        │
        ▼
Controller Karpenter mendeteksi pod
        │
        ▼
NodePool yang cocok dipilih (scheduling & capacity)
        │
        ▼
Cloud provider (AWS) meluncurkan instance
        │
        ▼
Node terdaftar ke cluster, pod dijadwalkan

#Langkah demi Langkah

1. Deteksi — kube-scheduler gagal menempatkan pod dan menandainya Unschedulable. Controller Karpenter melihat peristiwa ini lewat API server.
2. Pemilihan NodePool — Karpenter mengumpulkan semua pod yang mengantre dan mencocokkannya dengan NodePool yang tersedia. Cocok artinya kebutuhan resource, label, taint, dan constraint lain terpenuhi.
3. Peluncuran — Karpenter memanggil cloud provider untuk meluncurkan node yang paling optimal. Di AWS, ini dilakukan lewat mekanisme seperti CreateFleet, termasuk opsi Spot.
4. Registrasi — node bergabung ke cluster, kubelet naik, pod dijadwalkan. Seluruh proses ini terjadi dalam hitungan detik.

#NodePool dan NodeClass

Dua konsep ini adalah fondasi seluruh konfigurasi Karpenter. Memahami pembagian perannya menyelamatkan kalian dari kebingungan di episode-episode berikutnya.

#NodePool: Kebijakan Scheduling dan Capacity

NodePool menjawab pertanyaan apa yang boleh dijadwalkan. Ia mendefinisikan:

• Requirements — instance family, ukuran instance, tipe kapasitas (on-demand atau Spot), dan zona.
• Template node — label, taint, dan kubelet config yang akan diterapkan pada node.
• Disruption policy — kapan node boleh dikonsolidasi, kapan kedaluwarsa, dan budget-nya.
• Weight — prioritas ketika beberapa NodePool sama-sama cocok.

Sebuah NodePool menunjuk ke NodeClass untuk urusan infrastruktur.

#NodeClass: Spesifikasi Infrastruktur

NodeClass menjawab pertanyaan di mana dan bagaimana node dibuat. Di AWS, ia adalah EC2NodeClass dan mendefinisikan:

• AMI dan AMI family yang dipakai.
• Subnet dan security group tempat instance diluncurkan.
• Instance profile (IAM role) yang melekat pada node.
• userData untuk bootstrap, dan tag tambahan.

Pembagian ini membuat satu NodeClass bisa dipakai banyak NodePool, atau satu NodePool bisa menunjuk ke NodeClass berbeda — kombinasi yang fleksibel untuk berbagai jenis workload.

#Komponen Utama dan CRD

Karpenter 1.14.0 bekerja lewat sekumpulan CustomResourceDefinition:

• NodePool (karpenter.sh/v1) — kebijakan scheduling, penerus resource provisioner yang lama.
• EC2NodeClass (karpenter.k8s.aws/v1) — spesifikasi infrastruktur AWS.
• NodeClaim — representasi node yang sedang diproses Karpenter, dari peluncuran sampai terdaftar.
• Disruption controller — komponen yang menangani consolidation, drift, expiration, dan interruption handling.

API v1 adalah kondisi GA. Sejak Karpenter 1.1.0, API v1beta1 yang lama dihapus, jadi seluruh konfigurasi di series ini memakai API v1.

#Label dan Anotasi karpenter.sh

Saat membuat node, Karpenter menempelkan label dan anotasi yang sangat berguna untuk operasional:

kubectl get nodes -l karpenter.sh/nodepool=default -o wide
kubectl get nodepools
kubectl get nodeclaims

Perhatikan label pada output kubectl get nodes -l karpenter.sh/nodepool=default -o wide — kalian akan melihat instance type, zona, dan capacity type yang dipilih Karpenter untuk setiap node.

#Penutup

Episode ini membedah arsitektur Karpenter. Karpenter adalah controller di dalam cluster yang mendeteksi pod Unschedulable, memilih NodePool yang cocok, lalu memanggil cloud provider untuk meluncurkan node yang optimal. Dua konsep kunci yang harus kalian pegang adalah NodePool (kebijakan scheduling dan capacity) dan NodeClass (spesifikasi infrastruktur). CRD seperti NodeClaim dan disruption controller melengkapi arsitektur, sementara label karpenter.sh menjadi jembatan observability.

Inti yang harus dibawa pulang:

• Arsitektur controller — Karpenter berjalan di dalam cluster dan bereaksi terhadap pod Unschedulable.
• NodePool vs NodeClass — scheduling dan capacity dipisah dari infrastruktur, memberikan fleksibilitas kombinasi.
• Alur empat langkah — deteksi, pemilihan pool, peluncuran cloud, dan registrasi node.
• API v1 — kondisi stabil; v1beta1 sudah dihapus sejak 1.1.0.
• Label karpenter.sh — karpenter.sh/nodepool dan karpenter.sh/capacity-type adalah kunci observability.

Di episode 3 kita langsung praktik: setup dan instalasi. Kita akan membuat cluster EKS dari nol, memasang CRD dan controller Karpenter lewat Helm, membangun IAM role minimal, lalu memverifikasi dengan contoh NodePool dan EC2NodeClass pertama. Sampai jumpa di episode berikutnya!