Belajar Multigress - Configuration Management & GitOps

#Pendahuluan

Mengubah gateway lewat kubectl apply sembarangan adalah resep bencana: tidak ada riwayat, tidak ada review, dan sulit dirollback. Episode 11 memperkenalkan configuration management dan GitOps untuk konfigurasi Multigress — menyimpan semua manifest di Git, memvalidasi setiap perubahan, dan menerapkan pola rollout yang aman.

Prinsip GitOps sederhana: Git adalah sumber kebenaran, dan agent seperti Argo CD atau Flux menyinkronkan apa yang ada di Git ke cluster. Perubahan dimulai sebagai pull request, bukan sebagai perintah kubectl.

#Menyimpan Manifest Multigress di Git

#Struktur Repo yang Disarankan

Pisahkan konfigurasi per environment dan per fungsi. Contoh struktur:

config/
  base/
    gateway.yaml
    gatewayclass.yaml
  overlays/
    staging/
      kustomization.yaml
      httproute-tenant-a.yaml
    prod/
      kustomization.yaml
      httproute-tenant-a.yaml
      securitypolicy.yaml

Bagian base berisi manifest yang sama untuk semua environment, sedangkan overlays menambahkan perbedaan per environment. Ini memakai pola Kustomize yang umum di ekosistem GitOps.

#Menerapkan dengan Argo CD

Argo CD akan menyinkronkan aplikasi ke cluster:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: multigress-config
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/multigress-gitops
    targetRevision: HEAD
    path: config/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: multigress-system
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Perintah kubectl get app multigress-config -n argocd menampilkan status sinkronisasi. Dengan selfHeal: true, setiap perubahan manual di cluster akan dikembalikan ke kondisi Git — inilah yang membuat konfigurasi kembali terkendali.

#Memvalidasi Perubahan Konfigurasi dan Pola Rollout

#Validasi Sebelum Merge

Jangan pernah membiarkan manifest yang salah masuk ke cluster. Validasi dilakukan berlapis di pipeline CI (detail di episode 19):

kubectl apply --dry-run=client -f config/overlays/prod -k

Perintah kubectl apply --dry-run=client -k config/overlays/prod memeriksa sintaks tanpa mengubah cluster. Untuk validasi skema terhadap CRD, bisa memakai tool seperti kubeconform:

kubeconform -strict -summary -c \
  config/overlays/prod/httroute-tenant-a.yaml

Validasi ini menangkap typo field sebelum manifest menembus Argo CD.

#Preview Perubahan

Sebelum sync, lihat perbedaan antara Git dan cluster:

argocd app diff multigress-config

Perintah argocd app diff multigress-config menampilkan persis apa yang akan berubah. Gabungkan dengan pola canary dari episode 9 untuk perubahan yang lebih besar dari sekadar route.

#Rollout Pattern untuk Konfigurasi

Perubahan konfigurasi gateway juga perlu pola rollout:

• Perubahan kecil seperti weight: langsung, bisa dipatch.
• Perubahan listener atau TLS: terapkan saat window, pantau error rate.
• Perubahan arsitektur seperti pindah namespace: pakai pola blue-green route.

Setiap pola didokumentasikan dalam runbook — topik yang akan kita sempurnakan di episode 21.

#Mengelola Overlay Antar Environment

#Perbedaan Environment dalam Overlay

Environment staging dan prod berbeda dalam beberapa hal: hostname, rate limit, dan jumlah replika. Overlay memusatkan perbedaan tersebut:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
  - httproute-tenant-a.yaml
patches:
  - target:
      kind: HTTPRoute
      name: tenant-a-route
    patch: |-
      - op: replace
        path: /spec/hostnames
        value:
          - staging.example.com

Overlay staging mengganti hostname menjadi staging.example.com. Manifes base tetap bersih dari perbedaan environment — perubahan apa pun cukup dilakukan di satu tempat.

#Memastikan Konsistensi

Cek bahwa semua environment masih ter-render tanpa error:

kubectl kustomize config/overlays/staging > /dev/null
kubectl kustomize config/overlays/prod > /dev/null

Dua perintah di atas memastikan overlay staging dan prod valid. Perintah kubectl kustomize config/overlays/prod menghasilkan manifest akhir yang akan diterapkan — inilah yang sebenarnya disinkronkan Argo CD.

#Penutup

Episode 11 menempatkan konfigurasi Multigress di tempat yang benar: di Git. Kalian tahu cara menyusun base dan overlay, memvalidasi perubahan sebelum sync, serta menerapkan pola rollout yang aman untuk setiap jenis perubahan.

Inti yang harus dibawa pulang:

• Git adalah sumber kebenaran; Argo CD atau Flux menyinkronkan ke cluster.
• Pisahkan base dan overlays per environment.
• Validasi berlapis: dry-run, kubeconform, lalu diff Argo CD.
• Perubahan besar memakai pola rollout, bukan apply langsung.
• Batasi akses tulis langsung ke resource gateway dengan RBAC.

Di episode 12 selanjutnya kita akan membahas security policies & access control — gatekeeping akses dengan AuthorizationPolicy, JWT authentication dan integrasi external auth, serta pengamanan route dengan mutual TLS dan validasi sertifikat. Konfigurasi GitOps kalian adalah tempat yang tepat untuk menambahkan lapisan keamanan ini.