Pod-to-Pod Communication #

Model jaringan Kubernetes menjamin bahwa setiap Pod memiliki alamat IP unik sendiri dan seluruh Pod dapat saling berkomunikasi secara langsung tanpa melalui Network Address Translation (NAT). Namun, bagi kita yang bertanggung jawab menjaga kestabilan infrastruktur produksi, sekadar mengetahui “kontrak” ini tidaklah cukup. Kita harus memahami secara mendalam mekanisme fisik bagaimana paket data bergerak melintasi kartu jaringan virtual, jembatan virtual kernel, hingga terowongan enkapsulasi jaringan fisik.

Memahami alur kerja perjalanan paket data (packet flow) dari satu Pod ke Pod lain adalah fondasi utama kita dalam mendiagnosis gangguan konektivitas (network troubleshooting), menyetel performa transfer data, serta memahami mengapa objek abstraksi seperti Service dan DNS diciptakan.

Artikel ini akan membahas secara mendalam dua skenario utama komunikasi antar Pod: komunikasi di dalam satu node worker yang sama (intra-node) dan komunikasi lintas node worker (inter-node), serta menyajikan teknik-teknik pengujian jaringannya.

Skenario 1: Komunikasi Intra-Node (Pod di Node yang Sama) #

Ketika dua buah Pod berada di dalam satu server fisik atau VM worker node yang sama, paket data tidak pernah keluar menuju kartu jaringan fisik node tersebut. Seluruh proses pengiriman paket diselesaikan sepenuhnya di dalam memori dan kernel Linux host menggunakan kombinasi veth pair dan virtual bridge.

Mari kita perhatikan arsitektur internal komunikasi intra-node melalui diagram berikut:

flowchart TD
    subgraph PodA["Pod A Namespace (10.244.1.2)"]
        eth0A["eth0 (Pod A)"]
    end

    subgraph PodB["Pod B Namespace (10.244.1.3)"]
        eth0B["eth0 (Pod B)"]
    end

    subgraph HostNamespace["Host Node Worker 1"]
        cbr0["Virtual Bridge: cbr0 (Linux Bridge)"]
        vethA["veth-a (Host-end)"]
        vethB["veth-b (Host-end)"]
    end

    eth0A <--> vethA
    vethA <--> cbr0
    cbr0 <--> vethB
    vethB <--> eth0B

Komponen Kunci Jaringan Lokal Node #

  1. veth pair (Virtual Ethernet Pair): Kita dapat membayangkan veth pair sebagai kabel jaringan virtual dua arah. Ketika Kubelet membuat Pod baru, ia membuat sepasang interface veth. Satu ujung kabel virtual ini dimasukkan ke dalam namespace jaringan Pod (diberi nama eth0 di dalam Pod), sementara ujung kabel lainnya tetap berada di namespace host node (diberi nama acak seperti veth-a atau veth-b).
  2. Linux Bridge (cbr0): Ini adalah perangkat switch Ethernet virtual berbasis perangkat lunak yang berjalan di dalam kernel Linux host. Semua ujung kabel veth yang berada di namespace host (seperti veth-a dan veth-b) dicolokkan ke bridge ini. Bridge ini bertindak sebagai perantara yang menghubungkan seluruh interface jaringan virtual tersebut ke dalam satu segmen LAN lokal yang sama.

Alur Perjalanan Paket Data (Step-by-Step) #

