Pod datapath: CNI, DNS và kube-proxy
Từ tên service đến gói IP đi qua node.
Nắm bản chất
Một Kubernetes Service là API abstraction; CoreDNS phân giải hostname và dataplane chọn backend endpoint. CNI nối Pod network namespaces với các nodes; kube-proxy có thể lập trình iptables/nftables, hoặc Cilium eBPF thay thế service load balancing theo cấu hình.
Debug bắt đầu ở tầng đúng: DNS resolution, Service selector, ready
EndpointSlices, TCP listener, network policies rồi mới đi sâu routes/tunnels.
localhost chỉ tới network namespace hiện tại, không tới Service
khác.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
kubectl -n apps get svc api
kubectl -n apps get endpointslices
kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n apps exec deploy/api -- cat /etc/resolv.conf
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Vẽ request web.apps → api.apps → payments.data trong lab Buổi
15, liệt kê DNS hostname, ClusterIP, Pod IP và CNI hop.
Lỗi dễ mắc
Một Service tồn tại không đồng nghĩa đã có backend; EndpointSlices trống hoặc không ready sẽ làm request thất bại.
Tự kiểm tra
Pod nằm node khác có nhất thiết phải đi qua một userspace kube-proxy process không?Xem đáp án ↗
Không. Forwarding thực hiện bởi kernel/dataplane theo rules/maps được controllers lập trình.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 15Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