Module 3 — Kubernetes Networking: tổng quan

TL;DR: Kubernetes không invent mạng mới — nó compose plumbing Module 1–2 ở quy mô cluster: mỗi pod ≈ network namespace (thường multi-container chung netns), CNI plugin script veth/bridge/route thay Docker daemon, Service + kube-proxy = DNAT (và biến thể iptables/IPVS) tới pod IP, Ingress mở cửa L7, NetworkPolicy là filter theo identity. Module 3 là capstone track Networking Containers: mỗi khái niệm K8s map thẳng về stack, veth, bridge, NAT bạn đã tự tay dựng. Học xong bạn đọc được "Service không vào pod" / "NetworkPolicy im lặng" bằng cùng bản đồ debug Linux, không chỉ kubectl describe.

Vì sao module này tồn tại

Bạn đã ghép Docker-style bridge from scratch: netns, veth, bridge, SNAT, DNAT. Production cloud-native nhảy một nấc: hàng trăm pod, IP phẳng giữa node, VIP ClusterIP không có process listen, policy "default deny" mà traffic vẫn lọt vì CNI không enforce.

Tài liệu K8s hay bắt đầu từ YAML Service/Ingress. Phần hỏng thật nằm dưới API object: kubelet gọi CNI binary → plugin tạo veth + IP; kube-proxy chèn rule DNAT/IPVS; controller Ingress terminate TLS và route L7. Không nối được YAML với plumbing → debug chỉ còn restart pod và đổi annotation.

Module này không dạy vận hành cluster production (HA etcd, multi-CNI, service mesh). Nó dạy bản đồ nhập môn: pod network model → CNI là interface → traffic qua Service/kube-proxy → cửa L4/L7 (NodePort/LB/Ingress) → NetworkPolicy khi nào có hiệu lực. Mọi thứ map lại Module 1–2.

Đây là lộ trình capstone — đúng thứ tự concept stack và đúng thứ tự gói tin "chạm" khi client nói chuyện với app trong cluster:

flowchart LR
    P["1. Pod network<br/>flat IP + shared netns"] --> C["2. CNI<br/>plugin interface"]
    C --> S["3. Service<br/>kube-proxy DNAT/IPVS"]
    S --> I["4. Ingress<br/>L4 vs L7 entry"]
    I --> N["5. NetworkPolicy<br/>identity filter"]

Sau module này bạn sẽ

• Explain mô hình pod networking (flat IP, shared netns, pause container) và liên hệ veth/bridge.
• Explain CNI là interface (không implementation) và trade-off overlay vs routed.
• Trace traffic tới pod qua Service và kube-proxy (iptables/IPVS).
• Compare ClusterIP, NodePort, LoadBalancer và Ingress theo chiều traffic L4/L7.
• Design NetworkPolicy ingress/egress cơ bản và nhận biết khi policy không có hiệu lực.

Lộ trình module

Năm bài concept xếp theo phụ thuộc kỹ thuật — mỗi bài dựng một lớp mà bài sau giả định bạn đã nắm:

1. Pod networking — mỗi pod một IP, mô hình phẳng — contract cluster: mọi pod IP thấy nhau (trong model), không NAT pod-to-pod; container trong pod chung network namespace; pause/infra container giữ netns. Liên hệ thẳng veth + bridge (hoặc route) đã học.

2. CNI là gì — interface gắn mạng cho pod — kubelet không "tự biết" Calico hay Flannel: nó gọi binary CNI theo spec. Interface ≠ implementation. Trade-off overlay (VXLAN/encapsulation, dễ multi-subnet) vs routed (BGP/route thuần, latency/ops khác).

3. Service & kube-proxy — traffic tới pod thế nào — ClusterIP là VIP: không process listen. kube-proxy (iptables hoặc IPVS) DNAT/load-balance tới endpoint pod. Trace: client → Service IP → rule → pod IP:port — map DNAT Module 2 ở quy mô nhiều backend.

4. Ingress & load balancing — L4 vs L7 vào cluster — ClusterIP chỉ trong cluster; NodePort/LoadBalancer mở L4 ra ngoài; Ingress (và gateway tương đương) terminate/route L7 (host/path). Chọn theo chiều traffic, không theo "YAML nào hot".

5. NetworkPolicy — zero-trust giữa các pod — default allow nếu không có policy; khi có, design ingress/egress theo label. Pitfall cứng: NetworkPolicy không có hiệu lực nếu CNI/plugin không implement (hoặc enforce tắt) — YAML xanh, traffic vẫn full-mesh.

Bài tổng kết cuối module (và track) gom cheat sheet pod→Service→Ingress, map K8s → plumbing Linux/Docker, glossary, self-assessment khớp năm outcome trên, và gợi ý học tiếp (mesh, eBPF — ngoài scope v1).

Yêu cầu trước khi bắt đầu

Kiến thức trong course (bắt buộc):

• Module 1 — Linux Network Internals — stack, veth/tun/tap, bridge, iptables/netfilter. Bạn cần đọc được tầng nào đang hỏng trước khi nói "CNI hỏng".
• Module 2 — Container Networking — netns, veth, bridge from scratch, SNAT/DNAT, debug nsenter/tcpdump. Module 3 giả định bạn đã tự tay ghép Docker-style network; nếu chưa, quay lại M2 — bài Service/kube-proxy sẽ chỉ là từ vựng.

Môi trường thực hành:

• Đọc + sơ đồ đủ cho phần lớn concept (model, trade-off, trace logic). Không bắt buộc cluster để hiểu bản đồ.
• Cluster demo (tuỳ chọn nhưng khuyến khích): kind hoặc minikube trên Linux/macOS — kubectl get pods -o wide, kubectl exec + ip addr, quan sát Service endpoints. kind chạy node-as-container: view kernel host khác production bare-metal, nhưng đủ minh hoạ pod IP / Service / (tuỳ CNI) NetworkPolicy.
• kubectl cơ bản: get/describe/apply, đọc Events. Không cần admin production cluster.

Nếu M1–M2 còn mỏng (chưa ping hai netns qua veth, chưa đọc rule DNAT), đừng nhảy YAML Service — capstone chỉ chắc khi plumbing đã thấm.

Time budget

Cách học module này hiệu quả

• Luôn map về M1–M2. Gặp "pod không thấy pod" → netns/veth/route/CNI; "Service timeout" → DNAT/endpoints/kube-proxy mode; "policy không chặn" → CNI có enforce không? Bản đồ Linux trước, YAML sau.
• Đọc model trước plugin. Flat pod network và shared netns là contract; Calico/Cilium/Flannel chỉ là cách thực hiện contract. Học interface CNI trước tên thương hiệu.
• Trace một request end-to-end trên giấy. Client → Ingress/LB → Service → pod:port → app. Ghi mỗi chặng L3/L4/L7 và ai rewrite địa chỉ — rồi đối chiếu bài 03–04.
• Cluster kind là lab, không phải nguồn sự thật duy nhất. kind + CNI mặc định có thể không enforce NetworkPolicy; đó là bài học pitfall, không phải bug bài viết.
• Giữ kubectl + terminal song song khi có cluster. get endpoints, describe svc, exec vào pod xem ip route — output sống gắn abstract với plumbing.

Bài tiếp theo: Pod networking — mỗi pod một IP, mô hình phẳng