Mari kita telusuri alur pengiriman paket ketika Pod A (10.244.1.2) mengirimkan request HTTP ke Pod B (10.244.1.3):

  1. Penentuan Rute oleh Pod A: Kernel di dalam namespace Pod A memeriksa alamat IP tujuan (10.244.1.3). Karena IP tersebut berada di dalam subnet lokal yang sama (misalnya 10.244.1.0/24), kernel menyimpulkan paket dapat dikirim langsung ke gateway default, yaitu interface eth0 milik Pod A.
  2. Melintasi Kabel Virtual: Paket data meninggalkan eth0 Pod A dan secara instan muncul di ujung kabel pasangannya di namespace host, yaitu interface veth-a.
  3. Pengambilan Keputusan oleh Bridge: Paket data tiba di virtual bridge cbr0. Bridge ini bertindak layaknya switch fisik layer 2. Ia membaca alamat MAC tujuan dari paket tersebut. Jika bridge belum tahu di interface mana alamat MAC tujuan tersebut berada, ia akan menyebarkan kueri ARP (Address Resolution Protocol) ke seluruh port yang terhubung dengannya: “Siapa pemilik alamat IP 10.244.1.3?”.
  4. Respon dan Pengiriman: Interface veth-b (ujung dari Pod B) merespon dengan alamat MAC miliknya. Bridge cbr0 kemudian memperbarui tabel MAC address internalnya dan meneruskan paket tersebut langsung ke port veth-b.
  5. Penerimaan oleh Pod B: Paket data melintasi kabel virtual veth-b dan muncul di interface eth0 milik Pod B. Kernel Pod B menerima paket tersebut dan meneruskannya ke port aplikasi kita.

Seluruh komunikasi ini terjadi dengan kecepatan memori lokal (memory speed) tanpa melibatkan latensi kartu jaringan fisik (network interface card atau NIC), sehingga latensinya sangat rendah (di bawah 0,1 ms).

Skenario 2: Komunikasi Inter-Node (Pod Lintas Node) #

Ketika Pod A di Node 1 ingin menghubungi Pod C di Node 2, alur komunikasinya menjadi jauh lebih kompleks. Paket data sekarang harus meninggalkan server fisik Node 1, melintasi switch jaringan fisik data center atau infrastruktur VPC cloud, dan mendarat di Node 2.

Untuk mewujudkan hal ini, kita sangat bergantung pada konfigurasi routing CNI. Ada dua pendekatan utama yang umum digunakan oleh CNI untuk menghubungkan Pod lintas node: Overlay Network (Enkapsulasi) dan Native Routing (Direct Routing).

Pendekatan A: Overlay Network (Enkapsulasi VXLAN) #

Metode overlay network membuat jaringan logis virtual di atas jaringan fisik yang ada. CNI seperti Flannel secara default, atau Calico/Cilium dengan mode VXLAN aktif, akan membungkus paket data asli Pod ke dalam paket UDP jaringan fisik host node.

Mari kita perhatikan bagaimana paket di-enkapsulasi melintasi jaringan fisik:

flowchart TD
    subgraph Node1["Node Worker 1 (10.0.0.10)"]
        PodA["Pod A (10.244.1.5)"] --> Netns1["veth-a"]
        Netns1 --> Bridge1["cbr0"]
        Bridge1 --> Tunnel1["VXLAN Tunnel Interface (flannel.1)"]
        Tunnel1 --> NIC1["Physical NIC (eth0)"]
    end

    subgraph PhysicalNet["Infrastruktur Jaringan Fisik / Cloud VPC"]
        NIC1 -- "Encapsulated UDP Packet (Port 4789)" --> NIC2
    end

    subgraph Node2["Node Worker 2 (10.0.0.11)"]
        NIC2["Physical NIC (eth0)"] --> Tunnel2["VXLAN Tunnel Interface (flannel.1)"]
        Tunnel2 --> Bridge2["cbr0"]
        Bridge2 --> Netns2["veth-c"]
        Netns2 --> PodC["Pod C (10.244.2.3)"]
    end

