題干與適用場景
平台團隊維護共享 Kubernetes 叢集，應用團隊部署 gRPC 服務。平台要求統一入口、TLS 終止、依 service/method/header 路由並支援灰度發布；應用團隊只能修改自己的 Route，不能接管基礎設施或存取其他命名空間。請設計資源模型、請求路徑、授權邊界、可觀測性和失敗回退。
假設 Gateway API 控制器已安裝，後端服務使用 HTTP/2 gRPC，客戶端需要明確的逾時和重試策略。回答重點是跨團隊控制面的職責分離，不綁定特定 Gateway 實作。
面試官考察點
- 是否能拆分 GatewayClass、Gateway、GRPCRoute 和 Service 的責任。
- 是否理解 GRPCRoute 的匹配粒度與 HTTPRoute 差異，而非只寫一段 YAML。
- 是否處理跨命名空間 ReferenceGrant、RBAC、預設拒絕和稽核。
- 是否說明灰度權重、長連線、串流 RPC 與重試風險。
- 是否設計狀態觀測、回滾條件和控制器/資料面故障路徑。
回答前需要釐清的問題
- Gateway 由平台集中管理還是各團隊獨立擁有？這決定 Route 的 attach 權限和變更審批。
- 路由依 service、method、header 還是 hostname 區分？匹配優先級不同會改變規則衝突處理。
- RPC 是 unary 還是長時間 streaming？streaming 通常不適合依請求重試或中途切流。
- 灰度依請求比例、租戶、header 還是客戶端版本？需要定義權重、黏性和回滾訊號。
- 後端 Service 是否跨命名空間，是否允許跨叢集故障轉移？這會引入 ReferenceGrant 和額外健康檢查。
30 秒回答框架
我先把平台擁有的 Gateway 與應用擁有的 GRPCRoute 分開，Service 作為後端發現邊界。Route 只宣告 gRPC 方法和 metadata 匹配，跨命名空間引用必須經過明確授權。控制器把有效狀態和引用錯誤寫入可觀測條件，資料面按權重轉送並對 streaming 禁止盲目重試。灰度先從單一租戶或 header 開始，以錯誤率、尾延遲和業務指標作為回滾門檻，Route 無效或後端不健康時回到穩定版本。
分步驟深入解答
1. 資源職責與資料流
平台建立 GatewayClass 選擇控制器，再建立監聽器、位址和 TLS 策略。應用團隊在自己的命名空間建立 GRPCRoute，透過 parentRefs 掛到允許的 Gateway，並把規則指向自己的 Service。請求進入 Gateway 後，控制器產生資料面配置，依 hostname、gRPC service、method 和 headers 選擇 backendRefs。
2. 匹配與衝突處理
先定義精確匹配和預設匹配的優先級，例如完整 service/method 優先於僅 service，再優先於 header 兜底。禁止兩個團隊對同一 parent 和相同匹配條件產生隱式覆蓋；衝突應在 Accepted、ResolvedRefs 等狀態條件中暴露，並由 CI 檢查 Route 狀態。對未知 method，選擇明確的 UNIMPLEMENTED 或穩定後端回退，不能靜默轉送到任意服務。
3. 多租戶授權
應用只能寫自己的 Route 和 Service。Gateway 的 allowedRoutes 限制可 attach 的命名空間；跨命名空間 backendRef 需要 ReferenceGrant，且授權物件由目標命名空間擁有者批准。RBAC、Admission Policy 和 Git 審核共同阻止團隊修改平台 TLS、監聽器和他人的授權。稽核記錄應包含誰改變了 parent、backendRef 和權重。
4. 灰度、長連線與重試
unary RPC 可以按權重把新請求分到 stable/canary；streaming RPC 建立連線後，權重不會在中途重新計算。不要對非冪等 unary 呼叫自動重試，也不要在客戶端逾時不明時疊加 Gateway 重試。灰度鍵可以是明確 header 或租戶名單，避免隨機比例讓同一租戶在除錯時漂移。權重改變應小步提交，並記錄生效時間。
5. 健康、狀態與故障回退
資料面需要 gRPC health checking、連線池和明確的 per-route timeout。控制器不可用時，已下發配置應繼續服務但不能接受新的未驗證變更；Gateway 不可接受、引用無法解析或後端沒有可用端點時，狀態應讓發布系統阻斷。回滾可把權重歸零、恢復上一版本 Route，或切換到備用 Gateway；回滾動作必須冪等。
6. 可觀測性與容量邊界
依 route、service、method、status code、租戶和版本記錄請求數、錯誤率、P50/P95/P99 延遲、active streams、重試次數和連線耗時。高基數原始 metadata 不應直接作為指標標籤，可在日誌中取樣並脫敏。容量評估要涵蓋連線數、stream 並發、TLS CPU、控制器推送延遲和單個後端最大連線數；壓測 unary 與 streaming 兩種形態。
高品質示範回答
我會先確認平台團隊擁有 GatewayClass、Gateway 和監聽器，應用團隊只擁有本命名空間的 GRPCRoute 與 Service。GRPCRoute 依 service/method 和受控 header 匹配 backendRefs；跨命名空間引用需要目標方建立 ReferenceGrant，Gateway 的 allowedRoutes 和 RBAC 再限制 attach 範圍。
發布時我把 unary 請求依權重切到 stable 與 canary，streaming 連線只在建立時選路，不做中途切流。對非冪等呼叫不自動重試，逾時和重試預算由客戶端與 Gateway 協同。控制器持續暴露 Route 的 Accepted、ResolvedRefs 和後端健康狀態；CI 發現無效引用或衝突就阻斷發布。灰度從單租戶或明確 header 開始，以方法級錯誤率、尾延遲、active streams 和業務成功率觸發回滾，恢復上一版權重並保留稽核記錄。
常見錯誤
把 GRPCRoute 當作普通 Ingress
忽略 service/method 和 HTTP/2 語意會導致規則過寬；修正方法是先定義匹配優先級與未知 method 行為。
允許應用直接修改 Gateway
共享監聽器和 TLS 會被越權改動；修正方法是用 allowedRoutes、RBAC、ReferenceGrant 和 Admission Policy 分層授權。
對 streaming RPC 盲目重試或切流
會重複副作用或截斷長連線；修正方法是區分 unary/streaming，依冪等性和連線生命週期制定策略。
只看控制器部署成功
控制器成功不等於 Route 被接受或後端有端點；修正方法是檢查 Accepted、ResolvedRefs、健康狀態和資料面指標。
追問及應對
追問一：兩個 Route 匹配同一個 method 怎麼辦？
禁止依賴實作方的隱式順序。用 namespace/parent attach 策略限制所有權，在 CI 檢查衝突，並把不可解析狀態作為發布失敗條件。
追問二：canary 版本只對某個租戶開放，如何保持穩定？
用明確租戶或 header 匹配，避免隨機權重造成同一租戶漂移；同時記錄版本和租戶維度錯誤率，回滾時先撤銷該匹配。
追問三：Gateway 控制器宕機會中斷流量嗎？
取決於資料面是否保留最近有效配置。設計上讓已下發配置繼續服務，但凍結新變更，並監控配置年齡；超過安全期限則切到備用控制器或 Gateway。
追問四：跨命名空間 backendRef 為什麼需要額外授權？
它會讓一個團隊把流量指向另一個團隊的 Service。ReferenceGrant 把同意權交給目標命名空間擁有者，配合 RBAC 和稽核可防止隱式越權。