Belajar Flannel - Multi-node Deployment & Scaling

#Pendahuluan

Sejauh ini kalian bermain di cluster kecil. Sekarang waktunya berskala: membangun cluster kubeadm tiga node dan mengamati bagaimana Flannel berperilaku di lingkungan yang lebih realistis.

Episode 10 menguji Flannel pada skala nyata. Kalian akan membangun cluster tiga node, memverifikasi routing dan overlay, mensimulasikan kegagalan node, dan menilai sejauh mana Flannel bisa dipakai sebelum timbutuh CNI yang lebih canggih.

#Membangun Cluster Tiga Node

#Init Control Plane dan Join Worker

Mulai dari satu node control plane dan dua worker. Init control plane dengan CIDR default Flannel:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Setelah init selesai, kubeadm menampilkan perintah join. Jalankan di setiap worker node:

sudo kubeadm join 192.168.1.10:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Perintah kubeadm join di atas menghubungkan worker ke control plane. Setelah semua node bergabung, pasang Flannel seperti di episode 3 dan tunggu semua Pod kube-flannel Running.

#Verifikasi Status Node

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

Tiga node berstatus Ready dan tiga Pod kube-flannel Running menandakan setiap node punya flanneld dengan lease subnet masing-masing.

#Verifikasi Routing dan Overlay

#Route di Setiap Node

Masuk ke salah satu node dan periksa tabel route:

ip route | grep flannel

Output dari ip route | grep flannel menampilkan route menuju subnet node lain: 10.244.1.0/24 via IP node-2, dan 10.244.2.0/24 via IP node-3. Ini bukti sinkronisasi lease berjalan sempurna.

#Uji Pod Lintas Node

Deploy workload dengan anti-affinity agar Pod tersebar, lalu uji koneksi:

kubectl create deployment nginx --image=nginx --replicas=3
kubectl get pods -o wide
kubectl exec -it <pod-node-1> -- ping -c 3 <ip-pod-node-2>

Ketika ping dari Pod di node-1 ke Pod di node-2 berhasil, overlay VXLAN bekerja di seluruh cluster.

#Failure Domain

#Simulasi Node Down

Uji ketahanan Flannel dengan mencabut satu worker node secara terencana:

kubectl cordon worker-2
kubectl drain worker-2 --ignore-daemonsets
kubectl get nodes

Saat node-2 dalam status cordoned, Pod-podnya berpindah ke node lain. Flannel tidak perlu konfigurasi tambahan karena lease subnet node-2 tetap ada selama lease-nya belum kedaluwarsa.

#Perilaku Lease Saat Node Mati Lama

Jika worker-2 mati lebih lama dari masa berlaku lease, subnetnya bisa dialokasikan kembali ke node baru. Ini otomatis dan aman, tetapi perlu dipahami: alamat IP Pod yang dijalankan ulang bisa berbeda. Aplikasi harus selalu memakai Service, bukan IP Pod langsung.

kubectl get lease -n kube-system

Perintah kubectl get lease -n kube-system menunjukkan lease yang masih aktif. Lease node yang mati akan hilang setelah kedaluwarsa.

#Skala dan Batas Flannel

#Control Plane Bottleneck

Semua pembaruan lease dan route melewati API server. Pada cluster sangat besar, misalnya ratusan node dengan churn Pod tinggi, API server bisa menjadi bottleneck karena setiap pembaruan subnet harus melewati kubelet dan CNI. Flannel juga tidak mendistribusikan route secara global seperti BGP; setiap node menyimpan semua route sendiri.

#Kapan Beralih ke CNI yang Lebih Canggih

Ada tanda-tanda yang jelas: kebutuhan NetworkPolicy per namespace, jumlah node ribuan, atau traffic Pod yang harus melewati jalur optimal tanpa overlay. Saat itu muncul, pertimbangkan CNI dengan fitur lebih kaya. Perbandingan menyeluruh antara Flannel, Calico, dan Cilium ada di episode 22.

#Penutup

Episode 10 membuktikan Flannel bekerja di skala tiga node: routing tersinkron, overlay sehat, dan kegagalan node bisa disimulasikan dengan aman. Kalian juga sekarang tahu batas skala yang harus diperhatikan.

Inti yang harus dibawa pulang:

• Cluster tiga node menunjukkan sinkronisasi lease dan route antar node secara nyata.
• Route 10.244.x.0/24 di setiap node membuktikan overlay bekerja.
• Cordon dan drain mensimulasikan kegagalan node tanpa merusak jaringan.
• Lease yang kedaluwarsa akan mengembalikan subnet ke pool.
• Flannel bergantung pada API server sebagai pusat koordinasi lease.
• Skala sangat besar atau kebutuhan policy menandakan saatnya pindah CNI.

Di episode 11 selanjutnya kita akan membedah integrasi Flannel dengan CNI plugins — peran bridge, portmap, dan bandwidth di /opt/cni/bin, isi konfigurasi 10-flannel.conflist, serta integrasi Flannel dengan Multus untuk multiple network interfaces.