Belajar Flannel - Backend host-gw & Alternatif

#Pendahuluan

VXLAN adalah backend default yang andal, tetapi bukan satu-satunya. Bergantung pada jaringan host dan kebutuhan kalian, backend lain bisa memberi performa lebih tinggi, enkripsi bawaan, atau integrasi khusus.

Episode 5 mengeksplorasi backend host-gw yang menjadi primadona performa, lalu melirik wireguard dan ipsec untuk enkripsi, ipip dan udp untuk kasus khusus, serta extension yang membutuhkan kewaspadaan ekstra karena catatan keamanan terbaru.

#Backend host-gw

#Cara Kerja: Routing Langsung Tanpa Encapsulation

Host gateway, atau host-gw, bekerja dengan prinsip paling sederhana: alih-alih membungkus paket, flanneld cukup menambahkan route di tabel routing kernel. Paket dari Pod menuju Pod di node lain diteruskan langsung ke IP host node tujuan sebagai paket native.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "host-gw"
    }
  }

Dengan Type: host-gw, interface flannel.1 tidak lagi dibuat. Yang ada hanyalah route tambahan, sehingga latensi dan throughput menjadi lebih baik karena tidak ada overhead encapsulation.

#Kecepatan dan Batasan

Keunggulan host-gw jelas: performa mendekati native karena paket tidak dibungkus. Namun syaratnya tegas: semua node harus saling reachable pada lapisan jaringan host. Jika node berada di VLAN atau subnet berbeda tanpa route antar keduanya, host-gw tidak bisa bekerja. Inilah batas utama yang harus kalian periksa sebelum memilih backend ini.

ip route | grep flannel

Output dari ip route | grep flannel di backend host-gw menampilkan route langsung seperti 10.244.1.0/24 via 192.168.1.11 dev eth0, tanpa perantara tunnel.

#Backend WireGuard dan IPsec

#Enkripsi Traffic Antar Node

Ketika traffic antar node harus terenkripsi, Flannel menyediakan backend wireguard dan ipsec. WireGuard memakai protokol modern dengan performa tinggi dan implementasi kernel yang efisien. IPsec, melalui strongSwan, adalah opsi klasik yang banyak dipakai di lingkungan enterprise.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "wireguard",
      "Port": 51820
    }
  }

WireGuard default mendengarkan di UDP port 51820. Port ini harus dibuka di firewall seperti yang akan kita bahas di episode 15.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "ipsec"
    }
  }

Backend IPsec memakai IKEv2 dan membutuhkan modul serta tool strongSwan yang tersedia di node. Kedua backend ini menambah keamanan tetapi menurunkan throughput dibanding host-gw karena proses enkripsi.

#Backend ipip dan udp

#Penggunaan Khusus

Backend ipip membungkus paket dengan header IP-in-IP, protokol IP nomor 4, tanpa header UDP. Ini lebih ringan dari VXLAN tetapi hanya berjalan di jaringan IPv4 dan tidak di semua cloud provider. Backend udp adalah mode historis yang memakai user-space tunneling, sangat lambat, dan hanya relevan untuk jaringan yang tidak mendukung VXLAN — sebaiknya dihindari kecuali terpaksa.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "ipip"
    }
  }

Pilih ipip hanya jika kalian tahu persis infrastruktur kalian mengizinkan protokol IP 4 melewati seluruh hop.

#Backend extension dan Catatan Keamanan

#Menghubungkan ke External Network

Backend extension memungkinkan flanneld memanggil program eksternal untuk setup jaringan, memberikan fleksibilitas untuk integrasi vendor. Fleksibilitas ini datang dengan risiko: karena flanneld menjalankan program eksternal dengan argumen yang berasal dari konfigurasi, celah keamanan sangat mungkin terjadi.

#CVE-2026-32241

Pada 2026, CVE-2026-32241 teridentifikasi sebagai celah command injection pada extension backend. Argumen yang tidak divalidasi dapat memicu eksekusi perintah sembarang. Respons yang benar bukan menghindari extension selamanya, melainkan tiga hal: pastikan versi Flannel sudah di-patch, batasi siapa yang bisa mengedit ConfigMap kube-flannel-cfg, dan hindari extension kecuali benar-benar dibutuhkan.

#Memilih Backend yang Tepat

#Kriteria Keputusan

Kriteria paling penting dalam memilih backend: jaringan host kalian, kebutuhan keamanan, dan prioritas performa. Jika node saling reachable dan keamanan bukan syarat mutlak, host-gw adalah pilihan tercepat. Jika jaringan host beragam, VXLAN adalah pilihan paling fleksibel. Jika traffic harus dienkripsi, wireguard adalah keseimbangan terbaik antara keamanan dan kecepatan.

kubectl -n kube-flannel get cm kube-flannel-cfg -o yaml | grep -A5 Backend

Perintah kubectl -n kube-flannel get cm kube-flannel-cfg mengonfirmasi backend yang sedang dipakai cluster. Catat pilihan kalian karena keputusan ini akan berpengaruh pada arsitektur produksi di episode 21.

#Penutup

Episode 5 memperluas pilihan backend Flannel: host-gw untuk kecepatan tanpa encapsulation, wireguard dan ipsec untuk enkripsi, ipip dan udp untuk kasus khusus, serta extension yang memerlukan kewaspadaan karena CVE-2026-32241.

Inti yang harus dibawa pulang:

• host-gw meneruskan paket langsung tanpa encapsulation dengan syarat node saling reachable.
• WireGuard memakai UDP port 51820 dan memberi enkripsi berperforma tinggi.
• IPsec memakai IKEv2 via strongSwan untuk lingkungan enterprise.
• ipip memakai protokol IP 4; udp adalah mode historis yang sangat lambat.
• Extension backend rentan terhadap CVE-2026-32241 dan butuh pembatasan akses.
• Pilihan backend bergantung pada jaringan host, kebutuhan keamanan, dan prioritas performa.

Di episode 6 selanjutnya kita akan masuk ke subnet management — cara Flannel mengalokasikan subnet per node dari pool besar, perbedaan datastore Kubernetes API dan etcd, serta troubleshooting lease conflict dan sinkronisasi antar node. Ini fondasi untuk memahami mengapa setiap node punya alamat yang unik.