Kubernetes 101: Kustomize

Kubernetes punya ekosistem luas banget, terus berkembang, dan punya banyak alat buat nyederhanain, ngelancarin, dan ngoptimalin deployment aplikasi. Di tengah-tengah semuanya, ada dua nama yang sering muncul kalo ngomongin konfigurasi dan deployment: Helm dan Kustomize.

Pendahuluan

Kubernetes punya ekosistem yang luas banget, terus berkembang, dan punya banyak alat buat nyederhanain, ngelancarin, dan ngoptimalin deployment aplikasi. Di tengah-tengah semuanya, ada dua nama yang sering muncul kalo ngomongin konfigurasi dan deployment: Helm dan Kustomize.

Walaupun Helm udah cukup lama eksis dan jadi package manager terkenal buat Kubernetes, Kustomize makin lama makin banyak dipake karena ngasih pendekatan unik buat konfigurasi aplikasi.

Artikel ini bakal ngebahas lebih dalam tentang Kustomize, ngejelasin manfaatnya, kapan waktu yang tepat buat makainya, dan ngebandinginnya sama Helm.

Apa itu Kustomize?

Sebagai platform orkestrasi container, Kubernetes butuh konfigurasi detail lewat file manifest biar bisa jalan. Makin gede proyeknya, makin ribet juga ngatur konfigurasi buat berbagai environment development, staging, production. Nah, di sinilah Kustomize bantu, ngasih pendekatan unik buat manajemen konfigurasi yang emang dibuat khusus buat Kubernetes.

Kustomisasi Tanpa Templating

Nggak kayak alat manajemen konfigurasi lainnya, Kustomize nggak pake templating. Biasanya, templating butuh placeholder di file asli yang nantinya diganti sama nilai sebenarnya. Tapi, Kustomize bekerja dengan menambahkan perubahan langsung ke file manifest asli, jadi file aslinya tetap nggak berubah.

Layering Konfigurasi

Inti dari Kustomize itu layering konfigurasi. Kamu bisa mulai dari konfigurasi standar kamu, atau base. Di atas base ini, kamu bisa nambahin layer (atau overlay) perubahan buat skenario atau lingkungan tertentu.

Bayangin kamu punya deployment standar buat microservice. Di lingkungan development, kamu mungkin mau connect ke mock database. Di produksi, connect ke database utama lo. Dengan Kustomize, base-nya ngejelasin deployment standar, dan overlay-nya ngejelasin perubahan buat lingkungan development dan produksi.

Komponen Utama Kustomize

Base: Ini adalah konfigurasi dasar. Misalnya, base bisa aja nge-define Deployment Kubernetes pake dua replika dari container image tertentu.

Overlay: Dibangun di atas bases, overlays ngasih modifikasi. Lanjutin contoh tadi, overlay bisa ngubah base buat nyebutin sampe sepuluh replika, khusus buat lingkungan produksi.

kustomization.yaml: Bagian penting dari Kustomize, file ini ngatur gimana biar semua potongan ini nyambung. Dia ngereferensi resource, ngejelasin patch, dan bahkan bisa ngatur variabel.

Keuntungan Pakai Kustomize

Kustomize bukan satu-satunya alat buat manajemen konfigurasi di dunia Kubernetes, tapi dia punya keunggulan unik:

Manajemen Deklaratif yang Sederhana

Dengan Kustomize, fokusnya pindah dari gimana cara mengubah konfigurasi ke apa hasil akhirnya yang diinginkan. Pendekatan deklaratif ini cocok banget sama filosofi Kubernetes, bikin Kustomize jadi pasangan yang pas.

Contoh: Daripada nulis skrip yang bilang replace X with Y (imperative), kamu cukup bilang I want it to be Y (declarative).

Penanganan Konfigurasi yang Simpel

Karena nggak perlu mesin templating terpisah, Kustomize bikin kurva pembelajaran buat pengguna baru jadi lebih landai. Manifes Kubernetes asli nggak disentuh, dan patch atau perubahan dijelaskan secara eksplisit di overlay.

Pelestarian Manifes Asli

Salah satu poin terkuat dari Kustomize itu berkat sifatnya yang non-intrusif. Manifes asli tetap nggak disentuh, buat mastiin konfigurasi tetap konsisten dan bisa ditelusuri. Overlay bikin perubahan diterapkan dengan transparan tanpa merusak maksud asli dari manifes tersebut.

Peningkatan Reusabilitas dan Konsistensi

Dengan model base dan overlay di Kustomize, konfigurasi umum bisa didefinisikan sekali dan dipakai ulang di berbagai lingkungan. Ini memastikan konsistensi sambil meminimalkan redundansi dan potensi kesalahan.

Kustomize vs. Helm

Meski Helm dan Kustomize sama-sama bertujuan buat nyederhanain proses deployment di Kubernetes, mereka punya filosofi dan metodologi yang beda. Sini, OnXP kasih tau!

Pendekatan Kustomize

Kustomize fokus buat kustomisasi manifest YAML Kubernetes asli pake metode base-and-overlay. Kustomize nggak pake format templating baru, tapi langsung kerja dengan manifest Kubernetes yang asli. Dia ngerti kapan harus pake Kustomize bisa sama pentingnya kayak ngerti fungsinya:

Konfigurasi Lingkungan yang Beda: Proyek biasanya melibatkan banyak lingkungan, masing-masing punya sedikit perbedaan. Dengan pendekatan berlapis Kustomize—pake base dan overlay—ngatur perbedaan ini jadi lebih gampang dan jelas.

