Windows CNI Considerations — Mô Hình Networking Khác Biệt

Vì Sao Quan Trọng

Networking stack trên Windows không phải port 1:1 của Linux networking. Linux dùng netfilter/iptables (hoặc eBPF với Dataplane V2); Windows dùng một kiến trúc hoàn toàn khác — HNS (Host Networking Service) và VFP (Virtual Filtering Platform). Nếu bạn approach Windows networking troubleshooting với mental model của Linux (iptables -L, tc, eBPF program trace), bạn sẽ không tìm thấy gì tương ứng — cần mental model riêng.

Hệ quả trực tiếp quan trọng nhất cho GKE: GKE Dataplane V2 (dựa trên Cilium/eBPF) không hỗ trợ Windows node. Đây không phải giới hạn tạm thời — eBPF là công nghệ Linux kernel-native, không tồn tại equivalent trên Windows kernel. Windows node pool luôn dùng legacy dataplane (kube-proxy-based) dù phần Linux của cluster đã chạy Dataplane V2.

HNS & VFP: Windows Networking Primitives

Host Networking Service (HNS)

HNS là service quản lý network configuration cho container trên Windows — tương tự vai trò của kernel networking namespace + bridge trên Linux, nhưng implement khác biệt hoàn toàn:

Linux:  network namespace + veth pair + Linux bridge + iptables
Windows: HNS network + HNS endpoint + vSwitch + VFP policies

HNS quản lý:

• HNS Networks — tương đương "network" khái niệm, mode L2Bridge, L2Tunnel, Overlay, Transparent
• HNS Endpoints — tương đương network interface trong container, gắn vào Pod

Virtual Filtering Platform (VFP)

VFP là Hyper-V virtual switch extension chịu trách nhiệm packet filtering/forwarding — đóng vai trò tương tự netfilter/iptables trên Linux nhưng vận hành ở virtual switch layer, không phải kernel netfilter hook.

kube-proxy (Windows) → cấu hình rules → VFP → forward/NAT/load-balance packet

Kube-proxy Trên Windows: Kernelspace Mode

Điểm khác biệt lớn: kube-proxy trên Linux thường chạy iptables mode hoặc IPVS mode. Trên Windows, kube-proxy chạy ở kernelspace mode, tương tác trực tiếp với HNS/VFP để cấu hình load balancing rules cho Service:

Service ClusterIP request
    ↓
VFP policy (load balancing rule cấu hình bởi kube-proxy)
    ↓
DNAT tới Pod endpoint được chọn
    ↓
Pod (Windows container, network namespace riêng qua HNS endpoint)

Điều quan trọng: không có "userspace proxy mode" thực tế đáng dùng trên Windows production — kernelspace mode là phương án chuẩn, hiệu năng tốt hơn nhiều so với userspace mode cũ (đã deprecated).

CNI Plugin: win-bridge vs win-overlay

GKE Windows node pool sử dụng CNI plugin native cho Windows, không phải Calico/Cilium như phần Linux:

CNI mode	Network model	Khi nào dùng
win-bridge (L2Bridge)	Pod IP lấy trực tiếp từ VPC subnet range (alias IP)	GKE VPC-native cluster — mode chuẩn trên GKE
win-overlay (VXLAN overlay)	Pod IP từ overlay network riêng, encapsulate trong VXLAN	On-prem/self-managed cluster không có VPC-native support

Trên GKE, vì cluster bắt buộc VPC-native, Windows node pool dùng win-bridge mode: mỗi Windows node được assign một dải alias IP range từ VPC subnet, và Pod trên node đó lấy IP trực tiếp từ dải này — Pod IP routable trực tiếp trong VPC, không cần overlay encapsulation.

VPC Subnet: 10.0.0.0/20
  ├── Primary range: 10.0.0.0/24     (node IP)
  ├── Secondary range "pods": 10.4.0.0/14   (alias IP cho pod)
  └── Secondary range "services": 10.8.0.0/20

Windows Node 1 → được cấp alias block: 10.4.0.0/24 (256 IP cho pod trên node này)
Windows Node 2 → được cấp alias block: 10.4.1.0/24

Đây giống về nguyên lý với cách Linux node pool VPC-native hoạt động (mỗi node có secondary range riêng) — điểm khác là implementation layer: Linux dùng policy routing + iptables/eBPF, Windows dùng HNS L2Bridge + VFP.

Tại Sao Dataplane V2 Không Khả Dụng Cho Windows

GKE Dataplane V2 built trên Cilium, dùng eBPF program chạy trong Linux kernel để xử lý networking, Network Policy, và load balancing ở tốc độ cao, bypass phần lớn overhead của iptables truyền thống. eBPF là Linux kernel feature — Windows kernel không có equivalent subsystem tương đương (mặc dù Windows có "eBPF for Windows" project đang phát triển, GKE chưa tích hợp nó cho Windows node pool).

Hệ quả thực tế:

• Network Policy trên Windows node bị giới hạn hơn — Cilium NetworkPolicy enforcement (identity-based, L7-aware) không available; Windows chỉ hỗ trợ subset Network Policy semantics qua HNS/VFP ACL rules cơ bản
• Observability khác biệt — Cilium Hubble (flow visibility) chỉ cover phần Linux của cluster; Windows traffic không xuất hiện trong Hubble flow
• Nếu cluster đã enable Dataplane V2, phần Linux dùng Cilium, phần Windows dùng kube-proxy kernelspace song song — đây là hybrid dataplane hợp lệ trên GKE, không phải lỗi cấu hình

Common Pitfalls

1. DNS Resolution Chậm/Lỗi Trên Windows Pod

Windows container dùng resolver riêng (Dns Client service), khác Linux /etc/resolv.conf + nsswitch. Một số hành vi retry/caching DNS trên .NET (System.Net.Dns) khác Linux glibc resolver, dễ dẫn tới DNS caching quá lâu sau khi Service endpoint thay đổi (đặc biệt với .NET Framework cũ, DNS cache TTL không tự expire đúng cách). Khuyến nghị: set DNS_CACHE_TIMEOUT phù hợp ở application level nếu dùng .NET Framework legacy.

2. Network Policy Semantics Giới Hạn

Đừng assume Network Policy YAML viết cho Linux pod sẽ có effect tương đương khi áp cho Windows pod — luôn test riêng, vì enforcement engine khác nhau hoàn toàn (VFP ACL vs eBPF).

3. MTU Mismatch

Overlay hoặc L2Bridge mode có thể có MTU khác default 1500 tùy cấu hình VPC — mismatch MTU giữa Windows HNS network và underlying VPC network dẫn tới packet fragmentation silent, biểu hiện như "connection hangs" khó debug. Luôn verify MTU consistency khi troubleshoot latency bất thường trên Windows pod.

Tham Khảo

• Kubernetes Networking on Windows
• Windows Host Networking Service (HNS) overview
• GKE Dataplane V2 overview
• GKE VPC-native clusters (alias IP)