My Awesome Project

Appearance

PSC cho Managed Services & GKE Control Plane ​

Tại Sao Đây Là File "Bạn Gặp PSC Hằng Ngày Mà Không Biết" ​

Phần lớn engineer lần đầu chạm vào PSC không phải qua việc tự publish service, mà qua việc consume một managed service: tạo một Cloud SQL instance với Private Service Connect, hoặc nhìn thấy một forwarding rule lạ xuất hiện khi tạo GKE cluster. Đây là nơi PSC ngừng là lý thuyết và trở thành thứ bạn phải hiểu để vận hành production.

Điểm bản chất xuyên suốt file này: với managed service, producer chính là Google — cụ thể là một tenant project do Google quản lý, nằm ngoài tổ chức của bạn. Service attachment được Google tạo tự động; bạn (consumer) chỉ tạo endpoint. Hiểu được mô hình tenant project này giải thích vì sao bạn không thấy ILB hay backend của managed service trong project mình, vì sao connection có thể stuck PENDING, và vì sao DNS lại quan trọng đến vậy.

Internal Model: Tenant Project Là Producer ​

Mô hình tenant project ​

Khi bạn tạo một managed service (Cloud SQL, Memorystore, AlloyDB), Google không chạy instance đó trong project của bạn. Nó chạy trong một tenant project (còn gọi là service producer project) do Google sở hữu và quản lý, vô hình với bạn. Trong tenant project đó, Google dựng:

  • Instance thật (database engine, Redis...).
  • Một internal load balancer đứng trước instance.
  • Một service attachment trỏ tới ILB đó.

Bạn — phía consumer — chỉ tương tác với service attachment qua một endpoint trong VPC của mình. Toàn bộ phần phía sau service attachment (ILB, instance, networking của Google) là hộp đen.

Đây chính xác là mô hình producer–consumer ở file 01, chỉ khác là producer không phải bạn mà là Google. Vì vậy mọi nguyên lý — NAT, region affinity, accept list, connection limit — vẫn áp dụng, nhưng phía producer được Google tự động hóa.

Hai con đường tạo endpoint: tự động vs thủ công ​

Với managed service, có hai cách endpoint được tạo:

  1. Thủ công (manual): bạn reserve một internal IP, rồi tạo endpoint trỏ tới service attachment URI mà managed service cung cấp. Bạn kiểm soát hoàn toàn.

  2. Tự động (automatic) qua Service Connection Policy: bạn tạo trước một service connection policy trong VPC, khai báo subnet nào được dùng để cấp IP cho PSC endpoint của một class service nhất định. Khi tạo instance với tham số auto-connect, managed service tự tìm policy và tự tạo endpoint trỏ về service attachment của instance (Cloud SQL with Private Service Connect).

Service connection policy là một khái niệm quan trọng cần nắm: nó là cách consumer "ủy quyền trước" cho managed service tự tạo endpoint trong một subnet được chỉ định, thay vì phải tạo thủ công cho từng instance. Ở scale (hàng trăm instance), automatic + service connection policy là pattern bắt buộc.

Cloud SQL Với Private Service Connect ​

Cloud SQL là ví dụ điển hình nhất để nắm mô hình.

Cơ chế ​

Khi bạn tạo Cloud SQL instance với PSC enabled, "Cloud SQL tự động tạo một service attachment cho instance" — service attachment này là "điểm gắn mà các VPC network dùng để truy cập instance" (Cloud SQL with Private Service Connect).

Để một VPC kết nối được, project của VPC đó phải nằm trong danh sách allowed projects của instance. Đây chính là accept list (file 05) nhưng được expose qua Cloud SQL API dưới tên "allowed consumer projects". Endpoint từ project không nằm trong danh sách sẽ ở trạng thái PENDING (Cloud SQL with Private Service Connect).

DNS: vì sao dùng tên thay vì IP ​

