Kubernetes Network Model #
Kubernetes memilih pendekatan networking yang sangat spesifik dan berbeda dari model Docker biasa. Sebelum membahas Service, Ingress, atau NetworkPolicy, penting untuk memahami aturan-aturan dasar yang menjadi fondasi seluruh sistem jaringan Kubernetes. Aturan ini tidak bisa dikonfigurasi — mereka adalah kontrak yang harus dipatuhi oleh semua implementasi jaringan di atas Kubernetes.
Empat Aturan Fundamental #
Model jaringan Kubernetes dibangun di atas empat aturan yang tidak bisa dinegosiasikan:
Aturan 1: Setiap Pod mendapat IP address sendiri
→ Tidak ada NAT antara Pod
→ Pod-A bisa langsung menghubungi Pod-B menggunakan IP Pod-B
→ Tidak perlu port mapping seperti di Docker run -p
Aturan 2: Semua Pod bisa berkomunikasi satu sama lain
→ Tanpa NAT, dari node manapun ke node manapun
→ Pod di Node-1 bisa langsung hubungi Pod di Node-3
→ Tidak perlu konfigurasi khusus untuk komunikasi lintas node
Aturan 3: Node bisa berkomunikasi dengan semua Pod
→ Proses di node bisa hubungi Pod tanpa NAT
→ Penting untuk kubelet, node-level monitoring, dll
Aturan 4: IP yang Pod lihat adalah IP yang dilihat orang lain
→ Tidak ada IP masquerading
→ Pod tahu IP-nya sendiri adalah IP yang bisa dijangkau dari luar
Flat Network: Satu Ruang Alamat IP #
Model ini menciptakan apa yang disebut flat network — seolah semua Pod berada di satu jaringan besar yang sama, meskipun secara fisik mereka tersebar di banyak node.
Ilustrasi flat network:
Node 1 (10.0.0.1): Node 2 (10.0.0.2):
Pod A: 10.244.1.2 Pod C: 10.244.2.3
Pod B: 10.244.1.7 Pod D: 10.244.2.9
Komunikasi yang terjadi:
Pod A → Pod C: langsung, tanpa NAT
Pod B → Pod D: langsung, tanpa NAT
Pod A → Pod D: langsung, tanpa NAT
Dari perspektif Pod:
"Saya punya IP 10.244.1.2, dan saya bisa langsung
hubungi 10.244.2.3 tanpa perlu tahu bahwa
Pod C ada di node yang berbeda."
Ini berbeda fundamental dari Docker standalone, di mana container di mesin berbeda tidak bisa saling berkomunikasi tanpa port forwarding atau overlay network yang dikonfigurasi secara eksplisit.
Bagaimana IP Pod Dialokasikan #
Setiap node mendapat Pod CIDR — rentang IP yang bisa digunakan oleh Pod di node tersebut. Control plane mengalokasikan Pod CIDR yang tidak tumpang tindih ke setiap node.
Cluster CIDR: 10.244.0.0/16
Node 1 → Pod CIDR: 10.244.1.0/24 (bisa host 254 Pod)
Node 2 → Pod CIDR: 10.244.2.0/24
Node 3 → Pod CIDR: 10.244.3.0/24
Saat Pod dibuat di Node 1:
→ Kubelet meminta IP dari rentang 10.244.1.0/24
→ CNI plugin mengalokasikan 10.244.1.5 untuk Pod baru
→ IP ini unik di seluruh cluster
IP Pod bersifat ephemeral — berubah setiap kali Pod dibuat ulang. Jika Pod crash dan diganti Pod baru, IP-nya akan berbeda. Inilah mengapa komunikasi antar service tidak boleh mengandalkan IP Pod langsung — harus melalui Service yang memiliki IP stabil.
Peran CNI Plugin #
Kubernetes tidak mengimplementasikan jaringan sendiri. Ia mendelegasikan semua tugas jaringan ke CNI (Container Network Interface) plugin — komponen eksternal yang bertanggung jawab atas:
Tugas CNI plugin:
1. Membuat network interface di dalam Pod saat Pod dibuat
2. Mengalokasikan IP dari Pod CIDR
3. Memastikan Pod bisa berkomunikasi lintas node
4. Membersihkan interface dan membebaskan IP saat Pod dihapus
CNI plugin yang populer:
Flannel: Simple overlay network, cocok untuk cluster kecil/menengah
Calico: Dukungan NetworkPolicy kuat, performa tinggi, banyak dipakai produksi
Cilium: eBPF-based, observability sangat baik, cocok untuk cluster modern
Weave Net: Mudah di-setup, enkripsi bawaan
Canal: Kombinasi Flannel (routing) + Calico (NetworkPolicy)
Pilihan CNI plugin tidak mempengaruhi cara kamu menulis manifest Kubernetes — semua Pod, Service, dan NetworkPolicy manifest sama saja terlepas dari CNI yang digunakan. CNI adalah implementation detail.
Namespace Jaringan Pod #
Setiap Pod punya network namespace sendiri — isolasi jaringan di level kernel Linux. Ini berarti:
Network namespace Pod:
Pod A (network namespace A):
eth0: 10.244.1.5
lo: 127.0.0.1
Routing table: semua traffic keluar via eth0
Pod B (network namespace B):
eth0: 10.244.1.7
lo: 127.0.0.1
Implikasi:
→ Container dalam Pod yang sama berbagi namespace → bisa localhost
→ Container di Pod berbeda tidak berbagi namespace → butuh IP
→ Proses di host berbeda namespace dari semua Pod
Ini adalah alasan mengapa container dalam satu Pod bisa berkomunikasi via localhost (berbagi network namespace), tapi Pod berbeda harus menggunakan IP Pod atau Service.
Perbedaan dengan Docker Networking #
Memahami perbedaan ini penting terutama bagi yang sudah familiar dengan Docker:
Docker standalone:
Container mendapat IP internal (172.17.0.x) yang tidak routable dari luar host
Untuk akses dari luar: butuh port mapping (-p 8080:80)
Container di host berbeda: tidak bisa langsung berkomunikasi
→ Docker networking adalah host-scoped, bukan cluster-scoped
Kubernetes:
Pod mendapat IP yang routable di seluruh cluster
Tidak ada port mapping yang diperlukan untuk komunikasi antar Pod
Pod di node berbeda bisa langsung berkomunikasi
→ Kubernetes networking adalah cluster-scoped flat network
Ringkasan #
- Empat aturan tidak bisa dinegosiasikan — setiap Pod dapat IP sendiri, semua Pod bisa saling berkomunikasi tanpa NAT, node bisa hubungi semua Pod, dan tidak ada IP masquerading.
- Flat network = satu ruang IP untuk seluruh cluster — Pod di node berbeda bisa langsung berkomunikasi seolah berada di jaringan yang sama.
- IP Pod bersifat ephemeral — berubah setiap kali Pod dibuat ulang; jangan andalkan IP Pod langsung untuk komunikasi antar service, gunakan Service.
- CNI plugin mengimplementasikan model ini — Calico, Cilium, Flannel adalah pilihan populer; pilihan CNI tidak mempengaruhi cara menulis manifest.
- Setiap Pod punya network namespace sendiri — container dalam Pod yang sama berbagi namespace (bisa localhost), container di Pod berbeda tidak berbagi.
- Berbeda fundamental dari Docker standalone — Docker networking adalah host-scoped; Kubernetes networking adalah cluster-scoped flat network.
← Sebelumnya: Storage Performance Berikutnya: Pod-to-Pod Communication →