Belajar Flannel - Traffic Management (iptables/nftables)

#Pendahuluan

Tidak semua traffic berhenti di dalam cluster. Ada traffic dari Pod menuju internet, menuju node lain, atau menuju layanan di luar subnet. Di sinilah traffic management bekerja.

Episode 7 membedah aturan masquerade dan forwarding yang dikelola Flannel, alasan mengapa br_netfilter menjadi wajib sejak kubeadm 1.30, serta pilihan mode traffic manager iptables versus nftables. Setelah episode ini, kalian akan bisa membaca aturan yang terpasang di cluster dan tahu apa artinya.

#Masquerade dan Forwarding

#Kenapa IP Masquerade Diperlukan

Alamat IP Pod, seperti 10.244.1.5, tidak ter-routing di luar jaringan host. Tanpa pengaturan khusus, paket dari Pod yang menuju internet akan dibuang karena return traffic tidak tahu cara kembali. Masquerade memecahkan ini dengan mengganti source IP paket menjadi IP host saat paket keluar.

Flannel memasang aturan masquerade pada tabel NAT ketika diaktifkan lewat flag --ip-masq. Ini memastikan semua traffic keluar dari subnet Pod memakai IP node sebagai sumber.

iptables -t nat -L -n | grep FLANNEL

Output dari iptables -t nat -L pada chain FLANNEL menunjukkan aturan MASQUERADE yang hanya aktif untuk source IP di 10.244.0.0/16 dan destination di luar network tersebut.

#Forwarding Antar Namespace

Selain NAT, Flannel juga memastikan forwarding diizinkan. Kernel Linux secara default memblokir forwarding antar interface. Flannel mengaktifkannya melalui sysctl, karena tanpa forwarding paket Pod tidak akan pernah berpindah dari bridge ke interface VXLAN atau eth0.

sysctl net.ipv4.ip_forward

Nilai 1 dari sysctl net.ipv4.ip_forward menandakan kernel meneruskan paket antar interface. Ini prasyarat mutlak bagi semua CNI berbasis routing.

#br_netfilter dan Kubeadm 1.30

#Mengapa Setting Ini Krusial

Sejak kubeadm 1.30, persyaratan sysctl terkait bridge menjadi lebih ketat. Modul br_netfilter membuat paket yang lewat bridge ikut melewati filter netfilter, termasuk iptables. Tanpa ini, paket antar Pod pada node yang sama bisa lolos dari aturan kube-proxy, menyebabkan koneksi terputus secara misterius.

sysctl net.bridge.bridge-nf-call-iptables

Perintah sysctl net.bridge.bridge-nf-call-iptables harus mengembalikan nilai 1. Jika tidak, muat modul dan setel sysctl seperti yang sudah kalian lakukan di episode 0.

#Verifikasi di Seluruh Node

Karena kubelet dan CNI berjalan di setiap node, pastikan setting ini konsisten di semua node. Cara terbaik adalah lewat file konfigurasi sysctl atau file di /etc/sysctl.d agar tetap ada setelah reboot.

echo 'net.bridge.bridge-nf-call-iptables = 1' | sudo tee /etc/sysctl.d/99-flannel.conf
sudo sysctl --system

#Traffic Manager: iptables vs nftables

#Dua Mesin, Satu Tujuan

Flannel menawarkan dua implementasi untuk mengelola aturan traffic: iptables, yang sudah ada sejak awal, dan nftables, penerus modern iptables dengan sintaks dan kinerja lebih baik. Keduanya menghasilkan perilaku yang sama; perbedaannya di mesin netfilter yang dipakai.

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

Field TrafficManager dengan nilai nftables membuat Flannel memasang aturannya lewat nft. Nilai alternatifnya adalah iptables, yang juga merupakan default bagi sebagian besar rilis sebelumnya.

#Memilih Mode yang Tepat

Pertimbangan utama adalah kebijakan tim dan kompatibilitas tooling. Jika tim memakai nftables untuk mengelola firewall host, mode nftables menjaga semuanya tetap konsisten. Jika masih bergantung pada iptables dan tooling lawas, tetap di iptables tidak masalah. Yang penting, kalian tahu mode apa yang sedang dipakai agar tidak bingung saat debugging.

nft list ruleset | grep -i flannel

Output dari nft list ruleset menampilkan objek dengan nama yang mengandung flannel jika traffic manager memakai nftables.

#Melihat Aturan di Lapangan

#Inspeksi Menyeluruh

Untuk memahami traffic management secara utuh, inspeksi tabel NAT dan filter sekaligus:

iptables -t nat -L -n -v
iptables -t mangle -L -n -v

Kolom pkts dan bytes pada output menunjukkan seberapa sering aturan dipakai. Ini data yang berguna untuk membuktikan bahwa masquerade benar-benar memproses traffic keluar.

#Kenapa Kalian Harus Peduli

Traffic management adalah bagian yang paling sering membuat kebingungan di lapangan. Pod gagal mengakses internet padahal route dan backend sehat — penyebabnya biasanya di sini: masquerade tidak aktif, forwarding dimatikan, atau br_netfilter tidak dimuat. Dengan pemahaman episode ini, kalian sudah punya peta untuk menyelidiki.

#Penutup

Episode 7 melengkapi gambaran traffic Flannel: masquerade untuk traffic keluar, forwarding antar namespace, wajibnya br_netfilter sejak kubeadm 1.30, dan pilihan traffic manager iptables atau nftables.

Inti yang harus dibawa pulang:

• Masquerade mengubah source IP Pod menjadi IP host untuk traffic keluar cluster.
• Forwarding kernel harus diaktifkan agar paket bisa berpindah antar interface.
• br_netfilter dengan bridge-nf-call-iptables wajib aktif sejak kubeadm 1.30.
• TrafficManager bisa disetel ke iptables atau nftables di net-conf.json.
• Mode yang dipilih menentukan perintah untuk memeriksa aturan.
• Masalah konektivitas ke luar cluster biasanya berakar di lapisan ini.

Di episode 8 selanjutnya kita akan menguji integrasi Flannel dengan Kubernetes Service — pembagian tugas antara Flannel untuk pod networking dan kube-proxy untuk Service, cara kerja iptables atau ipvs, serta praktik menguji ClusterIP dan NodePort di atas Flannel.