Auto-mode vs Custom-mode VPC — Tại Sao Production Luôn Phải Dùng Custom

Vấn Đề Cốt Lõi

GCP cung cấp hai chế độ tạo VPC: auto-mode và custom-mode. Auto-mode sinh ra để làm cho việc bắt đầu trở nên nhanh chóng — và nó hoàn thành nhiệm vụ đó tốt. Nhưng chính cơ chế tự động hóa của nó tạo ra những ràng buộc kỹ thuật không thể giải quyết được ở scale production.

Để hiểu tại sao custom-mode là bắt buộc, cần hiểu auto-mode thực sự làm gì bên trong khi bạn tạo VPC.

Internal Model của Auto-mode

Khi bạn tạo VPC không chỉ định --subnet-mode:

gcloud compute networks create my-network
# Hoặc:
gcloud compute networks create my-network --subnet-mode=auto

GCP thực hiện các bước sau:

1. Tạo VPC global object
2. Ngay lập tức tạo một subnet trong mỗi region có sẵn (hiện tại 40+ regions)
3. Mỗi subnet được gán CIDR theo một bảng phân bổ cố định từ dải 10.128.0.0/9
4. Khi Google mở thêm region mới, GCP tự động thêm subnet mới vào VPC của bạn

Bảng phân bổ CIDR của auto-mode (cố định, không thể thay đổi):

us-central1:        10.128.0.0/20
us-west1:           10.138.0.0/20
us-east1:           10.142.0.0/20
us-east4:           10.150.0.0/20
europe-west1:       10.132.0.0/20
europe-west2:       10.154.0.0/20
europe-north1:      10.166.0.0/20
asia-east1:         10.140.0.0/20
asia-northeast1:    10.146.0.0/20
asia-southeast1:    10.148.0.0/20
[... tất cả 40+ regions]

Tất cả đều nằm trong 10.128.0.0/9 (dải 10.128.x.x đến 10.255.x.x).

Tại Sao Bảng Cố Định Này Là Vấn Đề Nghiêm Trọng

Bản chất của vấn đề: Mọi VPC auto-mode trong mọi tổ chức trên thế giới đều dùng cùng dải CIDR này. Google không thể phân bổ khác nhau cho mỗi tổ chức vì bảng là cố định bởi thiết kế.

Điều này có nghĩa là:

Tổ chức của bạn:
  VPC "prod-network" (auto-mode): us-west1 subnet = 10.138.0.0/20
  VPC "staging-network" (auto-mode): us-west1 subnet = 10.138.0.0/20

→ Hai VPC trong cùng tổ chức, cùng region, CÙNG CIDR
→ Không thể peering vì CIDR chồng lấp
→ Khi bạn cần kết nối prod ↔ staging: không có cách nào

Đây không phải lỗi thiết kế của tổ chức bạn — đây là hệ quả tất yếu của auto-mode.

Constraint 1: VPC Peering Không Thể Hoạt Động

VPC Peering yêu cầu CIDR của hai VPC không được chồng lấp. Với auto-mode, mọi VPC đều có 10.138.0.0/20 cho us-west1 — nên việc peering giữa bất kỳ hai VPC auto-mode nào trong cùng organization là không thể.

gcloud compute networks peerings create prod-to-staging \
  --network=prod-network \
  --peer-network=staging-network

# Lỗi: "Subnet IP ranges of the two networks overlap"
# Không có workaround nào — đây là hard constraint của Andromeda
# (route lookup sẽ ambiguous nếu hai subnets cùng CIDR)

Hệ quả thực tế: Trong môi trường multi-team hoặc multi-environment, VPC peering là nhu cầu gần như bắt buộc. Auto-mode đóng cửa với khả năng này từ đầu.

Constraint 2: Kích Thước Subnet Cố Định /20

Mỗi subnet auto-mode là /20 — đúng 4,096 IPs (4,092 usable sau khi trừ 4 reserved). Con số này không thể thay đổi vì:

1. Bạn không thể resize subnet đang có VMs. GCP không hỗ trợ shrink subnet (kể cả custom-mode). Với auto-mode, expand subnet cũng không được vì nó sẽ chồng lấp với subnet auto-mode của region kế tiếp trong bảng phân bổ cố định.

2. /20 có vẻ đủ nhưng GKE tiêu tốn IP rất nhanh: mỗi node GKE cần một primary IP từ subnet, mỗi pod cần một IP từ secondary range (thường 110 pods/node). Với 30 nodes, bạn đã dùng 30 primary IPs + 3,300 pod IPs từ secondary range. Nếu secondary range cũng trong /20, bạn chỉ còn ~800 IPs — không đủ cho scaling tiếp theo.

3. Không thể thêm secondary ranges một cách có hệ thống sau khi subnet đã được tạo auto-mode. Bạn có thể thêm, nhưng không thể kiểm soát địa chỉ bắt đầu nên khó maintain consistency.

Constraint 3: Subnet Tự Động Cho Region Mới — Silent Expansion

Khi Google mở thêm region mới (việc này xảy ra thường xuyên), GCP tự động thêm subnet mới vào tất cả VPCs auto-mode của bạn.

