Kustomize #

Mengelola manifest Kubernetes untuk berbagai lingkungan deployment (seperti development, staging, dan production) sering kali berujung pada masalah duplikasi file. Kita sering kali tergoda untuk menyalin seluruh file manifest YAML dari satu direktori lingkungan ke direktori lainnya, lalu mengubah beberapa baris konfigurasi secara manual. Praktik copy-paste ini sangat berisiko karena ketika ada pembaruan pada konfigurasi dasar (misalnya penambahan kontainer sidecar atau perubahan health check probe), kita harus memperbarui semua file duplikat tersebut satu per satu. Kustomize hadir untuk menyelesaikan masalah ini dengan pendekatan bebas template (template-free). Sebagai alat manajemen konfigurasi bawaan yang terintegrasi langsung ke dalam kubectl sejak versi 1.14, Kustomize memungkinkan kita mendefinisikan konfigurasi dasar sekali saja (base), lalu membuat penyesuaian khusus lingkungan (overlays) melalui mekanisme dekorasi dan patching deklaratif murni tanpa merusak file YAML asli.

Filosofi Tanpa Template (Template-Free) #

Sebagian besar alat manajemen paket seperti Helm menggunakan mesin template teks (seperti Go Templates) yang menyisipkan variabel dinamis ke dalam manifest menggunakan penanda khusus (seperti {{ .Values.replica }}). Pendekatan ini memiliki beberapa keterbatasan:

• YAML Tidak Valid Secara Sintaksis: File template Helm sebelum dikompilasi bukanlah YAML yang valid. Hal ini membuat kita tidak bisa memvalidasinya menggunakan parser YAML standar atau perkakas linter IDE sebelum proses rendering selesai dilakukan.
• Kerumitan Logika: Seiring berjalannya waktu, template cenderung dipenuhi dengan logika kondisional (if/else) dan perulangan (range) yang rumit. Hal ini membuat manifest sulit dibaca dan dipelihara oleh anggota tim yang tidak terbiasa dengan sintaksis template tersebut.
• Risiko Injection: Kesalahan penanganan spasi atau tipe data saat melakukan rendering teks dapat menyebabkan kegagalan parsing manifest atau celah keamanan injeksi konfigurasi.

Kustomize mengambil pendekatan yang sangat berbeda. Seluruh berkas konfigurasi di dalam Kustomize adalah berkas YAML Kubernetes murni yang valid. Kustomize tidak melakukan interpolasi teks, melainkan membaca dokumen YAML tersebut ke dalam memori sebagai struktur data pohon objek (object tree), melakukan transformasi terstruktur (seperti mengganti nama, menambah label, atau menimpa nilai properti), lalu mencetak kembali manifest YAML yang bersih.

Arsitektur dan Alur Kerja Kustomize #

Kustomize bekerja dengan memproses file kustomization.yaml yang mendefinisikan sumber daya dasar (resources), generator, transformer, dan aturan patch yang ingin diterapkan. Alur kerja kompilasi Kustomize digambarkan dalam diagram berikut:

flowchart TD
    BaseDir["Base Directory (base/)"] -->|"resources"| KustEngine["Kustomize Engine"]
    OverlayDir["Overlay Directory (overlays/production/)"] -->|"resources & bases"| KustEngine
    
    subgraph EnginePipeline["Pipeline Kustomize Engine"]
        direction TB
        GeneratorStage["1. ConfigMap/Secret Generators"] --> TransformerStage["2. Built-in Transformers (labels, annotations, namespace)"]
        TransformerStage --> PatchStage["3. Patching Phase (Strategic Merge & JSON Patches)"]
    end
    
    KustEngine --> EnginePipeline
    EnginePipeline -->|"Output Manifests"| FinalYAML["Final Plain YAML Manifests"]
    FinalYAML -. "kubectl apply -k" .-> K8sAPI["Kubernetes API Server"]

Ketika kita menjalankan perintah Kustomize, pipeline internal bekerja dalam urutan berikut:

1. Tahap Generator: Kustomize membuat sumber daya baru seperti ConfigMap dan Secret berdasarkan berkas teks, properti, atau literal yang ditentukan. Objek yang dihasilkan akan disisipkan ke dalam daftar manifest dengan nama yang ditambahkan hash suffix unik.
2. Tahap Transformer: Kustomize menerapkan aturan transformasi global secara hierarkis. Hal ini mencakup pengubahan namespace target, penambahan prefix/suffix nama sumber daya, penambahan label global (commonLabels), serta penulisan ulang tag citra kontainer (image tag overrides).
3. Tahap Patching: Kustomize menimpa atau menyisipkan properti spesifik ke objek tertentu menggunakan metode Strategic Merge Patch atau JSON Patch (RFC 6902). Output akhir dari proses ini adalah manifest YAML murni yang siap dikirimkan ke API Server.

