Belajar Cilium - Production-Ready Architecture

#Pendahuluan

Dua puluh episode membangun keterampilan dari nol. Episode 21 menempatkan semuanya dalam satu kerangka: bagaimana merancang arsitektur Cilium yang siap production. Bukan sekadar memasang Cilium, tapi merencanakan IPAM, kube-proxy replacement, encryption, observability, upgrade, dan operasional harian secara koheren.

Blueprint ini adalah hasil pengalaman menangani cluster riil. Setiap bagian — dari pilihan IPAM hingga runbook incident — punya alasan tersendiri dan saling berhubungan. Kalian tidak perlu menerapkan semuanya sekaligus, tetapi perlu tahu ke arah mana arsitektur harus tumbuh.

Satu prinsip yang berlaku untuk seluruh urutan di atas: dokumentasikan setiap keputusan beserta alasannya. Enam bulan kemudian, tim akan bertanya mengapa memilih direct routing alih-alih tunnel — dan jawabannya seharusnya bisa ditemukan di dokumentasi, bukan di ingatan. Keputusan arsitektur tanpa catatan adalah keputusan yang sulit dibatalkan.

#Perencanaan Arsitektur

Keputusan arsitektur paling baik dibuat sebelum workload masuk. Urutan yang disarankan:

1. IPAM: hitung jumlah pod maksimal per node dan pilih cluster-pool atau Multi-Pool (episode 9).
2. Kube-proxy replacement: aktifkan mode strict sejak awal (episode 8) untuk performa dan kesederhanaan.
3. Datapath: pilih direct routing atau tunnel berdasarkan topologi jaringan (episode 3).
4. Encryption: aktifkan WireGuard (episode 14) terutama jika cluster melintasi jaringan publik.

Contoh instalasi production yang menggabungkan keputusan tersebut:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set ipam.mode=cluster-pool \
  --set routing-mode=direct

--set kubeProxyReplacement=strict dan opsi lain di atas adalah satu paket keputusan yang direplikasi di semua environment. Simpan nilai ini sebagai helm values file di repository GitOps (episode 18) agar konsisten antar cluster.

#Observability dan Monitoring

Production tanpa observability berarti berjalan buta. Dua lapis yang harus ada:

• Hubble: untuk flow-level observability dan debugging policy (episode 7).
• Prometheus: untuk metrik performa, endpoint health, dan alerting jangka panjang.

Aktifkan pengumpulan metrik Prometheus saat install:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set prometheus.enabled=true \
  --set operator.prometheus.enabled=true

prometheus.enabled=true membuat agent Cilium mengekspos metrik untuk di-scrape Prometheus. Metrik penting yang dipantau: jumlah endpoint, health agent, flow rate, dan paket ter-drop. Buat dashboard dan alert dari metrik ini — misalnya alert ketika persentase drop tiba-tiba naik.

#CI/CD dan Operations

Perubahan pada Cilium harus melewati gerbang kualitas yang sama seperti perubahan aplikasi. cilium connectivity test adalah gerbang utama:

steps:
  - name: connectivity-test
    run: |
      cilium install --context staging --version 1.20.0
      cilium connectivity test --context staging

cilium connectivity test --context staging menjalankan seluruh skenario koneksi terhadap cluster staging sebelum perubahan dibawa ke production. Pipeline ini mencegah konfigurasi yang rusak menyebar.

Sizing node juga masuk kategori operasional: cadangkan sumber daya untuk agent Cilium dan operator (biasanya beberapa persen dari node), dan pastikan kernel semua node memenuhi syarat eBPF sebelum bergabung ke cluster.

Selain connectivity test, sertakan juga validasi policy di pipeline: kubectl apply --dry-run=server untuk memastikan manifest policy valid sebelum diterapkan, dan pratinjau dengan kubectl diff untuk melihat perubahan yang akan terjadi. Ini mencegah kesalahan sintaks masuk ke cluster melalui jalur otomatis.

#Upgrade Strategy dan Runbook

Upgrade rutin adalah bagian dari hidup. Pola yang disarankan:

1. Upgrade satu minor pada satu waktu (episode 20).
2. Uji di staging dengan cilium connectivity test sebelum production.
3. Gunakan rolling update node agar traffic tidak pernah berhenti total.
4. Punya runbook incident untuk skenario terburuk.

Runbook incident minimal untuk Cilium:

• Aplikasi tidak bisa terhubung: mulai dari hubble observe --verdict DROPPED (episode 19).
• Agent Cilium restart berulang: cek log agent dan dukungan kernel eBPF.
• IPAM habis: cilium-dbg ipam list, tambah pool atau perluas mask.
• Setelah setiap langkah, verifikasi kembali dengan connectivity test.

#Sizing Node dan Sumber Daya

Salah satu keputusan yang paling sering ditunda adalah menghitung sumber daya yang dibutuhkan Cilium. Dimulai dari pemeriksaan kondisi aktual:

kubectl top pod -n kube-system -l k8s-app=cilium
kubectl top pod -n kube-system -l app.kubernetes.io/name=cilium-operator
kubectl describe nodes | grep -A3 -B3 "eBPF\|cilium"

kubectl top pod -n kube-system -l k8s-app=cilium menampilkan penggunaan CPU dan memory agent per node. kubectl top pod -n kube-system -l app.kubernetes.io/name=cilium-operator melakukan hal yang sama untuk operator. Angka dari kubectl top ini menjadi dasar request dan limit yang realistis, bukan perkiraan.

Aturan praktis sizing: alokasikan cadangan sekitar 20 persen di atas penggunaan puncak untuk agent, dan pastikan operator mendapat sumber daya yang cukup untuk cluster besar. Kernel semua node harus memenuhi syarat eBPF sebelum bergabung ke cluster — periksa dengan ls /sys/kernel/btf dari episode 1, karena node dengan kernel tua akan menjadi beban operasional di kemudian hari.

Satu hal yang sering terlupa: sumber daya observability juga ikut dihitung. Hubble Relay dan UI membutuhkan CPU dan memory sendiri, dan jika kalian menyimpan flow untuk jangka panjang, disk untuk database flow bertambah seiring waktu. Masukkan semua ini ke dalam perhitungan biaya cluster sejak awal, bukan setelah tagihan muncul.

#Penutup

Inti yang harus dibawa pulang:

• Keputusan IPAM, kube-proxy replacement, datapath, dan encryption dibuat sebelum workload masuk.
• Helm values production disimpan sebagai code untuk konsistensi antar cluster.
• Hubble untuk flow observability; Prometheus untuk metrik dan alerting.
• cilium connectivity test menjadi gerbang kualitas di pipeline CI/CD.
• Upgrade dilakukan satu minor per satu, diuji di staging dulu.
• Runbook incident minimal: diagnosa drop, agent restart, dan IPAM habis.

Di episode 22, episode terakhir, kita akan membahas ekosistem alternatif dan refleksi akhir — perbandingan Cilium vs Calico vs Flannel vs Weave, kube-proxy replacement vs tradisional, Istio vs Cilium Service Mesh, rekap journey 0-21, checklist Cilium production-grade, dan arah masa depan Cilium bersama eBPF, Tetragon, dan multi-cluster.