Belajar Flannel - Subnet Management

#Pendahuluan

Semua jaringan Flannel berakar pada satu mekanisme: subnet lease. Tanpa pemahaman tentang lease, kalian akan sulit menjelaskan mengapa satu node kebagian IP 10.244.1.0/24 sementara node lain kebagian 10.244.2.0/24, apalagi saat terjadi konflik.

Episode 6 membedah mekanisme ini dari konsep hingga troubleshooting. Kalian akan belajar bagaimana flanneld mengklaim subnet, ke mana lease disimpan, dan bagaimana memastikan seluruh node saling sinkron.

#Konsep Subnet Lease

#Pool Besar, Subnet Kecil per Node

Flannel mengambil sebuah pool besar, defaultnya 10.244.0.0/16, lalu membaginya menjadi subnet kecil per node, defaultnya /24. Dengan demikian cluster bisa menampung hingga 256 node dan setiap node punya 254 alamat Pod.

Proses ini otomatis: saat flanneld memulai, dia meminta lease dari datastore. Datastore menjamin dua node tidak pernah mendapat subnet yang sama, karena setiap alokasi dicatat dan di-lock.

kubectl get lease -n kube-system
kubectl get lease -n kube-system worker-1 -o yaml

Perintah kubectl get lease -n kube-system menampilkan satu objek Lease per node. Field holderIdentity pada Lease worker-1 akan menunjukkan subnet yang diklaim node tersebut.

#Masa Berlaku Lease

Setiap lease punya masa berlaku dan diperpanjang secara berkala oleh flanneld. Jika sebuah node mati lama dan lease-nya kedaluwarsa, subnetnya bisa dialokasikan kembali ke node baru. Ini penting dipahami: lease bukan hak milik permanen, melainkan pinjaman yang harus diperbarui.

#Datastore: Kube vs etcd

#Kubernetes API: Mode Default

Mode kube memakai API server sebagai datastore, diaktifkan lewat flag --kube-subnet-mgr. flanneld memakai ServiceAccount-nya untuk membuat dan memperbarui objek Lease di namespace kube-system. Keunggulannya: tidak ada komponen tambahan, dan konsistensi dijamin oleh etcd di balik API server.

#etcd: Mode Historis

Mode etcd memakai etcd langsung sebagai datastore, tanpa melalui Kubernetes API. Mode ini berguna untuk setup non-Kubernetes atau upgrade dari instalasi lawas, tetapi lebih rumit karena kalian harus mengelola endpoint etcd, prefix, dan sertifikat secara manual.

kubectl -n kube-flannel get ds kube-flannel-ds -o yaml | grep -E "kube-subnet-mgr|kube-subnet-mgr="

Jika argumen --kube-subnet-mgr ada di DaemonSet, Flannel memakai datastore Kubernetes API.

#Melihat Lease dalam Aksi

#Membaca subnet.env di Node

Hasil runtime dari subnet manager tersimpan di file /run/flannel/subnet.env. File ini dibaca plugin CNI saat membuat Pod baru:

cat /run/flannel/subnet.env

Output dari cat /run/flannel/subnet.env berisi FLANNEL_NETWORK, FLANNEL_SUBNET, FLANNEL_MTU, dan FLANNEL_IPMASQ. Nilai FLANNEL_SUBNET menunjukkan subnet yang diklaim node ini.

#Memeriksa Lease Remote

Untuk memastikan semua node sinkron, bandingkan lease di API server dengan route yang ada di node:

ip route | grep flannel
kubectl get lease -n kube-system -o jsonpath='{.items[*].spec.holderIdentity}'

Setiap subnet di lease harus muncul sebagai route di seluruh node lain. Jika ada lease tanpa route yang sesuai, sinkronisasi antar node bermasalah.

#Troubleshooting Subnet

#Lease Conflict

Lease conflict terjadi ketika dua node mengklaim subnet yang sama. Penyebab umum: cluster di-restore dari backup tanpa membersihkan lease, atau dua cluster memakai network 10.244.0.0/16 yang sama dan saling bergabung. Solusinya: hapus objek Lease yang bentrok setelah memastikan node-nya memang mati.

kubectl delete lease -n kube-system <node-name>
kubectl rollout restart ds/kube-flannel-ds -n kube-flannel

#Subnet Tidak Terbentuk

Jika lease tidak pernah muncul untuk sebuah node, periksa log flanneld. Penyebab umum: ServiceAccount tidak punya izin, atau ConfigMap net-conf.json tidak valid sehingga flanneld gagal startup.

kubectl logs -n kube-flannel -l k8s-app=flannel

#Sinkronisasi Antar Node

Jika beberapa node tidak melihat subnet node lain, cek route dan FDB seperti yang sudah kita pelajari. Pada backend vxlan, pastikan port UDP 4789 terbuka; pada host-gw, pastikan node saling reachable. Episode 19 akan membawa kalian lebih dalam pada alur troubleshooting menyeluruh.

#Praktik Baik dalam Pengelolaan Lease

Jadikan pemeriksaan lease bagian dari rutinitas operasional. Alokasi yang sehat tampil sebagai satu subnet per node yang aktif. Jika jumlah lease tidak wajar, misalnya jauh lebih banyak dari jumlah node, ada node lama yang belum dibersihkan. Bersihkan hanya setelah memastikan node-nya memang tidak akan kembali.

#Penutup

Episode 6 menuntaskan pemahaman subnet management: konsep lease, pembagian pool menjadi subnet per node, perbedaan datastore kube dan etcd, serta cara memecahkan konflik dan sinkronisasi.

Inti yang harus dibawa pulang:

• Setiap node mengklaim satu subnet /24 dari pool 10.244.0.0/16.
• Lease disimpan sebagai objek Lease di namespace kube-system pada mode kube.
• Lease memiliki masa berlaku dan diperpanjang berkala oleh flanneld.
• subnet.env di /run/flannel memuat hasil runtime yang dibaca plugin CNI.
• Lease conflict biasanya berasal dari restore backup atau CIDR yang bentrok.
• Subnet yang tidak terbentuk biasanya karena izin atau net-conf.json tidak valid.

Di episode 7 selanjutnya kita akan membahas traffic management iptables/nftables — aturan masquerade untuk traffic keluar, forwarding antar namespace, pentingnya br_netfilter sejak kubeadm 1.30, dan mode traffic manager berbasis iptables versus nftables. Ini yang menentukan bagaimana Pod berbicara ke dunia luar.