My Awesome Project

Appearance

Troubleshooting Private Service Connect ​

Tư Duy Chẩn Đoán PSC ​

PSC fail theo cách đặc trưng: âm thầm. Không có exception rõ ràng, endpoint vẫn tồn tại trong console, IP đã được cấp — nhưng traffic không đi. Lý do là PSC có nhiều tầng quyết định độc lập (Org Policy → IAM → connection state → NAT → region → DNS), và một tầng fail làm cả chuỗi đứt mà không phát tín hiệu rõ.

Vì vậy, chẩn đoán PSC không phải đọc một error message, mà là đi qua các tầng theo thứ tự và xác định tầng nào đứt. Công cụ trung tâm là connection state — nó cho biết bộ máy đang kẹt ở đâu. File này tổ chức quanh năm state đó, sau đó là các failure mode kinh điển và công cụ trace.

Năm Connection State — Bản Đồ Chẩn Đoán ​

Endpoint báo cáo năm trạng thái connection (About accessing published services through endpoints):

StateÝ nghĩaTraffic chảy?Hành động
ACCEPTEDProducer đã chấp nhận, config cho phépCóNếu vẫn lỗi → tầng dưới (firewall, DNS, backend)
PENDINGChưa thiết lập: cần approval hoặc vượt limitKhôngKiểm tra accept list & connection limit phía producer
REJECTEDBị chặn bởi org policy hoặc reject listKhôngKiểm tra reject list & org policy
NEEDS_ATTENTIONVấn đề phía producer; một phần traffic có thể không chảyMột phầnLiên hệ/kiểm tra phía producer
CLOSEDService attachment đã bị xóa (trạng thái cuối)KhôngEndpoint vô dụng; tạo lại khi producer publish lại

State đầu tiên cần đọc luôn là state này. Nó thu hẹp không gian lỗi ngay lập tức: PENDING → vấn đề approval/limit; REJECTED → vấn đề policy; ACCEPTED nhưng vẫn lỗi → vấn đề nằm dưới tầng PSC (network/DNS/backend).

CLOSED và NEEDS_ATTENTION — hai state hay bị bỏ qua ​

  • CLOSED là trạng thái cuối (terminal): khi producer xóa service attachment, mọi endpoint trỏ tới nó chuyển CLOSED và không thể hồi phục. Đây là tình huống thực tế khi một managed service instance bị xóa hoặc producer ngừng publish — endpoint của bạn trở thành "mồ côi". Cách xử lý: xóa endpoint CLOSED và tạo lại khi service attachment mới xuất hiện.
  • NEEDS_ATTENTION báo hiệu vấn đề phía producer, một phần traffic có thể không chảy. Consumer không tự sửa được — cần phối hợp với producer. Đây là state thường gặp với managed service khi có thay đổi/sự cố ở tenant project của Google.

Cây Quyết Định Cho PENDING — Lỗi #1 Của PSC ​

PENDING là triệu chứng phổ biến nhất, và như đã phân tích ở file 05, nó có hai nguyên nhân khác nhau cần hai cách sửa. Đây là cây quyết định:

Endpoint ở trạng thái PENDING
│
├─ Connection preference của service attachment là gì?
│   │
│   ├─ ACCEPT_AUTOMATIC → bất thường: nếu auto mà vẫn PENDING,
│   │      kiểm tra org policy / quota / NAT subnet đã cạn chưa
│   │
│   └─ ACCEPT_MANUAL → kiểm tra tiếp:
│        │
│        ├─ Consumer (project/network/endpoint URI) có trong accept list không?
│        │   ├─ KHÔNG → thêm vào accept list (đây là nguyên nhân)
│        │   └─ CÓ → kiểm tra tiếp:
│        │
│        └─ Consumer đã vượt CONNECTION LIMIT chưa?
│            ├─ RỒI → tăng limit hoặc xóa bớt connection cũ
│            └─ CHƯA → kiểm tra NAT subnet exhaustion (bên dưới)

Nhánh quan trọng nhất: đừng cho rằng PENDING luôn là "chưa được approve". Một consumer đã trong accept list nhưng vượt connection limit vẫn PENDING — thêm lại vào accept list không sửa được gì, phải tăng limit (About controlling access to published services).

Failure Mode 1: NAT Subnet Exhaustion ​

Cơ chế ​

Mỗi PSC connection tiêu thụ một IP từ NAT subnet của producer (Manage published services). Khi NAT subnet cạn IP, mọi connection mới fail — thường biểu hiện là endpoint mới mãi không ACCEPTED.

Triệu chứng & phát hiện ​

  • Connection mới stuck dù consumer đã trong accept list và chưa vượt connection limit cá nhân.
  • Phía producer: kiểm tra số IP đã dùng trong NAT subnet so với capacity. Nhớ công thức: /29 = 4 IP usable, /24 = 252 IP usable (trừ 4 IP không dùng được).
  • Đây là lỗi phía producer, nên consumer debug sẽ thấy "tôi làm đúng mọi thứ mà vẫn không kết nối được" — cần producer kiểm tra NAT subnet.

Xử lý ​

Producer mở rộng NAT subnet hoặc thêm NAT subnet mới vào service attachment. Đây là lý do capacity planning NAT subnet (file 01) phải làm từ đầu: thêm NAT subnet khi đã cạn là phản ứng sau sự cố, và việc resize subnet không phải lúc nào cũng đơn giản.

Failure Mode 2: Region Mismatch ​

Cơ chế ​