Cloud SQL khuyến nghị mạnh dùng DNS name thay vì IP, vì "các network khác nhau kết nối tới cùng một instance, và PSC endpoint ở mỗi network có thể có IP khác nhau" (Cloud SQL with Private Service Connect). Điều này phản ánh đúng cơ chế PSC: cùng một service attachment, nhiều consumer, mỗi consumer chọn IP endpoint riêng trong VPC mình. Hardcode IP là anti-pattern vì IP đó chỉ đúng trong một VPC.

Cloud SQL cung cấp hai loại DNS name:

  • Per-instance DNS name (mọi edition): tên riêng cho từng instance.
  • Global write endpoint DNS name (Enterprise Plus): phục vụ disaster recovery, trỏ về instance đang là primary, hỗ trợ failover/switchover region.

Ràng buộc Cloud SQL PSC ​

Một số constraint bản chất cần nhớ (Cloud SQL with Private Service Connect):

  • Cần role compute.networkAdmin để tạo endpoint.
  • Không transitive từ peered VPC — mỗi VPC cần endpoint riêng.
  • Một instance không thể đồng thời dùng private services access (VPC peering kiểu cũ) và Private Service Connect.

Điểm cuối đặc biệt quan trọng khi migrate: bạn không thể bật PSC trên một instance đang dùng private services access; phải tạo instance mới hoặc theo quy trình migration của Cloud SQL.

Memorystore & AlloyDB: Cùng Pattern, Khác Tiểu Tiết ​

Memorystore (Redis/Valkey/Memcached) và AlloyDB tuân theo cùng mô hình tenant project + service attachment + endpoint. Khác biệt chủ yếu ở mức độ tự động hóa và đối tượng:

  • AlloyDB dùng PSC cho cả kết nối tới instance lẫn các tính năng như cross-region replica. Service attachment được tạo per-instance, consumer dùng service connection policy để auto-tạo endpoint.
  • Memorystore (đặc biệt các thế hệ cluster mới) dùng PSC làm phương thức kết nối chính, thay cho mô hình private services access cũ. Mỗi node/instance được expose qua endpoint trong consumer VPC.

Mental model để không bị lạc giữa các sản phẩm: đừng học từng managed service như một cơ chế riêng. Tất cả đều là cùng một bộ máy PSC — producer là tenant project của Google, service attachment auto-created, bạn tạo endpoint (thủ công hoặc qua service connection policy), và DNS giúp bạn không phụ thuộc IP cụ thể. Khi đã nắm khung này, mỗi managed service mới chỉ là một cấu hình quen thuộc.

GKE Control Plane Qua PSC — Phân Tích Sâu ​

Đây là ứng dụng PSC quan trọng và ít được hiểu đúng nhất, vì nó hoàn toàn ẩn dưới abstraction của GKE.

Vấn đề: control plane sống ở đâu ​

Control plane của GKE (API server, etcd, scheduler...) không chạy trong project của bạn — nó chạy trong một Google-managed project (xem Chương 5). Node của bạn (trong VPC của bạn) phải nói chuyện với control plane đó. Câu hỏi: kết nối private giữa hai network khác chủ này thực hiện thế nào?

Mô hình cũ: VPC Peering ​

Trước đây, GKE dùng VPC Network Peering giữa VPC của bạn và VPC chứa control plane. Điều này hoạt động, nhưng kế thừa mọi giới hạn của peering (xem file 02) — đặc biệt là giới hạn số cluster: chỉ 75 cluster per zone/region dùng VPC peering, vì mỗi cluster tốn một peering slot (About Private Service Connect — GKE).

Mô hình mới: PSC-based connectivity ​

Từ GKE 1.23 trở đi, mọi cluster public tạo từ ngày 15/03/2022 dùng hạ tầng PSC để control plane và node giao tiếp. Cơ chế (About Private Service Connect — GKE):

  • Control plane (trong Google-managed project) publish một service attachment.
  • Trong VPC của bạn, GKE tạo một internal PSC endpoint — đây chính là forwarding rule mà bạn thấy xuất hiện. Node dùng endpoint này để gọi API server.
  • "Google Cloud gán một internal IP cho control plane để forward request tới GKE management API" — toàn bộ traffic node ↔ control plane đi bằng internal IP, không bao giờ qua internet public.