Alur Enkapsulasi Paket (Step-by-Step) #

  1. Kegagalan Routing Lokal: Pod A (10.244.1.5) mengirim paket ke Pod C (10.244.2.3). Kernel Node 1 melihat bahwa IP tujuan berada di luar subnet lokal Node 1 (10.244.1.0/24). Paket dikirim ke interface default gateway host.
  2. Penangkapan oleh CNI Tunnel: Route table di Node 1 mengarahkan lalu lintas subnet 10.244.2.0/24 ke antarmuka terowongan virtual CNI (misalnya flannel.1 atau cilium_vxlan).
  3. Proses Enkapsulasi (Wrapping): Antarmuka virtual CNI mengambil paket asli dan membungkusnya di dalam satu paket UDP baru.
    • Header Dalam (Inner Header): Menunjukkan pengirim asli 10.244.1.5 (Pod A) dan tujuan asli 10.244.2.3 (Pod C).
    • Header Luar (Outer Header): Menunjukkan alamat IP fisik pengirim 10.0.0.10 (Node 1) dan alamat IP fisik tujuan 10.0.0.11 (Node 2) dengan port tujuan UDP standar VXLAN (port 4789).
  4. Perjalanan di Jaringan Fisik: Router fisik atau switch VPC cloud hanya melihat paket UDP biasa dari Node 1 ke Node 2. Mereka tidak perlu tahu mengenai keberadaan IP Pod. Paket dikirim seperti lalu lintas server-to-server biasa.
  5. Dekapsulasi di Node Tujuan: Paket mendarat di Node 2. Kernel Node 2 melihat paket tersebut ditujukan untuk port VXLAN 4789, lalu meneruskannya ke driver CNI lokal. Driver CNI membuka bungkus paket UDP tersebut, mengambil paket asli di dalamnya, dan melemparkannya ke bridge virtual Node 2 untuk diantarkan langsung ke Pod C.

Overhead dan Optimasi MTU #

Enkapsulasi VXLAN menambahkan beban tambahan (overhead) sebesar 50 byte pada setiap paket (header IP + UDP + VXLAN). Jika antarmuka jaringan fisik kita memiliki batas ukuran paket standar (MTU - Maximum Transmission Unit) sebesar 1500 byte, maka MTU di dalam Pod kita wajib diturunkan menjadi 1450 byte. Jika tidak, paket data akan mengalami fragmentasi di tingkat host node yang memicu penurunan performa throughput jaringan secara signifikan.

Pendekatan B: Native Routing (Direct Routing dengan BGP) #

Pada pendekatan native routing, kita tidak menggunakan enkapsulasi paket. Tidak ada overhead pembungkusan UDP. Paket dikirim secara mentah apa adanya melintasi jaringan fisik. CNI seperti Calico menggunakan protokol BGP (Border Gateway Protocol) untuk mengubah setiap worker node kita menjadi router dinamis yang mengiklankan rute CIDR Pod ke router jaringan fisik data center kita.

Alur Native Routing (Step-by-Step) #

  1. Pengiriman Langsung: Pod A (10.244.1.5) mengirim paket ke Pod C (10.244.2.3).
  2. Pengecekan Route Table Host: Kernel Node 1 melihat tabel routing yang dikonfigurasi oleh Calico: “Untuk menuju 10.244.2.0/24, kirim paket langsung melalui gerbang default gateway fisik node” (tanpa membungkus paket).
  3. Routing oleh Router Fisik: Router jaringan fisik kita sudah menerima iklan BGP dari Node 2 sebelumnya: “Blok 10.244.2.0/24 ada di belakang IP host 10.0.0.11”. Router fisik langsung membelokkan paket mentah tersebut ke Node 2.
  4. Penerimaan Langsung: Node 2 menerima paket mentah tersebut dan langsung meneruskannya ke Pod C via bridge local.

Kelebihan & Keterbatasan #

  • Kelebihan: Performa transmisi data maksimal (setara dengan jaringan bare-metal fisik) dan latensi minimal karena tidak ada beban CPU untuk enkapsulasi/dekapsulasi.
  • Keterbatasan: Router fisik data center kita harus dikonfigurasi agar mendukung integrasi BGP dengan node worker. Pada cloud provider publik (seperti AWS VPC), router cloud sering kali membuang paket yang memiliki alamat IP pengirim yang tidak terdaftar pada tabel routing VPC (masalah Source/Destination Check). Oleh karena itu, di cloud, kita sering menggunakan mode campuran (cross-subnet atau hybrid) di mana enkapsulasi hanya diaktifkan jika paket harus melintasi batas subnet router cloud.

Enkripsi Lalu Lintas Jaringan Antar-Node #

Secara default, seluruh paket data yang mengalir antar node worker berjalan dalam bentuk teks biasa (clear text). Jika kluster kita berada di cloud publik, ada risiko lalu lintas data sensitif kita (seperti data transaksi, kredensial, atau data pribadi pengguna) dapat diintip oleh pihak luar yang memiliki akses ke hypervisor cloud.

