My Awesome Project

Appearance

Chương 7: GKE Networking Internals — VPC-Native, CNI, Dataplane V2 Deep Dive ​

Vì sao chương này là phần khó nhất của GKE ​

Khi một dịch vụ chạy trên GKE bị chậm, mất gói, hoặc “connection refused” không rõ lý do, gần như chắc chắn câu trả lời nằm ở lớp mạng. Mạng GKE là nơi giao thoa của ba thế giới: networking Linux trên node (network namespaces, veth, bridge, iptables/eBPF), mô hình Service/NetworkPolicy của Kubernetes, và hạ tầng VPC toàn cục của Google Cloud (Andromeda SDN, alias IP, Cloud NAT, Cloud Load Balancing). Một kỹ sư không dựng được mental model xuyên suốt ba lớp này sẽ luôn debug mạng theo kiểu đoán mò.

Điểm mấu chốt khiến GKE networking khó: phần lớn cơ chế là “ẩn”. Một gói tin đi từ Pod A sang Pod B có thể đi qua veth pair, bridge ảo, chương trình eBPF trong kernel, alias IP trên NIC của node, fabric Jupiter của Google, rồi ngược lại — tất cả trong vài chục micro giây và không để lại dấu vết nếu bạn không biết chỗ để nhìn. Mục tiêu của chương này là biến những phần ẩn đó thành thứ bạn có thể quan sát, suy luận và kiểm chứng.

GKE mặc định dùng cluster VPC-native, trong đó Pod IP là alias IP định tuyến tự nhiên trong VPC (VPC-native clusters). Trên các cluster mới, GKE Dataplane V2 dựa trên eBPF/Cilium trở thành dataplane khuyến nghị, thay thế mô hình kube-proxy + iptables cổ điển (GKE Dataplane V2). Hai quyết định kiến trúc này định hình toàn bộ cách packet di chuyển, cách Service được cân bằng tải, và cách NetworkPolicy được thực thi.

Điều kiện tiên quyết ​

  • Đã đọc Chương 3 (VPC Model): subnet, secondary ranges, routes, firewall, alias IP.
  • Nắm vững Linux networking: network namespaces, veth pairs, bridge, iptables/netfilter, conntrack, routing table, ARP.
  • Hiểu mô hình Service/Endpoints/EndpointSlice và NetworkPolicy của Kubernetes.
  • Có kinh nghiệm vận hành workload thật trên GKE (Chương 5, 6).

Mức độ sâu ​

5/5 — Chương đi tới mức packet path từng chặng, cấu trúc dữ liệu trong kernel (iptables chains, conntrack, eBPF maps), và các giới hạn quy mô có số liệu cụ thể, đối chiếu trực tiếp tài liệu chính thức của GKE, Kubernetes và Cilium.

Cấu trúc chapter ​

1. VPC-Native Architecture — Alias IP, Pod CIDR Sizing & Migration ​

Nền tảng định tuyến của mọi cluster GKE:

  • VPC-native vs routes-based: khác biệt cơ chế, vì sao VPC-native là default
  • Alias IP ranges: Pod IP là alias IP trên NIC node, ý nghĩa với routing và firewall
  • Routes-based deprecation: giới hạn route quota, lộ trình migration
  • Pod CIDR sizing: /24 mỗi node, quan hệ với max-pods-per-node
  • Secondary range sizing: planning, mở rộng, discontiguous Pod CIDR
  • Cross-node pod-to-pod ở góc nhìn VPC: node → VPC → node đích → pod

2. CNI Evolution & Dataplane V2 — kubenet, Calico, eBPF/Cilium ​

Hành trình dataplane từ iptables tới eBPF:

  • kubenet (legacy): cơ chế, giới hạn, vì sao bị deprecate
  • Calico CNI: NetworkPolicy qua iptables, trần hiệu năng
  • GKE Dataplane V2: anetd DaemonSet, Cilium-based, eBPF programs trong kernel
  • eBPF vs iptables: giới hạn 260K endpoint map, latency, overhead
  • Cilium identity model: dựa trên label thay vì IP
  • Vì sao Dataplane V2 không cần kube-proxy

