My Awesome Project

Appearance

Chương 23: Cloud NAT — Cơ Chế Phân Bổ Port & Phòng Tránh Cạn Kiệt ​

Tại Sao Chương Này Quan Trọng ​

Cloud NAT port exhaustion là loại lỗi nguy hiểm nhất trong thực tế vận hành: nó xảy ra im lặng. Không có exception rõ ràng, không có error message trực tiếp từ tầng ứng dụng. Connection đơn giản là bị drop — và team thường mất nhiều giờ hoặc nhiều ngày để xác định nguyên nhân thật sự là thiếu NAT port.

Hiểu Cloud NAT không chỉ là biết cách cấu hình. Điều quan trọng hơn là nắm được cơ chế phân bổ port bên trong, tại sao giới hạn 64.512 ports/IP tồn tại, tại sao TCP TIME_WAIT tạo ra "phantom shortage", và tại sao GKE private clusters đặc biệt dễ gặp vấn đề này khi scale. Với kiến thức đó, capacity planning và troubleshooting trở thành kỹ năng chủ động, không phải phản ứng sau sự cố.

Cấu Trúc Chương ​

chapter-23-cloud-nat/
├── index.md                              ← file này
├── 01.cloud-nat-architecture-snat.md    ← Kiến trúc phân tán & cơ chế SNAT
├── 02.port-allocation-exhaustion.md     ← Port math, static/dynamic modes, 5-tuple, TIME_WAIT, exhaustion
├── 03.cloud-nat-gke.md                  ← Tích hợp GKE: private cluster, pod egress
└── 04.configuration-monitoring.md      ← Timeouts, NAT rules, metrics, logging

Các Subtopic ​

1. Kiến Trúc Cloud NAT & Cơ Chế SNAT ​

Cloud NAT không phải là một proxy VM hay một thiết bị vật lý — đây là điều phần lớn người dùng hiểu sai. Cloud NAT được triển khai trực tiếp trong Andromeda SDN, tầng mạng phần mềm của GCP. File này giải thích tại sao thiết kế phân tán này khác biệt hoàn toàn so với NAT truyền thống, cơ chế SNAT diễn ra như thế nào ở tầng datapath, và tại sao Cloud NAT không làm giảm băng thông.

Nội dung chính:

  • Andromeda integration: NAT xảy ra ở đâu trong data plane
  • Phân biệt distributed NAT vs appliance-based NAT
  • SNAT flow chi tiết: source IP/port replacement và connection tracking
  • Tại sao Cloud NAT chỉ hỗ trợ outbound (không có inbound unsolicited)
  • Endpoint-Independent Mapping: cơ chế và trade-offs

2. Port Allocation & Port Exhaustion ​

Đây là phần kỹ thuật cốt lõi nhất của chương — và là nơi phần lớn sự cố production phát sinh. File này mổ xẻ con số 64.512 ports/IP từ gốc, giải thích tại sao 5-tuple ràng buộc tái sử dụng port, và cách TCP TIME_WAIT tạo ra tình trạng "cạn kiệt ảo" ngay cả khi số kết nối thực tế không quá cao.

Nội dung chính:

  • Tại sao chỉ có 64.512 ports/IP (không phải 65.535)
  • Port allocation modes: static vs dynamic — cơ chế, trade-offs
  • Port math công thức: max VMs = ⌊(NAT IPs × 64.512) / ports-per-VM⌋
  • 5-tuple và ràng buộc tái sử dụng port
  • TCP TIME_WAIT 120s → phantom port shortage
  • Dynamic Port Allocation: cơ chế doubling
  • NAT_ALLOCATION_FAILED: triệu chứng, chẩn đoán, xử lý
  • Chiến lược phòng tránh exhaustion

3. Cloud NAT với GKE ​

GKE private clusters bắt buộc phải có Cloud NAT để node có thể pull image từ Artifact Registry và gọi API Google. Nhưng mô hình traffic của GKE có đặc điểm riêng: nhiều pod trên một VM node đều share NAT port allocation của node đó, không phải của pod. File này giải thích tại sao điều này tạo ra pressure đặc biệt và cách thiết kế đúng.

Nội dung chính:

  • Tại sao GKE private cluster cần Cloud NAT
  • Pod egress: traffic flow từ pod → node VM → Cloud NAT
  • ip-masq-agent và masquerade rules
  • NAT scope: ALL_SUBNETWORKS_ALL_IP_RANGES
  • Capacity planning cho GKE: tính theo số node, không phải số pod
  • Cloud NAT với GKE Autopilot

4. Cấu Hình, Giám Sát & Tối Ưu ​

Sau khi hiểu cơ chế, phần này đi vào thực hành: cấu hình timeout (TCP/UDP/ICMP), NAT rules để phân tách traffic theo destination, metrics để monitor, và logging để debug. Điểm đặc biệt là giải thích tại sao mỗi tham số tồn tại, không chỉ liệt kê giá trị.

Nội dung chính:

  • Connection timeout mechanics: TCP/UDP/ICMP và lý do khác nhau
  • TCP TIME_WAIT timeout tuning: mặc định 120s, có thể giảm xuống 5s
  • NAT rules: phân tách traffic theo destination IP range
  • Metrics quan trọng: port_usage, dropped_sent_packets_count, nat_allocation_failed
  • Cloud NAT logging: cấu trúc log, cost implications
  • Connection pooling và keep-alive patterns

Điều Kiện Tiên Quyết ​

References ​