Belajar Flannel - Production-Ready Architecture

#Pendahuluan

Semua episode sebelumnya adalah bahan bangunan. Episode ini merakitnya: bagaimana keputusan kecil di setiap episode bersatu menjadi arsitektur yang layak produksi.

Episode 21 memandu penyusunan arsitektur produksi Flannel: memilih backend, men-tune MTU, menyandingkan policy engine, menyusun strategi upgrade, serta menyiapkan operasional berupa pipeline GitOps, observability, sizing node, dan runbook insiden.

#Memilih Backend untuk Produksi

#VXLAN vs host-gw

Keputusan pertama dan paling penting: backend. Di produksi, pilihan bermuara pada dua kandidat utama. VXLAN fleksibel dan aman untuk jaringan host yang beragam. host-gw tercepat tetapi menuntut node saling reachable pada lapisan jaringan.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "MTU": 1450,
    "Backend": {
      "Type": "vxlan",
      "VNI": 1,
      "Port": 4789
    },
    "TrafficManager": "nftables"
  }

Jika keamanan traffic antar node menjadi syarat, pilih WireGuard. Keputusan ini ditentukan oleh tiga faktor: topologi jaringan host, kebutuhan keamanan, dan prioritas performa.

#Sizing Node dan Cluster

Perkirakan jumlah node dan churn Pod. Setiap node mengonsumsi satu subnet /24 dan semua node menyimpan route ke semua subnet lain. Cluster ratusan node tetap bisa berjalan, tetapi pantau beban API server sebagai pusat koordinasi lease.

#Tuning MTU dan Interface

#MTU yang Sudah Terverifikasi

Terapkan nilai MTU yang sudah diuji di staging. Ingat overhead VXLAN 50 bytes dan gejala fragmentasi dari episode 16. Verifikasi dengan ping -M do sebelum produksi menerima beban penuh.

#Interface yang Eksplisit

Selalu setel field Iface secara eksplisit. Di produksi, node sering punya banyak interface, dan tebakan flanneld bisa salah. Satu baris konfigurasi ini menyelamatkan dari masalah yang sulit didiagnosis.

#Policy Engine Pendamping

#Keamanan di Atas Flannel

Flannel mengurus connectivity; keamanan layer di atasnya diurus policy engine. Pilih Calico policy-only atau Cilium sesuai kenyamanan tim. Pastikan policy default deny diuji menyeluruh di staging sebelum produksi, dengan daftar izin untuk DNS, monitoring, dan ingress.

#Upgrade Strategy

#Kanary dan Rollback

Upgrade Flannel dengan pola kanary: terapkan di satu node, verifikasi, lalu biarkan rolling update menyelesaikan sisanya. GitOps menjadi tulang punggung strategi ini:

kubectl set image ds/kube-flannel-ds -n kube-flannel kube-flannel=docker.io/flannel/flannel:v0.28.8
kubectl rollout status ds/kube-flannel-ds -n kube-flannel

Perintah kubectl rollout status memantau progres. Jika ada node gagal, hentikan dan gunakan GitOps untuk rollback ke versi sebelumnya.

#CI/CD dan Operasional

#Pipeline GitOps

Konfigurasi Flannel hidup di repository infrastruktur dan diterapkan oleh Argo CD atau Flux. Perubahan melewati pull request dan review. Versi image di-pin jelas sehingga diff mudah dibaca.

#Observability

Dari episode 12, terapkan minimal: scrape metrik flanneld ke Prometheus, pasang alert untuk Pod flanneld restart berlebih dan perbedaan jumlah subnet antar node, serta pastikan log flanneld tersedia terpusat.

#Runbook Insiden

Siapkan runbook untuk insiden paling umum sebelum terjadi:

kubectl get nodes
kubectl get pods -n kube-flannel -o wide
kubectl get lease -n kube-system

Tiga perintah ini, kubectl get nodes, kubectl get pods -n kube-flannel, dan kubectl get lease -n kube-system, menjadi gerbang pertama setiap insiden. Runbook yang baik menuliskan langkah, perintah, dan kriteria selesai untuk setiap skenario.

#Menilai Arsitektur Secara Berkala

#Audit Berkala sebagai Kebiasaan

Arsitektur produksi tidak statis. Setiap beberapa bulan, tinjau kembali keputusan yang pernah diambil: apakah backend masih tepat, apakah MTU masih cocok dengan jalur jaringan, apakah policy engine masih sesuai kebutuhan. Audit berkala menjaga arsitektur tetap selaras dengan kenyataan lapangan.

#Dokumentasi dan Review Tim

Catat setiap perubahan arsitektur beserta alasannya. Saat tim baru bergabung, dokumentasi ini menjadi titik masuk yang berharga. Libatkan review tim untuk keputusan besar, karena perspektif beragam menangkap risiko yang luput dari satu orang.

#Penutup

Episode 21 merakit arsitektur produksi Flannel: keputusan backend dan MTU, policy engine pendamping, strategi upgrade kanary, serta operasional berupa GitOps, observability, dan runbook.

Inti yang harus dibawa pulang:

• Backend produksi dipilih dari topologi, keamanan, dan prioritas performa.
• MTU dan interface harus diverifikasi di staging sebelum produksi.
• Policy engine pendamping melengkapi keamanan di atas Flannel.
• Upgrade memakai pola kanary dengan rollback lewat GitOps.
• Observability minimal: metrik, alert, dan log terpusat.
• Runbook mendokumentasikan langkah pemecahan insiden yang teruji.

Di episode 22, episode terakhir, kita akan melihat ke sekeliling: ekosistem alternatif dan refleksi akhir — perbandingan menyeluruh Flannel vs Calico vs Cilium, rekap journey dari episode 0 sampai 21, checklist Flannel production-grade, dan masa depan Flannel di ekosistem Kubernetes.