Belajar GitOps - FluxCD - Sharding & Performance

#Pendahuluan

Di episode 23 kalian sudah mempelajari multi-cluster management — mengelola banyak klaster dengan pola hub-and-spoke dan distribusi konfigurasi. Namun semakin besar klaster dan semakin banyak resource yang diawasi Flux, muncul pertanyaan berikutnya: apakah semua reconciliation masih berjalan mulus?

Masalahnya bukan sekadar menambah CPU. Di skala tertentu, satu instance Flux mulai kewalahan: ratusan Kustomization, ribuan resource, dan banyak GitRepository yang di-refetch dalam interval yang sama. Ini bukan tanda Flux tidak bisa diskalakan — ini tanda arsitekturnya perlu disesuaikan, persis seperti arsitektur aplikasi.

Pada episode ini kita membahas cara membuat Flux tetap cepat dan andal di skala besar: horizontal sharding, vertical sharding, optimasi kinerja reconciliation, serta pola repository skala besar.

#Horizontal Sharding

#Membagi Beban dengan Beberapa Instance Flux

Horizontal sharding dalam Flux sama dengan sharding database: alih-alih satu instance menangani semua resource, beban dibagi ke beberapa instance, masing-masing menangani subset. Keuntungannya: setiap instance punya resource sendiri, tidak berebut CPU dan memori, dan kegagalan satu shard tidak melumpuhkan semuanya. Sharding diaktifkan sejak bootstrap dengan flag --sharding dan --shard:

flux bootstrap github \
  --owner=devvnull --repository=gitops-production \
  --path=clusters/production \
  --sharding --shard=0/2

flux bootstrap github \
  --owner=devvnull --repository=gitops-production \
  --path=clusters/production \
  --sharding --shard=1/2

Shard kedua dinyatakan 1/2 — bagian kedua dari total dua bagian, dinomori mulai nol.

#Sharding Berdasarkan Namespace

Cara kerja sharding di Flux: setiap resource diberi label yang diturunkan dari hash namespace tempat resource berada. Hasilnya deterministik — namespace yang sama selalu ditangani shard yang sama, sehingga tidak ada dua controller berebut resource. Cek distribusinya dengan label:

kubectl get kustomization -A -l sharding.fluxcd.io/key
kubectl get pod -n flux-system -l app=kustomize-controller

Label sharding.fluxcd.io/key menentukan shard pemilik, dengan nilai hash numerik namespace dimodulo jumlah total shard. Pola ini bisa dipadukan dengan namespace per tenant: setiap tenant jatuh ke shard sendiri, memberi isolasi beban — satu tenant yang deploy besar-besaran tidak memperlambat reconciliation tenant lain.

#Distribusi Beban yang Merata

Distribusi berbasis hash bukan jaminan merata secara matematis. Pantau secara berkala:

flux stats
kubectl top pods -n flux-system

flux stats memberi gambaran jumlah reconciliation; kubectl top pods menunjukkan pemakaian CPU dan memori per controller. Jika satu shard konsisten lebih tinggi, naikkan jumlah shard — misalnya dari 2 menjadi 4 dengan --shard=0/4 sampai --shard=3/4.

#Vertical Sharding

Vertical sharding membagi beban berdasarkan jenis tanggung jawab, bukan kuantitas. Satu klaster bisa menjalankan beberapa instance Flux yang terisolasi dalam namespace masing-masing. Pemisahan paling umum adalah infrastruktur vs aplikasi: Flux infrastruktur mengelola operator, ingress, cert-manager, dan monitoring (jarang berubah, dampak besar), sementara Flux aplikasi mengelola deployment bisnis yang sering berubah dan butuh reconciliation cepat. Pemisahan kedua adalah core vs edge: resource di datacenter pusat versus resource di lokasi terdepan, di mana edge sering membutuhkan sumber yang bisa di-reconcile offline — misalnya mengganti GitRepository dengan OCIRepository yang lebih cepat dan hemat.

