Chương 20: Cloud Load Balancing — Architecture & Mechanics

Tại sao chương này tồn tại

Load balancer là điểm vào (entry point) của traffic. Mọi request từ internet, mọi RPC nội bộ giữa các service, mọi packet đi tới một GKE Service đều đi qua một load balancer nào đó. Một cấu hình sai ở tầng này không gây ra bug cục bộ — nó gây ra phân phối tải lệch, health check flapping, 502 hàng loạt, SSL handshake fail, hoặc mất source IP của client. Và vì load balancer nằm ngay trên đường đi của 100% traffic, sai lầm ở đây luôn là sự cố production nghiêm trọng nhất.

Vấn đề là: Cloud Load Balancing trên GCP không phải một sản phẩm. Nó là một họ hơn một chục loại load balancer, được xây trên hai họ datapath hoàn toàn khác nhau (Google Front End và Envoy), cộng thêm một họ thứ ba không có proxy nào cả (Maglev/Andromeda passthrough). Cùng một khái niệm "session affinity" có ngữ nghĩa khác nhau giữa proxy LB và passthrough LB. Cùng một từ "health check" được thực thi ở những nơi khác nhau. Cùng một annotation trên một GKE Service có thể tạo ra một external passthrough NLB hoặc một internal proxy ALB tùy ngữ cảnh.

Phần lớn kỹ sư học Cloud Load Balancing bằng cách thuộc lòng "loại nào dùng cho việc gì" — một bảng tra cứu. Bảng đó vô dụng khi debug, vì nó không cho bạn biết packet thực sự đi đâu, state nằm ở đâu, và cái gì vỡ khi nào. Chương này đi theo hướng ngược lại: xây dựng mental model về cơ chế datapath bên trong trước, rồi mọi quyết định lựa chọn loại LB sẽ tự rơi ra như hệ quả.

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

• Chương 19 — VPC Routing & Connectivity: hiểu Andromeda là host vSwitch, tách bạch control plane / data plane, route resolution. Load balancing là một lớp xây trên mô hình routing đó.
• Chương 7 — GKE Networking Internals: VPC-native cluster, alias IP, Pod IP. Cần cho phần container-native LB và GKE Service.
• HTTP/HTTPS, TLS handshake, và TCP/IP fundamentals (3-way handshake, connection state, 5-tuple).

Mental model trung tâm: ba họ datapath, một mô hình resource

Nếu chỉ giữ lại một thứ từ cả chương, hãy giữ sơ đồ này. Toàn bộ phần còn lại là chi tiết hóa nó.

                  Một mô hình RESOURCE thống nhất
   Forwarding Rule → Target Proxy → URL Map → Backend Service → Backend (IG / NEG)
        (VIP)         (L7/L4)      (routing)   (health/affinity)   (endpoint thật)

                  Ba họ DATAPATH khác nhau thực thi nó
 ┌────────────────────────┬───────────────────────┬──────────────────────────┐
 │   GFE (Google Front    │   Envoy (managed      │   Maglev / Andromeda     │
 │   End)                 │   proxy fleet)        │   (passthrough)          │
 ├────────────────────────┼───────────────────────┼──────────────────────────┤
 │ Global, anycast,       │ Regional (hoặc        │ KHÔNG có proxy.          │
 │ chạy ở edge của        │ cross-region), chạy   │ Packet giữ nguyên IP     │
 │ Google network.        │ trên proxy-only       │ đích, được forward       │
 │ Terminate TLS/TCP.     │ subnet trong VPC.     │ thẳng tới backend.       │
 │ Global External ALB,   │ Terminate TLS/TCP.    │ Backend tự trả lời       │
 │ Classic ALB,           │ Regional/Internal     │ trực tiếp (DSR).         │
 │ Global Proxy NLB.      │ ALB, Internal/Regional│ External & Internal      │
 │                        │ Proxy NLB.            │ Passthrough NLB.         │
 └────────────────────────┴───────────────────────┴──────────────────────────┘
   "Proxy" = LB mở 2 connection            "Passthrough" = LB không mở
   (client→proxy, proxy→backend).          connection nào; nó chỉ chọn backend
   Backend thấy IP của proxy.              và để packet đi qua. Backend thấy IP client.

