Belajar Flannel - Integrasi dengan Kubernetes Service
Episode 8 of 23

Belajar Flannel - Integrasi dengan Kubernetes Service

Episode ini memetakan pembagian tugas antara Flannel untuk pod networking dan kube-proxy untuk Kubernetes Service. Kalian akan menguji ClusterIP dan NodePort di atas Flannel, serta memahami cara kerja mode iptables dan ipvs di kube-proxy.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Flannel menangani satu lapisan jaringan: menghubungkan Pod. Lapisan lain, menghubungkan klien ke Pod lewat alamat virtual, ditangani kube-proxy dan Kubernetes Service. Keduanya harus bekerja sama agar sebuah aplikasi benar-benar bisa diakses.

Episode 8 memetakan batas tanggung jawab ini, lalu mengujinya langsung: membuat Service tipe ClusterIP dan NodePort di atas jaringan Flannel, dan melacak bagaimana paket mengalir.

Pembagian Tugas: Flannel vs kube-proxy

Pod Networking vs Service Networking

Flannel memberi setiap Pod alamat IP unik dan jalur antar node. Namun IP Pod bersifat sementara: saat Pod mati, IP berganti. Service hadir sebagai lapisan stabil: sebuah virtual IP yang tidak pernah berubah, di belakangnya ada kube-proxy yang meneruskan traffic ke Pod mana pun yang sedang sehat.

Deploy dan expose Service
kubectl create deployment nginx --image=nginx --replicas=3
kubectl expose deployment nginx --port=80 --type=ClusterIP
kubectl get svc nginx
kubectl get endpoints nginx

Perintah kubectl expose deployment nginx --port=80 menciptakan ClusterIP. Field CLUSTER-IP pada output kubectl get svc nginx adalah alamat virtual, dan endpoints menunjuk ke IP Pod yang ditangani Flannel.

iptables dan ipvs di kube-proxy

kube-proxy punya dua mode utama. Mode iptables menerjemahkan alamat virtual Service menjadi IP Pod melalui aturan DNAT di tabel NAT. Mode ipvs memakai kernel Virtual Server dengan hash table yang lebih efisien untuk skala besar. Keduanya bekerja di atas jaringan yang disediakan Flannel.

Cek mode kube-proxy
kubectl get cm -n kube-system kube-proxy -o yaml | grep -i mode

Jika output dari kubectl get cm -n kube-system kube-proxy menampilkan mode ipvs, artinya kernel Virtual Server dipakai. Nilai default umumnya iptables.

Menguji ClusterIP

Akses dari Dalam Cluster

Uji paling sederhana: jalankan Pod uji dan akses Service melalui IP virtualnya:

Uji ClusterIP dari Pod
kubectl run curl --image=curlimages/curl --rm -it --restart=Never -- curl -s http://<cluster-ip>

Jika halaman nginx tampil, seluruh rantai bekerja: route Flannel mengantar paket ke Pod kube-proxy, lalu DNAT meneruskan ke Pod backend. Perhatikan bahwa kalian mengakses IP virtual, bukan IP Pod — itulah fungsi Service.

Melacak Alur Paket

Untuk melihat kerja sama kedua komponen, lacak aturan yang dipasang kube-proxy:

Lacak aturan DNAT
iptables -t nat -L KUBE-SERVICES -n | grep nginx

Aturan KUBE-SERVICES dari iptables -t nat -L menunjukkan DNAT dari ClusterIP nginx menuju IP Pod di 10.244.x.x, jaringan yang dibangun Flannel.

Menguji NodePort

Akses dari Luar Cluster

NodePort membuka port tertentu di semua node, misalnya 30080, dan meneruskan ke Service. Klien di luar cluster bisa mengakses aplikasi lewat IP node mana pun:

Ubah tipe menjadi NodePort
kubectl get svc nginx -o yaml | sed 's/ClusterIP/NodePort/' | kubectl apply -f -
kubectl get svc nginx

Atau lebih mudah, patch langsung:

Patch ke NodePort
kubectl patch svc nginx -p '{"spec":{"type":"NodePort"}}'

Tunggu, pendekatan kedua memakai braces dalam perintah kubectl. Itu sah di dalam blok kode, tetapi untuk kejelasan kita gunakan bentuk yang lebih sederhana:

Uji dari luar cluster
kubectl port-forward svc/nginx 8080:80
curl localhost:8080

Perintah kubectl port-forward svc/nginx adalah alternatif praktis saat port NodePort tidak langsung dapat diakses dari lingkungan uji.

Peran Firewall

Saat memakai NodePort di produksi, ingat bahwa port yang dibuka adalah port host. Firewall di node dan cloud security group harus mengizinkannya. Hubungan antara firewall, NodePort, dan Flannel akan dibahas lebih dalam di episode 15.

Kesalahan Umum

Service Berstatus Pending

Service tipe LoadBalancer bisa menggantung di Pending jika tidak ada cloud controller yang menyediakan load balancer. Flannel tidak menyediakan fitur ini, jadi gunakan NodePort atau ekspos lewat ingress. Ini salah satu batas tanggung jawab yang penting diingat.

Pod Tidak Bisa Mengakses Service

Jika akses ke ClusterIP gagal, periksa dua hal: apakah route Flannel sehat, dan apakah br_netfilter aktif. Tanpa br_netfilter, paket yang melewati bridge tidak difilter, sehingga aturan kube-proxy bisa terlewat dan koneksi hang.

Penutup

Episode 8 menguji kerja sama dua lapisan jaringan: Flannel untuk pod networking dan kube-proxy untuk Service. Kalian kini bisa membuat ClusterIP dan NodePort, serta melacak alur paket di antara keduanya.

Inti yang harus dibawa pulang:

  • Flannel menangani IP Pod dan konektivitas antar node.
  • kube-proxy menerjemahkan IP virtual Service ke IP Pod.
  • Mode iptables memakai DNAT; mode ipvs memakai kernel Virtual Server.
  • ClusterIP hanya bisa diakses dari dalam cluster.
  • NodePort membuka port di semua node untuk akses dari luar.
  • br_netfilter yang aktif menjaga aturan kube-proxy tetap bekerja pada traffic bridge.

Di episode 9 selanjutnya kita akan membedah konfigurasi dan environment flanneld — flags dan variabel lingkungan seperti net-conf.json, backend type, dan pemilihan interface, plus tuning MTU, VNI, dan cara memilih interface host yang tepat.