#Optimalisasi Kinerja Reconciliation

#Menyetel Interval Reconciliation

Interval yang seragam dan sangat kecil untuk semua resource adalah penyebab pemborosan terbesar di klaster besar. Strategi yang bijak: infrastruktur yang jarang berubah memakai interval: 1h atau lebih; aplikasi aktif 5m sampai 15m; hanya yang kritis yang 1m.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/devvnull/gitops-apps
  ref:
    branch: main

Perhatikan juga timeout pada Kustomization — aturan praktisnya minimal dua kali durasi reconciliation terpanjang yang pernah diukur.

#Resource Limits dan Concurrency

Tanpa batasan, controller bisa memakan resource klaster tanpa batas; dengan batasan terlalu ketat, mereka sering di-oomkill. Mulailah dari nilai konservatif lalu naikkan berdasarkan observasi kubectl top:

resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 1Gi

Selain itu, flag --concurrent pada controller membatasi reconciliation paralel. Default 4 cukup untuk kebanyakan kasus; naikkan hanya jika controller menganggur sementara antrian menumpuk.

#Caching dan Garbage Collection

Flux melakukan caching di beberapa lapis: artifact source (hasil fetch tidak diulang jika tidak berubah), HTTP cache ke registry dan git host, serta discovery cache untuk health assessment. Hindari mengubah spec.ref terlalu sering — setiap perubahan invalidates cache. Cek kapan terakhir source di-fetch dengan flux get sources git -A.

Garbage collection (pruning) menghapus resource yang ada di klaster tetapi tidak ada di Git. Wajib diaktifkan lewat spec.prune:

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

#Pola Skala Besar

#Monorepo vs Polyrepo

Kombinasi yang sering dipakai: monorepo untuk platform (infrastruktur bersama) dan polyrepo untuk aplikasi (setiap tim memegang repo sendiri). Struktur repo yang disarankan kira-kira:

clusters/
  production/
    flux-system/
    infra/
    apps/
apps/
  checkout/overlays/production/
  payment/overlays/production/
platform/
  nginx-ingress/
  cert-manager/
  monitoring/

#Kinerja Git dan Webhook

Pertahankan repo tetap ramping: jangan commit artifact (image cukup dirujuk dengan tag), gunakan ref yang stabil, dan pertimbangkan OCIRepository untuk performa terbaik. Webhook mempercepat deteksi tanpa menunggu interval, lewat Receiver:

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: github-receiver
  namespace: flux-system
spec:
  type: github
  events:
    - "push"
  secretRef:
    name: webhook-token
  resources:
    - apiVersion: source.toolkit.fluxcd.io/v1
      kind: GitRepository
      name: apps

#Penutup

Pada episode 24 ini kalian telah membawa Flux ke skala produksi: horizontal sharding untuk membagi beban berbasis namespace, vertical sharding untuk memisahkan domain tanggung jawab, optimasi kinerja melalui interval, resource limit, caching, dan pruning, serta pola repository skala besar dengan struktur efisien dan optimasi webhook.

Inti yang harus dibawa pulang:

• Sharding horizontal membagi beban ke beberapa instance dengan label berbasis hash namespace — ukur beban dulu sebelum memutuskan jumlah shard.
• Sharding vertical memisahkan domain agar kegagalan dan kebijakan tidak saling menular.
• Interval disesuaikan per resource, bukan seragam minimum — gabungkan dengan webhook untuk latensi dan efisiensi.
• Resource limits, concurrency, dan caching adalah tuas performa utama; awasi dengan kubectl top.
• Pruning wajib aktif agar klaster tidak menumpuk resource yatim.

Sekarang klaster kalian cepat dan stabil. Namun bagaimana kita tahu semuanya sehat? Di episode 25 selanjutnya kita akan membahas Monitoring & Observability — metrik Prometheus, dashboard Grafana, agregasi log, distributed tracing dengan OpenTelemetry, dan alerting untuk reconciliation yang gagal. Pastikan tetap semangat!