Belajar Flannel - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian sudah tahu apa itu Flannel dan mengapa dia lahir. Sekarang kita masuk ke bagian yang paling penting untuk dipahami sebelum mengoperasikannya: arsitektur internal.

Episode 2 membedah bagaimana Flannel bekerja di balik layar. Kita akan mengikuti alur dari kubelet memanggil CNI, flanneld mengambil subnet lease, sampai terbentuknya interface VXLAN. Setelah episode ini, kalian akan bisa membaca konfigurasi Flannel di cluster kalian sendiri dan tahu setiap bagiannya bertanggung jawab atas apa.

#Cara Kerja di Balik Layar

#Alur: Lease, Backend, dan CNI

Alur kerja Flannel berputar di sekitar satu daemon bernama flanneld yang berjalan di setiap node. Saat node pertama kali bergabung, flanneld meminta sebuah subnet lease dari datastore. Lease ini memberi node hak eksklusif atas satu blok IP, misalnya 10.244.1.0/24.

Setelah mendapat lease, flanneld membangun interface jaringan sesuai backend yang dipilih: interface VXLAN flannel.1 untuk backend vxlan, atau route langsung untuk backend host-gw. Terakhir, saat kubelet membuat Pod baru, plugin CNI flannel membaca hasil kerja flanneld dan membuat interface Pod di dalam subnet node tersebut.

kubelet panggil CNI -> flannel ambil subnet lease -> buat interface -> bridge cni0

#Datastore: Kubernetes API vs etcd

Lease subnet harus disimpan di tempat yang bisa diakses semua node. Flannel mendukung dua datastore: Kubernetes API dan etcd. Mode Kubernetes API adalah default di instalasi modern lewat flag --kube-subnet-mgr. Lease disimpan sebagai objek Lease di namespace kube-system.

Mode etcd dipakai untuk setup non-Kubernetes atau versi lawas. Karena mayoritas pengguna memakai Kubernetes API, seluruh series ini fokus pada mode tersebut, tetapi konsep subnet lease tetap identik.

#Komponen Utama Flannel

#flanneld

flanneld adalah daemon utama. Tugasnya: membaca konfigurasi, mengambil lease, membangun backend, dan menjaga sinkronisasi route. Dia juga menulis file /run/flannel/subnet.env yang dibaca plugin CNI. Tanpa flanneld, tidak ada jaringan Pod yang terbentuk.

#Subnet Manager

Subnet manager adalah modul yang berkomunikasi dengan datastore. Dia yang mengajukan lease, memperpanjang masa berlaku, dan mendengarkan perubahan dari node lain. Di mode kube, subnet manager berkomunikasi dengan API server menggunakan ServiceAccount yang disediakan Flannel.

#Backend

Backend adalah modul yang menentukan cara paket diteruskan antar node. Opsi utama: vxlan untuk encapsulation UDP, host-gw untuk routing langsung, serta wireguard dan ipsec untuk enkripsi. Setiap node memakai backend yang sama, didefinisikan sekali di net-conf.json.

#CNI Plugin flannel

Plugin CNI flannel adalah penghubung antara kubelet dan flanneld. Dia membaca /run/flannel/subnet.env dan file konfigurasi /etc/cni/net.d/10-flannel.conflist, lalu mendelegasikan pembuatan bridge dan veth ke plugin bridge dari containernetworking/plugins.

#Net-conf: Sumber Konfigurasi

#net-conf.json

Semua keputusan besar Flannel ada di satu file: net-conf.json. File ini disimpan dalam ConfigMap kube-flannel-cfg dan di-mount ke /etc/kube-flannel di setiap Pod flanneld.

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-flannel-cfg
  namespace: kube-flannel
data:
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

Field Network adalah pool besar tempat setiap node mengambil subnet, dan Backend menentukan mekanisme penerusan paket. Di episode 4 sampai 5 kita akan membahas pilihan backend secara detail.

kubectl get cm -n kube-flannel kube-flannel-cfg -o yaml
cat /run/flannel/subnet.env

Perintah kubectl get cm -n kube-flannel kube-flannel-cfg menampilkan konfigurasi yang sama, sedangkan cat /run/flannel/subnet.env menunjukkan hasil runtime: FLANNEL_NETWORK, FLANNEL_SUBNET, dan FLANNEL_MTU yang sudah dihitung flanneld.

#Menelusuri Runtime

#Verifikasi Alur Kerja di Node

Untuk melihat bukti kerja arsitektur ini, kalian bisa memeriksa hasil konkret flanneld di node. Interface flannel.1 menandakan backend vxlan terbentuk, route dengan prefix 10.244.x.0/24 menandakan lease dari node lain sudah di-sinkronkan, dan file subnet.env menandakan plugin CNI punya bahan untuk membuat Pod baru.

ip -d link show flannel.1
ip route | grep flannel

Jika ip route | grep flannel menampilkan beberapa route 10.244.x.0/24, itu artinya semua node sudah saling mengenal subnet masing-masing. Arsitektur yang sederhana ini adalah kunci mengapa Flannel mudah di-debug dan dirawat.

#Kenapa Arsitektur Ini Penting

Memahami arsitektur bukan sekadar teori. Saat troubleshooting di episode 19, kalian akan membedah lapisan satu per satu: apakah lease ada, apakah backend terbentuk, apakah CNI plugin jalan. Semua itu hanya bisa dilakukan kalau kalian paham peta arsitektur yang sudah kita gambar di episode ini.

#Kenapa Ini Menjadi Dasar Semua Episode

Setiap masalah yang kalian temui di episode berikutnya bisa dilacak ke salah satu komponen arsitektur ini. Masalah konektivitas: cek backend. Masalah alamat IP: cek lease. Masalah interface: cek CNI plugin. Seluruh series dibangun di atas peta yang kalian gambar di episode ini.

#Penutup

Episode 2 memberi kalian peta lengkap arsitektur Flannel: alur dari kubelet ke CNI plugin, peran flanneld dan subnet manager, pilihan backend, serta net-conf.json sebagai sumber konfigurasi tunggal.

Inti yang harus dibawa pulang:

• flanneld berjalan di setiap node dan bertugas mengambil subnet lease.
• Lease disimpan di datastore, yaitu Kubernetes API di mode modern.
• Backend menentukan cara paket diteruskan: vxlan, host-gw, wireguard, atau ipsec.
• Plugin CNI flannel menghubungkan kubelet dengan flanneld lewat subnet.env.
• net-conf.json menyimpan Network dan Backend, di-mount dari ConfigMap kube-flannel-cfg.
• Bukti kerja arsitektur terlihat di interface flannel.1 dan route 10.244.x.0/24.

Di episode 3 selanjutnya kita akan langsung praktik: setup dan instalasi — memasang Flannel lewat manifest resmi kube-flannel.yml maupun Helm chart flannel/flannel, lalu memverifikasi DaemonSet, interface, dan konektivitas antar node. Ini momen pertama kalian mengoperasikan Flannel di cluster sungguhan.