Belajar Network Engineer - Kubernetes Networking

#Pendahuluan

Setelah di episode 16 kalian menganyam overlay sendiri, sekarang lihat bagaimana platform aplikasi modern memakai prinsip yang sama dalam skala masif: Kubernetes. Bagi network engineer 2026, cluster bukan lagi wilayah asing — tim platform akan bertanya kenapa pod tak saling tembus, kenapa policy tidak jalan, atau kenapa conntrack penuh, dan kalian diharapkan ikut menjawab.

Episode ini membedah empat lapisan networking Kubernetes: pod network + CNI, Service & kube-proxy, traffic masuk (Ingress/Gateway API), dan NetworkPolicy.

#Model Dasar: Pod Network yang Flat

Kubernetes menuntut satu kontrak sederhana namun berdampak besar:

1. Tiap pod punya IP unik, routable ke semua pod lain tanpa NAT.
2. Node-agent (kubelet) bisa bicara dengan semua pod.
3. Pod melihat dirinya dengan IP yang sama dari sudut pandang siapa pun.

Konsekuensinya: alamat pod datang dari CIDR cluster (--cluster-cidr, misal 10.244.0.0/16), dibagi per-node. Trafik antar-node diteruskan oleh... tergantung pilihan kalian — inilah CNI.

#CNI: Plugin yang Menghidupkan Kontrak

CNI (Container Network Interface) adalah spesifikasi plugin yang menyambungkan pod ke jaringan. Saat pod lahir, kubelet memanggil binary CNI untuk membuat veth pair, attach bridge/vxlan, assign IP. Pilihan utamanya:

Pertanyaan arsitektur klasiknya: overlay vs routing native. Overlay (VXLAN ala episode 16) bebas di infrastruktur apa pun; native routing butuh underlay yang routable (BGP antar node) tapi lebih cepat karena tanpa enkapsulasi. Kalau kalian sudah paham kedua dunia itu, pemilihan CNI tinggal soal konteks.

#Service: IP Stabil di Atas Pod Rapuh

Pod mati-hidup tiap deployment; IP-nya berganti. Service memberi virtual IP + DNS name yang stabil:

Yang menarik bagi engineer: kube-proxy adalah implementatornya. Ia memprogram setiap node agar VIP "ada" tanpa proses forwarding sentral:

• Mode iptables: rule NAT acak-weighted per backend — sederhana, lambat saat ribuan service.
• Mode IPVS: hash table kernel-grade — scale besar.
• Mode eBPF (via CNI seperti Cilium): data path native, paling efisien.

Debugging klasik yang wajib hafal: service ClusterIP hanya ada di iptables/IPVS — ping VIP sering gagal padahal trafik TCP normal; uji dengan request nyata, bukan ICMP.

kubectl get svc -o wide
kubectl -n kube-system get ds        # daemonset CNI/kube-proxy
sudo iptables-save | grep -i my-svc   # rule NAT-nya

#Traffic Masuk: Ingress dan Gateway API

Service LoadBalancer per aplikasi itu mahal (satu cloud LB tiap service). Solusi standarnya Ingress: satu LB di depan, routing L7 (host/path) ke banyak service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port: { number: 80 }

Ingress punya batasan ekspresi (port non-HTTP sulit); generasi penerusnya Gateway API — role-oriented (GatewayClass/Gateway/HTTPRoute), lebih kaya protokol, dan memisahkan kepemilikan infra vs tim aplikasi. Untuk kasus advanced: service mesh (Istio/Linkerd, kini makin banyak sidecar-less via eBPF) menambahkan mTLS, retry, dan traffic splitting antar-service — layer 7 governance di atas semuanya.

#NetworkPolicy: Microsegmentation Era Cloud-Native

Default Kubernetes = allow all antar pod — flat seperti LAN tanpa VLAN. Di era zero-trust, itu tidak bisa dibiarkan; jawabannya NetworkPolicy, firewall berlabel selektor.

Pola produksi wajib: default-deny dulu, izin eksplisit kemudian:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: prod
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: prod
spec:
  podSelector:
    matchLabels: { app: api }
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }
      ports:
        - { protocol: TCP, port: 8080 }

Membacanya sebagai network engineer: ini ACL dinamis berbasis identitas label — deny ip any any lalu permit from web to api tcp/8080. Egress juga bisa dibatasi (hanya DNS + destinasi tertentu), menutup jalur eksfiltrasi data.

Praktik lab cepat untuk membuktikan perilakunya:

kubectl apply -f policy-default-deny.yaml
kubectl run probe --rm -it --image=busybox -- wget -qO- --timeout=3 http://api.prod:8080
# ditolak -> tambahkan label app=web pada probe, ulangi -> lolos

#Common Pitfalls

• CIDR cluster overlap dengan on-premise/VPC — persis jebakan episode 15; pod tak bisa di-route hybrid, migrasi macet. Rencana alamat global!
• Menjanjikan policy tanpa CNI enforcement — audit security lolos di kertas, nol di realita; selalu uji deny nyata.
• Conntrack table penuh — gejala: koneksi baru gagal sporadis saat trafik spike; pantau nf_conntrack_count vs max, naikkan/tune timeout.
• NodePort/LB untuk segalanya — biaya & permukaan serangan meledak; konsolidasi lewat Ingress/Gateway API.

#Penutup

Inti yang harus dibawa pulang:

• Kontrak K8s networking: pod IP flat, no-NAT, semua bisa saling capai — CNI-lah yang mengimplementasikannya (Flannel/Calico/Cilium).
• Service stabilkan alamat; kube-proxy memprogramnya via iptables/IPVS/eBPF — debug dengan trafik nyata.
• Masuk trafik: Ingress untuk L7 hari ini, Gateway API untuk masa depan; mesh menambah mTLS & traffic control.
• NetworkPolicy default-deny + allow eksplisit adalah microsegmentasi berbasis identitas — skill ACL kalian, sintaks YAML.

Di episode 18 kita kembali ke garis pertahanan: firewall dan Next-Gen Firewall — stateful inspection, IDS/IPS inline, application awareness lintas port, dan desain zona trust-untrust-DMZ yang menjadi kerangka keamanan enterprise. Sampai jumpa!