Kubernetes 混合版本代理如何保障控制面升級期間的 API 相容？
題幹與適用場景
在一個多可用區 Kubernetes 叢集中，控制面需要從 v1.35 滾動升級到 v1.36。升級窗口內，不同 kube-apiserver 可能認識不同的資源版本，客戶端請求某個 API 伺服器時可能得到誤導性的 404。請設計並解釋 Mixed Version Proxy（混合版本代理）如何路由請求、限制安全邊界、觀測效果並支援回滾。回答要區分 Kubernetes v1.36 的 Beta 行為與傳統版本偏差策略。
面試官考察點
- 是否能把版本偏差、發現快取和 API 可見性拆成獨立故障域。
- 是否理解代理只處理資源請求，不能取代 API 版本轉換或儲存遷移。
- 是否能說明對等 API 伺服器發現、轉發、身分透傳和循環避免。
- 是否把升級安全、稽核、逾時、重試和回滾納入整體設計。
回答前需要釐清的問題
- 升級是同一叢集內的滾動替換，還是跨叢集遷移？這裡按同一叢集、多個對等 API 伺服器處理。
- 客戶端主要使用 Kubernetes 原生資源，還是包含聚合 API 伺服器和 CRD？代理對未知資源版本的涵蓋範圍需要單獨確認。
- 控制面是否啟用統一負載平衡、mTLS、稽核與集中指標？這些決定身分透傳和故障定位方案。
- 允許的額外延遲、不可用窗口和回滾時間分別是多少？
30 秒回答框架
先說明問題：滾動升級時，請求落到舊 API 伺服器會把「新版本資源」誤判為不存在。然後給出路徑：入口 API 伺服器做發現與本地判定，若資源版本未知則把請求轉發給相容的對等 API 伺服器；回應、狀態碼和稽核身分返回給原請求方。最後補上邊界：依賴版本偏差策略、禁止循環代理、限制代理身分、對轉發失敗使用明確錯誤，不用重試掩蓋控制面故障，並透過指標與灰度開關回滾。
分步驟深入解答
1. 請求分類與轉發決策
API 伺服器先解析請求的 group、version、resource 和動詞。若本地已註冊該資源，直接走本地驗證、授權、准入和儲存路徑；若請求版本在本地發現資訊中未知，則查詢對等 API 伺服器的可用版本。只有對等方明確支援該資源版本時才轉發，否則返回可區分的錯誤。代理不猜測版本，也不把普通業務 404 改寫成轉發。
2. 對等發現、身分與循環控制
對等 API 伺服器應來自受控的控制面成員列表或安全的內部發現機制，連線使用叢集既有的服務身分與加密通道。轉發請求攜帶原始使用者身分、群組、授權標頭和稽核上下文，但代理本身仍需執行本地授權邊界。請求增加 hop 標記或等價的內部中繼資料；看到已代理標記時禁止再次轉發，避免 A 到 B 再回 A 的循環。
3. 一致性與失敗處理
資源讀取可能在不同 API 伺服器間看到短暫不同的發現快取，因此客戶端應以伺服器返回的資源版本和 resourceVersion 為準。轉發只在目標伺服器可用且版本相容時發生；連線逾時、目標拒絕或回應版本不匹配都應快速失敗並記錄原因。對寫請求避免無界重試，防止重複建立或更新；需要重試時依賴冪等鍵或客戶端的明確重試策略。
4. 發布、觀測與回滾
先在非高峰期升級一個 API 伺服器，觀察代理命中率、轉發延遲、未知版本錯誤、5xx、稽核完整性和發現收斂時間，再擴大批次。v1.36 中 Mixed Version Proxy 進入 Beta 並預設啟用，但仍應結合版本偏差策略和發行版支援矩陣驗證。出現異常時停止後續替換、將流量固定到已知相容節點，必要時關閉特性閘並回滾控制面；保留轉發鏈路與原始身分的稽核記錄。
高品質示範回答
我會把 Mixed Version Proxy 當作升級期間的控制面相容層，而不是新的 API 閘道。入口伺服器先完成驗證、授權和准入前的請求分類；本地認識的資源走本地路徑，只有本地發現未知但對等伺服器明確支援的資源才轉發。轉發連線使用控制面已有的安全身分，透傳原使用者和稽核上下文，並設定單跳標記防止循環。對等伺服器返回的狀態碼和回應體要保留語義，逾時或版本不匹配立即失敗，寫請求不做無界自動重試。
我會用灰度升級驗證這條鏈路：記錄本地命中、代理命中、目標版本、延遲、錯誤類型和稽核關聯 ID；當命中率或 5xx 超過門檻時暫停替換並把流量留在相容節點。v1.36 的 Beta 預設開啟不等於可以跳過發行版驗證，我仍會檢查版本偏差策略、聚合 API 和 CRD 的適用範圍。回滾包括停止升級、恢復控制面成員、關閉特性閘（如果發行版允許）和核對發現快取，確保客戶端不會繼續使用過期能力。
常見錯誤
- 把代理描述成任意 API 版本轉換器，忽略它主要解決未知資源版本的路由問題。
- 只說「轉發到新節點」，沒有說明對等發現、身分透傳和循環保護。
- 對所有 404 都轉發，導致真實的資源不存在被放大成控制面流量。
- 對寫請求進行無條件重試，造成重複副作用。
- 只看平均延遲，遺漏發現收斂、稽核完整性和版本偏差約束。
追問及應對
追問一：聚合 API 伺服器或 CRD 也能自動代理嗎？
先確認該資源是否屬於 Mixed Version Proxy 的實作範圍。聚合 API 伺服器有獨立的發現、驗證和可用性邊界，不能因為主 API 伺服器能代理原生資源就推斷它也能代理。回答中應給出能力矩陣和明確的「不支援時快速失敗」路徑。
追問二：如何防止轉發放大控制面故障？
設定單跳、逾時、並發上限和熔斷；轉發失敗不回源無限重試。把代理命中率、目標錯誤和排隊長度納入告警，並在升級控制器中設定批次暫停條件。
追問三：客戶端發現快取過期怎麼辦？
客戶端仍需遵守 Kubernetes 的發現與版本偏差策略。伺服器端代理只能降低滾動升級期間的錯誤 404，不能替客戶端永久快取新資源，也不能取代 API 資源的版本遷移。必要時讓客戶端重新發現並使用明確的 API 版本。