Belajar Karpenter - Observability & Metrics

#Pendahuluan

Di episode 11 kalian sudah memahami drift detection dan bagaimana Karpenter menjaga node tetap selaras dengan template NodeClass dan NodePool. Tapi ada pertanyaan yang selalu muncul begitu sistem otomatis berjalan: bagaimana kita tahu semuanya bekerja dengan benar? Autoscaler yang tidak diamati adalah bom waktu. Setiap keputusan provisioning dan konsolidasi terjadi otomatis tanpa pengawasan manusia, sehingga tanpa metrik kalian tidak akan pernah tahu mengapa sebuah node dibuat, kenapa dihapus, atau mengapa sebuah pod menganggur sebagai Pending.

Episode ini membahas observability. Kalian akan belajar membaca metrik Prometheus yang diekspos Karpenter, memahami makna tiap kelompok metrik, memakai dashboard Grafana siap pakai, dan menyusun alerting untuk dua skenario kritis: pod yang terlalu lama Pending dan konsolidasi yang gagal atau tidak kunjung terjadi.

#Mengapa Observability Karpenter Berbeda

Autoscaler node mengelola sumber daya paling mahal di cluster: mesin EC2. Berbeda dengan HPA yang hanya mengubah replica, Karpenter membuat dan menghapus infrastruktur nyata, sehingga galat di sini berdampak finansial langsung. Observability bukan sekadar keinginan, melainkan kebutuhan untuk menjawab pertanyaan-pertanyaan ini:

• Berapa cepat Karpenter merespon pod Pending?
• Apakah node yang dipilih benar-benar efisien untuk workload?
• Apakah konsolidasi menghasilkan penghematan atau malah menyebabkan churn?
• Apakah event interruption dari AWS ditangani tepat waktu?
• Adakah pod yang tercecer sebagai Pending tanpa penyebab yang jelas?

#Metrik Kelompok Node

Metrik dengan awalan karpenter_nodes_* menggambarkan siklus hidup node yang dikelola Karpenter. Yang paling sering dipakai adalah karpenter_nodes_allocatable — gauge yang berisi jumlah resource yang tersedia pada node yang dimiliki Karpenter, dengan label resource seperti cpu, memory, dan pods.

# Kapasitas CPU total yang disediakan Karpenter
sum(karpenter_nodes_allocatable{resource="cpu"})
 
# Jumlah node yang dibuat dan dihapus dalam satu jam terakhir
sum(increase(karpenter_nodes_created[1h]))
sum(increase(karpenter_nodes_terminated[1h]))
 
# Perbandingan resource yang terpakai vs total allocatable
sum(karpenter_nodes_allocatable{resource="cpu"}) -
  sum(karpenter_node_utilization{resource="cpu"})

Perhatikan metrik karpenter_nodes_terminated bersama label alasan terminasi. Lonjakan angka ini bersamaan dengan berkurangnya pod bisa menandakan konsolidasi bekerja, tetapi jika terjadi terus-menerus tanpa jeda, bisa jadi ada masalah dengan PDB atau disruption.budgets yang terlalu agresif.

#Metrik Kelompok Pod

karpenter_pods_startup_time_seconds adalah histogram yang mengukur waktu dari pod disubmit sampai pod siap menerima traffic. Inilah metrik terbaik untuk mengevaluasi janji utama Karpenter: latency provisioning dalam hitungan detik. Nilai _sum dibagi _count memberikan rata-rata waktu startup.

# Rata-rata startup pod dalam detik
rate(karpenter_pods_startup_time_seconds_sum[5m]) /
  rate(karpenter_pods_startup_time_seconds_count[5m])

Selain itu ada karpenter_pods_pending_duration_seconds yang mengukur berapa lama pod menunggu di antrian scheduling. Jika metrik ini tinggi sementara node tidak dibuat, masalahnya bukan di kecepatan provisioning melainkan di constraint NodePool yang terlalu sempit atau kuota AWS yang habis.

#Metrik Scheduling dan Provisioning

Karpenter mengekspos karpenter_provisioner_scheduling_duration_seconds untuk mengukur durasi pengambilan keputusan scheduling — dari pod masuk queue sampai instance type terpilih. Metrik ini penting karena membedakan dua sumber delay yang berbeda: waktu komputasi internal Karpenter melawan waktu API AWS untuk meluncurkan instance.

#Mengumpulkan Metrik dengan Prometheus

