Belajar Karpenter - Multi-NodePool & Multi-Cluster

#Pendahuluan

Di episode 9 kalian sudah mengoptimalkan biaya dengan prioritas Spot, filter instance, dan penanganan interupsi otomatis. Episode 10 ini membawa kalian ke skala yang lebih besar: bagaimana menata banyak NodePool dalam satu cluster, dan bagaimana memperlakukan Karpenter ketika cluster yang dikelola bukan satu, melainkan banyak.

Setelah episode ini, kalian akan paham cara memisahkan workload general, GPU, spot-only, dan zona spesifik menggunakan weight dan taints, serta praktik terbaik kebijakan per cluster untuk deployment multi-cluster.

#Multiple NodePools

#Mengapa Lebih dari Satu NodePool

NodePool tunggal yang melayani semua workload memang sederhana, tetapi cepat menjadi kaku. Workload database butuh on-demand dan volume besar, sementara worker batch lebih suka spot murah. Workload ML butuh instance GPU, dan layanan latency-sensitive butuh zona tertentu. Menggabungkan semuanya ke satu NodePool membuat setiap kelompok saling berkompromi.

Pemisahan yang umum digunakan:

• general-pool — workload default, spot dengan fallback on-demand
• gpu-pool — instance GPU untuk training dan inference, bertaint
• spot-only-pool — batch job yang toleran terhadap interupsi
• az-pool — workload yang harus berjalan di zona tertentu

#Weight: Memberi Skor Preferensi

Saat sebuah pod bisa dijadwalkan oleh lebih dari satu NodePool, Karpenter memilih NodePool mana yang dipakai. Field spec.weight menentukan preferensi: NodePool dengan weight lebih besar lebih diprioritaskan, dan nilai default-nya adalah nol. Sebagai contoh, sebuah NodePool general dengan weight 10 akan dipilih sebelum NodePool spot-only dengan weight 5.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  weight: 10
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m

#Taints: Memisahkan Workload Khusus

Weight mengatur preferensi, tetapi taints mengatur izin. NodePool untuk GPU diberi taint agar pod biasa tidak bisa masuk, dan hanya pod yang memiliki toleration nvidia.com/gpu yang dijadwalkan ke sana.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-pool
spec:
  weight: 20
  template:
    spec:
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g5.xlarge", "g5.2xlarge"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Dengan konfigurasi ini, workload web biasa tidak akan pernah berjalan di node GPU yang mahal.

#NodePool untuk Zona Tertentu

Untuk workload yang membutuhkan lokasi tertentu, misalnya karena kedekatan dengan database atau regulasi data, NodePool bisa dibatasi pada zona spesifik melalui label topology.kubernetes.io/zone.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: az-a
spec:
  template:
    spec:
      requirements:
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["us-east-1a"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

#Matriks Pemisahan NodePool

#Multi-Cluster

#Karpenter Berjalan per Cluster

Karpenter adalah controller yang hidup di dalam satu cluster dan mengelola node cluster tersebut. Tidak ada Karpenter pusat yang mengatur banyak cluster. Ketika kalian punya sepuluh cluster, berarti ada sepuluh instance Karpenter yang berjalan terpisah — masing-masing dengan NodePool, NodeClass, dan disruption policy sendiri.

Keuntungan isolasi ini adalah blast radius yang kecil. Kesalahan konfigurasi di satu cluster tidak menjalar ke cluster lain. Namun konsekuensinya, setiap cluster perlu dikelola dengan disiplin yang sama agar tidak terjadi penyimpangan konfigurasi antar lingkungan.

#Kebijakan per Cluster yang Konsisten

Best practice pertama untuk multi-cluster adalah konsistensi lewat kode. Definisikan NodePool dan NodeClass sebagai file yang dikelola lewat GitOps, misalnya dengan ArgoCD atau Flux, lalu terapkan ke semua cluster dari satu sumber. Dengan cara ini, perbedaan antar cluster bisa dikurangi hanya pada hal-hal yang memang harus berbeda.

kubectl apply -f clusters/staging/karpenter/
kubectl apply -f clusters/production/karpenter/

Selain itu, perhatikan hal-hal berikut:

• Gunakan nama resource yang seragam antar cluster agar tooling linting dan audit bekerja identik.
• Bedakan NodePool per lingkungan bila perlu, misalnya staging yang memakai spot saja dan production dengan on-demand lebih banyak.
• Amankan konfigurasi dengan membatasi siapa yang boleh menulis NodePool dan NodeClass melalui RBAC.
• Pantau drift konfigurasi dengan membandingkan state yang diterapkan terhadap state yang diharapkan.

#Contoh Kebijakan per Lingkungan

Cluster staging biasanya boleh berjalan agresif menghemat biaya, sedangkan production membutuhkan lebih banyak jaring pengaman. Konfigurasi berikut mencontohkan perbedaan tersebut.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 15m

#Kesalahan Umum

#Weight Tanpa Taint yang Tepat

Weight yang besar tidak mencegah workload salah tempat jika taint tidak dipasang. Gunakan kombinasi keduanya: weight untuk preferensi, taint untuk pembatasan keras.

#Satu Konfigurasi untuk Semua Lingkungan

Memaksa staging dan production memakai NodePool identik mengabaikan perbedaan kebutuhan biaya dan stabilitas. Sesuaikan kebijakan per lingkungan, tetapi pertahankan satu sumber kebenaran di Git.

#Penutup

Multi-NodePool dan multi-cluster adalah dua level organisasi yang harus dirancang, bukan dibiarkan tumbuh liar. Weight, taint, dan isolasi zona membuat satu cluster tertata; GitOps dan kebijakan per lingkungan menjaga banyak cluster tetap selaras.

Inti yang harus dibawa pulang:

• NodePool memisahkan kepentingan — general, GPU, spot-only, dan zona spesifik bisa hidup berdampingan.
• Weight untuk preferensi, taint untuk izin — keduanya bekerja bersama, bukan saling menggantikan.
• Karpenter berjalan per cluster — setiap cluster mengelola kebijakan dan infrastrukturnya sendiri.
• GitOps menjaga konsistensi — satu sumber kebenaran mencegah konfigurasi menyimpang antar cluster.

Di episode 11, kalian akan belajar tentang drift detection — bagaimana Karpenter mendeteksi perbedaan antara template NodePool dan NodeClass dengan node aktual, serta fitur NodeOverlay untuk memperbarui node tanpa replasemen penuh. Sampai jumpa!