🎯 Mục tiêu bài học

Hiểu mô hình mạng Kubernetes từ cơ bản đến nâng cao: tại sao mỗi Pod có IP riêng, 4 loại communication patterns, CNI plugins (Cilium khuyến nghị 2026), và kube-proxy với nftables.

1. Kubernetes Networking Requirements

Kubernetes có 3 yêu cầu cốt lõi về networking:

• Mọi Pod phải giao tiếp được với mọi Pod khác trong cluster không cần NAT
• Mọi Node phải giao tiếp được với mọi Pod không cần NAT
• IP mà Pod tự nhìn thấy phải giống IP mà Pods khác nhìn thấy

Đây là "flat network model" — không giống Docker mặc định (NAT-based).

2. Bốn Communication Patterns

2.1 Container-to-Container (trong cùng Pod)

Containers trong cùng Pod chia sẻ network namespace → giao tiếp qua localhost.

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

2.2 Pod-to-Pod

Mỗi Pod có một IP riêng biệt trong cluster. Pods giao tiếp trực tiếp qua IP — CNI plugin đảm bảo 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 giao tiếp với Service qua ClusterIP (virtual IP). kube-proxy tạo iptables/nftables rules để DNAT (destination NAT) sang Pod IP thực.

# 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 từ bên ngoài cluster vào Service qua NodePort, LoadBalancer, hoặc Gateway API (HTTPRoute).

3. CNI (Container Network Interface)

CNI là interface chuẩn giữa Kubernetes và network plugins. Khi Pod được tạo, kubelet gọi CNI plugin để:

• Tạo network interface cho Pod
• Gán IP address
• Cấu hình routing

3.1 Cilium — Khuyến nghị 2026

Cilium dùng eBPF (extended Berkeley Packet Filter) tại kernel level — không cần iptables chains.

Ưu điểm Cilium:

• eBPF: fast, programmable, kernel-level networking
• L7 visibility và load balancing (HTTP, gRPC, Kafka)
• Built-in observability với Hubble (real-time network traffic)
• Native Gateway API implementation
• Sidecarless Service Mesh (không cần 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 là CNI mature với hỗ trợ eBPF dataplane (tùy chọn), BGP routing cho bare metal. Phù hợp khi cần tương thích rộng hoặc BGP peering với routers vật lý.

3.3 Flannel

Flannel đơn giản, dễ cài nhưng thiếu Network Policy support và observability. Không khuyến nghị cho production.

4. eBPF — Tại sao nhanh hơn iptables?

iptables dùng linear rule matching — O(n) với n rules. Khi cluster có hàng nghìn services, iptables chain rất dài, ảnh hưởng performance.

eBPF dùng hash maps — O(1) lookup bất kể số lượng services. eBPF programs chạy trực tiếp trong kernel, không có context switch sang 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 implement Service load balancing trên mỗi Node.

5.1 iptables mode (legacy)

Tạo iptables DNAT rules cho mỗi Service endpoint. Vẫn hoạt động nhưng kém scalable.

5.2 nftables mode — Khuyến nghị 2026

IPVS mode deprecated K8s 1.35. nftables là backend mới, hiệu quả hơn 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 với CoreDNS

CoreDNS là DNS server mặc định của Kubernetes, chạy như Deployment trong 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

Tóm tắt

• Kubernetes flat network: mỗi Pod có IP riêng, không 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 khuyến nghị 2026 — nhanh, L7 observability, Gateway API native
• kube-proxy nftables: thay IPVS (deprecated K8s 1.35)
• CoreDNS: service discovery qua DNS names