Karpenter mengekspos endpoint /metrics pada port 8080 di namespace karpenter. Prometheus dapat mengumpulkannya lewat ServiceMonitor, atau dengan scrape config langsung seperti contoh berikut:

scrape_configs:
  - job_name: karpenter
    kubernetes_sd_configs:
      - role: endpoints
        namespaces:
          names:
            - karpenter
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_label_app_kubernetes_io_name]
        regex: karpenter
        action: keep
      - source_labels: [__meta_kubernetes_endpoint_port_name]
        regex: http
        action: keep

Setelah scrape aktif, verifikasi bahwa metrik masuk lewat kubectl port-forward -n karpenter service/karpenter 8080:8080 lalu kunjungi endpoint. Untuk skala produksi, simpan data lebih lama dengan remote write atau thanos, karena metrik Karpenter paling berguna ketika bisa dibandingkan antar minggu untuk melihat tren biaya dan latency.

#Dashboard Grafana

Membangun dashboard dari nol memakan waktu. Untungnya komunitas dan AWS menyediakan dashboard siap impor. Karpenter menyertakan JSON dashboard resmi di repositorinya, dan contoh deployment EKS dari aws-samples juga memuat panel untuk Karpenter bersama metrik node lainnya.

• Karpenter dashboard resmi: memuat panel metrik node, pod, dan provisioner dalam satu layar.
• EKS workshop / aws-samples dashboard: dikemas bersama dashboard EKS lain, cocok untuk kondisi cluster EKS nyata.
• Panel custom: karpenter_nodes_allocatable dibanding karpenter_pods_startup_time_seconds sering cukup untuk memantau efisiensi.

#Alerting untuk Pod Pending Lama

Pod yang menganggur sebagai Pending adalah sinyal paling awal bahwa autoscaling gagal. Kombinasi metrik Kubelet dan kube-state-metrics menghasilkan alert yang akurat:

groups:
  - name: karpenter-alerts
    rules:
      - alert: KarpenterPodPendingLong
        expr: |
          time() - kube_pod_created > 300
            and on(namespace, pod) kube_pod_status_phase{phase="Pending"} == 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod pending lebih dari 5 menit"

Saat alert ini berbunyi, gunakan langkah diagnosis berikut: cek kondisi NodeClaim dengan kubectl get nodeclaims, periksa log controller dengan kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter, dan pastikan limit EC2 instance tidak tercapai. Episode 18 akan membahas troubleshooting ini lebih dalam.

#Alerting untuk Konsolidasi

Konsolidasi adalah fitur penghematan, tetapi ia juga bisa menjadi sumber gangguan jika salah konfigurasi. Pantau karpenter_consolidation_seconds_since_last untuk mendeteksi konsolidasi yang tidak berjalan sama sekali, dan karpenter_consolidation_pods_evicted_total untuk melihat jumlah pod yang dievakuasi.

# Berapa detik terakhir sejak konsolidasi terakhir berjalan
karpenter_consolidation_seconds_since_last
 
# Pod yang di-evict oleh konsolidasi dalam satu jam
sum(increase(karpenter_consolidation_pods_evicted_total[1h]))

#Penutup

Observability mengubah Karpenter dari kotak hitam menjadi sistem yang bisa diprediksi dan dipertanggungjawabkan.

Inti yang harus dibawa pulang:

• Empat kelompok metrik utama: node, pod, scheduling, dan konsolidasi — masing-masing menjawab pertanyaan operasional yang berbeda dan harus dipantau bersamaan.
• Histogram waktu adalah emas: karpenter_pods_startup_time_seconds dan metrik scheduling menunjukkan latency nyata yang dirasakan pengguna, bukan sekadar status cluster.
• Scrape aktif sejak awal: pasang Prometheus sejak instalasi Karpenter, bukan setelah masalah terjadi, agar data historis tersedia untuk perbandingan.
• Alert Pending wajib ada: pod yang menganggur lebih dari beberapa menit adalah kegagalan autoscaling yang harus memicu alert, bukan hanya terlihat di dashboard.
• Dashboard mempercepat diagnosis: pakai dashboard resmi atau dari aws-samples sebagai titik awal, lalu sesuaikan dengan label biaya dan NodePool kalian.

Metrik sudah siap dipantau, tapi ada satu aspek yang menentukan apakah cluster kalian aman untuk produksi: jaringan. Di episode 13 kita membahas Networking Integration — bagaimana Karpenter memilih subnet dan Availability Zone, peran security group, cara kerja ENI dan Pod ENI, VPC CNI, hingga EFA untuk workload HPC dan ML. Sampai jumpa!