Belajar GitOps - FluxCD - GitOps Toolkit Deep Dive Architecture

#Pendahuluan

Di episode 2 kalian sudah mengenal lima kelompok controller GitOps Toolkit dan posisinya dalam alur rekonsiliasi. Sekarang kita bedah satu per satu: CRD apa saja yang disediakan setiap controller, bagaimana konfigurasi ditulis, dan detail teknis yang membuat masing-masing bekerja. Episode ini adalah referensi teknis inti — kalian boleh kembali ke sini kapan pun bingung dengan istilah di episode praktik.

#Source Controller

Source Controller adalah pintu masuk seluruh alur: ia menarik, memvalidasi, dan menyimpan source ke dalam cluster sebagai objek Kubernetes. Semua controller lain membaca hasil kerja Source Controller.

#GitRepository CRD

Mendefinisikan repository Git yang ditarik secara berkala. Bisa menunjuk ke branch, tag, commit tertentu, atau referensi semver:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: web-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/acme/web-app
  ref:
    semver: ">=1.0.0"
  verify:
    provider: cosign

Perhatikan interval: 1m — ini menentukan seberapa sering FluxCD mengecek Git. Referensi ref mendukung branch, tag, commit, dan semver, plus dukungan submodules dan GPG verification untuk memastikan source tidak diutak-atik.

#HelmRepository dan HelmChart CRDs

HelmRepository menunjuk ke repository chart (misalnya index Helm), sedangkan HelmChart adalah hasil turunan yang dihasilkan FluxCD setelah mengambil index — objek ini yang kemudian dikonsumsi Helm Controller.

#Bucket dan OCIRepository CRDs

Bucket menunjuk ke object storage seperti S3, GCS, atau Azure Blob untuk manifest yang disimpan sebagai artefak. OCIRepository menunjuk ke image OCI yang berisi manifest. Semakin banyak tim memakai pola OCI karena artefaknya immutable dan bisa diverifikasi.

#Verifikasi Source

Source bisa diverifikasi dengan dua mekanisme: GPG (tanda tangan Git commit) dan Cosign (tanda tangan pada artefak OCI). Dengan verifikasi, hanya konten yang ditandatangani oleh key yang dipercaya yang boleh masuk ke cluster.

#Kustomize Controller

Kustomize Controller adalah pekerja utama: ia membaca source (biasanya hasil Source Controller) dan mewujudkan manifest menjadi objek di cluster.

#Kustomization CRD

Objek Kustomization menentukan source mana yang dipakai, path di dalamnya, dan target namespace:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: web-app
  namespace: flux-system
spec:
  sourceRef:
    kind: GitRepository
    name: web-app
  path: ./deploy
  prune: true
  interval: 10m

#Reconciliation Logic

Controller menarik source, memproses manifest (termasuk file kustomization.yaml Kustomize bila ada), lalu menerapkan hasilnya. prune: true mengaktifkan garbage collection: objek yang ada di cluster tapi tidak lagi ada di Git akan dihapus — ini menjaga cluster bersih dan selaras persis dengan repo.

#Dependency dan Health Checking

Kustomization bisa mendeklarasikan ketergantungan ke Kustomization lain lewat dependsOn, sehingga urutan deploy terjamin. Controller juga menilai kesehatan objek hasil rekonsiliasi dengan memeriksa kondisi objek — misalnya menunggu Deployment mencapai ready sebelum menganggap sukses.

#Helm Controller

Helm Controller membawa kekuatan Helm ke dunia deklaratif. Alih-alih menjalankan helm install manual, semua dinyatakan lewat objek HelmRelease.

#HelmRelease CRD

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: nginx
  namespace: web
spec:
  chart:
    spec:
      chart: nginx
      version: ">=4.0.0"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
  values:
    controller.replicaCount: 2

#Release Management dan Values Override

Values diambil dari chart default dan bisa dioverride lewat blok values, file valuesFrom (dari ConfigMap atau Secret), atau referensi chart. Semua strategi ini bisa dipakai bersamaan dengan urutan prioritas yang jelas.

#Rollback dan Drift Detection

Bila upgrade gagal, FluxCD bisa otomatis rollback ke versi release sebelumnya. Helm Controller juga mendeteksi drift: perubahan manual pada release yang tidak ada di Git akan dideteksi dan direkonsiliasi kembali.

#Notification Controller

Notification Controller mengubah FluxCD dari sistem yang senyap menjadi sistem yang komunikatif.

• Event sources: semua controller mengirim event (pulled, applied, failed, dan lainnya) ke Notification Controller.
• Alert providers: event diteruskan ke platform eksternal — Slack, Discord, GitHub, GitLab, email, dan webhook generic.
• Webhook receivers: endpoint di dalam cluster yang menerima panggilan dari Git hosting untuk memicu rekonsiliasi instan, alih-alih menunggu interval.

#Image Automation Controllers

Tiga controller ini menutup loop pembaruan image tanpa campur tangan manusia:

Alurnya: controller memindai registry, membandingkan dengan policy, lalu ImageUpdateAutomation membuat commit yang memperbarui manifest di Git — dan rekonsiliasi normal FluxCD mengambil alih untuk menerapkan versi baru.

#Penutup

Episode 3 melengkapi pemahaman teknis toolkit:

• Source Controller: GitRepository, HelmRepository, HelmChart, Bucket, OCIRepository, verifikasi GPG dan Cosign.
• Kustomize Controller: Kustomization, reconciliation, dependency, health checking, prune dan GC.
• Helm Controller: HelmRelease, values override, rollback, dan drift detection.
• Notification Controller: event sources, alert providers, dan webhook receivers.
• Image Automation: ImageRepository, ImagePolicy, dan ImageUpdateAutomation.

Di episode 4 kita mulai praktik sungguhan: menginstall FluxCD ke cluster kalian — menyiapkan prasyarat, memilih metode instalasi, menjalankan flux bootstrap github, dan memverifikasi seluruh instalasi. Sampai jumpa!