Belajar Karpenter - Performance & Tuning

#Pendahuluan

Di episode 18 kalian sudah belajar troubleshooting: membaca log controller, kondisi NodeClaim dan NodePool, serta menangani masalah umum hingga pod yang tak kunjung terjadwal. Mengetahui cara memperbaiki yang rusak adalah setengah perjalanan. Setengah lainnya adalah membuat sistem berjalan sebaik mungkin sejak awal.

Episode ini membahas dua dimensi kinerja Karpenter. Pertama, latency provisioning: seberapa cepat pod baru bisa berjalan setelah dinyatakan pending. Kedua, efisiensi binpacking: seberapa padat pod duduk di node sehingga setiap instance terpakai secara optimal. Keduanya bisa disetel lewat spec.template dan kebijakan disruption.

#Mengukur Latency Provisioning

Sebelum menyetel apa pun, ukur dulu. Karpenter mengekspos metrik Prometheus pada endpoint /metrics di port 8080. Tiga metrik yang paling berguna:

• karpenter_pods_startup_duration_seconds — waktu end-to-end dari pod dibuat hingga berstatus running.
• karpenter_scheduler_scheduling_duration_seconds — durasi simulasi scheduling di sisi Karpenter.
• karpenter_cloudprovider_duration_seconds — latency panggilan ke API cloud provider.

sum(rate(karpenter_cloudprovider_duration_seconds_sum[5m]))
  / sum(rate(karpenter_cloudprovider_duration_seconds_count[5m]))

Dengan membandingkan ketiganya, kalian tahu di mana waktu terbuang. Jika scheduling simulation lambat, masalahnya di constraint; jika cloudprovider lambat, masalahnya di API rate limit atau pemilihan instance yang terlalu sempit.

#Faktor yang Memengaruhi Kecepatan

Dua faktor dominan menentukan latency provisioning:

API rate. Karpenter melakukan panggilan EC2 untuk meluncurkan instance dan melakukan dry-run untuk menguji instance type. Jika kluster kalian sangat aktif, panggilan ini bisa kena throttling dan setiap percobaan menjadi lambat. Gejalanya terlihat dari karpenter_cloudprovider_duration_seconds yang membengkak dan karpenter_cloudprovider_errors_total yang naik.

Instance selection. Saat menjadwalkan, Karpenter mensimulasikan pod terhadap daftar instance type yang diizinkan NodePool. Semakin ketat constraint, semakin sedikit opsi valid, dan semakin banyak kerja yang harus dilakukan sebelum menemukan kecocokan.

#Tuning spec.template untuk Kecepatan

NodePool spec.template.spec.requirements menentukan ruang pencarian instance. Semakin luas, semakin besar peluang dapat instance dan semakin kebal terhadap gejolak kapasitas, tetapi simulasi scheduling jadi lebih berat. Sebaliknya, membatasi terlalu sempit membuat pencarian cepat tetapi mudah gagal.

Pendekatan yang seimbang:

