Skip to main content

4. Basic of Networking

Mục lục​

Networking​

1. Pod nhận IP address thế nào trong cluster 1 node?​

Bắt đầu với 1 cluster Kubernetes single-node. Node có 1 địa chỉ IP, ví dụ 192.168.1.2 — đây là IP dùng để truy cập vào node Kubernetes, SSH vào, v.v. Nếu dùng Minikube, IP này thực chất là IP của máy ảo Minikube bên trong hypervisor, không phải IP của laptop — laptop có thể có IP khác, ví dụ 192.168.1.10. Vì vậy, hiểu rõ VM của mình được setup thế nào là điều quan trọng.

Trên cluster single-node này, đã tạo sẵn 1 Pod — 1 Pod host 1 container. Khác với thế giới Docker, nơi IP address luôn được gán cho Docker container, trong thế giới Kubernetes, IP address được gán cho Pod. Mỗi Pod trong Kubernetes có 1 IP address nội bộ riêng.

💡 Hình dung như thế này: Node IP giống địa chỉ tòa nhà — dùng để tìm và đi vào đúng tòa nhà (SSH vào node). Pod IP giống số phòng bên trong tòa nhà đó — chỉ có ý nghĩa khi đã ở đúng tòa nhà, và một tòa nhà khác hoàn toàn có thể đánh số phòng y hệt (ví dụ phòng 202) mà không sao, vì chúng nằm ở 2 tòa nhà riêng biệt. Nhưng nếu ghép 2 tòa nhà này vào chung 1 khu (cluster) mà không đánh số lại, sẽ có 2 phòng cùng mang số 202 trong cùng 1 khu — đó chính xác là vấn đề xảy ra khi nhiều node dùng chung 1 dải mạng nội bộ, sẽ nói ở mục tiếp theo.

Trong ví dụ này, IP nằm trong dải 10.244, và IP gán cho Pod là 10.244.0.2. Vậy Pod lấy IP này từ đâu? Khi Kubernetes được cấu hình lần đầu, 1 mạng nội bộ riêng (private network) với địa chỉ 10.244.0.0 được tạo ra, và tất cả Pod đều gắn vào mạng này.

Pod IP vs Node IP — Single NodeNode — 192.168.1.2(Minikube: đây là IP của VM Minikube, không phải laptop)Internal private network — 10.244.0.0Pod — 10.244.0.2container bên trong(Docker: IP gán cho container — K8s: IP gán cho Pod)Node IP dùng để truy cập/SSH vào node — Pod IP dùng để giao tiếp giữa các Pod, khác hẳn tầng địa chỉ.

Ngoài đời, có thể thấy đúng 2 tầng IP này bằng kubectl:

kubectl get nodes -o wide
# Output minh họa
NAME     STATUS   ROLES           AGE   VERSION   INTERNAL-IP
master   Ready    control-plane   10d   v1.30.0   192.168.1.2
kubectl get pods -o wide
# Output minh họa
NAME        READY   STATUS    RESTARTS   AGE   IP           NODE
myapp-pod   1/1     Running   0          5m    10.244.0.2   master

Cột INTERNAL-IP của kubectl get nodes chính là IP của node (192.168.1.2), còn cột IP của kubectl get pods chính là IP nội bộ của Pod (10.244.0.2) — 2 cột này nằm ở 2 lệnh khác nhau vì chúng thuộc 2 tầng địa chỉ hoàn toàn khác nhau.

Khi deploy nhiều Pod, mỗi Pod đều được gán 1 IP riêng từ mạng này — các Pod có thể giao tiếp với nhau qua IP đó. Nhưng dùng trực tiếp IP nội bộ này để truy cập Pod khác không phải ý hay, vì IP này có thể thay đổi khi Pod bị tạo lại (recreate). Có cách tốt hơn để thiết lập giao tiếp giữa các Pod (sẽ nói ở phần sau) — nhưng trước tiên cần hiểu cơ chế networking nội bộ này hoạt động thế nào.

Mọi thứ khá đơn giản khi chỉ có 1 node. Nhưng khi cluster có nhiều node thì sao?

2. Vì sao cluster nhiều node cần giải pháp networking riêng?​

Giả sử có 2 node chạy Kubernetes, gán IP 192.168.1.2 và 192.168.1.3. Lưu ý: 2 node này chưa phải là 1 phần của cùng 1 cluster network. Mỗi node có 1 Pod được deploy (như phần trên), mỗi Pod gắn vào 1 mạng nội bộ riêng và có IP riêng.