3. Detailed Packet Path Analysis — 5 Đường Đi Của Gói Tin ​

Mổ xẻ từng chặng packet di chuyển:

  • Same-node pod-to-pod: veth → bridge/eBPF → veth → netns pod đích
  • Cross-node pod-to-pod: veth → eth0 → VPC (alias IP) → node đích → pod
  • Pod-to-Service: ClusterIP DNAT → chọn backend (iptables hoặc eBPF)
  • Pod-to-external: alias IP → masquerade (ip-masq-agent) → Cloud NAT nếu private
  • External-to-pod: LB → node/NEG → eBPF/kube-proxy → pod, container-native LB

4. kube-proxy & Service Dataplane — iptables vs eBPF ​

Cơ chế cân bằng tải Service ở tầng node:

  • iptables mode: PREROUTING/KUBE-SERVICES chains, DNAT, session affinity
  • Chain explosion: độ phức tạp O(Services × Endpoints), điểm gãy hiệu năng
  • iptables lock contention: serialize cập nhật rule trong kernel
  • Rule resyncing: full sync vs incremental, ảnh hưởng latency điều khiển
  • Dataplane V2 (eBPF): kiến trúc thay thế, hash map O(1)

5. NetworkPolicy Enforcement — Calico iptables vs Dataplane V2 eBPF ​

Thực thi chính sách mạng ở quy mô lớn:

  • Mô hình NetworkPolicy của Kubernetes: default-allow tới default-deny
  • Calico: dịch policy thành iptables/ipset, trần scale
  • Dataplane V2: policy theo Cilium identity, eBPF, FQDN-based egress
  • NetworkPolicy logging tích hợp: quan sát allow/deny
  • Anti-pattern phổ biến và cách thiết kế policy chịu được thay đổi

6. Troubleshooting Toolkit — tcpdump, nsenter, Hubble, Connectivity Tests ​

Bộ công cụ debug mạng thực chiến:

  • tcpdump bên trong network namespace của pod
  • nsenter để debug ở cấp node và netns
  • Hubble: observability của Dataplane V2
  • GCP Connectivity Tests: kiểm tra đường đi ở tầng VPC
  • ip route, arp, iptables, conntrack table và giới hạn
  • eBPF tracing, script bpftrace cho ca khó

Cách đọc chapter theo mục tiêu công việc ​

Nếu bạn đang debug một sự cố mạng cụ thể ​

  1. Bắt đầu từ file 3 (packet path) để khoanh vùng chặng gãy.
  2. Sang file 6 (troubleshooting toolkit) để chọn đúng công cụ cho chặng đó.
  3. Nếu liên quan Service/cân bằng tải, đọc file 4; nếu liên quan bị chặn kết nối, đọc file 5.

Nếu bạn đang thiết kế cluster networking mới ​

  1. File 1 (VPC-native, CIDR sizing) để khóa IP plan từ đầu.
  2. File 2 (Dataplane V2) để chọn dataplane đúng ngay khi tạo cluster.
  3. File 5 (NetworkPolicy) để thiết kế isolation model trước khi onboard workload.

Nếu bạn đang tối ưu hiệu năng/chi phí mạng ở scale lớn ​

  1. File 4 (iptables vs eBPF) để hiểu điểm gãy hiệu năng dataplane.
  2. File 2 để đánh giá giới hạn quy mô của Dataplane V2.
  3. File 3 để tối ưu egress path (masquerade, Cloud NAT, container-native LB).

Khung quyết định production (tóm tắt) ​

Quyết địnhTác động chínhRủi ro nếu làm saiFile nên đọc
Chọn dataplane (DPv2 hay không)Hiệu năng Service, NetworkPolicy, observabilityKhông bật được Hubble/eBPF sau này nếu tạo sai2
Kích thước secondary range cho PodSố node/pod tối đaCạn Pod IP giữa lúc scale/upgrade1
Dùng container-native LB (NEG)Latency, độ ổn định traffic vàoDouble-hop, mất gói khi node đổi3
Mô hình NetworkPolicyBlast radius khi bị xâm nhậpLateral movement không kiểm soát5
Cấu hình ip-masq-agentKhả năng giữ source Pod IPSNAT sai, firewall on-prem chặn nhầm3

