Pod-to-Pod Communication #
Memahami bagaimana paket data bergerak dari satu Pod ke Pod lain adalah fondasi untuk mendiagnosis masalah jaringan dan memahami mengapa konsep seperti Service dan DNS sangat penting. Ada dua skenario yang perlu dipahami: komunikasi antara Pod di node yang sama, dan komunikasi antara Pod di node yang berbeda.
Komunikasi dalam Satu Node #
Ketika dua Pod berada di node yang sama, komunikasi mereka melewati virtual ethernet bridge di dalam node tersebut.
Node 1
Pod A Pod B
(10.244.1.2) (10.244.1.7)
┌─────────┐ ┌─────────┐
│ eth0 │ │ eth0 │
└────┬────┘ └────┬────┘
│ veth-a │ veth-b
│ (virtual ethernet pair) │
└──────────────┬───────────────┘
│
┌────┴────┐
│ cbr0 │ ← Linux bridge (created by CNI)
│(bridge) │
└─────────┘
Prosesnya:
Pod A mengirim paket ke 10.244.1.7 (Pod B):
1. Kernel Pod A melihat: 10.244.1.7 ada di subnet lokal (10.244.1.0/24)
2. ARP request: "siapa punya 10.244.1.7?"
3. Bridge cbr0 menjawab: "via veth-b"
4. Paket dikirim melalui cbr0 → veth-b → eth0 Pod B
5. Pod B menerima paket
Seluruh proses terjadi di dalam node, tidak ada traffic keluar ke network fisik.
Komunikasi Lintas Node #
Komunikasi antara Pod di node yang berbeda lebih kompleks — paket harus melewati network fisik antara node. Di sinilah CNI plugin memainkan peran utama.
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 A → Pod C:
1. Pod A mengirim paket ke 10.244.2.3
2. Kernel Pod A: 10.244.2.3 TIDAK di subnet lokal → kirim ke gateway
3. Paket keluar dari Node 1 menuju network fisik
4. [Di sini CNI plugin bekerja]
5. Paket tiba di Node 2
6. Node 2 meneruskan ke Pod C via bridge lokal
Bagaimana paket bisa sampai ke Node 2 dan tahu bahwa 10.244.2.3 ada di sana? Ada dua pendekatan utama:
Pendekatan 1: Overlay Network (Encapsulation) #
CNI plugin seperti Flannel menggunakan teknik encapsulation — paket asli dibungkus dalam paket UDP atau IP baru dengan header yang menunjuk ke node tujuan.
Overlay dengan VXLAN (Flannel default):
Paket asli:
Src: 10.244.1.2 (Pod A)
Dst: 10.244.2.3 (Pod C)
Setelah di-encapsulate:
Outer header:
Src: 10.0.0.1 (Node 1 IP)
Dst: 10.0.0.2 (Node 2 IP)
Inner header (payload):
Src: 10.244.1.2 (Pod A IP, asli)
Dst: 10.244.2.3 (Pod C IP, asli)
Node 2 menerima paket, membuka encapsulation, meneruskan ke Pod C.
Overhead: setiap paket punya header tambahan. Untuk traffic intensif, ini mempengaruhi throughput dan latensi.
Pendekatan 2: Native Routing (BGP) #
CNI plugin seperti Calico bisa menggunakan BGP (Border Gateway Protocol) untuk mengiklankan Pod CIDR setiap node ke router fisik. Tidak ada encapsulation — routing terjadi di layer jaringan biasa.
Native routing dengan BGP (Calico):
Router jaringan tahu:
10.244.1.0/24 → via 10.0.0.1 (Node 1)
10.244.2.0/24 → via 10.0.0.2 (Node 2)
Pod A mengirim ke 10.244.2.3:
→ Paket dikirim ke router
→ Router meneruskan ke 10.0.0.2 (Node 2)
→ Node 2 meneruskan ke Pod C
Tidak ada overhead encapsulation → performa lebih baik.
Tapi butuh integrasi dengan router fisik.
Mengapa IP Pod Tidak Cukup #
Meskipun Pod bisa saling berkomunikasi langsung via IP, menggunakan IP Pod secara langsung dalam kode atau konfigurasi adalah praktik yang salah.
Masalah dengan hardcode IP Pod:
Service A dikonfigurasi: connect to 10.244.1.7 (Pod B)
Skenario 1: Pod B crash → Pod baru dibuat dengan IP 10.244.1.12
Service A masih coba hubungi 10.244.1.7 → GAGAL
Service A tidak tahu Pod B sudah punya IP baru
Skenario 2: Pod B di-scale dari 1 ke 3 replica
Service A hanya tahu IP satu Pod → load tidak terdistribusi
Skenario 3: Rolling update → Pod B diganti dengan versi baru
IP berubah → Service A kehilangan koneksi
Solusinya adalah Service — resource Kubernetes yang menyediakan IP stabil dan DNS name yang tidak berubah meskipun Pod di belakangnya berubah. Service dibahas di artikel berikutnya.
DNS untuk Penemuan Pod #
Kubernetes menyediakan DNS internal yang memungkinkan Pod saling menemukan berdasarkan nama, bukan IP. Setiap Pod mendapat DNS record yang bisa digunakan untuk resolusi:
Format DNS untuk Pod:
<pod-ip-dengan-dash>.<namespace>.pod.cluster.local
Contoh:
Pod dengan IP 10.244.1.5 di namespace production:
10-244-1-5.production.pod.cluster.local
Namun format ini jarang digunakan secara langsung.
Yang lebih umum: DNS record untuk Service yang di-forward ke Pod.
DNS Pod langsung memang bisa digunakan, tapi karena IP berubah saat Pod restart, ini tetap tidak reliable. DNS Service jauh lebih berguna karena tidak berubah.
Mengamati Jaringan Pod #
Beberapa perintah berguna untuk memeriksa networking Pod:
# Lihat IP Pod
kubectl get pods -o wide
# Output:
# NAME READY STATUS IP NODE
# api-abc123 1/1 Running 10.244.1.5 worker-1
# api-def456 1/1 Running 10.244.2.8 worker-2
# Masuk ke dalam Pod dan cek interface jaringan
kubectl exec -it api-abc123 -- ip addr show
# Cek routing table dari dalam Pod
kubectl exec -it api-abc123 -- ip route
# Test koneksi dari Pod A ke Pod B
kubectl exec -it api-abc123 -- curl http://10.244.2.8:8080
# Lihat Pod CIDR yang dialokasikan ke setiap node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'
Ringkasan #
- Komunikasi dalam satu node melalui Linux bridge — CNI plugin membuat virtual ethernet bridge; paket tidak perlu keluar ke network fisik.
- Komunikasi lintas node via overlay atau native routing — overlay (VXLAN) lebih fleksibel tapi punya overhead; native routing (BGP) lebih efisien tapi butuh integrasi router.
- IP Pod bersifat ephemeral — berubah saat Pod restart, scale, atau update; jangan hardcode IP Pod dalam konfigurasi atau kode aplikasi.
- Gunakan Service, bukan IP Pod langsung — Service menyediakan IP stabil dan DNS name yang tidak berubah meskipun Pod di belakangnya berubah.
- CNI plugin adalah implementasi detail — pilihan CNI (Flannel, Calico, Cilium) mempengaruhi performa dan fitur, tapi tidak mengubah cara kamu menulis manifest.
kubectl get pods -o wide— cara paling mudah melihat IP Pod dan di node mana ia berjalan.
← Sebelumnya: Kubernetes Network Model Berikutnya: Service →