系統設計面試：如何遷移 Kubernetes KMS v2 並證明 Secret 已加密？
題干與適用場景
平台團隊需要保護 etcd 中的 Secret。叢集有多個 kube-apiserver、外部 KMS 外掛和大量歷史物件，且不能在遷移時停止發布。請設計配置變更、金鑰輪換、存量重寫、驗證、監控和回滾。
面試官考察點
- 是否理解 KMS v2 的信封加密邊界和 DEK/KEK 關係。
- 是否區分「新寫入加密」與「歷史物件已經重寫」。
- 是否能處理多個 apiserver、KMS 不可用、輪換和並行更新。
- 是否用 etcd 取證與 API 讀回證明結果，而非只看配置檔。
回答前需要釐清的問題
- 目前 Kubernetes 版本、KMS 外掛版本和高可用拓撲是什麼？
- 需要保護哪些資源，是否包含自訂資源和稽核日誌？
- 外部 KMS 的可用性、延遲、金鑰輪換與災備承諾是什麼？
- 允許的控制面發布窗口、回滾期限和合規證據格式是什麼？
30 秒回答框架
先在非生產叢集驗證 KMS v2 外掛和權限，再把 KMS 設為首選 provider、保留舊 provider 作讀取回退，滾動更新每個 kube-apiserver。新寫入會加密，但歷史物件必須逐個無操作更新或用儲存版本遷移重寫。驗證包括 API 讀回、etcd 前綴取證、KMS 指標、故障演練和稽核記錄。確認所有物件完成重寫後才移除舊 provider，並保留可稽核的回滾窗口。
分步驟深入解答
1. 釐清加密模型
Kubernetes 使用信封加密：資料加密金鑰（DEK）加密資源，金鑰加密金鑰（KEK）由外部 KMS 保護。KMS v2 透過服務端快取和每個 API server 的 DEK 設計降低請求開銷，但不等於 etcd 自動重寫所有舊資料。
2. 先驗證外掛和權限
在隔離叢集測試 socket、身分、逾時、重啟和 KMS 不可用行為。確認 kube-apiserver 能解密舊 provider 寫入的物件，也能用新 provider 寫入新 Secret。記錄延遲、錯誤、快取命中和 KMS 呼叫量。
providers:
- kms:
apiVersion: v2
name: external-kms
endpoint: unix:///var/run/kms/plugin.sock
- aescbc:
keys:
- name: old-key
secret: <base64-secret>3. 高可用滾動切換
先把新 KMS provider 放在配置首位，保留舊 provider 讀取回退，再逐個重啟 kube-apiserver。每一步確認 API 讀寫、與 leader 無關的並發請求和稽核輸出，避免同時重啟全部控制面。配置檔和外掛版本必須可回滾。
4. 重寫存量物件
只切換 provider 只影響後續寫入。對 Secret 及其他受保護資源執行分批無操作更新，或使用儲存版本遷移工具觸發重寫；遇到衝突要重試。按命名空間分片、限速並記錄物件版本，防止一次性更新壓垮 API server、etcd 或 KMS。
5. 驗證加密證據
建立新 Secret 後從 etcd 讀取原始位元組，確認以 KMS v2 加密前綴儲存；再透過 API 讀取並比較明文。抽樣舊物件和每類資源，統計尚未重寫數量。API 讀回成功不能單獨證明磁碟上的值已加密。
6. 輪換、故障和回滾
輪換 KEK 後保持舊 KEK 可解密，逐批重寫並監控失敗。演練 KMS 逾時、socket 斷開、單個 apiserver 回滾和外掛升級。若錯誤率超閾值，暫停重寫，恢復舊配置讀取資料；只有確認新 provider 穩定和存量完成後才移除舊 provider。
高品質示範回答
我會先在隔離叢集驗證 KMS v2 外掛、權限、延遲和故障行為。生產配置把 KMS v2 放在首位，短期保留舊 provider 作讀取回退，逐個滾動重啟 kube-apiserver。新寫入加密後，再按資源和命名空間分批無操作更新，記錄進度、衝突和重試。驗證既包含 API 讀回，也包含 etcd 前綴和抽樣物件取證；確認歷史物件完成重寫後才移除舊 provider。KEK 輪換和 KMS 故障都要有演練、閾值和局部回滾方案。
常見錯誤
- 只改配置不重寫舊物件 → 歷史明文仍在 etcd → 分批更新並統計完成度。
- 同時重啟所有 apiserver → 控制面中斷 → 逐個滾動並觀察健康指標。
- 只看 API 讀回 → 無法證明底層儲存加密 → 做 etcd 原始位元組取證。
- 立即刪除舊 provider → 舊資料無法解密 → 等遷移完成並保留回滾窗。
- 忽略 KMS 延遲和快取 → 高峰時 API 請求雪崩 → 壓測、限速和監控呼叫量。
追問及應對
配置 KMS v2 後，新 Secret 是否全部安全？
新寫入會按首選 provider 加密，但舊物件不會自動變更。必須執行存量重寫，並以 etcd 證據確認。
KMS 暫時不可用時能否繼續寫入？
取決於外掛快取和配置，不能假設一定可用。應預先定義逾時、拒絕寫入、告警和恢復後的重試策略，並演練控制面行為。
為什麼保留舊 provider 是風險而非永久方案？
它在遷移窗口內提供可回滾的解密能力，但擴大了金鑰和配置邊界。存量確認完成後應移除，並保留輪換與恢復證據。