My Awesome Project

Appearance

Chương 24: Private Service Connect — Mô Hình Hiện Đại Để Expose Service ​

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

Trong gần một thập kỷ, cách duy nhất để hai VPC network trên Google Cloud nói chuyện với nhau ở mức private là VPC Network Peering — và cùng với nó là tất cả những giới hạn cố hữu: phải đảm bảo IP range không trùng nhau giữa các bên, phải chia sẻ toàn bộ route table, không có tính bắc cầu (non-transitive), và quan trọng nhất là peering mở ra một bề mặt kết nối rộng — một khi peer, hai network nhìn thấy nhau ở mức IP một cách khá toàn diện.

Private Service Connect (PSC) ra đời để giải quyết một bài toán hẹp hơn nhưng quan trọng hơn nhiều trong kiến trúc multi-tenant: làm thế nào để một bên (producer) expose đúng một service cụ thể cho một bên khác (consumer), mà không cần peering, không cần phối hợp IP range, và không mở ra toàn bộ network? Đây chính là mô hình mà mọi managed service hiện đại của Google Cloud — Cloud SQL, Memorystore, AlloyDB, thậm chí cả GKE control plane — đều dùng dưới lớp vỏ. Nếu bạn không hiểu PSC, bạn không thực sự hiểu cách các managed service kết nối vào VPC của mình, và bạn sẽ không thể debug khi connection ở trạng thái PENDING mãi mãi.

PSC không phải là "một cách kết nối network khác". Nó là một sự dịch chuyển mô hình tư duy: từ network-centric connectivity (kết nối hai mạng) sang service-centric connectivity (publish và consume một service qua một điểm NAT). Hiểu được sự dịch chuyển này là mục tiêu cốt lõi của chương.

Mô Hình Tư Duy Cốt Lõi (đọc trước khi đi vào chi tiết) ​

Trước khi đi sâu vào từng subtopic, hãy nắm ba điểm bản chất sẽ xuyên suốt chương:

  1. PSC là một cặp resource bất đối xứng qua một lớp NAT. Phía producer có service attachment (gắn với một internal load balancer); phía consumer có endpoint (một forwarding rule với một internal IP). Giữa hai bên là một NAT subnet do producer cấp phát. Vì có NAT, hai VPC không cần biết IP range của nhau và được phép trùng IP range — đây là điểm khác biệt nền tảng so với peering.

  2. Đơn vị được expose là service, không phải network. Consumer chỉ tiếp cận được đúng cái IP của endpoint trỏ tới service attachment đó — không phải toàn bộ producer VPC. Đây là lý do PSC an toàn hơn peering trong multi-tenant.

  3. Kết nối luôn một chiều và không bắc cầu (qua endpoint). Traffic đi từ consumer → producer. Endpoint không cho phép producer chủ động kết nối ngược lại consumer (muốn vậy phải dùng PSC interface), và endpoint không truyền tiếp connectivity sang các network peered với consumer.

Mọi thứ còn lại trong chương — Google APIs, GKE, Cloud SQL, approval, DNS — đều là biến thể của ba nguyên lý trên.

Cấu Trúc Chương ​

chapter-24-private-service-connect/
├── index.md                                  ← file này
├── 01.psc-architecture-components.md         ← Kiến trúc & components: service attachment, endpoint, backend, interface, NAT
├── 02.psc-vs-vpc-peering.md                  ← PSC vs VPC Peering: routing, transitivity, security, use cases
├── 03.psc-google-apis.md                     ← PSC cho Google APIs: all-apis/vpc-sc bundle, vs Private Google Access
├── 04.psc-managed-services-gke.md            ← PSC cho managed services (Cloud SQL, Memorystore, AlloyDB) & GKE control plane
├── 05.consumer-producer-iam-approval.md      ← Consumer vs producer: IAM, approval workflow, accept/reject list, connection limit
├── 06.global-access-and-dns.md               ← Global access cross-region & DNS automation (A record, Service Directory)
└── 07.psc-troubleshooting.md                 ← Troubleshoot: connection states, connectivity tests, flow logs

Các Subtopic ​

1. Kiến Trúc & Components của PSC ​

File nền tảng của chương. Mổ xẻ bốn resource cốt lõi của PSC — service attachment (producer), endpoint (consumer), backend (NEG qua load balancer), và interface (kết nối ngược producer → consumer) — và quan trọng nhất là cơ chế NAT cho phép hai VPC trùng IP range vẫn nói chuyện được. Đây là nơi xây dựng mental model chính xác về data flow của PSC ở tầng datapath.

Nội dung chính:

  • Bốn loại resource PSC và vai trò bất đối xứng producer/consumer
  • NAT subnet: tại sao tồn tại, cách cấp phát IP, mỗi connection tiêu thụ 1 IP
  • Data flow chi tiết: consumer endpoint → NAT → producer ILB → backend
  • Tại sao PSC đạt line-rate (NAT phân tán trong Andromeda, không có proxy trung tâm)
  • Overlapping IP ranges: tại sao PSC xử lý được mà peering thì không
  • Endpoint vs backend: khi nào cần load balancer trước service attachment

2. PSC vs VPC Peering ​