Untuk mengamankan data tersebut, CNI modern seperti Cilium dan Calico menyediakan opsi enkripsi transparan tingkat kluster menggunakan WireGuard atau IPsec.

Enkripsi Transparan Layer Jaringan (CNI WireGuard):
  [Pod A (Plain Data)] 
         │
         ▼
  [Node 1 Kernel (Cilium WireGuard Interface)] ──> Enkripsi Paket (AES/ChaCha20)
         │
         ▼ (Encrypted Tunnel via Jaringan Fisik)
  [Node 2 Kernel (Cilium WireGuard Interface)] ──> Dekripsi Paket
         │
         ▼
  [Pod C (Plain Data)]

Dengan mengaktifkan fitur ini, kernel Linux host secara otomatis akan mengenkripsi seluruh paket data antar-Pod sebelum meninggalkan node worker menggunakan algoritma kriptografi modern berkecepatan tinggi (seperti ChaCha20 untuk WireGuard), dan mendekripsinya saat mendarat di node tujuan. Aplikasi kita tidak memerlukan modifikasi kode sama sekali karena keamanan dijamin langsung pada tingkat infrastruktur jaringan.

Anti-Pattern vs Solusi dalam Komunikasi Antar Pod #

Mari kita pelajari beberapa kesalahan fatal yang sering kita temukan saat mengelola komunikasi antar Pod beserta perbandingan manifes kodenya.

Anti-Pattern 1: Menggunakan Alamat IP Pod Secara Hardcoded untuk Menghubungi Layanan Lain #

Kita menaruh konfigurasi alamat IP Pod database (10.244.1.7) secara langsung di dalam konfigurasi variabel lingkungan (environment variables) Pod backend kita.

Kode Manifest Salah (Hardcoded Ephemeral IP) # 

# JANGAN LAKUKAN INI DI PRODUKSI: IP Pod mudah berubah
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-app-bad
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: app-container
          image: my-app:v1.0.0
          env:
            - name: DATABASE_URL
              value: "postgresql://postgres:[email protected]:5432/db" # JANGAN: IP Pod database tidak stabil!

Konsekuensi Buruk #

Jika Pod database mengalami crash di tengah malam, Kubernetes akan menghidupkan kembali Pod database baru yang sehat di node worker lain. Namun, Pod database baru ini akan mendapatkan alamat IP baru (misalnya 10.244.2.12). Akibatnya, Pod backend kita akan kehilangan koneksi secara total dan terus menerus memicu error koneksi database karena mereka masih mencoba menghubungi alamat IP lama 10.244.1.7.

Kode Solusi (Menggunakan Abstraksi Service DNS) #

Kita wajib mendeploy sebuah objek Service di depan Pod database kita. Service menyediakan IP virtual yang stabil (ClusterIP) dan nama DNS internal yang tidak akan pernah berubah selama objek Service tersebut aktif, tidak peduli berapa kali Pod di belakangnya mengalami restart atau pergantian alamat IP.

# SOLUSI: Selalu gunakan nama DNS Service internal
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-app-good
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: app-container
          image: my-app:v1.0.0
          env:
            - name: DATABASE_URL
              value: "postgresql://postgres:[email protected]:5432/db" # Kredensial stabil via DNS Service

Anti-Pattern 2: Mengabaikan Penyelarasan MTU pada CNI Overlay Cloud #

Kita mendeploy kluster Kubernetes mandiri di cloud AWS menggunakan CNI Calico dengan enkapsulasi VXLAN aktif, namun kita tetap membiarkan setelan MTU pada CNI menggunakan nilai default ethernet fisik host sebesar 1500 byte.

Konsekuensi Buruk #

Setiap kali aplikasi kita mengirimkan paket data berukuran penuh (1500 byte), driver CNI akan menambahkan header enkapsulasi VXLAN sebesar 50 byte, membuat ukuran paket membengkak menjadi 1550 byte. Karena jaringan VPC cloud membatasi paket fisik maksimal 1500 byte, host node terpaksa memecah satu paket tersebut menjadi dua bagian (packet fragmentation) di tingkat kernel host. Hal ini memicu pemborosan CPU node secara drastis untuk proses fragmentasi/reassembly dan menurunkan kinerja throughput jaringan hingga 30%.