Endpoint trỏ tới service attachment phải cùng region với service attachment đó (About accessing published services through endpoints). Tạo endpoint ở us-west1 trỏ vào service attachment ở us-central1 sẽ không hoạt động.

Triệu chứng ​

Đây là lỗi của người mới phổ biến nhất. Endpoint có thể tạo được nhưng connection không thành công, hoặc API từ chối tạo. Lưu ý: đây khác với truy cập cross-region — nếu endpoint cùng region với service attachment nhưng client ở region khác muốn dùng, đó là bài toán global access (file 06), không phải region mismatch.

Xử lý ​

Tạo endpoint cùng region với service attachment. Nếu cần client ở region khác dùng, bật global access trên endpoint (đặt ở region của service attachment), không phải tạo endpoint ở region client.

Failure Mode 3: ACCEPTED Nhưng Traffic Vẫn Không Đi ​

Khi state là ACCEPTED mà vẫn lỗi, vấn đề nằm dưới tầng PSC. Kiểm tra theo thứ tự:

  1. Firewall của consumer. Egress rule từ client tới IP endpoint phải cho phép. Endpoint là internal IP trong VPC consumer — firewall egress vẫn áp dụng.
  2. DNS. Client có đang gọi đúng tên/IP không? Với managed service, kiểm tra DNS name phân giải về đúng IP endpoint (không hardcode IP cũ — xem file 04). Với Google APIs, kiểm tra client đã override endpoint sang *.p.googleapis.com chưa (file 03).
  3. Backend phía producer. Service attachment ACCEPTED không đảm bảo backend khỏe. Nếu ILB/backend của producer down, traffic tới được PSC nhưng không có ai trả lời. Đây là lúc NEEDS_ATTENTION có thể xuất hiện.
  4. PROXY protocol mismatch. Nếu producer bật PROXY protocol mà client không nói được, hoặc ngược lại, connection bị hỏng ở tầng ứng dụng dù PSC ACCEPTED.

Công Cụ Trace: Connectivity Tests ​

Connectivity Tests (trong Network Intelligence Center) là công cụ chính để trace đường đi qua PSC. Nó mô phỏng đường đi của packet từ source tới đích và cho biết bị chặn/đứt ở đâu, bao gồm cả việc trace qua PSC endpoint và NAT tới service attachment phía producer.

Cách dùng cho PSC:

  • Source: VM/IP của consumer. Destination: IP của PSC endpoint (hoặc service attachment).
  • Connectivity Tests sẽ thể hiện các bước: từ source → forwarding rule (endpoint) → PSC → phía producer, và chỉ ra nơi traffic bị drop (ví dụ firewall, hoặc connection chưa ACCEPTED).
  • Nó hữu ích đặc biệt khi state là ACCEPTED nhưng traffic không đi: test cho biết liệu vấn đề là firewall consumer, routing, hay phía producer.

Connectivity Tests là phân tích cấu hình (config-based), nên nó phát hiện được lỗi cấu hình (firewall, route, region) ngay cả khi chưa có traffic thật — rất hợp cho debug PSC nơi traffic fail âm thầm.

Công Cụ Trace: Flow Logs & Metrics ​

VPC Flow Logs ​

Bật VPC Flow Logs trên subnet chứa endpoint để xem traffic thật có rời client và tới endpoint không. Flow logs giúp phân biệt:

  • Traffic không rời client → vấn đề ở client/DNS (client không gọi endpoint IP).
  • Traffic tới endpoint nhưng không có return → vấn đề phía PSC/producer (connection chưa ACCEPTED, backend down).

(Chi tiết flow logs ở Chương 3.)

PSC Metrics ​

PSC expose metrics trong Cloud Monitoring để quan sát sức khỏe connection, ví dụ:

  • Số byte/packet đi qua endpoint (consumer side) — xác nhận traffic thực sự chảy.
  • Trạng thái connection của service attachment (producer side).
  • Số connection đang dùng so với NAT subnet capacity — cảnh báo sớm NAT exhaustion.

Đặt alert trên NAT subnet usage và trên trạng thái connection là cách chủ động phát hiện vấn đề trước khi consumer phàn nàn.

Quy Trình Chẩn Đoán Tổng Hợp (Runbook) ​

Khi một PSC connection không hoạt động, đi theo thứ tự sau để không bỏ sót tầng:

  1. Đọc connection state. ACCEPTED / PENDING / REJECTED / NEEDS_ATTENTION / CLOSED — đây là điểm vào.
  2. PENDING → chạy cây quyết định: accept list? connection limit? NAT exhaustion?
  3. REJECTED → kiểm tra reject list và org policy (compute.disablePrivateServiceConnectCreationForConsumers).
  4. CLOSED → service attachment đã bị xóa; tạo lại endpoint khi producer publish lại.
  5. NEEDS_ATTENTION → vấn đề phía producer; với managed service, kiểm tra trạng thái instance/service.
  6. ACCEPTED nhưng lỗi → kiểm tra theo thứ tự: region match → firewall consumer → DNS (đúng tên/IP, đúng endpoint override) → backend producer → PROXY protocol.
  7. Dùng Connectivity Tests để xác nhận đường đi và định vị điểm drop.
  8. Dùng Flow Logs + Metrics để xác nhận traffic thực tế và phát hiện NAT exhaustion.

Nguyên tắc xuyên suốt: PSC fail âm thầm, nên không đoán — đọc state, đi theo tầng, dùng công cụ trace để xác nhận từng giả thuyết.

References ​