Belajar Karpenter - Drift Detection

#Pendahuluan

Di episode 10 kalian sudah mengatur banyak NodePool dalam satu cluster dan menjaga konsistensi antar cluster dengan GitOps. Episode 11 ini membahas masalah yang muncul justru setelah semuanya berjalan: drift. Cluster yang sehat bukan hanya berhenti di provisioning yang cepat, tetapi juga harus menjaga node yang ada selalu sesuai dengan konfigurasi yang diinginkan.

Setelah episode ini, kalian akan paham apa itu drift, bagaimana Karpenter mendeteksinya, serta apa itu NodeOverlay dan kapan sebaiknya dipakai.

#Konsep Drift

#Apa Itu Drift

Drift adalah kondisi di mana node yang sedang berjalan tidak lagi sama dengan template yang mendefinisikannya. Karpenter mendeteksi drift dengan membandingkan spesifikasi NodePool dan NodeClass terhadap kondisi aktual node di AWS. Ketika keduanya berbeda, node dianggap drifted.

Contoh drift yang paling umum:

• AMI drift — AMI yang dipilih lewat amiSelectorTerms diperbarui, misalnya versi Amazon Linux terbaru, sedangkan node masih berjalan di AMI lama.
• Security group drift — daftar security group pada EC2NodeClass diubah, tetapi node masih memakai daftar lama.
• Instance type drift — requirement instance type pada NodePool berubah, sehingga node dengan tipe lama dianggap tidak sesuai.
• User data dan tag drift — perubahan pada userData atau tag EC2NodeClass tidak tercermin pada node.

kubectl get nodeclaims -l karpenter.sh/drifted=true

#Mengapa Drift Berbahaya

Node yang drifted adalah sumber masalah yang diam-diam. Image lama bisa membawa kernel atau runtime yang sudah memiliki celah keamanan. Konfigurasi yang menyimpang membuat perilaku cluster sulit ditebak. Tanpa deteksi, drift menumpuk sampai akhirnya baru disadari ketika sudah menjadi insiden.

#Proses Perbaikan Drift

Karpenter memperlakukan drift seperti bentuk disruption lain. Node yang drifted masuk dalam antrian disruption, di-drain dengan hormat, lalu diganti dengan node baru yang mengikuti template terbaru. Proses ini sama dengan siklus disruption yang sudah dibahas di episode 7.

kubectl get nodeclaim -o yaml | grep -A 8 'karpenter.sh/drifted'

#Melindungi Node dari Drift

Kadang sebuah node sengaja dipertahankan dalam kondisi lama, misalnya karena sedang menjalankan proses yang tidak boleh terputus. Annotation karpenter.sh/do-not-drift bisa dipasang untuk menghentikan penggantian node tersebut oleh drift.

apiVersion: v1
kind: Pod
metadata:
  name: long-running-job
  annotations:
    karpenter.sh/do-not-drift: "true"
spec:
  containers:
    - name: job
      image: busybox

#NodeOverlay: Pembaruan Tanpa Replasemen Penuh

#Masalah di Balik Replasemen Penuh

Mengganti node untuk setiap perubahan template itu mahal dan berisiko. Setiap replasemen berarti membuat instance baru, menarik image, dan menjalankan drain — beban kerja dan biaya yang tidak kecil, apalagi jika perubahan hanya sepele seperti memperbarui userData. Untuk kasus seperti ini, Karpenter menyediakan fitur eksperimental bernama NodeOverlay.

#Apa Itu NodeOverlay

NodeOverlay adalah kemampuan Karpenter untuk memperbarui bagian node secara langsung di tempat, tanpa meluncurkan instance pengganti. Fitur ini diaktifkan lewat feature gate NodeOverlay dan saat ini bersifat alpha. Dengan NodeOverlay, perubahan pada userData atau konfigurasi AMI yang tidak membutuhkan kernel baru bisa diterapkan tanpa replasemen node.

kubectl set env deployment/karpenter -n karpenter \
  --list | grep FEATURE_GATES

#Kapan NodeOverlay Lebih Baik

Pertimbangkan NodeOverlay ketika perubahan yang dilakukan bersifat konfigurasi, bukan perubahan pada struktur instance. Contohnya memperbarui userData untuk memasang dependensi tambahan, atau menyesuaikan konfigurasi yang dibaca saat boot. Sebaliknya, perubahan yang mengubah kernel atau membutuhkan disk baru tetap lebih baik ditangani dengan replasemen penuh.

#Kesalahan Umum

#Mengabaikan Drift Annotation

Drift yang dibiarkan menumpuk membuat cluster berjalan di atas fondasi yang tidak sesuai konfigurasi. Pantau annotation karpenter.sh/drifted secara rutin dan pastikan perbaikan berjalan.

#Terlalu Mengandalkan NodeOverlay

NodeOverlay menggoda karena terlihat murah, tetapi menerapkan overlay pada konfigurasi yang seharusnya diganti secara penuh justru menambah risiko. Gunakan fitur ini secara selektif.

#Penutup

Drift detection adalah mekanisme Karpenter untuk memastikan cluster tidak berjalan jauh dari yang diinginkan. Dengan deteksi otomatis, annotation perlindungan, dan NodeOverlay untuk kasus yang tepat, kalian bisa menjaga node tetap sesuai template tanpa mengorbankan ketersediaan.

Inti yang harus dibawa pulang:

• Drift adalah selisih template dan realita — AMI, security group, dan instance type adalah contoh pemicu utamanya.
• Drift ditangani seperti disruption — node di-drain dan diganti mengikuti template terbaru.
• do-not-drift adalah pengecualian — gunakan untuk proses yang tidak boleh terputus, dengan konsekuensi yang disadari.
• NodeOverlay hemat replasemen — fitur alpha untuk pembaruan di tempat, bukan pengganti replasemen penuh.

Di episode 12, kalian akan belajar memantau Karpenter lewat metrik Prometheus seperti karpenter_nodes_* dan karpenter_pods_*, membangun dashboard Grafana, serta menyusun alert untuk pod yang Pending terlalu lama. Sampai jumpa!