Struktur Direktori Standar Produksi #

Untuk mengimplementasikan Kustomize secara bersih, kita harus memisahkan secara tegas antara kode dasar (base) yang berisi arsitektur aplikasi secara umum, dan kode varian (overlays) yang berisi konfigurasi spesifik untuk masing-masing lingkungan operasional.

k8s/
├── base/                         # Konfigurasi dasar yang diwarisi semua lingkungan
│   ├── kustomization.yaml        # Daftar resource dasar yang dikelola
│   ├── deployment.yaml           # Manifest deployment vanilla (tanpa modifikasi lingkungan)
│   ├── service.yaml              # Abstraksi port jaringan internal aplikasi
│   └── configmap.yaml            # Kerangka konfigurasi default aplikasi
└── overlays/                     # Penyesuaian khusus untuk tiap lingkungan
    ├── development/              # Varian lingkungan Development
    │   ├── kustomization.yaml    # Hubungkan ke base & atur override skala kecil
    │   └── deployment-patch.yaml # Patch resource limits dan env dev
    ├── staging/                  # Varian lingkungan Staging
    │   ├── kustomization.yaml
    │   └── deployment-patch.yaml
    └── production/               # Varian lingkungan Production (Skala Besar)
        ├── kustomization.yaml
        ├── deployment-patch.yaml # Konfigurasi resource limit tinggi & replika banyak
        └── hpa.yaml              # Sumber daya HPA (hanya aktif di lingkungan produksi)

Implementasi Komponen Base #

Mari kita definisikan komponen dasar (base) terlebih dahulu. File di dalam folder base/ ini tidak boleh dimodifikasi secara langsung ketika kita hanya ingin mengubah nilai konfigurasi untuk lingkungan tertentu.

1. base/kustomization.yaml #

Berkas ini bertindak sebagai berkas indeks yang memberi tahu Kustomize file manifest mana saja yang menjadi bagian dari aplikasi dasar kita.

# File: k8s/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# Menyatakan semua manifest Kubernetes yang dikelola di tingkat dasar
resources:
  - deployment.yaml
  - service.yaml
  - configmap.yaml

# Menambahkan label standar ke semua sumber daya dasar untuk kemudahan pelacakan
commonLabels:
  app.kubernetes.io/part-of: core-banking
  app.kubernetes.io/component: transaction-api

2. base/deployment.yaml #

Ini adalah cetak biru (blueprint) Deployment aplikasi kita. Kita menulis spesifikasi kontainer standar di sini.

# File: k8s/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: transaction-api # Nama vanilla tanpa prefix/suffix lingkungan
spec:
  replicas: 1           # Default jumlah replika minimal
  selector:
    matchLabels:
      app: transaction-api
  template:
    metadata:
      labels:
        app: transaction-api
    spec:
      containers:
      - name: app-container
        image: registry.company.com/banking/transaction-api:latest
        ports:
        - containerPort: 8080
          name: http
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 300m
            memory: 256Mi
        readinessProbe:
          httpGet:
            path: /healthz/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

3. base/service.yaml #

Abstraksi layanan port jaringan dasar untuk menghubungkan lalu lintas internal kluster.

# File: k8s/base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: transaction-api
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: transaction-api

4. base/configmap.yaml #

Kerangka konfigurasi dasar aplikasi yang bersifat non-sensitif.

# File: k8s/base/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: "localhost"
  DB_PORT: "5432"
  LOG_LEVEL: "info"

Implementasi Komponen Overlays (Kasus Lingkungan Production) #

Sekarang kita akan menulis varian konfigurasi untuk lingkungan production. Pada lingkungan ini, kita ingin meningkatkan jumlah replika menjadi 5, mengonfigurasi batas sumber daya kontainer (resource limits) yang lebih tinggi, mengarahkan aplikasi ke database produksi eksternal, dan menambahkan fitur Horizontal Pod Autoscaler (HPA) yang tidak dibutuhkan di lingkungan development.

1. overlays/production/kustomization.yaml #

Berkas kustomisasi di tingkat overlay ini mengimpor komponen dasar dan menerapkan aturan modifikasi khusus.