Đây là file giúp bạn ra quyết định kiến trúc. So sánh PSC với VPC Peering trên các trục: routing (full route exchange vs single NAT'd IP), transitivity, bảo mật (blast radius), IP coordination, và scale. Không phải catalog — mỗi điểm so sánh đều nhằm soi sáng vì sao hai mô hình được thiết kế khác nhau và khi nào chọn cái nào.

Nội dung chính:

  • Routing model: peering trao đổi toàn bộ subnet routes vs PSC chỉ expose 1 IP
  • Non-transitivity: cả hai đều non-transitive nhưng vì lý do khác nhau
  • Security & blast radius: tại sao PSC là lựa chọn đúng cho multi-tenant
  • IP overlap: peering cấm trùng, PSC cho phép
  • Scale limits: số peering connection vs số PSC endpoint
  • Decision matrix: khi nào peering vẫn đúng, khi nào bắt buộc PSC

3. PSC cho Google APIs ​

Cách dùng PSC để truy cập Google APIs (Cloud Storage, BigQuery, Pub/Sub...) qua một internal IP do bạn tự chọn, thay vì qua private.googleapis.com/restricted.googleapis.com của Private Google Access. Giải thích hai bundle all-apis và vpc-sc, DNS p.googleapis.com, và tại sao mô hình này quan trọng cho hybrid connectivity (on-prem gọi Google APIs qua IP nội bộ).

Nội dung chính:

  • PSC endpoint cho Google APIs vs Private Google Access: khác biệt bản chất
  • Bundle all-apis vs vpc-sc: phạm vi service và quan hệ với VPC Service Controls
  • Global internal IP: tại sao endpoint này global còn endpoint service thì regional
  • DNS p.googleapis.com và Service Directory zone tự tạo
  • Hybrid: on-prem truy cập Google APIs qua PSC endpoint IP
  • Giới hạn: chỉ HTTP-based protocol, không Workspace apps

4. PSC cho Managed Services & GKE Control Plane ​

Phần "tại sao bạn thực sự gặp PSC hằng ngày mà không biết". Cloud SQL, Memorystore, AlloyDB và GKE control plane đều dùng PSC dưới lớp vỏ. File này giải thích producer ở đây là Google-managed tenant project, service attachment được tạo tự động, và bạn (consumer) chỉ tạo endpoint. Đặc biệt phân tích sâu mô hình GKE control plane connectivity dựa trên PSC (thay thế VPC peering cũ, scale 1000 cluster vs 75).

Nội dung chính:

  • Mô hình tenant project: producer là Google, service attachment auto-created
  • Cloud SQL PSC: per-instance service attachment, allowed projects, DNS name
  • Memorystore & AlloyDB: cùng pattern, khác biệt nhỏ
  • GKE control plane qua PSC: internal endpoint, node → control plane, DNS-based endpoint
  • Tại sao PSC cho phép GKE scale tới 1000 cluster (peering chỉ 75)
  • Service connection policy: tự động tạo endpoint cho managed service

5. Consumer vs Producer: IAM & Approval Workflow ​

Cơ chế kiểm soát "ai được kết nối vào service của tôi". Phân tích connection preference (ACCEPT_AUTOMATIC vs ACCEPT_MANUAL), consumer accept/reject list, connection limit per project/network, và vòng đời approval (PENDING → ACCEPTED). Đây là nơi phần lớn sự cố "endpoint stuck PENDING" được giải thích đến tận gốc.

Nội dung chính:

  • Connection preference: auto-accept vs explicit accept list
  • Accept list (tối đa 5000 giá trị) & reject list (tối đa 64) theo project/network/endpoint
  • Connection limit per consumer: cơ chế và khi nào connection bị giữ PENDING
  • Approval workflow end-to-end: consumer tạo endpoint → producer accept
  • IAM: role nào cần ở phía producer và consumer
  • Anti-pattern: auto-accept trong môi trường multi-tenant không tin cậy

6. Global Access & DNS Automation ​

Hai tiện ích phía consumer làm PSC dùng được ở quy mô thật. Global access cho phép resource ở mọi region truy cập một endpoint regional (HA cross-region). DNS automation tự tạo A record / private zone khi service attachment có domain name. Giải thích cơ chế và trade-off của từng cái.

Nội dung chính:

  • Endpoint là regional resource: ý nghĩa và giới hạn mặc định same-region
  • Global access: cơ chế --allow-psc-global-access, thuần consumer-side
  • HA pattern: nhiều endpoint regional + global access cho DR
  • DNS automation: khi service attachment khai báo domain, A record tự tạo
  • Service Directory namespace & private zone cho endpoint
  • Trade-off: global access và data residency/latency

7. Troubleshooting PSC ​

Playbook chẩn đoán. Năm connection state (ACCEPTED, PENDING, REJECTED, NEEDS_ATTENTION, CLOSED) và nguyên nhân từng cái; dùng Connectivity Tests để trace qua NAT; flow logs; và các failure mode kinh điển (NAT subnet cạn, vượt connection limit, sai region, accept list thiếu).

Nội dung chính:

  • Năm connection state và ý nghĩa từng trạng thái
  • Cây quyết định: PENDING do approval hay do vượt limit?
  • NAT subnet exhaustion: triệu chứng và cách phát hiện
  • Region mismatch: lỗi phổ biến nhất với người mới
  • Connectivity Tests cho PSC: trace endpoint → service attachment
  • Flow logs & metrics để quan sát traffic qua endpoint

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

References ​