Mapping nhanh chủ đề con với loại incident phổ biến ​

Loại incidentTriệu chứng chínhFile cần đọc trước
Pod không scale dù còn CPU/RAMPending pod, lỗi cấp IP01
Latency Service tăng theo số endpointp99 tăng khi cluster lớn04
Kết nối bị chặn bất ngờtimeout giữa hai namespace05
Egress ra ngoài bị drop/SNAT saifirewall on-prem từ chối03
502/connection reset qua LoadBalancertraffic vào không ổn định03, 04
conntrack table đầydrop ngẫu nhiên dưới tải cao06
Không quan sát được vì sao gói bị dropthiếu visibility06

Năm sai lầm xuyên suốt thường gặp ở cấp chương ​

Trước khi đi vào từng file, đây là các sai lầm lặp lại nhiều nhất, cắt ngang mọi chủ đề của chương — nhận diện sớm sẽ tiết kiệm rất nhiều giờ debug:

  1. Sizing IP theo hiện trạng thay vì theo đỉnh tải. Cạn Pod IP là sự cố im lặng cho tới lúc scale/upgrade, khi đó đã muộn. Luôn tính headroom autoscaling và upgrade (file 1).
  2. Để quyết định bất biến trôi theo mặc định. Dataplane và IP plan không sửa in-place được; chọn theo quán tính nghĩa là tự khóa mình vào ngõ cụt (file 1, 2).
  3. Debug mà không biết “lúc này gói mang IP gì”. NAT đổi địa chỉ giữa các chặng; không nắm điều này dẫn tới đọc nhầm dữ liệu tcpdump (file 3, 6).
  4. Coi Service và NetworkPolicy là “miễn phí”. Mỗi Service/endpoint là chi phí dataplane thực; mỗi policy theo IP là gánh nặng cập nhật khi churn cao (file 4, 5).
  5. Bật default-deny mà quên phụ thuộc ẩn. DNS, health check, metrics, sidecar — bị chặn nhầm gây sự cố khó hiểu (file 5).

Mỗi sai lầm trên được phân tích sâu kèm cách phòng tránh trong file tương ứng.

Cross-reference với Google Cloud Architecture Framework ​

  • Reliability: thiết kế mạng phải có headroom IP, tránh single point of failure ở dataplane, và quan sát được packet drop (Reliability pillar).
  • Security: NetworkPolicy default-deny và giới hạn lateral movement là kiểm soát bắt buộc ở scale (Security pillar).
  • Performance optimization: chọn dataplane và LB model để tránh điểm gãy O(n) của iptables (Architecture Framework).

References chung của chapter ​

Những câu hỏi kiến trúc bắt buộc trả lời trước production ​

  1. Cluster đang dùng dataplane nào, và nếu cần Hubble/eBPF thì có phải tạo lại cluster không?
  2. Secondary range cho Pod chịu được tăng trưởng bao lâu, đã tính headroom upgrade chưa?
  3. Egress của Pod có cần giữ source IP để qua firewall on-prem không, ip-masq-agent đã cấu hình đúng chưa?
  4. Traffic vào dùng container-native LB (NEG) hay vẫn đi qua NodePort/kube-proxy?
  5. Có NetworkPolicy default-deny ở các namespace nhạy cảm chưa?
  6. Khi conntrack hoặc endpoint map gần đầy, có cảnh báo sớm không?
  7. Khi cần debug packet drop, team có sẵn quy trình tcpdump/Hubble/Connectivity Tests chưa?

Nếu chưa trả lời rõ các câu hỏi này, mạng cluster chưa nên coi là “production ready”.

Cross-reference với các chương khác ​