• Izinkan beberapa keluarga instance dengan ukuran yang masuk akal, bukan hanya satu.
• Tetapkan karpenter.sh/capacity-type dan zona sesuai kebutuhan agar Karpenter tidak membuang waktu mengeksplorasi opsi yang tak terpakai.
• Gunakan karpenter.sh/instance-type cap untuk mencegah pemilihan instance raksasa bagi workload kecil.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["ap-southeast-1a", "ap-southeast-1b"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - "m6i.large"
            - "m6i.xlarge"
            - "m6i.2xlarge"

#Consolidation Windows

Konsolidasi mengubah node yang jarang terpakai menjadi penghematan, tetapi konsolidasi yang terlalu agresif membuat node diciptakan dan dibongkar berulang kali. Di sinilah disruption.consolidationPolicy bermain.

Pola WhenUnderutilized memindahkan pod dan membongkar node secepat mungkin saat pemanfaatan rendah — cepat tapi reaktif. Pola WhenEmpty menunggu node benar-benar kosong selama ttlSecondsAfterEmpty sebelum dibongkar, yang lebih tenang untuk workload berdenyut.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    ttlSecondsAfterEmpty: 600
    expireAfter: 720h

#Efisiensi Binpacking

Binpacking adalah kemampuan Karpenter mengemas pod ke node sepadat mungkin. Kunci pertama: resource requests yang benar. Karpenter menjadwalkan berdasarkan requests, bukan limits. Jika sebuah pod meminta 4 vCPU padahal hanya memakai 1 vCPU rata-rata, node akan membesar dan biaya melonjak tanpa alasan.

Praktik yang benar:

• Gunakan VPA atau observability untuk mengukur penggunaan nyata sebelum menetapkan request.
• Hindari menetapkan request yang meniru limit.
• Tinjau ulang request setiap kali fitur baru diluncurkan.

Kunci kedua: hindari fragmentation. Fragmentasi terjadi ketika sisa kapasitas node terlalu kecil untuk pod mana pun, sehingga node terlihat terpakai sebagian namun tidak bisa diisi lagi. Instance besar dengan sedikit pod adalah contoh klasiknya.

#Menghindari Fragmentasi

Beberapa cara mengurangi fragmentasi:

• Pastikan ukuran request tidak meninggalkan sisa aneh — kombinasi 0.4, 0.6, dan 1.1 vCPU dalam satu node menghasilkan sisa yang sulit diisi.
• Batasi ukuran instance maksimum agar node tidak membesar melampaui kebutuhan agregat.
• Biarkan konsolidasi bekerja: WhenUnderutilized akan meremas pod bersama dan membongkar node yang kurang padat.

Perhatikan juga label well-known seperti karpenter.sh/instance-type dan topology.kubernetes.io/zone yang dipakai Karpenter untuk menghitung spread. Topology spread yang dipaksakan lintas pod besar menghambat binpacking karena Karpenter harus menyebar pod ke banyak node.

#Tuning disruption.budgets

Budgets membatasi seberapa banyak node yang boleh diproses disruption secara bersamaan. Budget yang terlalu longgar membuat perubahan cepat tetapi berisiko mengganggu layanan; budget yang terlalu ketat membuat kluster lambat merespons perubahan konfigurasi.

Karpenter v1 mendukung budget berdasarkan alasan dan jadwal. Misalnya, batasi drift pada jam kerja agar kluster tenang saat trafik penuh, lalu beri ruang lebih luas di luar jam kerja.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted
        schedule: "0 8 * * mon-fri"
      - nodes: "40%"
        reasons:
          - Drifted
        schedule: "0 20 * * mon-fri"
      - nodes: "10%"

#Penutup

Kinerja Karpenter bukan soal menekan satu tombol, melainkan keseimbangan antara kecepatan provisioning dan kepadatan node.

Inti yang harus dibawa pulang:

• Ukur sebelum menyetel: metrik karpenter_cloudprovider_duration_seconds dan karpenter_scheduler_scheduling_duration_seconds menunjukkan di mana waktu terbuang.
• Requirement yang seimbang menang: terlalu sempit membuat gagal, terlalu luas membuat lambat; mulailah dari keluarga instance yang wajar.
• Requests menentukan binpacking: Karpenter menjadwalkan berdasarkan requests, jadi request yang berlebihan membesarkan node dan biaya.
• Konsolidasi butuh windows yang tepat: WhenEmpty dengan ttlSecondsAfterEmpty menenangkan kluster berdenyut, expireAfter menyerap pembaruan AMI.
• Budget disruption adalah safety valve: batasi drift dan konsolidasi dengan budget beralasan dan berjadwal.

Dengan tuning ini, Karpenter kalian berjalan cepat dan hemat. Tapi ecosystem tidak berhenti di versi yang kalian gunakan saat ini. Di episode 20 kita membahas fitur stabil terbaru di Karpenter v1.14 — evolusi dari v1.0, API v1, Static Capacity, NodeOverlay, drift detection untuk CA bundle, dan perbaikan scheduling serta disruption budget. Sampai jumpa!