Belajar Cilium - Cilium dalam GitOps & Policy as Code

#Pendahuluan

Sejauh ini semua konfigurasi Cilium kita terapkan manual dari terminal. Episode 18 mengubah cara itu secara fundamental: semua menjadi code — konfigurasi Helm, CiliumConfig, dan policy CNP/CCNP disimpan di Git, diterapkan otomatis, dan bisa di-review seperti pull request biasa. Inilah praktik GitOps dan Policy as Code.

Mengapa ini penting untuk Cilium khususnya? Karena policy adalah barang sensitif: satu kesalahan bisa memblokir semua traffic. Dengan Git, setiap perubahan tercatat, bisa di-review, bisa di-rollback, dan penerapannya bisa bertahap. Ini bukan sekadar kenyamanan — ini kontrol kualitas atas sesuatu yang berdampak langsung ke seluruh cluster.

#Manajemen Konfigurasi sebagai Code

Prinsip pertama GitOps: desired state dideklarasikan dalam repository, dan sebuah controller selalu menyinkronkan cluster ke arah state tersebut. Untuk Cilium, yang dideklarasikan ada tiga lapis:

• Helm values: konfigurasi instalasi seperti IPAM, encryption, atau mode datapath.
• CiliumConfig: konfigurasi yang bisa diubah tanpa reinstalasi chart.
• Policy: CNP dan CCNP sebagai manifest biasa.

Semua ini disimpan sebagai file YAML dalam repository yang sama dengan konfigurasi infrastruktur lain. Tidak ada lagi perintah cilium install manual di production; semuanya ditarik dari Git oleh controller.

#CiliumConfig untuk Helm

CiliumConfig adalah resource yang memungkinkan konfigurasi tertentu diubah tanpa me-reinstall chart. Contoh definisinya:

apiVersion: cilium.io/v2
kind: CiliumConfig
metadata:
  name: cilium
  namespace: kube-system
spec:
  debug: false
  ipam:
    mode: cluster-pool
  kubeProxyReplacement: strict

spec.kubeProxyReplacement: strict adalah contoh pengaturan yang dideklarasikan sebagai code. Karena file ini ada di Git, setiap perubahan mode datapath atau IPAM tercatat lengkap dengan siapa yang mengubah dan kapan.

#Policy CNP/CCNP dalam Git

Policy juga menjadi manifest biasa. Simpan semua CNP dan CCNP dalam satu direktori yang rapi agar mudah di-review dan di-audit:

tree policy/

tree policy/ menampilkan struktur direktori policy, misalnya file policy/frontend/allow-ingress.yaml dan policy/global/blokir-debug-port.yaml. Setiap file direview lewat pull request sebelum digabung, dan riwayat perubahan policy bisa ditelusuri kapan saja.

Dengan struktur ini, pertanyaan klasik "siapa yang mengubah policy ingress kemarin?" dijawab hanya dengan git log — tanpa menebak-nebak dari ingatan.

#Argo CD dan Flux

Dua tool GitOps yang umum dipakai: Argo CD dan Flux. Keduanya mampu mengelola Helm release dan manifest kustom. Contoh Application Argo CD untuk mengelola Cilium:

Kedua tool ini berbeda gaya: Argo CD berbasis aplikasi dengan UI yang kaya dan operasi berbasis "sync", sedangkan Flux lebih dekat ke Git asli dengan reconciliation yang ketat dan dukungan satu arah dari Git ke cluster. Pilih berdasarkan kesukaan tim, bukan berdasarkan fitur yang sama-sama ada di keduanya — kebanyakan fitur inti setara.

Contoh Application Argo CD untuk mengelola Cilium:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cilium
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://git.example.com/platform/cluster.git
    path: cilium
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: kube-system
  syncPolicy:
    automated:
      prune: true

spec.source.path: cilium menunjuk ke direktori manifest Cilium di repository. Dengan automated.syncPolicy, setiap perubahan di Git langsung disinkronkan ke cluster. Flux memakai HelmRelease dan Kustomization dengan semangat yang sama — pilih salah satu dan konsisten memakainya.

#Best Practice: Versioning, Review, Canary

Menjadikan policy sebagai code hanya setengah pekerjaan. Separuh lainnya adalah praktik pengelolaannya:

• Versioning: simpan policy di repository yang sama dengan kode aplikasi atau di repository infra terpisah; gunakan tag dan riwayat yang jelas.
• Review flow: wajibkan minimal satu reviewer untuk perubahan policy, terutama yang menyentuh policy global.
• Canary: terapkan policy ke satu namespace atau satu workload dulu, amati Hubble dan metrik, lalu perluas cakupan.

Contoh pola canary yang aman: terapkan policy baru dengan endpointSelector yang hanya mencakup namespace staging, jalankan cilium connectivity test di sana, dan hanya setelah lulus, perluas selector ke production.

#Penerapan Bertahap dalam Praktik

Sebelum membiarkan GitOps menerapkan policy secara otomatis, biasakan memvalidasi manifest terlebih dahulu di terminal. Dua perintah yang mencegah kesalahan masuk ke cluster:

kubectl apply --dry-run=server -f policy/frontend/allow-ingress.yaml
kubectl diff -f policy/frontend/allow-ingress.yaml

kubectl apply --dry-run=server -f policy/frontend/allow-ingress.yaml memvalidasi manifest terhadap API server tanpa menerapkan — menangkap kesalahan sintaks dan skema sebelum berdampak. kubectl diff -f policy/frontend/allow-ingress.yaml menampilkan perbedaan antara state saat ini dan state yang akan diterapkan, sehingga reviewer bisa melihat persis apa yang berubah.

Untuk Argo CD, perhatikan alur sync yang aman:

argocd app diff cilium
argocd app sync cilium --prune --dry-run
argocd app sync cilium

argocd app diff cilium menampilkan perbedaan antara Git dan cluster. argocd app sync cilium --prune --dry-run mensimulasikan sync tanpa mengubah apa pun. Baru setelah keduanya bersih, jalankan argocd app sync cilium untuk benar-benar menerapkan.

Prinsip yang harus dipegang: pratinjau selalu lebih murah daripada rollback. Otomatisasi penuh memang menarik, tetapi untuk barang sensitif seperti policy, satu langkah pratinjau tambahan di pipeline atau di workflow manual jauh lebih berharga daripada kecepatan beberapa detik.

#Penutup

Inti yang harus dibawa pulang:

• GitOps menjadikan konfigurasi Cilium sebagai code yang tercatat dan bisa di-review.
• Tiga lapis code: helm values, CiliumConfig, dan policy CNP/CCNP.
• CiliumConfig mengubah konfigurasi tanpa reinstalasi chart.
• Argo CD dan Flux adalah tool utama untuk sinkronisasi Git ke cluster.
• Versioning, review flow, dan canary menjaga kualitas perubahan policy.
• Gunakan auto-sync bijak: otomatis untuk konfigurasi, waspada untuk policy.

Di episode 19 selanjutnya kita akan membahas performance dan troubleshooting — menggunakan cilium-dbg untuk endpoint, identity, dan policy, mengumpulkan diagnostik dengan cilium-bugtool, memantau traffic dengan cilium monitor, dan memecahkan masalah umum seperti policy yang menolak traffic, identity hilang, dan IPAM kehabisan pool. Ini toolkit yang akan kalian bawa ke production.