Tại sao điều này nguy hiểm trong production?

Scenario: Tổ chức bạn có policy bảo mật nghiêm ngặt:
  - Mọi subnet mới phải được review trước khi tạo
  - Không được có subnet không được kiểm soát trong prod VPC
  - Change management yêu cầu approval

Với auto-mode:
  → Google thêm subnet mới → route mới được thêm vào route table
  → Không có notification rõ ràng
  → Firewall policies của bạn có thể không cover subnet mới
  → Subnet mới có thể vi phạm security baseline của bạn

Với custom-mode, không có subnet nào được tạo mà không có sự chủ động của bạn.

Custom-mode VPC: Internal Model

gcloud compute networks create prod-vpc --subnet-mode=custom

Với custom-mode, GCP chỉ tạo VPC global object — không có subnet nào. Route table ban đầu chỉ có implied routes từ default internet gateway.

Bạn có toàn quyền kiểm soát:

• Tạo subnet ở bất kỳ region nào, bất kỳ lúc nào
• Chọn bất kỳ CIDR trong RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) hoặc một số ranges đặc biệt
• Định nghĩa secondary ranges ngay khi tạo subnet
• Không có subnet nào bị thêm tự động

Cấu Trúc Subnet Tối Ưu Cho Production

Khi tạo subnet trong custom-mode, best practice là xác định ngay từ đầu tất cả secondary ranges bạn có thể cần:

gcloud compute networks subnets create prod-us-west1 \
  --network=prod-vpc \
  --region=us-west1 \
  --range=10.0.0.0/20 \
  --secondary-range \
    gke-pods=10.1.0.0/16,\
    gke-services=10.2.0.0/20,\
    internal-lb=10.3.0.0/24

Lý do quan trọng phải làm điều này ngay từ đầu: Sau khi cluster GKE đã được tạo dùng secondary range gke-pods, bạn không thể thay đổi CIDR của range đó mà không xóa và tạo lại cluster. Đây là một trong những điểm không thể undo được dễ dàng trong GCP networking.

Tại Sao Secondary Ranges Là Thành Phần Thiết Yếu

Secondary ranges không chỉ dành cho GKE. Chúng là cơ chế cho phép nhiều logical address spaces trong một subnet vật lý:

Subnet "prod-us-west1" (10.0.0.0/20):
  Primary range: 10.0.0.0/20        → VM primary IPs
  Secondary range "gke-pods":        → Alias IPs cho GKE pods
    10.1.0.0/16 (65K pod IPs)
  Secondary range "gke-services":    → Service cluster IPs
    10.2.0.0/20 (4K service IPs)
  Secondary range "internal-services": → Internal LB IPs
    10.3.0.0/24 (254 IPs)

Andromeda nhận biết secondary ranges và install routes tương ứng. Traffic đến bất kỳ IP nào trong secondary range được forward đến VM "owning" range đó — đây là cơ chế của Alias IP (sẽ chi tiết trong file 04).

Điều quan trọng về secondary ranges: chúng phải không chồng lấp với bất kỳ range nào trong cùng VPC, bao gồm cả secondary ranges của các subnets khác.

Quyết Định Thiết Kế: Bao Nhiêu Subnets Trong Một Region?

Một câu hỏi thường gặp: nên có bao nhiêu subnets trong mỗi region?

Một Subnet Per Region (Simplest)

us-west1: 10.0.0.0/16 (tất cả workloads dùng chung)
  Primary: VMs
  Secondary: pods, services

Phù hợp khi tất cả workloads trong region có cùng security posture. Firewall rules dùng tags/service accounts để phân biệt, không phải subnet boundaries.

Multiple Subnets Per Region (Segmentation)

us-west1:
  prod-public-us-west1:   10.0.0.0/22  (Public-facing, có internet access)
  prod-private-us-west1:  10.0.4.0/22  (Private, không có internet access)
  prod-data-us-west1:     10.0.8.0/22  (Database tier, strict isolation)

Phù hợp khi cần network-level isolation (ví dụ: compliance yêu cầu database không cùng subnet với application tier).

Trade-off: Nhiều subnets = nhiều routes, nhiều complexity trong firewall rules, khó maintain consistency. Đừng tạo subnets chỉ vì "có thể hữu ích sau này" — tạo khi có nhu cầu thực sự.

Giới Hạn Kỹ Thuật Của Subnet

Không Thể Shrink CIDR

Một khi subnet đã được tạo với /20, bạn không thể thu nhỏ xuống /21. Bạn chỉ có thể expand (nếu range liền kề còn trống).

Expand Subnet Có Giới Hạn

Việc expand primary CIDR của subnet cần thỏa mãn:

1. Không được chồng lấp với subnet khác trong VPC
2. New range phải bao gồm old range (supernet)
3. Không thể thêm discontiguous ranges vào primary CIDR

# OK: mở rộng từ /20 lên /19 (10.0.0.0/19 bao gồm 10.0.0.0/20)
gcloud compute networks subnets expand-ip-range prod-us-west1 \
  --region=us-west1 \
  --prefix-length=19