Chương 7 không đứng một mình; nó là điểm hội tụ của nhiều chương:

  • Chương 3 (VPC Model): alias IP, secondary ranges, firewall, routes — nền tảng để hiểu vì sao Pod IP định tuyến được trong VPC. Đọc lại nếu phần file 1 còn mơ hồ.
  • Chương 5 (Control Plane): API server phát tán Service/EndpointSlice/NetworkPolicy mà dataplane (kube-proxy/anetd) tiêu thụ. Latency điều khiển ở file 4 liên quan trực tiếp tới hành vi watch/informer của control plane.
  • Chương 6 (Node Lifecycle): max-pods-per-node (file 1 ở đây) gắn với capacity design của node; upgrade surge/blue-green ảnh hưởng headroom Pod IP.
  • Chương 8 (Scheduler): scheduling quyết định Pod nằm ở node nào, ảnh hưởng same-node vs cross-node path và phân bố backend của Service.
  • Chương 20–21 (Load Balancing, Ingress/Gateway): container-native LB (NEG) ở file 3 là nền tảng cho mọi mô hình expose service hiện đại.
  • Chương 12 (Security): NetworkPolicy ở file 5 là một lớp trong defense-in-depth, kết hợp với Workload Identity, mTLS và admission control.

Hiểu các mối liên hệ này giúp tránh tối ưu cục bộ một chương mà phá vỡ giả định của chương khác.

Bảng thuật ngữ then chốt của chương ​

Thuật ngữÝ nghĩa ngắn gọn
VPC-nativeCluster dùng alias IP cho Pod, định tuyến tự nhiên trong VPC (file 1)
Alias IP rangeDải IP phụ gán lên NIC node, nguồn cấp Pod IP (file 1)
Secondary rangeDải subnet riêng cho Pod và Service trong VPC-native (file 1)
Dataplane V2Dataplane GKE dựa trên eBPF/Cilium, thay kube-proxy (file 2)
anetdDaemonSet Cilium-based lập trình eBPF trên mỗi node (file 2)
Cilium identityNhóm Pod cùng label thành một danh tính cho policy (file 2, 5)
ClusterIP DNATDịch địa chỉ đích từ VIP Service sang Pod backend (file 3, 4)
ip-masq-agentQuyết định SNAT egress của Pod theo nonMasqueradeCIDRs (file 3)
NEGNetwork Endpoint Group, cho LB trỏ thẳng Pod IP (file 3)
conntrackBảng theo dõi kết nối của netfilter, tài nguyên hữu hạn (file 4, 6)
Endpoint mapeBPF map ánh xạ Service→backend, trần ~260K (file 2, 4)
HubbleLớp observability flow theo identity của Cilium (file 5, 6)

Production roadmap đề xuất cho Chapter 7 ​

Giai đoạn 1: Khóa nền tảng bất biến (trước khi tạo cluster) ​

Mục tiêu: ra đúng các quyết định không sửa được sau này.

  • Chốt IP plan (secondary range Pod/Service, max-pods-per-node theo pool) — file 1.
  • Quyết định dataplane (Dataplane V2 hay không) — file 2.
  • Phác thảo isolation model (namespace, tier, sensitive workload) trước khi onboard — file 5.

Deliverables: tài liệu IPAM cấp tổ chức, quyết định dataplane có lý do rõ ràng, bản đồ isolation sơ bộ.

Giai đoạn 2: Chuẩn hóa traffic path (khi onboard workload) ​

Mục tiêu: traffic vào/ra đi đúng đường tối ưu.

  • Mặc định container-native LB (NEG) cho traffic vào — file 3.
  • Cấu hình ip-masq-agent/nonMasqueradeCIDRs theo ma trận đích — file 3.
  • Áp default-deny + mở DNS và phụ thuộc ẩn ở namespace nhạy cảm — file 5.

Deliverables: mẫu Service/Ingress chuẩn dùng NEG, ConfigMap masquerade theo môi trường, bộ NetworkPolicy nền.

Giai đoạn 3: Quan sát và phòng ngừa (vận hành liên tục) ​

Mục tiêu: thấy trước sự cố thay vì chạy theo.

  • Dashboard Pod IP utilization, conntrack, endpoint map (DPv2) — file 1, 4, 6.
  • Bật deny.log của network policy logging + Hubble — file 5, 6.
  • Theo dõi latency điều khiển (Ready→nhận traffic) như SLO nội bộ — file 4.