# File: k8s/overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# Mengarahkan relative path ke direktori base
resources:
  - ../../base
  - hpa.yaml # Tambahkan resource HPA yang hanya ada di production

# Mengubah namespace target secara otomatis untuk semua resource
namespace: prod-banking

# Memberikan prefix pada nama resource untuk membedakannya secara visual di kluster
namePrefix: prod-
# Hasil: transaction-api -> prod-transaction-api

# Melakukan override tag citra kontainer ke versi rilis produksi yang stabil
images:
  - name: registry.company.com/banking/transaction-api
    newTag: v1.4.2

# Menambahkan label spesifik lingkungan secara global
commonLabels:
  environment: production
  tier: backend

# Menambahkan anotasi pelacakan perubahan ke seluruh manifest
commonAnnotations:
  kubernetes.io/change-cause: "Pembaruan rilis ke versi v1.4.2 untuk performa tinggi"

# Menerapkan patch modifikasi spesifik ke objek Deployment
patches:
  - path: deployment-patch.yaml
    target:
      kind: Deployment
      name: transaction-api

2. overlays/production/deployment-patch.yaml #

Di dalam file patch ini, kita hanya menulis bagian struktur YAML yang ingin kita ubah atau tambahkan. Kita tidak perlu menulis ulang seluruh spesifikasi Deployment dasar.

# File: k8s/overlays/production/deployment-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: transaction-api # Harus cocok dengan nama resource di base
spec:
  replicas: 5           # Naikkan replika menjadi 5 untuk ketersediaan tinggi di produksi
  template:
    spec:
      containers:
      - name: app-container # Kustomize mencocokkan container berdasarkan name
        resources:
          # Naikkan batas sumber daya untuk menangani lalu lintas produksi
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 2000m
            memory: 2Gi
        env:
          - name: APP_ENV
            value: "production"
          - name: DB_HOST
            value: "prod-db-cluster.internal.company.com" # Arahkan ke DB produksi

3. overlays/production/hpa.yaml #

Sumber daya tambahan yang hanya diaktifkan pada lingkungan produksi untuk melakukan auto-scaling secara dinamis.

# File: k8s/overlays/production/hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: transaction-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: prod-transaction-api # Perhatikan penulisan nama harus memperhitungkan prod- prefix
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 75

Mekanisme Patching Secara Mendalam #

Kustomize menyediakan dua cara utama untuk melakukan penyesuaian (patching) manifest dasar: Strategic Merge Patch dan JSON Patch (RFC 6902). Memahami perbedaan keduanya sangat krusial saat merancang perubahan konfigurasi yang kompleks.

1. Strategic Merge Patch (SMP) #

Strategic Merge Patch adalah cara bawaan Kubernetes untuk menggabungkan dua dokumen YAML. Mekanisme ini bekerja secara cerdas dengan menganalisis skema objek Kubernetes. SMP menggunakan atribut khusus yang disebut dengan merge key untuk mencocokkan elemen di dalam daftar (array/list), alih-alih menimpa seluruh daftar tersebut seperti pemrosesan JSON standar.

Sebagai contoh, pada objek Deployment, daftar kontainer (containers) menggunakan name sebagai merge key.

# BASE SPECIFICATION:
spec:
  template:
    spec:
      containers:
      - name: app-container
        image: app:latest
      - name: log-exporter
        image: fluentd:v1

# PATCH SPECIFICATION:
spec:
  template:
    spec:
      containers:
      - name: app-container # SMP menemukan container dengan name yang sama
        image: app:v1.4.2   # Hanya baris ini yang diubah

Jika Kustomize mendeteksi kecocokan merge key, ia akan menggabungkan properti internal kontainer tersebut (seperti mengganti citra atau menambahkan environment variables). Elemen kontainer kedua (log-exporter) akan tetap dipertahankan tanpa perubahan meskipun tidak ditulis ulang di file patch.

2. JSON Patching (RFC 6902) #

JSON Patch adalah standar industri untuk memanipulasi dokumen terstruktur menggunakan daftar instruksi operasi yang sangat presisi seperti add, remove, replace, move, dan copy. Pendekatan ini sangat berguna ketika kita ingin mengubah properti yang tidak memiliki merge key (misalnya mengubah port pertama di dalam array port tanpa nama, atau menghapus elemen volume tertentu).

Untuk menerapkan JSON Patch, kita menulis daftar operasi langsung di dalam kustomization.yaml di bawah blok patches:

