Kubernetes bài 2 - Mạng lưới k8s và luồng Traffic ở Packet Level

Pod không chỉ là một container: Rất nhiều người nhầm lẫn Pod 1-1 với Container. Thực chất, Pod là đơn vị triển khai nhỏ nhất, có thể chứa một hoặc nhiều container

Trong bài trước, chúng ta đã hình dung Kubernetes như một nhạc trưởng điều phối các container. Nhưng để dàn nhạc chơi được, các nhạc công phải nghe thấy nhau. Hệ thống mạng (Networking) trong Kubernetes là một kiệt tác về kỹ thuật, nhưng cũng là một bãi mìn về hiệu năng và bảo mật nếu bạn không hiểu rõ bản chất hoạt động của nó ở tầng Kernel.

Bài viết này sẽ bóc tách các khái niệm cốt lõi nhất và theo dấu một gói tin (packet) để xem nó thực sự đi qua những đâu.

Những mảnh ghép cơ bản nền tảng Pod và Service

Để hiểu mạng Kubernetes, trước tiên phải hiểu hai đối tượng nền tảng là Pod và Service.

Pod không chỉ là một container: Rất nhiều người nhầm lẫn Pod 1-1 với Container. Thực chất, Pod là đơn vị triển khai nhỏ nhất, có thể chứa một hoặc nhiều container. Điểm mấu chốt là các container trong cùng một Pod sẽ chia sẻ chung một Network Namespace. Nghĩa là chúng dùng chung một địa chỉ IP, chung không gian port và có thể giao tiếp với nhau qua localhost.

Tuy nhiên, Pod có vòng đời rất ngắn (ephemeral). Chúng có thể bị sập, bị xóa và tạo lại trên một Node khác với một IP hoàn toàn mới. Nếu ứng dụng A muốn gọi ứng dụng B, nó không thể dựa vào IP của Pod B vì IP này liên tục thay đổi.

Đó là lúc Service xuất hiện: Service đóng vai trò như một danh bạ tĩnh. Nó cung cấp một địa chỉ IP cố định (ClusterIP) và một tên miền nội bộ (DNS name). Khi Pod A gọi đến Service B, Service B sẽ làm nhiệm vụ cân bằng tải (Load Balancing) và đẩy traffic đến đúng các Pod B đang còn sống (dựa trên cơ chế gắn nhãn - Labels). Dù các Pod phía sau có sinh ra hay chết đi, IP của Service vẫn bất biến.

Giao thông mạng dịch chuyển qua Kube-proxy như thế nào

Nói Service làm nhiệm vụ Load Balancing, nhưng thực tế Service không phải là một con Nginx hay HAProxy chạy vật lý. Nó là một khái niệm ảo được thực thi bởi kube-proxy – một thành phần chạy trên mọi Worker Node.

Cách kube-proxy định tuyến gói tin (packet routing) quyết định trực tiếp đến độ trễ của toàn bộ hệ thống:

Chế độ iptables (Mặc định): Kube-proxy sẽ tạo ra các quy tắc iptables trong Linux Kernel để chặn các gói tin đi đến IP của Service và bẻ lái (NAT) chúng sang IP của Pod đích. Vấn đề là iptables xử lý các rule theo chuỗi tuần tự (O(n)). Nếu bạn có 5.000 Services, hệ thống phải duyệt qua hàng chục ngàn rule cho mỗi gói tin. Điều này tạo ra độ trễ cực lớn và nghẽn cổ chai CPU.
Chế độ IPVS: Dành cho các hệ thống scale lớn. IPVS (IP Virtual Server) cũng nằm trong Kernel nhưng sử dụng cấu trúc dữ liệu Hash Table (O(1)). Dù bạn có 10.000 Services, thời gian tra cứu và định tuyến vẫn gần như ngay lập tức.
Kỷ nguyên eBPF (Cilium): Những hệ thống hiện đại nhất hiện nay thậm chí đã loại bỏ hoàn toàn kube-proxy và iptables để chuyển sang eBPF. Kỹ thuật này cho phép chạy các chương trình định tuyến trực tiếp bên trong nhân Linux mà không cần đi qua toàn bộ network stack, giúp giảm độ trễ (latency) xuống mức thấp nhất và tăng throughput lên tối đa.

Rủi ro mạng phẳng và giải pháp kiểm soát bằng Network Policies

Dưới góc nhìn bảo mật, mạng Kubernetes mặc định là một cơn ác mộng. Hệ thống này được thiết kế theo nguyên tắc mạng phẳng (Flat Network) tức là mọi Pod đều có thể giao tiếp trực tiếp với mọi Pod khác trên mọi Node mà không bị cản trở (Default Allow).

Hãy tưởng tượng bạn có Pod Frontend (chạy Web) và Pod Backend (chạy Database). Nếu một hacker khai thác được lỗ hổng RCE trên Web và chiếm quyền Pod Frontend, hắn có thể ping, scan port và truy cập thẳng vào Pod Database mà không gặp bất kỳ rào cản nào. Kỹ thuật này gọi là Lateral Movement (Di chuyển ngang).

Để chặn đứng rủi ro này, chúng ta bắt buộc phải sử dụng Network Policies. Đây là cơ chế Tường lửa nội bộ (Micro-segmentation) của Kubernetes, được thực thi bởi các CNI (Container Network Interface) như Calico hay Cilium.

Best Practice: Áp dụng nguyên tắc Zero Trust bằng cách thiết lập cấu hình Default Deny All. Cấm toàn bộ traffic vào/ra trong một Namespace. Sau đó, bạn mới mở lại (Whitelist) một cách cụ thể, ví dụ chỉ cho phép Pod Frontend được phép gọi đến port 5432 của Pod Database. Mọi kết nối đi chệch khỏi quy tắc này sẽ bị drop ở ngay tầng Kernel.

Hành trình chi tiết của một gói tin từ Internet đến đúng Pod

Để tổng hợp lại, hãy theo dấu một gói tin từ trình duyệt của người dùng cho đến khi nó chạm vào ứng dụng của bạn trong Kubernetes:

Từ Internet đến Load Balancer: Người dùng gõ tên miền của ứng dụng. Request đập vào Cloud Load Balancer (AWS ALB, Google Cloud Load Balancer) nằm ngoài hệ thống Kubernetes.
Vào Ingress Controller: Load Balancer đẩy traffic vào Ingress Controller (thường là Nginx hoặc Traefik) chạy bên trong Cluster. Ingress đọc HTTP Header (Host, Path) để biết gói tin này muốn đi đến dịch vụ nào.
Qua Service để tra cứu mạng: Ingress Controller tra cứu và đẩy gói tin đến Service tương ứng. Tại đây, iptables hoặc IPVS trên Node sẽ bẻ lái gói tin (Destination NAT), thay IP đích từ IP của Service thành IP của một Pod thực tế đang rảnh rỗi.
Xuyên qua CNI đến Container: Gói tin đi qua mạng Overlay (như VXLAN/IPIP do Calico/Flannel quản lý) để đến đúng Worker Node chứa Pod. Cuối cùng, nó chui qua cặp giao diện mạng ảo (veth pair) để vào đúng Network Namespace của Pod và được ứng dụng xử lý.

Toàn bộ quy trình phức tạp này diễn ra trong vài mili-giây. Hiểu được luồng đi này, khi hệ thống báo lỗi Timeout hoặc không thể kết nối, bạn sẽ biết chính xác mình cần kiểm tra ở Ingress, ở Service hay ở chính bản thân Pod.