Contohnya, perusahaan mungkin punya konfigurasi yang beda buat pengembangan lokal, testing CI/CD, staging, dan produksi. Dengan Kustomize, mereka bisa punya base yang umum sama overlay buat tiap lingkungan spesifik, jadi perbedaannya jelas dan nggak bikin konfigurasi jadi berantakan.

Menghindari Beban Templating: Kalau tim atau individu lebih suka langsung ngelola manifest Kubernetes asli tanpa ribet sama templating engine, Kustomize jadi pilihan yang lebih straightforward.

Workflow GitOps: GitOps itu cara manajemen cluster Kubernetes dan pengiriman aplikasi dengan menggunakan Git sebagai sumber kebenaran untuk infrastruktur dan aplikasi yang deklaratif.

Karena Kustomize sifatnya deklaratif dan bisa layering konfigurasi, dia cocok banget sama prinsip GitOps. Alat-alat kayak ArgoCD atau Flux yang mendukung GitOps biasanya juga bisa integrasi langsung sama Kustomize.

Pendekatan Helm

Helm ngenalin konsep yang namanya “chart” – ini tuh kayak paket lengkap aplikasi Kubernetes. Satu chart udah ada semua yang diperlukan buat jalanin aplikasi, alat, atau layanan di cluster Kubernetes.

Helm juga punya templating engine yang bikin kontennya bisa di-generate secara dinamis sesuai dengan nilai yang kamu kasih pas instalasi.

Perbandingan

Penggunaan Kustomize dan Helm

Kapan Harus Pakai Kustomize:

1. Abstraksi Minimal: Kalo kamu lebih suka kerja deket sama YAML Kubernetes asli tanpa harus pusingin templating lain, Kustomize pas banget tuh.
2. Konfigurasi Lingkungan Berbeda: Metode base-and-overlay-nya Kustomize jago banget buat ngejaga konfigurasi umum sambil nerapin patch khusus buat tiap lingkungan. Jadi, bisa lebih jelas bedain dan ngurangin konfigurasi yang melenceng.
3. Konfigurasi Stateless: Kustomize itu stateless. Jadi kalo kamu butuh alat yang cuma nerapin konfigurasi tanpa ngelacak state, Kustomize lebih simpel.
4. Workflow GitOps: Karena sifatnya yang deklaratif dan kompatibel sama manifest Kubernetes asli, Kustomize sering jadi pilihan buat workflow GitOps.

Kapan Harus Pakai Helm:

1. Aplikasi Paket: Kalo kamu butuh aplikasi yang udah dikemas dan bisa di-deploy cuma dengan satu perintah, chart Helm pilihan yang tepat. Helm Hub nawarin banyak chart dari komunitas buat software populer.
2. Manajemen Rilis: Helm melacak setiap deployment sebagai 'release'. Jadi, kalo kamu butuh riwayat detail rilis, rollback, dan manajemen versi, Helm ini keren banget.
3. Konfigurasi Dinamis: Templating di Helm memungkinkan kamu buat bikin manifest secara dinamis. Jadi, kalau kamu perlu bikin konfigurasi yang beda banget berdasarkan nilai input, Helm lebih cocok.
4. Manajemen Dependensi: Chart Helm bisa mendefinisikan dependensi ke chart lain, jadi kamu bisa ngatur deployment aplikasi yang saling bergantung dengan lebih mudah dan terkoordinasi.

Kustomize In Action

Biar kamu semakin paham Gambaran dan kegunaan Kustomize, nih OnXP kasih contoh praktisnya, yang ngebahas fitur-fitur kunci dan kegunaannya.

Konfigurasi Dasar:

Misalnya kita punya aplikasi simpel—sebuah web server. Begini kira-kira konfigurasi dasarnya (base/deployment.yaml):

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: simple-web-server
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: web-server
        image: example-web-server:1.0

Bikin Overlay buat Development:

Sekarang, buat environment development kita. Ini yang kita mau:

1. Pake image yang beda dengan tag dev
2. Kurangin jumlah replika jadi 1 biar lebih hemat resource

Kita bikin overlay buat development:

# overlays/dev/kustomization.yaml
bases:
- ../../base
patchesStrategicMerge:
- deployment-dev.yaml

# overlays/dev/deployment-dev.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: simple-web-server
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: web-server
        image: example-web-server:dev

Dengan konfigurasi di atas, kalo kamu ngejalanin

$ kubectl apply -k overlays/development/ hasilnya bakal nge-deploy image web server yang ditag dev dengan satu replika aja, yang pas banget buat environment development kita.

Kesimpulan

 Jadi, intinya Kustomize itu solusinya buat masalah penting di Kubernetes—alat yang bikin konfigurasi jadi lebih gampang diubah tanpa bikin jauh dari file manifest Kubernetes yang asli. Dengan cara kerja bases dan overlays, Kustomize bikin semuanya jadi simpel, jelas, dan bisa dipakai ulang.

Di dunia cloud-native sekarang, di mana infrastruktur sebagai kode udah jadi hal biasa dan GitOps lagi ngetren, Kustomize jadi salah satu alat yang menonjol. Alat ini gak cuma ngebantu manajemen konfigurasi, tapi juga bikin semua prosesnya terkontrol dengan versi, bisa dilacak, dan gampang direplikasi.

Gitu deh, kayak alat lainnya, penting banget buat evaluasi kebutuhan kamu, infrastruktur yang udah ada, dan preferensi tim.

Kustomize punya banyak fitur keren dan kelebihan, tapi yang paling oke adalah cara dia bikin konfigurasi yang tadinya ribet jadi lebih gampang dan ngebantu proses deploy di berbagai lingkungan.

Karena Kubernetes masih jadi andalan di dunia orkestrasi kontainer, paham dan manfaatin alat kayak Kustomize bakal jadi keuntungan besar buat developer, operator, dan organisasi kamu.