Kode Solusi (Mengonfigurasi MTU secara Presisi pada CNI) #

Kita harus menyelaraskan ukuran MTU pada konfigurasi plugin CNI agar menyisakan ruang bagi header enkapsulasi. Untuk VXLAN, kurangi MTU sebesar 50 byte dari MTU fisik host (1500 - 50 = 1450).

# SOLUSI: Contoh potongan konfigurasi ConfigMap Calico CNI
apiVersion: v1
kind: ConfigMap
metadata:
  name: calico-config
  namespace: kube-system
data:
  # Konfigurasi MTU teroptimasi untuk VXLAN overlay
  veth_mtu: "1450" # Memastikan paket di dalam Pod maksimal 1450, sehingga total paket fisik setelah enkapsulasi pas 1500

Panduan Praktis Menguji & Debugging Jaringan Pod #

Ketika terjadi kendala komunikasi antar Pod di kluster, kita dapat melakukan investigasi sistematis langsung dari terminal menggunakan alat bantu debugging jaringan.

1. Membuat Pod Debug Terisolasi (netshoot) #

Sering kali image aplikasi produksi kita sengaja dirancang sangat minimalis (distroless) demi keamanan, sehingga tidak memiliki utility seperti ping, curl, atau nslookup. Kita dapat meluncurkan kontainer debug khusus bernama netshoot yang sudah dilengkapi dengan seluruh perangkat analisis jaringan:

kubectl run network-debugger --rm -i --tty --image nicolaka/netshoot -- /bin/bash

2. Pengujian Koneksi Layer 3 (IP Routing) #

Dari dalam Pod debug, lakukan ping langsung ke IP Pod tujuan untuk memverifikasi fungsionalitas CNI inter-node routing:

# Ping IP Pod tujuan di node worker lain
ping -c 4 10.244.2.3

3. Melacak Lompatan Paket (Tracepath) #

Jika ping gagal, gunakan tracepath atau traceroute untuk melihat di lompatan (hop) router mana paket data kita dibuang:

tracepath -n 10.244.2.3

4. Memantau Paket Data Fisik Node Worker #

Jika kita memiliki akses SSH ke node worker host, kita dapat menggunakan tcpdump pada kartu jaringan fisik node untuk memastikan apakah paket terenkapsulasi VXLAN (port 4789) berhasil keluar dari node pengirim:

# Pantau lalu lintas VXLAN di node worker host
sudo tcpdump -i eth0 -n udp port 4789

Ringkasan #

  • Komunikasi intra-node berjalan cepat di memori: Pod di node yang sama berkomunikasi melalui virtual ethernet bridge lokal (cbr0) menggunakan veth pairs tanpa menyentuh jaringan fisik.
  • Overlay network menggunakan enkapsulasi VXLAN: Paket asli dibungkus dalam paket UDP port 4789 host untuk dikirim lintas node; membutuhkan penyesuaian MTU sebesar 1450 byte untuk menghindari fragmentasi.
  • Native routing BGP meniadakan overhead: Menghubungkan Pod langsung melalui jaringan fisik menggunakan rute IP asli; memerlukan integrasi erat dengan konfigurasi router fisik/cloud VPC.
  • Enkripsi transparan dengan WireGuard: CNI modern mendukung enkripsi otomatis tingkat kernel untuk lalu lintas antar node guna melindungi data sensitif dari sniffing jaringan fisik.
  • Selalu gunakan DNS Service: IP Pod bersifat ephemeral dan rentan berubah saat Pod restart. Selalu gunakan nama DNS Service stabil untuk komunikasi inter-service.
  • Gunakan container debug netshoot: Gunakan kubectl run dengan image debugger khusus untuk mendiagnosis kendala routing, DNS, dan firewall port secara interaktif.

← Sebelumnya: Kubernetes Network Model   Berikutnya: Service →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact