Belajar Karpenter - Troubleshooting

#Pendahuluan

Di episode 17 kalian sudah mengenal fitur lanjutan Karpenter: static capacity, bare metal, hingga dukungan provider komunitas di platform lain. Semakin kompleks sebuah sistem, semakin penting kemampuan mencari tahu mengapa ia tidak bekerja seperti harapan. Karpenter adalah sistem yang bergerak cepat — puluhan keputusan dilakukan setiap detik — sehingga ketika ada yang salah, gejala muncul jauh dari akar masalah.

Episode ini membekali kalian dengan alur diagnostik yang sistematis. Kita mulai dari log controller, lalu kondisi NodeClaim dan NodePool, pesan validasi webhook, dan event Kubernetes. Terakhir, kita bedah masalah umum beserta solusinya satu per satu.

#Alur Diagnostik: Mulai dari Gejala

Jangan langsung membuka log. Mulailah dengan pertanyaan: apa yang sebenarnya terjadi? Pod pending, node tidak dibuat, atau node tidak pernah dibongkar? Tiga gejala ini menunjuk ke lapisan yang berbeda — scheduler, cloud provider, atau disruption.

Urutan yang paling efektif:

1. Lihat status pod dan NodeClaim.
2. Baca event yang terhubung ke pod dan NodeClaim.
3. Telusuri log controller Karpenter.
4. Periksa resource AWS di sisi lain seperti IAM, kuota, dan subnet.

#Log Controller Karpenter

Controller Karpenter berjalan di namespace karpenter sebagai deployment bernama karpenter. Log di sana adalah sumber kebenaran utama tentang apa yang sedang dipikirkan Karpenter.

kubectl logs -n karpenter deploy/karpenter --tail=200

kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter -f --tail=50

Level log bisa dinaikkan ke debug melalui ConfigMap karpenter-global-settings di namespace yang sama, dengan mengubah key logLevel. Log debug menampilkan detail scheduling simulation, pilihan instance type, dan alasan sebuah node ditolak — sangat berguna saat gejalanya samar.

#Kondisi NodeClaim dan NodePool

NodeClaim adalah objek paling penting untuk dibaca. Setiap claim memiliki kondisi di status yang menunjukkan fase hidupnya.

kubectl get nodeclaims
kubectl get nodeclaim <nama-nodeclaim> -o yaml

Perhatikan bagian status.conditions. Kondisi seperti Launching, Registered, dan Initialized menandakan progres normal. Jika Registered bernilai false, node tidak bisa bergabung ke cluster — biasanya soal IAM atau bootstrap. NodePool punya kondisi serupa; NodePool yang tidak sehat membuat semua workload yang menunjuk ke sana tidak pernah terjadwal.

#Validasi Webhook

Karpenter memasang admission webhook untuk memvalidasi NodePool dan EC2NodeClass sebelum diterima. Kesalahan konfigurasi biasanya muncul di sini — sebelum resource dibuat, bukan saat dijalankan.

kubectl apply -f nodepool.yaml
kubectl get validatingwebhookconfiguration -l app.kubernetes.io/name=karpenter

Jika YAML salah, kubectl apply akan menolak dengan pesan yang cukup eksplisit, misalnya requirement yang duplikat atau field yang tidak dikenal. Pastikan apiVersion sesuai dengan versi Karpenter yang terpasang; mencampur versi CRD adalah penyebab paling umum error no matches for kind.

#Membaca Event Kubernetes

Event merekam apa yang terjadi pada objek tertentu. Untuk pod yang pending, deskripsikan pod-nya; untuk node yang tidak kunjung dibuat, saring event berdasarkan kind NodeClaim.

kubectl describe pod <nama-pod>
kubectl get events --field-selector involvedObject.name=<nama-pod>

kubectl get events --field-selector involvedObject.kind=NodeClaim --sort-by=.lastTimestamp

Event pada NodeClaim menampilkan perjalanan claim tersebut: diluncurkan, terdaftar, terinisialisasi, hingga dihapus. Jika claim berhenti di tengah, event di sekitarnya menceritakan alasannya.

#Masalah Umum dan Solusinya

#Node Gagal Dibuat: IAM dan Limit Instance

Ketika Karpenter tidak bisa meluncurkan instance, log controller akan memuat error dari API AWS, misalnya AccessDenied pada instance profile, atau pesan kuota untuk batas vCPU. Solusi untuk IAM: pastikan instance profile di EC2NodeClass benar dan role tersebut memiliki policy yang dibutuhkan untuk meluncurkan instance.

Untuk limit instance, cek kuota vCPU EC2 di region yang dipakai. Karpenter tidak punya mekanisme coba-coba sampai lolos — ia menunggu error lalu mengirim event. Lebih baik menaikkan kuota di AWS Support Center, atau memperluas pilihan instance type di NodePool agar ada opsi yang tersedia.

#Spot Capacity Kosong

Kapan pun kapasitas spot menipis, error seperti InsufficientInstanceCapacity atau NoSpotCapacity muncul di NodeClaim. Karpenter akan mencoba instance type lain dalam satu batch, tetapi jika NodePool membatasi terlalu sempit — misalnya satu keluarga instance di satu zona — peluang sukses sangat kecil.

Perbaikan tercepat: tambahkan lebih banyak instance type melalui requirement, dan aktifkan beberapa zona. Semakin beragam pilihan, semakin tahan terhadap gejolak kapasitas spot.

#Drift Berlebihan

Drift terjadi saat node tidak lagi cocok dengan spesifikasi — misalnya AMI atau security group berubah di EC2NodeClass. Jika perubahan terjadi terus-menerus, Karpenter terus mengganti node dan cluster terasa tidak stabil.

Cara mengendalikan: kurangi frekuensi perubahan pada EC2NodeClass, dan gunakan disruption budget untuk membatasi berapa banyak node drift yang boleh diproses sekaligus.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    budgets:
      - nodes: "20%"
        reasons:
          - Drifted

#Disruption Gagal karena PDB

Konsolidasi dan drift menghormati Pod Disruption Budget. Jika sebuah PDB menolak eviction — karena minAvailable terlalu tinggi atau maxUnavailable nol — NodeClaim tidak akan dibongkar dan event DisruptionBlockedByPDB muncul.

Periksa dengan kubectl get pdb -A lalu lihat aplikasi mana yang menahan. Opsi solusi: turunkan minAvailable, beri toleransi untuk pod yang benar-benar bisa diganggu, atau pisahkan workload tersebut ke NodePool yang tidak dikonsolidasi.

#Pod Pending yang Tak Terjadwal

Pod pending tanpa NodeClaim berarti Karpenter menganggap tidak ada NodePool yang cocok. Deskripsikan pod dan baca event didn't match any node atau Insufficient — di sana tercantum constraint yang gagal.

Cek juga apakah ada taint tanpa toleration, topology spread yang mustahil dipenuhi, atau requirement NodePool yang bentrok. Karpenter tidak membuat NodeClaim jika tidak ada instance type yang lolos semua constraint pod.

#Penutup

Troubleshooting Karpenter bukanlah sihir, melainkan disiplin membaca tanda-tanda di urutan yang benar.

Inti yang harus dibawa pulang:

• Mulai dari gejala: tentukan lapisan masalah — scheduling, cloud provider, atau disruption — sebelum menyentuh log.
• Log controller adalah sumber kebenaran: kubectl logs -n karpenter memperlihatkan keputusan dan error internal Karpenter.
• Kondisi NodeClaim menceritakan siklus hidup: Registered dan Initialized adalah penanda sehat; error di status langsung mengarah ke IAM atau kuota.
• PDB bisa menahan konsolidasi: event DisruptionBlockedByPDB dan kubectl get pdb -A memastikan budget disruption dipatuhi.

Karpenter yang berjalan bukan berarti berjalan cepat. Di episode 19 kita membahas Performance dan Tuning — faktor latency provisioning, tuning spec.template dan consolidation windows, efisiensi binpacking, hingga cara menghindari fragmentasi dengan resource requests yang benar. Sampai jumpa!