# Contoh JSON Patch di kustomization.yaml
patches:
  - target:
      kind: Deployment
      name: transaction-api
    patch: |-
      # Operasi 1: Mengganti replicas secara langsung
      - op: replace
        path: /spec/replicas
        value: 3
      
      # Operasi 2: Menghapus probe kesiapan (readiness probe) dari container pertama (index 0)
      - op: remove
        path: /spec/template/spec/containers/0/readinessProbe
      
      # Operasi 3: Menyisipkan environment variable baru ke akhir array env
      - op: add
        path: /spec/template/spec/containers/0/env/-
        value:
          name: NEW_PROD_API_KEY
          value: "secure-prod-token-value"      

Generator Konfigurasi: ConfigMap dan Secret #

Salah satu tantangan terbesar dalam mengoperasikan aplikasi di Kubernetes adalah memperbarui konfigurasi tanpa menghentikan layanan. Secara bawaan, jika kita memperbarui data di dalam ConfigMap eksternal dan menerapkan perubahan tersebut dengan kubectl apply, Kubernetes tidak akan memicu restart otomatis pada Pod yang merujuk ConfigMap tersebut jika ConfigMap di-mount sebagai environment variables. Akibatnya, aplikasi kita tetap berjalan dengan konfigurasi lama sampai Pod tersebut terhapus secara manual atau ter-restart karena alasan lain.

Kustomize menyelesaikan masalah ini secara elegan melalui ConfigMapGenerator dan SecretGenerator.

# File: k8s/overlays/production/kustomization.yaml (Potongan kode generator)
configMapGenerator:
  - name: prod-app-config
    behavior: replace # Menggantikan configmap dasar bernama 'app-config'
    files:
      - configs/app.properties # Membaca konfigurasi dari berkas eksternal
    literals:
      - DB_HOST="prod-db-cluster.internal.company.com"
      - LOG_LEVEL="error"

secretGenerator:
  - name: prod-db-secrets
    type: Opaque
    literals:
      - DB_PASSWORD="SuperSecretProductionPasswordInput!"

Mekanisme Hash Suffix dan Rolling Update Otomatis #

Ketika kita menjalankan proses kompilasi Kustomize, generator ini akan membaca konten file atau literal, lalu membuat objek ConfigMap baru dengan menyisipkan hash konten unik di belakang namanya (misalnya prod-app-config-7hgk9m2x).

Isi Berkas configs/app.properties:
  max_connections=100  --> Kompilasi --> ConfigMap: prod-app-config-7hgk9m2x

Ubah Nilai Berkas configs/app.properties:
  max_connections=250  --> Kompilasi --> ConfigMap: prod-app-config-g8k2m9x4

Secara dinamis, Kustomize akan memindai seluruh manifest Deployment kita yang merujuk pada prod-app-config dan menulis ulang nama referensi tersebut untuk dicocokkan dengan nama yang mengandung hash baru (prod-app-config-g8k2m9x4). Karena spesifikasi nama ConfigMap di dalam objek Deployment berubah, Kubernetes API Server mendeteksi ini sebagai pembaruan template pod yang valid dan secara otomatis memicu proses Rolling Update untuk menggantikan Pod lama dengan Pod baru yang membawa konfigurasi termutakhir.

built-in Transformers Utama #

Kustomize menyediakan perkakas transformasi bawaan (transformers) untuk mempercepat modifikasi metadata massal tanpa perlu menulis berkas patch yang berulang-ulang.

1. namespace #

Transformer ini memindahkan seluruh sumber daya yang dideklarasikan di dalam file kustomisasi ke namespace tertentu. Jika namespace tersebut belum ada di manifest dasar, Kustomize akan menyisipkannya secara otomatis pada semua objek yang mendukung lingkup namespace (namespaced-scope resources) seperti Pods, Services, Deployments, dan Ingress, serta memperbarui referensi binding RBAC (seperti RoleBinding).

namespace: prod-finance-services

2. commonLabels & commonAnnotations #

Menambahkan label atau anotasi ke semua sumber daya dan selektor pencocokan secara otomatis. Ini sangat membantu untuk standarisasi tata kelola kluster (cluster governance). Kustomize memastikan bahwa label baru juga disisipkan ke dalam spec/selector/matchLabels dan spec/template/metadata/labels pada Deployment agar relasi Pod tidak terputus.

commonLabels:
  billing-code: "dept-908"
  compliance: "pci-dss"

3. namePrefix & nameSuffix #

