題干與適用場景
你管理數百個 Kubernetes 叢集。v1.36 的核心元件提供 /statusz，預設返回人類可讀文字，並可透過顯式內容協商請求結構化 API。請設計採集、權限、版本相容、告警和故障隔離方案。假設部分叢集仍運行舊版本，且控制面端點不能暴露公網。
面試官考察點
面試官考察你能否區分健康探針、元件狀態和業務 SLO，設計多叢集採集的認證、限流、版本解析和降級。高品質回答還會處理敏感資訊、告警風暴、採集器故障和控制面本身不可達的情況。
回答前需要釐清的問題
- 需要的是存活判斷、依賴狀態，還是版本化診斷欄位？
- 採集器部署在每個叢集內，還是由中心控制面拉取？
- 哪些角色可以讀取 statusz，返回內容是否含內部拓撲或版本資訊？
- 異常發現目標是秒級告警，還是分鐘級容量與趨勢分析？
30 秒回答
「我會把 statusz 當診斷訊號，不把它直接當業務健康。叢集內採集器透過最小權限和私網存取端點，優先請求結構化版本並保留文字供人工排障；舊叢集走相容探針。中心平台按叢集、元件和版本聚合，做限流、快取和告警去重。控制面不可達時單獨標記採集鏈路故障，不能誤報為元件內部失敗。」
分步驟深入解答
1. 定義訊號與版本契約
記錄元件身份、版本、回應格式、檢查項和時間戳。結構化 API 的欄位按版本解析，未知欄位保留但不強依賴；文字只做展示和故障取證。把 statusz 與 /livez、/readyz 以及業務指標分層。
2. 設計採集拓撲
優先在叢集內運行輕量採集器，透過本地網路存取 API server、scheduler 和 controller manager。中心只接收脫敏後的狀態事件和聚合指標，避免把控制面端點暴露到公網。採集器本身要有佇列、退避和本地快取。
3. 處理認證與授權
為採集器建立唯讀、資源範圍最小的身份，限制可存取的元件端點和網路路徑。審計讀取者、頻率和回應大小；禁止復用管理員憑據。若欄位包含版本或拓撲資訊，按租戶與維運角色過濾。
4. 控制負載與失敗
設定每元件並發、逾時、快取和最大回應大小。控制面繁忙或不可達時退避，不反覆重試放大故障。區分元件報告失敗、HTTP 失敗、網路不可達和採集器自身積壓四類狀態。
5. 聚合與告警
按叢集、元件、版本和故障類型建立時間序列，使用事件指紋去重。告警需要連續窗口和影響範圍，例如多個元件同時異常或同版本叢集集中失敗；單次採集逾時只進入低優先級診斷。
6. 灰度與回滾
先在少量 v1.36 叢集啟用結構化採集，比較 API 負載、欄位穩定性、告警精度和採集延遲，再擴大範圍。發現欄位或負載問題時關閉新解析器，退回相容探針，保留原始回應和審計記錄。
高品質示範回答
我會把 statusz 作為控制面診斷訊號，與存活探針和業務 SLO 分層。每個叢集內的唯讀採集器透過私網存取元件端點，中心只接收脫敏狀態和聚合指標；舊版本使用相容探針。結構化回應按版本解析，未知欄位不阻斷採集，文字只用於人工取證。限制並發、逾時、快取和回應大小，區分元件失敗、網路失敗和採集器積壓。按事件指紋和連續窗口去重告警，先在少量 v1.36 叢集灰度，必要時關閉新解析器回退。
常見錯誤
- 把 statusz 當業務 SLO → 誤判使用者體驗 → 與業務指標分層。
- 中心直接存取公網端點 → 攻擊面擴大 → 叢集內採集、中心收狀態。
- 復用管理員憑據 → 越權讀取 → 建立最小唯讀身份。
- 未知欄位導致整條流水線失敗 → 升級即中斷 → 按版本寬鬆解析。
- 所有逾時都報警 → 告警風暴 → 區分採集鏈路與元件故障並去重。
追問及應對
為什麼還要保留文字回應？
結構化欄位適合機器聚合，文字便於值班人員快速閱讀和事故取證。兩者應來自同一端點，但用途不同。
控制面不可達時如何避免誤報？
把網路不可達、認證失敗、採集器積壓和元件報告失敗分開建模。只有有足夠證據時才升級元件故障告警。
如何支援舊版本叢集？
採集器先探測端點和版本，再選擇結構化解析、文字解析或相容探針；能力矩陣記錄可用欄位，不能假設所有叢集都支援 Beta 介面。
如何防止 statusz 採集本身拖慢 API server？
限制頻率和並發，使用快取與退避，設定回應大小上限，並在 API server 負載升高時自動降低採集頻率。