Ba hệ quả lặp lại xuyên suốt chương:

1. Proxy vs passthrough là sự phân chia quan trọng nhất, hơn cả L4 vs L7. Một proxy LB kết thúc connection của client và mở connection mới tới backend — backend không bao giờ thấy IP thật của client (chỉ thấy qua header X-Forwarded-For với ALB, hoặc proxy protocol). Một passthrough LB không kết thúc gì cả — nó chọn backend bằng consistent hashing rồi để packet đi xuyên qua với IP đích nguyên vẹn; backend trả lời trực tiếp về client (Direct Server Return). Hai mô hình này khác nhau ở source IP, ở nơi state sống, ở ngữ nghĩa "connection", và ở cách failover.

2. GFE là global và sống ở control plane của Google; Envoy là regional và sống trong VPC của bạn. GFE-based LB (Global External ALB) dùng anycast VIP được quảng bá ở biên mạng Google — không tốn IP trong VPC, không cần proxy-only subnet. Envoy-based LB cần một proxy-only subnet trong mỗi region: đó là pool IP mà các Envoy proxy do Google quản lý sẽ dùng làm source khi gọi backend. Sự khác biệt này quyết định scope (global vs regional), latency, và cả việc backend của bạn thấy source IP nào.

3. Mô hình resource là chung, nhưng ngữ nghĩa của từng resource thay đổi theo họ datapath. "Backend service" của một Global ALB cấu hình balancing mode RATE và session affinity cookie; "backend service" của một internal passthrough NLB cấu hình connection tracking mode và session affinity 5-tuple. Cùng tên resource, cùng API, nhưng cơ chế thực thi bên dưới hoàn toàn khác. Đừng để cái tên chung đánh lừa bạn rằng cơ chế giống nhau.

Cấu trúc chương

Chương đi từ mô hình tổng quát → từng họ datapath cụ thể → các thành phần cắt ngang (NEG, health check) → tích hợp GKE → các lớp vận hành/bảo mật chồng lên (draining, SSL, Armor).

File	Chủ đề	Câu hỏi cốt lõi nó trả lời
01. LB Taxonomy & Architecture Model	Bản đồ đầy đủ các loại LB; mô hình resource thống nhất; ba họ datapath GFE/Envoy/Maglev; proxy vs passthrough	Có bao nhiêu loại LB và chúng khác nhau ở cơ chế nào, không chỉ ở use case?
02. Global External Application LB	Anycast VIP, Maglev đứng trước GFE, kiến trúc two-tier GFE, URL map, backend service, balancing mode, session affinity L7	Một request HTTP từ internet đi qua những tầng nào trước khi tới Pod? Backend được chọn thế nào?
03. Envoy-based Regional & Internal ALB	Envoy managed proxy fleet, proxy-only subnet, regional scope, khác biệt cơ chế so với GFE	Vì sao Envoy LB cần proxy-only subnet còn GFE LB thì không? Backend thấy source IP nào?
04. Passthrough Network LB	Maglev & Andromeda, Direct Server Return, connection tracking mode, consistent hashing, session affinity 5/3/2-tuple, ILB như next-hop	Khi không có proxy, backend được chọn thế nào và connection được "nhớ" ở đâu?
05. Network Endpoint Groups (NEGs)	Các loại NEG (zonal, serverless, internet, PSC, hybrid), container-native LB với Pod IP, NEG controller, readiness gate	Vì sao container-native LB loại bỏ được một network hop so với instance group?
06. Health Checks Architecture	Distributed prober model, dải IP 35.191.0.0/16 & 130.211.0.0/22, interval/timeout/threshold, proxy vs passthrough health checking	Probe đến từ đâu, vì sao phải mở firewall cho dải lạ, và một backend "unhealthy" nghĩa là gì?
07. GKE Service LoadBalancer Integration	LoadBalancer Service, NEG-based vs legacy, externalTrafficPolicy Local vs Cluster, GKE subsetting, session affinity	Vì sao externalTrafficPolicy: Local giữ được client IP nhưng có thể gây phân phối lệch?
08. Connection Draining & Graceful Shutdown	Cơ chế draining timeout, khác biệt proxy vs passthrough, graceful shutdown phối hợp với app	Khi xóa một backend, connection đang chạy bị cắt ngay hay được chờ? Chờ bao lâu, ai chờ?
09. SSL Policies & TLS Termination	Minimum TLS version, profile COMPATIBLE/MODERN/RESTRICTED/CUSTOM, cipher suite, gắn vào target proxy	TLS được terminate ở đâu, và làm sao ép một mức bảo mật TLS tối thiểu trên toàn bộ LB?
10. Cloud Armor & Edge Security	WAF preconfigured rules, enforce ở GFE edge, rule priority, rate limiting, Adaptive Protection, edge security policy	Cloud Armor chặn request ở đâu trong stack, trước hay sau khi tới backend?

