如何設計 Kubernetes 多可用區的 Topology Aware Routing？

題目與背景

一個三可用區 Kubernetes 叢集執行跨區存取成本較高的服務。團隊希望請求優先發送到來源區的 Pod，同時在某區容量不足、流量傾斜或節點故障時保持可用。請設計 Topology Aware Routing 的啟用、端點分布、回退、觀測與回滾。

面試官考察什麼

• 能否區分 EndpointSlice hints、kube-proxy 消費邏輯和 Service 的流量策略。
• 能否識別「每區至少三個端點」和流量來源均衡等前提，而不是假設同區永遠更好。
• 能否設計無 hints 時的全域回退、故障保護和熱點監控。
• 能否量化跨區成本、延遲、端點負載與發布風險。

先問清楚的澄清問題

流量與目標

請求來源是否均勻分布在各區？目標是降低 p95 延遲、跨區流量成本，還是滿足資料駐留？跨區存取是否比返回錯誤更可接受？

端點與擴縮容

每個 zone 有多少 ready Pod？擴縮容、滾動發布和 PodDisruptionBudget 是否會暫時低於安全端點數？Service 是否有本地節點流量需求？

故障與觀測

故障域是 zone、節點還是網路？如何發現某區端點過載、hints 缺失或 kube-proxy 回退？是否允許按服務逐步啟用？

30 秒回答框架

我會先確認來源流量和端點分布滿足同區路由前提，再透過 EndpointSlice hints 或 Service 的流量分布設定逐步啟用。控制面在端點不足、區域不均或條件不滿足時回退到全域端點，確保可用性。監控跨區位元組、p95 延遲、每區請求和端點負載，canary 驗證後擴大範圍；發現熱點或故障就關閉 hints，恢復全域路由。

深入解答步驟

1. 明確控制面與資料面

EndpointSlice controller 根據端點拓撲產生 hints，kube-proxy 等元件消費 hints 影響流量選擇。Topology Aware Routing 的目標是偏好來源區端點，不保證所有請求都嚴格同區。系統設計應把控制面計算、EndpointSlice 傳播和節點資料面行為分開觀測。

2. 檢查啟用前提

官方文件建議每個 zone 至少有三個端點；在三可用區叢集通常意味著至少九個端點，端點不足時控制器可能不產生 hints。來源流量嚴重集中在單一區域也可能把該區端點壓滿，因此先用歷史流量和容量資料驗證假設。

3. 選擇設定方式

可以使用 Service 的 topology mode 或相關 trafficDistribution 能力表達偏好。示例設定應與目標 Kubernetes 版本匹配：

apiVersion: v1
kind: Service
metadata:
  name: checkout
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: checkout
  ports:
    - port: 443
      targetPort: 8443

不要混用舊的 topology-aware-hints 註解、目前 topology-mode 和版本特定欄位；發布前確認 API 版本、feature gate 和 kube-proxy 行為。

4. 設計安全回退

控制面或 kube-proxy 在端點不足、hints 無效或分配不安全時應使用叢集範圍端點。回退路徑必須可觀測，不能靜默把跨區流量誤判成同區優化成功。故障演練覆蓋整區失聯、EndpointSlice 延遲、節點標籤錯誤和 kube-proxy 版本不一致。

5. 防止熱點與不均衡

同區偏好會縮小候選端點集合。按 zone 統計請求數、連線數、CPU、佇列和錯誤率；當某區來源比例過高或端點數偏少時，降低同區偏好或暫時回退。擴縮容與滾動發布必須保持每區 ready 端點和 PDB 餘量。

6. 評估成本與延遲

同時記錄跨區流量位元組、請求 p50/p95/p99、連線重用、端點負載和失敗率。用同一流量視窗比較啟用前後，避免把快取命中或客戶端重試變化歸因於拓撲路由。成本下降不能以錯誤率和尾延遲惡化為代價。

7. 分階段發布與回滾

先在非關鍵 Service 或單一區域 canary 啟用，驗證 EndpointSlice hints、kube-proxy 選擇和回退事件，再擴大到同類服務。回滾只需移除偏好設定並確認全域端點恢復；保留設定版本、指標視窗和故障演練記錄。

高品質示例回答

我會把拓撲偏好當作可回退的效能優化。先確認每區端點和來源流量足以避免熱點，再讓 EndpointSlice controller 產生 hints，由節點資料面消費。端點不足、區域失衡或元件不相容時自動回到全域端點。監控跨區位元組、每區負載、延遲、錯誤率和回退次數，先 canary 後擴展；任何區過載或故障都透過關閉偏好恢復可用性。

常見錯誤

• 假設 hints 存在就一定嚴格同區路由。
• 忽略每區端點數量和來源流量均衡的前提。
• 只看跨區成本，不看某區端點過載和尾延遲。
• 把舊註解、版本欄位和 feature gate 當成通用 API。
• 沒有無 hints 時的全域回退和演練。
• 發布或縮容時讓某區 ready 端點低於安全餘量。

追問與回答

為什麼端點不足時要回退？

拓撲偏好會縮小候選集合；端點太少會增加單點過載和故障風險。回退到全域端點能優先保持可用性。

三個端點是硬規則嗎？

這是官方文件給出的適用建議，用於讓每區分配更均衡，並非所有工作負載的絕對保證。應結合流量、容量和故障目標驗證。

如果所有請求都來自一個 zone 呢？

同區偏好可能把壓力集中到該區。應降低偏好、增加該區端點或回退全域路由，並用負載和延遲指標確認選擇。

如何驗證 kube-proxy 真的消費了 hints？

檢查 EndpointSlice 的 hints、節點元件版本和實際請求分布；用跨區位元組與每區端點命中率做端到端驗證，不能只看控制面物件。

回滾是否需要重建 Service？

通常只需移除或調整拓撲偏好設定，並確認 EndpointSlice 與節點資料面恢復全域選擇；仍要保留一次回滾演練和指標證據。