Belajar MetalLB - GitOps & Config as Code

#Pendahuluan

Di episode 14 kita menyinggung bahwa GitOps adalah lapisan proteksi terakhir konfigurasi MetalLB. Episode 18 membahas ini secara menyeluruh: bagaimana mengelola semua resource MetalLB sebagai code di repository, menerapkannya lewat Argo CD atau Flux, melakukan versioning, menjalankan review flow, dan menerapkan perubahan secara bertahap.

Mengapa GitOps penting untuk MetalLB? Karena resource MetalLB mengendalikan jaringan cluster. Kesalahan kecil — pool salah, peer salah ASN, advertisement salah referensi — bisa langsung berdampak ke produksi. Dengan GitOps, setiap perubahan melalui review, audit trail tersimpan, dan rollback tinggal satu perintah.

#Konfigurasi MetalLB sebagai Code

#Struktur Repository

Semua resource MetalLB bisa ditulis sebagai file YAML dalam repository. Struktur yang disarankan memisahkan environment:

mkdir -p metallb-config/overlays/production
touch metallb-config/ipaddresspool.yaml
touch metallb-config/l2advertisement.yaml
touch metallb-config/bgpadvertisement.yaml
touch metallb-config/bgppeer.yaml

mkdir -p metallb-config/overlays/production membuat struktur folder untuk konfigurasi dasar dan overlay per environment. File-file ini adalah sumber kebenaran — tidak ada konfigurasi yang dibuat di luar repository.

#Contoh Konfigurasi di Repository

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: prod-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.200-192.168.20.240

Satu perubahan pada file ini adalah satu commit yang bisa di-review, diuji, dan di-rollback — persis seperti perubahan kode aplikasi.

#Menerapkan dengan Argo CD

#Membuat Application Argo CD

Argo CD menerapkan seluruh isi direktori ke cluster secara terus-menerus. Application untuk konfigurasi MetalLB:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: metallb-config
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://github.com/org/metallb-config
    path: overlays/production
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: metallb-system
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

syncPolicy: automated: prune: true, selfHeal: true membuat Argo CD menghapus resource yang hilang dari repository dan memulihkan perubahan manual kembali ke kondisi repository. Dengan ini, kubectl apply manual terhadap resource MetalLB otomatis "dibalikkan" oleh Argo CD.

#Menjalankan Argo CD

kubectl apply -f application.yaml
argocd app get metallb-config

argocd app get metallb-config menampilkan status sinkronisasi. Setelah commit baru ke repository, Argo CD otomatis menerapkan perubahan dan menampilkan status Synced.

#Menerapkan dengan Flux

#Kustomization Flux

Flux memakai Kustomization untuk menerapkan direktori ke cluster:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: metallb-config
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./clusters/production/metallb
  prune: true
  validation: client

validation: client membuat Flux memvalidasi YAML sebelum diterapkan, menangkap syntax error lebih awal. Dengan prune: true, resource yang tidak lagi ada di repository ikut dihapus.

#Menjalankan Flux

flux reconcile kustomization metallb-config
flux get kustomization metallb-config

flux reconcile kustomization metallb-config memicu sinkronisasi manual tanpa menunggu interval. flux get kustomization metallb-config menampilkan status terakhir.

#Versioning, Review, dan Penerapan Bertahap

#Versioning Konfigurasi

Konfigurasi MetalLB sebaiknya di-versioning seperti kode:

• Setiap perubahan adalah commit dengan pesan yang jelas, misalnya feat: tambah prod-pool.
• Gunakan tag atau branch per rilis jika diperlukan.
• Simpan sejarah perubahan untuk audit — siapa mengubah apa dan kapan.

#Review Flow

Sebelum perubahan jaringan disetujui, alur review harus melibatkan pihak yang tepat:

• PR dibuat dari branch fitur ke branch utama.
• Platform engineer meninjau dampak terhadap pool dan advertisement.
• Network engineer meninjau dampak terhadap peering dan routing (jika ada).
• CI menjalankan validasi sederhana, misalnya linter YAML.

#Penerapan Bertahap

Perubahan besar — seperti migrasi versi CRD atau penambahan peer baru — sebaiknya diterapkan bertahap:

• Terapkan di cluster staging dulu, amati beberapa hari.
• Terapkan ke satu node atau satu lingkungan kecil di produksi.
• Pantau metric dan log, baru sebarkan ke seluruh cluster.

#Penutup

Episode 18 menuntaskan GitOps & config as code: semua resource MetalLB sebagai code di repository, penerapan otomatis dengan Argo CD atau Flux, versioning dan review flow, serta penerapan perubahan secara bertahap.

Inti yang harus dibawa pulang:

• Semua resource MetalLB bisa ditulis sebagai file YAML di repository.
• Argo CD menerapkan direktori secara otomatis dengan prune dan selfHeal.
• Flux memakai Kustomization dengan validasi client dan reconciliation.
• Versioning memberi audit trail untuk setiap perubahan jaringan.
• Review melibatkan platform dan network engineer sebelum merge.
• Perubahan besar diterapkan bertahap, mulai dari staging.

Di episode 19 selanjutnya kita akan membahas performance & troubleshooting — diagnostik lewat kubectl get svc, describe svc, events, dan log speaker, pengecekan route BGP di router, serta penanganan masalah umum seperti IP tidak ter-assign, dua Service ber-IP sama, dan upgrade dari v0.15 ke v0.16.