Tuy nhiên, nếu nhìn vào địa chỉ mạng nội bộ của cả 2 node, sẽ thấy chúng giống hệt nhau: cả 2 mạng đều có địa chỉ 10.244.0.0, và các Pod deploy trên đó cũng có cùng địa chỉ IP luôn — cách này sẽ không hoạt động tốt khi các node là 1 phần của cùng 1 cluster, vì Pod trùng IP address sẽ dẫn tới xung đột IP (IP conflict) trên mạng.

IP Conflict Across Two NodesNode 1 — 192.168.1.2network 10.244.0.0Pod — 10.244.0.2Node 2 — 192.168.1.3network 10.244.0.0Pod — 10.244.0.2=⚠ IP CONFLICT2 node chưa thuộc cùng 1 cluster network — mỗi node tự tạo network 10.244.0.0 riêng, Pod trùng địa chỉ.

Đó là 1 vấn đề. Khi 1 Kubernetes cluster được setup, Kubernetes không tự động thiết lập bất kỳ loại networking nào để xử lý các vấn đề này. Thực tế, Kubernetes kỳ vọng người dùng tự thiết lập networking đáp ứng 1 số yêu cầu nền tảng nhất định:

  • Mọi container/Pod trong 1 Kubernetes cluster phải giao tiếp được với nhau mà không cần cấu hình NAT.
  • Mọi node phải giao tiếp được với mọi container.
  • Mọi container phải giao tiếp được với các node trong cluster.

Kubernetes kỳ vọng người dùng tự thiết lập 1 giải pháp networking đáp ứng đúng các tiêu chí này. May mắn là không cần tự làm từ đầu, vì đã có sẵn nhiều giải pháp dựng sẵn, ví dụ: Cisco ACI, Cilium, Big Cloud Fabric, Flannel, VMware NSX-T, và Calico. Tùy nền tảng dùng để deploy Kubernetes cluster mà chọn 1 trong các giải pháp này.

Ví dụ: nếu tự dựng Kubernetes cluster từ đầu trên hệ thống riêng, có thể dùng Calico hoặc Flannel. Nếu deploy trên môi trường VMware, NSX-T có thể là lựa chọn tốt. Nếu dùng Play with Kubernetes labs, họ dùng Weave Net làm giải pháp networking.

Quay lại cluster với networking tùy chỉnh (Flannel hoặc Calico): giải pháp này giờ quản lý network và IP trên các node, gán 1 network address khác nhau cho từng node trong mạng. Việc này tạo ra 1 mạng ảo (virtual network) chứa toàn bộ Pod và node, nơi tất cả được gán 1 IP address duy nhất (unique). Bằng cách dùng các kỹ thuật routing đơn giản, cluster networking cho phép giao tiếp giữa các Pod/node khác nhau, đáp ứng đúng yêu cầu networking của Kubernetes. Nhờ vậy, mọi Pod giờ có thể giao tiếp với nhau bằng IP address đã được gán.

Custom Networking Solution (e.g. Flannel, Calico) Resolves the ConflictNode 1 — 192.168.1.2network 10.244.1.0Pod — 10.244.1.2Node 2 — 192.168.1.3network 10.244.2.0Pod — 10.244.2.2Virtual network — mọi Pod/Node có IP duy nhất, giao tiếp qua routingVí dụ minh họa — địa chỉ mạng cụ thể (10.244.1.0, 10.244.2.0) chỉ mang tính minh họa cho ý tưởng "mỗi node 1 dải khác nhau".

Nguồn tham khảo​

Nguồn gốc: Khóa "Kubernetes for the Absolute Beginners - Hands-on Tutorial" — module "Networking Basics", bài "Networking Basics", nền tảng KodeKloud.

Đính chính/cập nhật (fact-check):

  • Từ bản NSX-T 4.0 (2022), VMware đã đổi tên sản phẩm từ "VMware NSX-T Data Center" thành "VMware NSX" (gộp chung với dòng NSX-V cũ) — 2026, ESX Virtualization: VMware NSX-T 4 Released and product name changed to VMware NSX
  • Cilium, Calico, Flannel vẫn là 3 giải pháp CNI phổ biến nhất hiện nay cho Kubernetes; Cilium (dùng eBPF) đang là lựa chọn phổ biến nhất cho cluster mới nhờ độ trễ thấp hơn — 2026, tổng hợp từ các bài so sánh CNI hiện hành
  • Weaveworks (công ty đứng sau Weave Net) đã ngừng hoạt động từ tháng 2/2024, repo GitHub chính thức bị archive tháng 6/2024; một fork cộng đồng (avhost) vẫn tiếp tục maintain — 2024, SiliconANGLE, The New Stack
  • Big Switch Networks (chủ sở hữu Big Cloud Fabric) bị Arista Networks mua lại năm 2020; sản phẩm được đổi tên thành "Converged Cloud Fabric (CCF)" trong danh mục Arista — 2020, Arista press release