Belajar Karpenter - Disruption & Consolidation

#Pendahuluan

Di episode 6 kalian sudah melihat bagaimana Karpenter melakukan provisioning: mengelompokkan pod yang belum terjadwal, melakukan binpacking, lalu meluncurkan instance type terkecil yang cukup. Episode 7 ini membalik arah: bukan menambah node, melainkan menghapusnya. Karpenter tidak hanya hebat saat menambah kapasitas, tetapi juga saat memangkas kapasitas yang tidak efisien lewat dua mekanisme utama: disruption budget dan consolidation.

Setelah episode ini, kalian akan paham bagaimana membatasi jumlah node yang boleh diganggu bersamaan, apa perbedaan consolidationPolicy: WhenEmpty dengan WhenUnderutilized, dan bagaimana kedua fitur ini bekerja sama menjaga biaya cluster tetap rendah.

#Mengapa Disruption Diperlukan

Kebutuhan kapasitas cluster tidak pernah konstan. Aplikasi yang ramai di pagi hari bisa lengang di malam hari. Deployment baru bisa menurunkan jumlah replika, dan batch job yang selesai membuat node menganggur. Tanpa mekanisme pemangkasan, node yang tidak terpakai tetap ditagih AWS. Inilah alasan Karpenter membangun controller khusus bernama disruption controller yang terus-menerus mengevaluasi apakah ada node yang layak diganggu.

Disruption dalam konteks Karpenter berarti proses menghentikan sebuah node dan menggeser pod-podnya ke node lain. Proses ini dilakukan secara bertahap agar tidak memengaruhi ketersediaan aplikasi: pod di-drain dengan hormat, baru node di-terminate.

#Disruption Budgets

#Konsep Dasar

Memangkas node itu perlu, tetapi memangkas terlalu banyak sekaligus berbahaya. Jika dua belas node di-drive dan semuanya penuh pod, lalu semua diganggu bersamaan, aplikasi bisa kehilangan kapasitas secara drastis. Disruption budget adalah mekanisme Karpenter untuk membatasi berapa banyak node yang boleh dalam proses disruption pada saat yang sama, baik per NodePool maupun per cluster.

Di Karpenter versi 1, konfigurasi ini ditulis pada bagian spec.disruption.budgets di NodePool.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
    budgets:
      - nodes: 10%
      - nodes: "3"
        schedule: "0 9 * * *"

#Budget per NodePool dan per Cluster

Budget yang ditulis di NodePool berlaku untuk node-node yang dibuat oleh NodePool tersebut. Untuk membatasi disruption di seluruh cluster, Karpenter menyediakan budget default global: jika sebuah NodePool tidak mendefinisikan budget sama sekali, Karpenter menerapkan batas default sebesar 10 persen dari node yang dikelola NodePool tersebut.

Field schedule memungkinkan kalian membuat budget yang berbeda pada waktu tertentu, misalnya melonggarkan batas di luar jam kerja atau mengencangkannya saat jam sibuk. Pola ini berguna untuk memastikan disruption tidak terjadi berbarengan dengan puncak trafik.

#Melindungi Node dari Disruption

Terkadang sebuah pod membutuhkan perlindungan total dari disruption, misalnya pod yang sedang memproses batch job yang tidak bisa diulang. Karpenter menghormati annotation karpenter.sh/do-not-disrupt pada pod.

kubectl get pod critical-job-xyz -n apps -o jsonpath='{.metadata.annotations.karpenter\.sh/do-not-disrupt}'

#Consolidation

#Dua Kebijakan: WhenEmpty dan WhenUnderutilized

Jika disruption budget menjawab pertanyaan berapa banyak, consolidation menjawab pertanyaan kapan dan bagaimana. Karpenter menyediakan dua consolidationPolicy:

• WhenEmpty — menghapus node yang tidak lagi menjalankan pod non-DaemonSet setelah consolidateAfter tercapai. Ini kebijakan yang paling konservatif: node dihapus hanya ketika sudah benar-benar kosong.
• WhenUnderutilized — selain menghapus node kosong, juga menggabungkan pod dari beberapa node yang jarang terpakai ke satu node yang lebih efisien, atau mengganti satu node mahal dengan node yang lebih murah.

spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 10m

spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 5m

#Bagaimana Consolidation Bekerja

Proses consolidation berjalan dalam siklus berulang. Untuk setiap node yang dikelola Karpenter, controller menghitung dua hal: apakah node tersebut layak dihapus, dan apakah ada kombinasi instance yang lebih murah yang tetap muat menampung pod-pod di node tersebut. Jika jawabannya ya, Karpenter membuat node baru terlebih dahulu, menunggu pod baru siap, baru meng-drain node lama. Dengan urutan ini, downtime aplikasi praktis tidak terasa.

kubectl get nodes -l karpenter.sh/managed=true
kubectl get nodeclaims -o wide

Node yang sedang dipindahkan akan tampak masuk dalam proses drain sebelum di-terminate.

#Skema Prioritas Disruption

Agar pengambilan keputusan tetap teratur, Karpenter mengikuti urutan prioritas berikut saat menentukan node mana yang diganggu lebih dulu:

Semakin tinggi prioritas, semakin dulu ditangani. Ini memastikan budget yang terbatas dipakai untuk gangguan yang paling penting.

#Kesalahan Umum

#Menyetel consolidateAfter Terlalu Agresif

Nilai seperti 1s membuat Karpenter terus-menerus mengevaluasi dan memindahkan pod, menghasilkan churn yang tidak perlu dan menambah beban API server. Beri jeda yang wajar, misalnya beberapa menit.

#Melupakan Efek DaemonSet

DaemonSet seperti kube-proxy dan CNI berjalan di semua node. Saat menghitung apakah sebuah node layak dihapus, Karpenter mengabaikan pod DaemonSet. Sebuah node dengan satu pod DaemonSet tetap dianggap kosong oleh kebijakan WhenEmpty.

#Penutup

Disruption budget dan consolidation adalah dua sisi dari satu tujuan: kapasitas yang selalu pas dengan kebutuhan. Budget menjaga proses pemangkasan tetap aman, sementara consolidation memastikan setiap node yang tersisa dipakai seefisien mungkin.

Inti yang harus dibawa pulang:

• Budget adalah rem keamanan — spec.disruption.budgets membatasi berapa banyak node yang boleh diganggu bersamaan, per NodePool maupun global.
• WhenEmpty untuk stabilitas — node hanya dihapus ketika benar-benar kosong.
• WhenUnderutilized untuk hemat — pod digabungkan dan instance diganti dengan yang lebih murah.
• do-not-disrupt adalah hak veto — satu annotation cukup untuk melindungi pod atau node dari disruption.

Di episode 8, kalian akan belajar bagaimana constraint dari sisi pod seperti nodeSelector, toleration, dan anti-affinity memengaruhi pilihan NodePool — dan bagaimana Karpenter memperlakukan DaemonSet serta pod critical saat melakukan drain. Sampai jumpa!