My Awesome Project

Appearance

Shared VPC: Quản lý mạng tập trung ​

Vì sao cần Shared VPC ​

Tổ chức production không thể để mỗi project tự quản lý networking một cách độc lập:

Anti-pattern: Mỗi project một mạng riêng
my-project-prod:
  VPC: 10.0.0.0/16

my-project-staging:
  VPC: 10.0.0.0/16  # BỊ CHỒNG LẤN! Không thể giao tiếp
  
Kết quả: Không định tuyến được traffic, không có service mesh, firewall hỗn loạn

Shared VPC cung cấp:

  • Quản lý mạng tập trung
  • Một perimeter bảo mật duy nhất
  • Giao tiếp service-to-service
  • Chia sẻ subnet giữa nhiều project

Kiến trúc ​

Organization
├── Host Project (chứa VPC)
│   └── Network: shared-vpc-prod
│       ├── Subnet: us-central1
│       ├── Subnet: us-east1
│       └── Firewall rules
│
└── Service Projects (dùng VPC từ host)
    ├── Service Project A (GKE)
    ├── Service Project B (Cloud Run)
    └── Service Project C (Compute Engine)

Quan hệ chính: Service projects không thể tự tạo network — phải dùng network của host project.

Thiết lập ​

bash
# 1. Bật Shared VPC ở cấp organization
gcloud compute shared-vpc organizations enable ORG_ID

# 2. Chỉ định host project
gcloud compute shared-vpc host-projects create HOST_PROJECT_ID

# 3. Tạo shared network
gcloud compute networks create shared-vpc-prod \
  --project=HOST_PROJECT_ID \
  --subnet-mode=custom

# 4. Tạo shared subnet
gcloud compute networks subnets create us-central1-subnet \
  --project=HOST_PROJECT_ID \
  --network=shared-vpc-prod \
  --region=us-central1 \
  --range=10.0.0.0/24

# 5. Gắn service project
gcloud compute shared-vpc associated-projects attach SERVICE_PROJECT \
  --host-project=HOST_PROJECT_ID

# 6. Cấp quyền
gcloud projects add-iam-policy-binding SERVICE_PROJECT \
  --member=serviceAccount:service-account@HOST_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/compute.networkUser

Network Admin vs quản lý service account ​

Host Project:
- Network Admin (từ host project)
  - Có thể sửa subnet, firewall, routes
  - Là điểm kiểm soát tập trung

Service Projects:
- Network User (role được ủy quyền)
  - Có thể tạo resource dùng shared network
  - Không thể sửa network

Giao tiếp service liên project ​

yaml
# GKE cluster ở service project A
Namespace: default
Pod: frontend-deployment
Service: frontend-svc (10.1.0.1)

# Cloud SQL ở service project B
Internal IP: 10.2.0.5

# Cả hai kết nối qua Shared VPC → có thể giao tiếp
# frontend-svc → 10.2.0.5 (định tuyến trực tiếp)

Firewall rules trong Shared VPC ​

bash
# Central firewall rule ở host project
gcloud compute firewall-rules create allow-backend-api \
  --project=HOST_PROJECT_ID \
  --network=shared-vpc-prod \
  --allow=tcp:8080 \
  --source-ranges=10.0.0.0/16 \
  --target-service-accounts=backend-sa@service-project-a.iam.gserviceaccount.com

# Resource trong service project tự động dùng firewall trung tâm
# (không cần tạo rule trùng lặp cho từng project)

Giới hạn của Shared VPC ​

Không thể:
- Peering giữa service projects (hãy dùng shared VPC)
- Có nhiều host project cho một organization (chỉ 1)
- Service project đóng vai trò host
- Chính sách routing động có thể khác nhau giữa host/service project

Shared VPC đa vùng ​

hcl
# Terraform: Shared network đa vùng

resource "google_compute_network" "shared_vpc" {
  project                 = var.host_project_id
  name                    = "shared-vpc-prod"
  auto_create_subnetworks = false
  routing_mode            = "GLOBAL"  # Bật định tuyến liên vùng
}

resource "google_compute_subnetwork" "us_central" {
  project       = var.host_project_id
  name          = "us-central1"
  region        = "us-central1"
  network       = google_compute_network.shared_vpc.id
  ip_cidr_range = "10.0.0.0/24"
}

resource "google_compute_subnetwork" "us_east" {
  project       = var.host_project_id
  name          = "us-east1"
  region        = "us-east1"
  network       = google_compute_network.shared_vpc.id
  ip_cidr_range = "10.1.0.0/24"
}

# GKE cluster ở service project, trải rộng nhiều region
resource "google_container_cluster" "global_cluster" {
  project  = var.service_project_id
  name     = "global-cluster"
  
  # Dùng Shared VPC từ host project
  network    = "shared-vpc-prod"
  subnetwork = google_compute_subnetwork.us_central.name
  
  # Pod CIDR từ shared subnet
  ip_allocation_policy {
    cluster_secondary_range_name  = "pods"
    services_secondary_range_name = "services"
  }
}

Tác động chi phí ​

Giá của Shared VPC:

  • Không có chi phí thêm cho VPC/subnet
  • Egress charge áp theo từng service project
  • Chi phí Shared NAT gateway do host project chịu
Ví dụ: 2 service projects dùng shared NAT
- Service Project A: 10TB egress
- Service Project B: 5TB egress
- Tổng chi phí egress: (10+5TB) × $0.12/GB
  tính vào host project (nơi NAT tồn tại)

Di chuyển từ VPC Peering sang Shared VPC ​

bash
# Mẫu cũ: VPC peering
Proj A (network A) ←→ Peering ←→ Proj B (network B)

# Mẫu mới: Shared VPC
Proj A & B dùng cùng network từ Host project
(đơn giản hơn, không phải bảo trì peering)

# Các bước di chuyển:
# 1. Tạo shared VPC trong host project mới
# 2. Tạo subnets trong shared VPC
# 3. Gắn service projects
# 4. Di chuyển resource dần dần
# 5. Cập nhật DNS, load balancer
# 6. Xóa VPC peering cũ

Tham khảo ​