Cluster có hai endpoint cho control plane:

  • Internal endpoint (PSC endpoint trong VPC bạn) — dùng cho giao tiếp nội bộ cluster.
  • External endpoint (tùy chọn) — có thể tắt để giới hạn truy cập chỉ qua IP nội bộ.

Vì sao PSC mở khóa 1000 cluster ​

Vì PSC không tốn peering slot và không trao đổi route (xem cơ chế ở file 02), giới hạn cluster nhảy từ 75 lên 1000 per network với PSC (About Private Service Connect — GKE). Đây là minh họa thực tế đắt giá nhất cho luận điểm "PSC scale tốt hơn peering vì không tiêu tốn route/peering resource". Một platform team chạy hàng trăm cluster cho nhiều team không thể làm được với peering — PSC là điều kiện kỹ thuật để mô hình đó tồn tại.

DNS-based endpoint và authorized networks ​

GKE hỗ trợ truy cập control plane qua DNS-based endpoint (khuyến nghị) hoặc IP-based endpoint. Với IP-based endpoint, authorized networks giới hạn IP nào được gọi control plane, và có thể chặn cả Cloud VM, Cloud Run, external IP (About Private Service Connect — GKE). Một điểm linh hoạt quan trọng: các thiết lập isolation (DNS vs IP endpoint, node dùng internal/external IP) có thể đổi sau khi tạo cluster mà không cần tạo lại cluster.

Constraint đặc thù: webhook URL nội bộ ​

Giới hạn chính của internal control plane endpoint: không hỗ trợ webhook URL kiểu IP-based nội bộ. Để admission webhook hoạt động, bạn phải tạo headless Service + Endpoints tương ứng để redirect traffic webhook (About Private Service Connect — GKE). Đây là một gotcha thực tế khi chạy mutating/validating webhook (xem Chương 10) trên private cluster PSC.

Pattern: Centralized Connectivity Cho Managed Services Ở Scale ​

Một bài toán thực tế: tổ chức có hàng chục VPC (mỗi team một VPC) và nhiều Cloud SQL instance dùng chung. Tạo endpoint thủ công cho từng cặp (VPC × instance) là không khả thi.

Cách đúng dựa trên cơ chế đã học:

  • Dùng service connection policy trong mỗi consumer VPC, chỉ định subnet cấp IP cho PSC endpoint. Khi tạo instance với auto-connect, endpoint tự sinh.
  • Dùng DNS name của Cloud SQL (không hardcode IP), để cùng một connection string hoạt động ở mọi VPC dù IP endpoint khác nhau.
  • Quản lý allowed projects ở phía instance như một danh sách kiểm soát truy cập tập trung.

Bài học cơ chế: vì mỗi consumer VPC có endpoint với IP riêng nhưng cùng trỏ về một service attachment, DNS abstraction là thứ giữ cho kiến trúc không vỡ khi số VPC tăng. Không có DNS, bạn sẽ chôn mình trong việc quản lý IP per-VPC.

Anti-Pattern: Hardcode IP Của PSC Endpoint Vào Connection String ​

Vì sao sai về cơ chế: PSC endpoint IP là local trong từng consumer VPC. Cùng một Cloud SQL instance được truy cập từ 3 VPC sẽ có 3 endpoint với 3 IP khác nhau. Hardcode một IP cụ thể nghĩa là connection string chỉ đúng trong đúng một VPC, và sẽ vỡ khi (a) app chạy ở VPC khác, (b) endpoint được tạo lại với IP mới, hoặc (c) failover region.

Hệ quả ở scale: mỗi lần thay đổi topology (thêm VPC, DR failover), bạn phải sửa connection string ở nhiều nơi — một nguồn outage cổ điển. Với global write endpoint của Cloud SQL Enterprise Plus, hardcode IP làm mất hoàn toàn khả năng DR tự động.

Cách đúng: luôn dùng DNS name do managed service cung cấp. DNS giải quyết đúng IP endpoint theo từng VPC, và theo dõi failover tự động.

References ​