Alias IP Ranges — Cơ Chế Routing Pods GKE Không Cần NAT
Bài Toán Mà Alias IP Giải Quyết
Trong một Kubernetes cluster, mỗi pod cần một địa chỉ IP riêng để giao tiếp trực tiếp với pods khác. Vấn đề kỹ thuật: pod chạy bên trong một VM (node), và VM đó chỉ có một primary IP. Làm sao pods có thể có IPs riêng mà traffic đến pods không phải đi qua NAT?
Trả lời của GCP là Alias IP — một cơ chế cho phép một VM "sở hữu" một dải IP (range) mà tất cả packets đến range đó sẽ được forward vào VM đó, và VM có thể gán các IPs trong range đó cho các processes/containers bên trong mà không cần NAT.
Cơ chế này khác với một số cloud providers dùng NAT (SNAT/DNAT) cho pod-to-pod traffic — điều đó tạo overhead, khó debug, và ẩn source IP thực sự.
Internal Model: Cách Andromeda Xử Lý Alias IP
Từ Góc Nhìn Của Andromeda Agent
Khi bạn gán một alias IP range cho một VM (ví dụ: /24 block 10.1.5.0/24 cho node GKE):
- Control plane update metadata của VM: VM này "owns" range
10.1.5.0/24 - Andromeda agent trên host nhận thông tin này và cập nhật forwarding table
- Khi có packet đến bất kỳ IP nào trong
10.1.5.0/24, Andromeda agent:- Nhận ra range này thuộc về VM này (không phải VM khác)
- Forward packet vào VM (qua virtual interface)
- Bên trong VM, OS hoặc container runtime phân phối packet đến container/pod có IP tương ứng
Không có bước NAT nào trong quá trình này. Source IP của packet được giữ nguyên, destination IP cũng được giữ nguyên.
Pod A (10.1.5.3) trên Node 1 → Pod B (10.1.8.7) trên Node 2:
1. Pod A gửi packet: src=10.1.5.3, dst=10.1.8.7
2. Packet ra khỏi Pod A vào virtual NIC của Node 1
3. Andromeda trên host của Node 1:
- Kiểm tra: 10.1.5.3 có phải alias IP của Node 1 không? → CÓ
(anti-spoofing pass)
- Lookup: 10.1.8.7 → Node 2 có alias IP range 10.1.8.0/24
- Encapsulate và gửi đến host của Node 2
4. Andromeda trên host của Node 2:
- Decapsulate
- Forward vào Node 2 (VM), Node 2 biết 10.1.8.7 là Pod B
5. Pod B nhận packet: src=10.1.5.3, dst=10.1.8.7
(địa chỉ thật, không bị NAT)Route Installation Tự Động
Khi alias IP range được gán, GCP tự động thêm route vào VPC route table:
Trước khi gán alias IP:
Route table VPC:
10.0.0.0/20 → local (primary subnet)
10.1.0.0/16 → local (secondary range, abstract)
0.0.0.0/0 → default-internet-gateway
Sau khi Node 1 được gán alias range 10.1.5.0/24:
Route table VPC (conceptual):
10.1.5.0/24 → vm-node1 (Node 1 là next hop)
[tương tự cho mỗi node được gán range]"Tự động install" ở đây không phải là route visible trong GCP Console route table — đây là internal routing được Andromeda quản lý, dựa trên alias IP assignments được lưu trong VM metadata. Điều quan trọng là bạn không cần tạo static routes thủ công cho pod traffic — GCP xử lý việc này.
Anti-Spoofing: Bảo Mật Tại Data Plane
Một trong những tính năng quan trọng nhất của alias IP: anti-spoofing được enforce tại Andromeda.
Thông thường trong networking, khi một VM có IP 10.0.0.5, nó không được phép gửi packet với source IP khác (ví dụ 10.0.1.7) vì Andromeda sẽ drop packet đó.
Với alias IP, quy tắc này được mở rộng: VM có primary IP 10.0.0.5 và alias range 10.1.5.0/24 được phép gửi packet với source IP bất kỳ trong {10.0.0.5, 10.1.5.0/24}. Mọi source IP khác đều bị drop.
Hệ quả cho GKE: Các pod chỉ được phép gửi traffic với source IP nằm trong alias range của node của chúng. Pod không thể giả mạo IP của pod khác trên node khác — kể cả khi pod có access vào raw network của VM.
Node 1: primary IP 10.0.0.5, alias range 10.1.5.0/24
Được phép gửi từ:
✓ 10.0.0.5 (primary)
✓ 10.1.5.0 - 10.1.5.255 (alias range)
Bị drop:
✗ 10.1.8.7 (alias range của Node 2, không phải Node 1)
✗ 10.0.0.6 (IP của VM khác)
✗ bất kỳ IP nào không thuộc về Node 1Đây là lý do tại sao Kubernetes Network Policies có thể enforce ở cấp mạng trong GKE — vì anti-spoofing tại Andromeda đảm bảo source IP là chính xác và không thể giả mạo.
Alias IP vs IP Forwarding
Một khái niệm dễ nhầm lẫn là sự khác biệt giữa Alias IP và IP forwarding (--can-ip-forward).
IP forwarding (--can-ip-forward=true): VM có thể nhận packet có destination IP không phải của nó và forward tiếp (như router). Anti-spoofing check vẫn áp dụng cho egress, nhưng ingress không bị giới hạn bởi IP của VM.
Alias IP: VM có thể nhận packet đến alias range, và gửi packet với source trong alias range. Không cần --can-ip-forward=true.
Đừng bật IP forwarding khi mục đích chỉ là dùng Alias IP cho pods — đó là hai cơ chế khác nhau:
Alias IP: Node nhận packet đến pods, pods gửi traffic qua node
→ Dùng cho GKE VPC-native networking
IP Forwarding: VM nhận packet và route tiếp đến VM khác
→ Dùng cho VM làm gateway/proxy/NVA (Network Virtual Appliance)Secondary Ranges và Alias IP: Mối Quan Hệ
Alias IP range trên một VM phải được lấy từ primary hoặc secondary range của subnet.
Subnet prod-us-west1:
Primary: 10.0.0.0/20
Secondary: gke-pods = 10.1.0.0/16
Node 1 trong prod-us-west1:
Primary IP: 10.0.0.5 (từ primary range)
Alias range: 10.1.5.0/24 (từ secondary range "gke-pods")
✓ Hợp lệ: 10.1.5.0/24 ⊂ 10.1.0.0/16
Node 2 trong prod-us-west1:
Alias range: 10.1.6.0/24 (từ secondary range, block tiếp theo)
✓ Không chồng lấp với Node 1
Thử gán alias range không thuộc secondary range:
Alias range: 10.5.0.0/24 (không thuộc secondary range nào)
✗ GCP từ chối: range không thuộc về subnet nàyTại sao phải là secondary range? Vì primary range được dùng cho VM IPs (primary + optional alias từ primary). Secondary range cung cấp địa chỉ space riêng biệt, giúp phân biệt node traffic và pod traffic ở cấp routing.
GKE VPC-native Cluster: Toàn Bộ Flow
GKE "VPC-native" cluster (trái ngược với "routes-based" cluster cũ) sử dụng Alias IP hoàn toàn.
Khi GKE tạo một node (Compute Engine VM):
- Node được tạo trong subnet với primary IP
- GKE control plane gán một
/24block từ pod secondary range cho node đó - Alias IP range được set trên VM's network interface
- Kubelet trong node biết CIDR block của mình và cấp IPs từ block đó cho pods
Khi pod được schedule lên node:
- Kubelet gán một IP từ node's CIDR block cho pod
- Gọi CNI plugin (GKE dùng gke-network-plugin hoặc Dataplane V2)
- CNI tạo virtual network interface cho pod (veth pair)
- CNI configure routing trong OS của node để pod nhận traffic
Traffic giữa 2 pods trên cùng node:
- Không đi qua Andromeda
- Routing trong OS của node (kernel networking)
- Extremely low latency
Traffic giữa 2 pods trên khác nodes:
- Đi qua Andromeda (encapsulation/decapsulation)
- Andromeda biết đích nhờ alias IP routing
- Không qua internet, đi qua Google fabric
GKE Dataplane V2 (eBPF-based): Thay Đổi Model
Dataplane V2 (sử dụng eBPF và Cilium) thay đổi cách CNI hoạt động bên trong node, nhưng vẫn dùng Alias IP cho node-to-node routing qua Andromeda. Điểm khác biệt chính:
- Kubernetes Network Policies được enforce bằng eBPF tại pod network interface (không phải iptables)
- Hiệu năng tốt hơn với nhiều policies
- Observability tốt hơn qua Hubble (nếu enabled)
Từ góc nhìn của Andromeda và alias IP, Dataplane V2 và traditional dataplane hoạt động giống nhau. Sự khác biệt ở intra-node forwarding và policy enforcement.
Alias IP và Firewall Rules
Một điểm quan trọng: Firewall rules áp dụng cho cả primary IP và alias IP ranges của VM.
Nếu bạn có firewall rule cho phép traffic đến tag gke-node, rule đó áp dụng cho primary IP và tất cả alias IP ranges của các nodes có tag đó.
Nhưng có một subtlety: bạn có thể viết firewall rule target vào pod CIDR range cụ thể:
# Firewall rule target pod range trực tiếp
# Allow traffic từ monitoring pods đến tất cả pods
name: allow-monitoring-to-pods
direction: INGRESS
sourceRanges:
- 10.1.0.0/16 # toàn bộ pod CIDR
targetRanges:
- 10.1.0.0/16 # target pods (dùng destinationRanges với egress)
action: ALLOW
protocols: [tcp:9090] # Prometheus scrapeĐiều này cho phép granular control ở cấp pod network, không chỉ ở cấp node.
Giới Hạn Và Ràng Buộc Kỹ Thuật
Số Lượng Alias IP Ranges Per Interface
Mỗi network interface có thể có nhiều alias IP ranges (là array). Giới hạn thực tế phụ thuộc vào số lượng ranges và block sizes, nhưng thực tế với GKE, mỗi node thường chỉ có một alias range (một /24 block).
Alias IP và External IPs
Alias IPs là internal IPs. Bạn không thể tạo alias IP với external (public) IP address. Mỗi alias IP là địa chỉ private từ subnet của VM.
MTU Considerations
Alias IP không thay đổi MTU của interface. Packets vẫn bị giới hạn bởi MTU của VPC (thường 1460 hay 1500). Nếu workload cần jumbo frames (ví dụ HPC), cần configure VPC MTU lên cao (8896 max) — điều này áp dụng cho cả primary IP và alias ranges.
Không Hỗ Trợ Multicast
VPC không hỗ trợ multicast. Kubernetes không dùng multicast cho service discovery (dùng DNS thay thế), nên đây không phải vấn đề với GKE. Nhưng nếu workload nào cần multicast (ví dụ một số clustering protocols), phải implement overlay network riêng.
Tại Sao VPC-native Tốt Hơn Routes-based Cluster
GKE trước đây có "routes-based" clusters — mỗi pod range được implement bằng custom static routes trong VPC. Vấn đề của approach cũ:
Routes limit: VPC có giới hạn số lượng routes. Mỗi node trong routes-based cluster thêm một route. Cluster lớn có thể hit route limit.
Route propagation overhead: Mỗi khi node mới join hoặc leave, route phải được thêm/xóa và propagate. Chậm và tạo churn.
Không hoạt động với VPC Peering tốt: Custom routes không được exchange qua peering theo default. Pods trong peered VPC không thể route đến nhau.
Không có anti-spoofing tốt: Routes-based không có mechanism tương đương alias IP anti-spoofing tại data plane.
VPC-native với Alias IP giải quyết tất cả: không thêm route per-node (routing được handle trong-memory bởi Andromeda), hoạt động với peering, và có anti-spoofing native.
References
- Alias IP Ranges Overview — Tài liệu chính thức
- VPC-native Clusters — GKE và Alias IP
- GKE Dataplane V2 — eBPF-based dataplane
- Anti-spoofing in GCP — Cơ chế bảo mật tại data plane