Deliverables: bộ dashboard mạng, cảnh báo sớm tài nguyên hữu hạn, runbook debug theo path.

Mô hình trưởng thành vận hành mạng (maturity model) ​

Mức 1 — Reactive ​

  • Debug mạng theo cảm tính, restart pod khi gặp lỗi.
  • Không có default-deny; mạng phẳng.
  • Không theo dõi Pod IP/conntrack cho tới khi cạn.

Mức 2 — Managed ​

  • Có IP plan và dùng container-native LB.
  • Có một số NetworkPolicy cho dịch vụ quan trọng.
  • Có dashboard cơ bản và biết dùng tcpdump/Connectivity Tests.

Mức 3 — Predictive ​

  • Cảnh báo sớm Pod IP, conntrack, endpoint map trước ngưỡng.
  • Default-deny ở mọi namespace nhạy cảm + logging allow/deny.
  • Runbook debug theo path, luyện qua game day.

Mức 4 — Optimized ​

  • Dataplane V2 + Hubble là tiêu chuẩn; observability cấp identity.
  • Isolation model versioned, FQDN egress thay cho 0.0.0.0/0.
  • MTTR mạng đo được và cải thiện theo quý.

Mô hình trách nhiệm (RACI gợi ý) ​

  • Platform/Network team: IP plan, lựa chọn dataplane, mẫu LB/NEG, masquerade policy, baseline NetworkPolicy.
  • SRE/Operations: dashboard, cảnh báo tài nguyên hữu hạn, runbook debug, incident response mạng.
  • Application teams: khai báo Service đúng, connection pooling/keep-alive (giảm áp lực conntrack), label đúng chuẩn cho policy.
  • Security/Compliance: chuẩn isolation, FQDN egress, audit NetworkPolicy, quản trị label như bề mặt bảo mật.

FAQ của toàn chương ​

Chương này nên đọc tuần tự hay theo nhu cầu? ​

Khi mới tiếp cận, đọc tuần tự 1→6 để dựng mental model. Khi đã nắm, dùng theo nhu cầu: bảng mapping incident→file ở trên giúp nhảy thẳng vào phần cần thiết.

Quyết định nào trong chương là bất biến, phải làm đúng từ đầu? ​

IP plan (file 1) và lựa chọn dataplane (file 2) gần như không sửa in-place được — sai là phải tạo lại cluster. Các phần còn lại (LB model, NetworkPolicy, masquerade) điều chỉnh được trong vận hành.

Tổ chức nhỏ có cần áp dụng tất cả không? ​

Không cần ngay. Tối thiểu nên: IP plan có headroom, dùng container-native LB, và default-deny ở namespace nhạy cảm. Mở rộng theo mô hình trưởng thành khi hệ thống lớn dần.

Làm sao biết chương đã được áp dụng hiệu quả? ​

Các chỉ số cải thiện đo được: ít sự cố cạn IP/conntrack hơn, MTTR mạng ngắn hơn, ít 5xx trong rollout hơn, và kết nối bị chặn luôn truy được nguyên nhân nhờ logging/Hubble.

Kết luận của chapter ​

Mạng GKE thưởng cho những đội xây được mental model xuyên suốt và phạt nặng những đội debug theo cảm tính. Khi bạn nắm được packet path từng chặng, hiểu vì sao Dataplane V2 thay thế iptables, biết NetworkPolicy thực thi ra sao, và có sẵn bộ công cụ quan sát đúng chỗ, phần lớn sự cố mạng sẽ chuyển từ “bí ẩn nhiều giờ” thành “khoanh vùng vài phút”. Đó là mục tiêu thực dụng của chương này: không chỉ hiểu lý thuyết, mà có năng lực vận hành mạng cluster ở quy mô production.

Cách dùng chương hiệu quả nhất là biến từng file thành năng lực cụ thể: IP plan thành tài liệu IPAM, dataplane thành quyết định có lý do, packet path thành runbook debug, NetworkPolicy thành isolation model versioned, và troubleshooting toolkit thành quy trình chuẩn luyện qua game day. Khi đó chương này không chỉ là tài liệu đọc, mà là nền tảng vận hành mạng cho toàn tổ chức.