Menyisipkan awalan atau akhiran teks pada kolom metadata/name di seluruh objek. Ini sangat berguna jika kita mendeploy aplikasi yang sama beberapa kali di dalam namespace yang sama untuk tujuan pengujian paralel.

namePrefix: test-
nameSuffix: -v2
# Objek Service 'api' akan berganti nama menjadi 'test-api-v2'

4. images #

Mengubah nama repositori registry, tag rilis, atau nilai digest SHA citra kontainer tanpa perlu mencari jalur kontainer di dalam manifest Deployment secara manual.

images:
  - name: registry.company.com/banking/transaction-api
    newName: registry-backup.company.com/banking/transaction-api-mirror
    newTag: v1.4.2-patch1

Perintah Operasional Kustomize #

Kita dapat menjalankan proses kompilasi Kustomize secara langsung menggunakan CLI kubectl bawaan atau menggunakan biner mandiri kustomize (standalone binary).

1. Preview Manifest Hasil Render #

Sebelum menerapkan manifest ke kluster produksi, jalankan perintah render untuk mencetak hasil kompilasi YAML ke konsol untuk memastikan tidak ada kesalahan struktur spasi atau patching.

# Preview hasil menggunakan kubectl bawaan
kubectl kustomize k8s/overlays/production/

# Preview hasil menggunakan biner kustomize standalone (jika terinstall)
kustomize build k8s/overlays/production/

2. Memeriksa Selisih Konfigurasi (Diff) #

Untuk memvalidasi dampak perubahan sebelum memodifikasi state kluster, gunakan flag diff untuk melihat baris mana saja yang akan berubah.

# Bandingkan keadaan kluster aktif dengan manifest lokal baru
kubectl diff -k k8s/overlays/production/

3. Menerapkan Konfigurasi secara Langsung #

Jika hasil kompilasi dan diff sudah divalidasi dengan aman, kirim payload manifest ke API Server menggunakan opsi direktori kustomisasi (-k).

# Terapkan konfigurasi lingkungan produksi
kubectl apply -k k8s/overlays/production/

# Hapus seluruh resource yang dikelola oleh kustomisasi tersebut
kubectl delete -k k8s/overlays/production/

Perbandingan Komparatif: Kustomize vs Helm #

Kedua alat ini memiliki keunggulan dan skenario penggunaan yang berbeda. Kita harus memilih alat yang sesuai dengan karakteristik arsitektur aplikasi dan kemampuan operasional tim kita.

Skenario Kolaborasi (Helm + Kustomize Post-Rendering) #

Di tingkat produksi perusahaan skala besar, kita tidak harus memilih salah satu dari kedua alat ini. Kita dapat menggabungkan kekuatan keduanya menggunakan teknik Post-Rendering.

Dalam skenario ini, kita menggunakan Helm untuk mengunduh dan melakukan rendering awal terhadap paket kompleks pihak ketiga yang tersedia di internet (misalnya database PostgreSQL Bitnami), kemudian menyalurkan (piping) output YAML hasil render tersebut ke Kustomize untuk menambahkan label kepatuhan internal perusahaan atau melakukan patch keamanan khusus sebelum dikirimkan ke Kubernetes API Server.

# Render helm chart publik -> pipeline ke kustomize lokal -> apply ke kluster
helm template my-postgres oci://registry-1.docker.io/bitnamicharts/postgresql \
  --values values-custom.yaml \
  | kubectl kustomize ./kustomize-patches \
  | kubectl apply -f -

Anti-Pattern dalam Penerapan Kustomize #

Hindari kesalahan desain konfigurasi berikut agar tim kita tidak terjebak dalam masalah kompleksitas baru yang sulit di-maintain:

1. Menyalin Seluruh Isi Manifest dari Base ke Overlays (Copy-Paste Anti-Pattern) #

# k8s/overlays/production/deployment-patch.yaml
# ANTI-PATTERN: Menulis ulang seluruh isi file base/deployment.yaml secara utuh 
# hanya untuk mengubah baris replica atau resource limit.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: transaction-api
spec:
  replicas: 5
  selector:
    matchLabels:
      app: transaction-api
  template:
    metadata:
      labels:
        app: transaction-api
    spec:
      containers:
      - name: app-container
        image: registry.company.com/banking/transaction-api:v1.4.2
        # JANGAN: Menyalin port, probe, volume, dan parameter lain yang identik dengan base!
        ports:
        - containerPort: 8080 
        readinessProbe:
          httpGet:
            path: /healthz/ready
            port: 8080