# FAIL: không thể thêm 10.0.32.0/20 vào subnet 10.0.0.0/20
# (chúng không liền kề theo cấu trúc supernet)

Secondary Ranges Không Thể Xóa Khi Đang Dùng

Nếu GKE cluster đang dùng secondary range gke-pods, bạn không thể xóa range đó. Phải xóa cluster trước. Đây là ràng buộc phải nhớ khi thiết kế teardown procedure.

Migration: Auto-mode → Custom-mode

Nếu bạn đang có auto-mode VPC cần migrate (thường gặp khi tổ chức đã dùng auto-mode ban đầu và cần expand), có hai approaches:

Approach 1: Parallel Migration (Recommended)

Không cố migrate subnet auto-mode sang custom-mode. Thay vào đó:

1. Tạo custom-mode VPC mới với CIDR planning đúng đắn
2. Tạo subnets mới không chồng lấp với auto-mode VPC
3. Deploy workloads mới vào custom-mode VPC
4. Migrate workloads cũ từng phần: tạo VM mới trong custom-mode, chuyển traffic (dùng DNS hoặc load balancer), xóa VM cũ
5. Sau khi toàn bộ workloads đã migrate, xóa auto-mode VPC

Ưu điểm: Zero downtime (nếu làm đúng), có thể rollback bất kỳ lúc nào Nhược điểm: Cần chạy song song 2 VPCs tạm thời, cần thêm IPs cho migration period

Approach 2: Tắt Auto-subnet cho Auto-mode VPC

Bạn có thể convert auto-mode VPC sang custom-mode (một way, không thể reverse):

gcloud compute networks update my-network --switch-to-custom-subnet-mode

Sau lệnh này:

• VPC trở thành custom-mode
• Các subnets auto-mode đang có được giữ nguyên (không bị xóa)
• Không còn subnet nào được tự động tạo khi có region mới
• Bạn có thể xóa các subnets không cần thiết từng cái một

Lưu ý quan trọng: Các subnets vừa convert vẫn có CIDR cũ từ bảng phân bổ auto-mode. Vấn đề peering (CIDR collision với auto-mode VPCs khác) vẫn tồn tại cho các subnets đó. Phải thay thế chúng với subnets có CIDR mới để giải quyết triệt để.

Tại Sao Không Nên Resize Subnet Theo Cách Thông Thường

Một anti-pattern phổ biến: cố gắng "sửa" auto-mode VPC bằng cách thêm secondary ranges và hy vọng nó đủ cho production. Điều này không giải quyết vấn đề peering và tạo ra technical debt khó clean up.

Custom-mode: Các Quyết Định Thiết Kế Phải Làm Trước

Danh sách quyết định phải có trước khi tạo bất kỳ subnet nào:

1. Phạm vi CIDR toàn VPC

• RFC 1918 range nào? 10.0.0.0/8 cho large orgs, 172.16.0.0/12 cho smaller
• Có cần kết nối với on-premises? Phải biết on-premises dùng gì để tránh collision
• Có VPN/Interconnect tới môi trường khác? Kiểm tra CIDR của bên kia

2. Phân bổ per-region

• Bao nhiêu IPs cần cho mỗi region?
• Dự kiến scale trong 3-5 năm? (Đừng thiết kế cho ngày hôm nay)
• Regions nào cần GKE? (Cần tính thêm secondary ranges)
• Regions nào có thể thêm sau? (Dành không gian trước)

3. Secondary ranges

• Mỗi region cần bao nhiêu pod IPs cho GKE? (Mỗi node = 110 pods mặc định, plan cho max nodes × 110)
• Cần Internal LB IPs không?
• Các workloads đặc thù nào cần isolated IP ranges?

4. CIDR for peering partners

• Nếu cần peer với VPC khác (team khác, env khác), CIDR đó là gì?
• Phải không overlap với bất kỳ CIDR nào trong VPC của bạn

Tất cả những điều này phải được lập thành văn bản và review trước khi tạo VPC. Việc thay đổi sau rất đau đớn.

Checklist Production: Custom-mode VPC

Trước khi coi custom-mode VPC là production-ready:

□ CIDR plan đã được document và version-controlled
□ CIDR không chồng lấp với:
  □ On-premises networks
  □ Các VPCs khác trong tổ chức
  □ Các VPCs sẽ peering trong tương lai
  □ 100.64.0.0/10 (Shared Address Space, dùng bởi một số ISPs)
  □ 169.254.0.0/16 (Link-local)
□ Secondary ranges đã được định nghĩa cho tất cả subnets cần GKE
□ Không có auto-mode subnet nào trong VPC
□ Firewall rules đã được review và document
□ Private Google Access đã được bật cho private subnets
□ Flow logs đã được cấu hình
□ IAM permissions cho network-admin role đã được thiết lập

References

• VPC Network Modes — Tài liệu chính thức về auto vs custom mode
• Creating VPC Networks — Hướng dẫn tạo VPC với custom mode
• Subnet Considerations — Các ràng buộc kỹ thuật của subnet
• VPC Quotas — Giới hạn số lượng VPCs, subnets