Belajar Calico - GitOps & Policy as Code

#Pendahuluan

Sejauh ini kita menerapkan policy dengan calicoctl apply langsung ke klaster. Di produksi, pola itu berisiko: tidak ada jejak, tidak ada review, dan tidak ada rollback yang mudah. Episode 18 mengubah cara kerja kalian menjadi policy as code — semua konfigurasi Calico hidup di repositori, dan klaster menyamakan dirinya dengan repositori itu.

GitOps bukan sekadar "simpan YAML di git". Ini soal membuat git menjadi satu-satunya sumber kebenaran, menjadikan penerapan policy bisa di-review seperti kode, dan membangun jalur audit yang lengkap.

#Kenapa Policy Harus Menjadi Code

#Masalah Penerapan Manual

Dengan calicoctl apply, perubahan policy tidak punya sejarah. Siapa mengubah policy tadi malam? Perubahan apa yang ikut terbawa? Sulit dijawab. Lebih parah, tidak ada cara mudah untuk melihat perbedaan antara policy yang diinginkan dan yang terpasang.

#Solusi GitOps

Dengan GitOps, tiap perubahan policy adalah commit dengan pesan jelas dan pull request yang direview. Klaster secara otomatis menyamakan kondisi nyata dengan isi repositori. Perubahan yang tidak diinginkan mudah dideteksi karena klaster melapor "out of sync".

#Struktur Repositori Calico

#Layout yang Disarankan

Susun resource Calico dalam folder yang terpisah dari manifest aplikasi:

calico/
  installation.yaml
  ippools/
    default-ipv4-ippool.yaml
  bgp/
    bgpconfiguration.yaml
    bgppeers.yaml
  policies/
    tiers/
    global/
    namespace/

Struktur ini memisahkan konfigurasi infrastruktur (Installation, IPPool) dari policy keamanan, sehingga kewenangan review bisa dibedakan: tim platform untuk yang pertama, tim aplikasi untuk yang kedua.

#Satu Resource Contoh

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - name: default-ipv4-ippool
        cidr: 192.168.0.0/16
        blockSize: 26
        encapsulation: IPIP

Resource ini identik dengan yang kalian tulis manual — hanya saja sekarang dia dikelola git.

#Menerapkan dengan Argo CD atau Flux

#Argo CD: Application untuk Calico

Dengan Argo CD, buat Application yang menunjuk ke folder calico/:

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

automated.prune dan automated.selfHeal membuat Argo CD menghapus resource yang hilang dari git dan mengembalikan perubahan manual ke kondisi git.

#Flux: Kustomization

Dengan Flux, buat Kustomization yang menunjuk ke sumber yang sama:

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

Kedua pendekatan sama-sama valid; pilih yang sudah kalian pakai untuk workload lain agar operasionalnya seragam.

#Praktik Penerapan

kubectl get application calico-policy -n argocd
kubectl get application calico-policy -n argocd -o jsonpath='{.status.sync.status}'
calicoctl get globalnetworkpolicy -o wide

calicoctl get globalnetworkpolicy -o wide membandingkan policy yang terpasang dengan yang ada di git — dasar dari review dan audit.

#Versioning, Review, dan Penerapan Bertahap

#Versioning Policy

Simpan policy dalam urutan semantik: folder per environment (staging/, prod/), dan gunakan tag release untuk major change. Perubahan breaking — seperti default deny global baru — layak mendapat major version tersendiri.

#Alur Review

Setiap perubahan policy melewati alur: branch → pull request → review → merge ke main. Beri label wajib pada PR yang mengubah tier: security, karena bagian inilah yang paling berdampak:

git checkout -b add-payments-deny
git add calico/policies/namespace/
git commit -m "feat(calico): default deny untuk namespace payments"
git push origin add-payments-deny

#Penerapan Bertahap

Jangan sekali merge langsung menyala di produksi. Terapkan di staging lebih dulu, amati metrik, lalu naikkan ke produksi:

staging (bukan production) -> produksi satu namespace -> produksi penuh

Kombinasikan dengan smoke test otomatis: setelah sinkron, jalankan kubectl exec untuk memastikan aplikasi inti masih bisa berkomunikasi.

#Jebakan GitOps Calico

#Resource yang Tidak Boleh Di-Prune Sembarangan

Installation dan FelixConfiguration adalah resource yang sangat berdampak. Hati-hati dengan prune: true jika folder policy tidak lengkap — Argo CD bisa menghapus IPPool yang masih dipakai. Selalu sediakan resource lengkap di git.

#Conflict dengan Kubeconversion

Jika ada beberapa tools yang menulis resource yang sama (misalnya script manual dan Argo CD), hasilnya perang kondisi. Tetapkan satu sumber kebenaran: git, dan biarkan tools lain read-only terhadap resource Calico.

#Penutup

Episode 18 mengubah konfigurasi Calico dari perintah ad-hoc menjadi kode yang dikelola: repositori terstruktur, Argo CD atau Flux sebagai penerap, review flow per perubahan, dan penerapan bertahap yang aman.

Inti yang harus dibawa pulang:

• Policy as code membuat setiap perubahan tercatat dan bisa di-review.
• Pisahkan folder infrastruktur dan folder policy dalam satu repositori.
• Argo CD dan Flux sama-sama bisa menegakkan kondisi git.
• selfHeal dan prune membuat klaster selalu menyamai git.
• Penerapan bertahap: staging dulu, lalu produksi per namespace.
• Hati-hati memprune resource berdampak seperti Installation dan IPPool.

Di episode 19 selanjutnya kita membahas performance dan troubleshooting — diagnosa dengan calicoctl, log Felix dan typha, kasus umum seperti pod tidak bisa komunikasi, policy menolak traffic, BGP tidak up, masalah IPAM, dan upgrade versi.