Lộ trình đọc đề xuất

Nếu bạn đang thiết kế public entry point cho một web app/API (internet-facing): 01 → 02 → 09 → 10. Đây là chuỗi: hiểu mô hình → Global External ALB → bảo mật TLS → WAF/DDoS. Đủ để dựng một public endpoint production-grade.

Nếu bạn đang debug "tại sao traffic phân phối lệch / health check fail / 502": 01 → 06 → 08 → (02 hoặc 04 tùy loại LB). Health check và connection draining là nguồn gốc của phần lớn 502 và phân phối lệch; hiểu prober model và balancing mode là chìa khóa.

Nếu bạn đang expose service trên GKE (Service / internal LB): 01 → 05 → 07 → 04. Container-native NEG, GKE Service integration, externalTrafficPolicy, và passthrough mechanics là bốn thứ quyết định hành vi thật của một GKE Service.

Nếu bạn đang xây internal microservice mesh (đông-tây, trong VPC): 01 → 03 → 04 → 06. Internal ALB (Envoy) cho L7 routing nội bộ, internal passthrough NLB cho L4 hiệu năng cao, health check để hiểu liveness.

Nguyên tắc xuyên suốt chương

1. Proxy hay passthrough? — luôn hỏi câu này trước. Nó quyết định backend thấy source IP nào, "connection" nghĩa là gì, state nằm ở đâu, và failover hoạt động ra sao. Mọi nhầm lẫn khác đều bắt nguồn từ việc không phân biệt được hai mô hình này.

2. GFE = global/anycast/edge; Envoy = regional/proxy-only-subnet/trong-VPC. Scope, latency, IP consumption, và source IP nhìn từ backend đều suy ra từ việc datapath là GFE hay Envoy.

3. Health check không phải "ping cho vui" — nó là cơ chế điều khiển luồng traffic. Một backend chỉ nhận traffic khi prober đánh dấu nó healthy. Hiểu sai prober model (dải IP, threshold, nơi probe xuất phát) là nguyên nhân số một của 502 và "traffic không vào pod".

4. Mô hình resource chung không có nghĩa là cơ chế chung. Backend service / session affinity / connection draining đều có ngữ nghĩa khác nhau giữa proxy LB và passthrough LB. Luôn diễn giải resource trong ngữ cảnh họ datapath của nó.

5. Cloud Armor và SSL policy enforce ở proxy, nên chúng chỉ áp dụng được cho proxy LB. Một passthrough NLB không terminate TLS và không có proxy để chạy WAF — đó là lý do kiến trúc, không phải thiếu sót tính năng (Network Edge Security của Armor là một cơ chế L3/4 riêng cho passthrough).

References

• Cloud Load Balancing Overview
• Application Load Balancer Overview
• External Application Load Balancer Overview
• Proxy-only Subnets for Envoy-based Load Balancers
• Internal Passthrough Network Load Balancer Overview
• Network Endpoint Groups Overview
• Health Checks Overview
• Container-native Load Balancing
• Cloud Armor Security Policy Overview