# ==============================================================================
# BENAR: Tulis HANYA baris yang ingin diganti (Overlay Minimalis).
# Kustomize akan menggabungkan sisanya secara otomatis dari base.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: transaction-api
spec:
  replicas: 5

Jika kita menduplikat seluruh struktur manifest di file patch, kita kehilangan manfaat utama dari Kustomize. Ketika struktur dasar di base/ diubah (misalnya mengganti port container dari 8080 menjadi 9000), deployment di production akan gagal berjalan karena file patch masih mempertahankan port 8080 lama yang menimpa file base.

2. Menyimpan Secret Sensitif Plain-Text di Git Repositori #

# k8s/overlays/production/kustomization.yaml
# ANTI-PATTERN: Menyimpan password rahasia plain-text langsung di repositori Git
secretGenerator:
  - name: database-secret
    literals:
      - DB_PASSWORD="production-cleartext-password-exposed-here" # JANGAN!

Menyimpan kunci rahasia secara plain-text di Git adalah pelanggaran keamanan kritis. Siapa pun yang memiliki akses ke repositori Git dapat melihat kredensial produksi kluster kita.

✓ SOLUSI TERBAIK:
  Gunakan operator eksternal seperti External Secrets Operator (ESO). 
  Di dalam Kustomize, kita hanya mendefinisikan kerangka 'ExternalSecret' 
  yang merujuk ke database secret aman di luar kluster (seperti AWS Secrets Manager atau Vault).

Checklist Audit Konfigurasi Kustomize #

Lakukan audit mandiri pada direktori Kustomize Anda untuk memastikan standar produksi telah terpenuhi:

STRUKTUR FILE & HIERARKI:
  □ Direktori dasar (base) hanya berisi manifest murni yang bebas dari parameter khusus lingkungan.
  □ Folder overlays tidak menduplikat file manifest secara penuh; melainkan hanya berisi patch minimal.
  □ Berkas kustomization.yaml di folder overlay menggunakan target path relative '../../base' secara tepat.
  □ Semua resource yang dikelola terdaftar di bawah array 'resources', bukan diimpor melalui mekanisme eksternal ad-hoc.

MANAJEMEN KONFIGURASI & KEAMANAN:
  □ ConfigMapGenerator digunakan untuk mengelola konfigurasi aplikasi agar memicu rolling update otomatis saat data berubah.
  □ SecretGenerator tidak mengekspos kata sandi atau sertifikat dalam format teks polos (plain-text) ke dalam Git.
  □ Menggunakan transformer 'namespace' untuk memisahkan isolasi beban kerja lingkungan secara bersih di kluster.
  □ Image tag didefinisikan secara deklaratif di bawah blok 'images' di overlay, bukan di-hardcode di deployment-patch.yaml.

VALIDASI DAN DEPLOYMENT:
  □ Pipa CI/CD menjalankan perintah 'kubectl diff -k' sebelum mengeksekusi apply.
  □ Proses rendering mandiri telah diuji dan divalidasi sukses menggunakan perintah 'kubectl kustomize'.
  □ Label global 'commonLabels' disisipkan untuk standarisasi monitoring dan pelacakan kepemilikan aset.

Ringkasan #

• Overlay Tanpa Template — Kustomize mengadopsi prinsip bebas template (template-free) yang mempertahankan kevalidan sintaksis berkas YAML Kubernetes asli sehingga mudah dibaca dan divalidasi.
• Pisahkan Base dan Overlays — Pastikan manifest dasar diletakkan di direktori base/ secara netral, sedangkan parameter khusus lingkungan dikelola secara terpisah di direktori overlays/.
• Optimalkan Suffix Hash ConfigMap — Manfaatkan ConfigMapGenerator untuk membuat suffix hash otomatis demi memicu rolling update Pod saat konfigurasi diubah secara dinamis.
• Pahami Metode Patching — Gunakan Strategic Merge Patch untuk penggabungan cerdas berdasarkan atribut merge key, dan gunakan JSON Patch untuk operasi presisi tingkat tinggi.
• Gunakan Transformers Global — Manfaatkan fitur namespace, commonLabels, dan images untuk melakukan modifikasi metadata massal secara instan pada hasil kompilasi.
• Hindari Drift Konfigurasi — Hindari melakukan perintah modifikasi langsung kubectl edit pasca deployment; seluruh perubahan konfigurasi wajib tercatat di repositori Kustomize Git.

← Sebelumnya: Helm   Berikutnya: kubectl Tips →