🎯 Lesson Objective

Understand the basic to advanced Kubernetes network model: why each Pod has its own IP, 4 types of communication patterns, CNI plugins (Cilium recommended 2026), and kube-proxy with nftables.

1. Kubernetes Networking Requirements

Kubernetes has 3 core networking requirements:

• Every Pod must be able to communicate with every other Pod in the cluster no need for NAT
• Every Node must be able to communicate with every Pod no need for NAT
• The IP that the Pod itself sees must be the same as the IP that other Pods see__HTMLTAG_19___

This is a "flat network model" — unlike the default Docker (NAT-based).

2. Four Communication Patterns

2.1 Container-to-Container (in the same Pod)

Containers in the same Pod share network namespace → communicate via localhost.

# Container A call container B (cùng pod)
curl http://localhost:8080/api

2.2 Pod-to-Pod

Each Pod has a separate IP in the cluster. Pods communicate directly over IP — CNI plugin ensures routing.

# Pod A (10.244.1.5) gọi Pod B (10.244.2.3)
curl http://10.244.2.3:8080/api
Thực tế nên dùng Service name, không hardcode IP
curl http://backend-service/api

2.3 Pod-to-Service

Pods communicate with the Service via ClusterIP (virtual IP). kube-proxy creates iptables/nftables rules to DNAT (destination NAT) to real Pod IP.

# Client Pod → Service ClusterIP (10.96.0.100) → kube-proxy rules → Pod IP (10.244.x.x)
curl http://backend-service    # CoreDNS resolve → ClusterIP → Pod

2.4 External-to-Service

Traffic from outside the cluster to the Service via NodePort, LoadBalancer, or Gateway API (HTTPRoute).

3. CNI (Container Network Interface)

CNI is the standard interface between Kubernetes and network plugins. When the Pod is created, the kubelet calls the CNI plugin to:

• Create network interface for Pod
• Assign IP address
• Routing configuration

3.1 Cilium — Recommended 2026

Cilium uses eBPF (extended Berkeley Packet Filter) at the kernel level — no need for iptables chains.

Cilium Advantages:

• eBPF: fast, programmable, kernel-level networking
• L7 visibility and load balancing (HTTP, gRPC, Kafka)
• Built-in observability with Hubble (real-time network traffic)
• Native Gateway API implementation
• Sidecarless Service Mesh (no need for Envoy sidecar)
• Network policies: L3/L4/L7

# Cài Cilium với Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true \
  --set hubble.ui.enabled=true
Verify
cilium status
cilium connectivity test

3.2 Calico

Calico is CNI mature with eBPF dataplane support (optional), BGP routing for bare metal. Suitable when broad compatibility or BGP peering with physical routers is needed.

3.3 Flannel

Flannel is simple and easy to install, but lacks Network Policy support and observability. Not recommended for production.

4. eBPF — Why is it faster than iptables?

iptables uses linear rule matching — O(n) with n rules. When the cluster has thousands of services, the iptables chain is very long, affecting performance.

eBPF uses hash maps — O(1) lookup regardless of number of services. eBPF programs run directly in the kernel, without a context switch to user space.

              iptables (legacy):
User Space ←→ Kernel iptables chains (linear rules)
                   ↓ O(n) per packet
          eBPF (Cilium):

User Space    Kernel eBPF programs + hash maps
↓ O(1) per packet

5. kube-proxy Modes 2026

kube-proxy implements Service load balancing on each Node.

5.1 iptables mode (legacy)

Create iptables DNAT rules for each Service endpoint. Still works but less scalable.

5.2 nftables mode — Recommended 2026

IPVS mode deprecated K8s 1.35. nftables is the new backend, more efficient than iptables.

# Cấu hình trong kubeadm-config.yaml
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: nftables

# Kiểm tra kube-proxy mode hiện tại
kubectl get cm kube-proxy -n kube-system -o yaml | grep mode
Verify nftables rules
sudo nft list ruleset | grep k8s

6. DNS with CoreDNS

CoreDNS is the default DNS server of Kubernetes, running as Deployment in kube-system.

# CoreDNS pods
kubectl get pods -n kube-system -l k8s-app=kube-dns
Xem CoreDNS config
kubectl get configmap coredns -n kube-system -o yaml
Test DNS resolution từ trong pod
kubectl run -it --rm debug --image=busybox:1.36 -- nslookup kubernetes.default
kubectl run -it --rm debug --image=busybox:1.36 -- nslookup backend-service.production.svc.cluster.local

7. Network Diagram

                    ┌─────────────────────────────────────┐
                    │           Kubernetes Cluster          │
                    │                                       │
  External Traffic  │   ┌──────────┐      ┌──────────┐    │
       │            │   │  Node 1  │      │  Node 2  │    │
       ▼            │   │          │      │          │    │
  ┌─────────┐      │   │ Pod A    │      │ Pod B    │    │
  │ Gateway │─────▶│   │ 10.0.1.2 │─────▶│ 10.0.2.3 │    │
  │  API    │      │   │          │      │          │    │
  └─────────┘      │   │ CNI:     │      │ CNI:     │    │
                    │   │ Cilium   │      │ Cilium   │    │
                    │   │ (eBPF)   │      │ (eBPF)   │    │
                    │   └──────────┘      └──────────┘    │
                    └─────────────────────────────────────┘
                              Pod CIDR: 10.0.0.0/16

Summary

• Kubernetes flat network: each Pod has its own IP, no NAT
• 4 patterns: container-to-container (localhost), pod-to-pod (direct IP), pod-to-service (ClusterIP + kube-proxy), external-to-service (NodePort/Gateway API)
• Cilium eBPF: CNI recommended 2026 — fast, L7 observability, native API Gateway
• kube-proxy nftables: replace IPVS (deprecated K8s 1.35)
• CoreDNS: service discovery via DNS names