題幹與適用場景
你負責一個運行在 Linux、SELinux enforcing 節點上的多租戶 Kubernetes 叢集。平台使用 CSI 卷，部分工作負載會共享同一個卷；團隊計畫升級到 v1.36。請在不假設所有節點都啟用 SELinux 的前提下，設計相容性評估、灰度、觀測和回滾方案。
面試官考察點
面試官希望聽到你能區分 SELinux 節點與普通節點，理解卷掛載上下文和遞迴重標記的差異，並識別特權與非特權 Pod 共享卷的風險。高品質回答還會涵蓋 CSI 驅動、Pod securityContext、啟動時延、資料存取、准入邊界和版本化回滾。
回答前需要釐清的問題
- 哪些節點處於 enforcing，哪些 CSI 驅動和檔案系統在支援範圍內？
- 共享卷是業務硬約束，還是可以透過拆分卷或資料交換替代？
- 遷移優先級是啟動時延、租戶隔離、作業連續性，還是三者的明確權衡？
- 當前版本是否允許顯式選擇卷標記策略，回滾窗口和證據保留期限是什麼？
30 秒回答
「我先盤點節點 SELinux 模式、CSI 驅動、卷類型和共享關係。v1.36 的改進把支援卷的標記路徑轉向掛載上下文，減少遞迴重標記成本，但可能改變共享卷的存取結果。我會先在隔離節點池對可重試工作負載做對照測試，觀察掛載、標籤、讀寫、啟動時延和拒絕日誌；通過後再擴大灰度。發現不相容時停止新工作負載進入灰度池，保留運行中 Pod 和證據，並按當前版本支援的策略回退。」
分步驟深入解答
1. 建立影響清單
記錄每個節點的核心與 SELinux 狀態、enforcing/permissive 模式、Kubernetes 版本、CSI 驅動版本和卷類型。將 Pod 的 seLinuxOptions、運行身份、特權級別、卷掛載路徑與是否被多個 Pod 共享導出為清單。沒有 SELinux 的節點不應被納入本次行為結論。
2. 理解行為差異
官方變更說明 v1.36 將 SELinux 卷標記改進提升為穩定能力：對支援的卷，系統可使用掛載上下文代替逐檔遞迴重標記。這通常能縮短大卷啟動時間，但共享卷由不同安全域存取時，原有「先重標記再使用」的假設可能失效。不要把「掛載成功」當作「應用一定可讀寫」。
3. 檢查驅動與策略邊界
逐個 CSI 驅動確認是否支援掛載上下文、檔案系統和掛載選項限制。按當前叢集版本文件核對 seLinuxChangePolicy、相關 feature gate 及預設值，避免把舊版本欄位或開關直接複製到新叢集。准入策略應限制不必要的特權、固定共享卷的安全域，並記錄策略變更。
4. 設計可重複的對照測試
準備相同映像、UID/GID、securityContext 和卷資料的測試 Pod，分別涵蓋單 Pod、同安全域共享、特權與非特權混用、空卷和已有大量檔案的卷。驗證掛載上下文、檔案標籤、讀寫、重啟恢復、擴容以及 CSI 重連；同時記錄從 Pod 建立到 Ready 的分段時延。
5. 灰度與護欄
先建立獨立節點池和少量 CSI StorageClass，選擇可重試作業。灰度期間禁止把同一共享卷同時交給未經驗證的安全域組合；將拒絕日誌、掛載失敗、應用權限錯誤、啟動時延和重啟成功率設為門檻。護欄觸發後停止擴容，不要透過放寬 SELinux 或特權權限來掩蓋問題。
6. 處理共享卷風險
如果一個卷在特權與非特權 Pod 之間共享，先拆分為獨立卷或統一安全域，再決定是否繼續遷移。對必須共享的場景，明確誰負責標籤、何時掛載、如何回收，並用實際存取矩陣驗證。只在應用恢復後才刪除舊卷，避免把標籤問題誤判為資料損壞。
7. 回滾與證據保留
回滾時先停止新 Pod 進入灰度節點池，保留運行中作業和事件，再根據當前版本支援的策略顯式選擇遞迴路徑或舊節點池。記錄 feature gate、節點標籤、CSI 設定、Pod 清單和 SELinux AVC 拒絕日誌。回滾後重新執行同一對照測試，確認行為恢復，而不是只看部署命令成功。
高品質示範回答
我會把遷移拆成盤點、對照、灰度和回滾四層。先確認只有 SELinux 可用且 enforcing 的 Linux 節點受影響，再核對 CSI 驅動與當前版本的安全上下文字段。v1.36 對支援卷使用掛載上下文，減少遞迴重標記，但共享卷和不同安全域的組合需要重點驗證。測試涵蓋空卷、大卷、單 Pod、同域共享以及特權/非特權混用，比較標籤、讀寫、拒絕日誌、啟動時延和重啟恢復。灰度節點池只接收可重試作業；門檻失敗就停止擴容、保留證據並按文件支援的策略回退。
常見錯誤
- 把所有節點都當作 SELinux 節點 → 得出錯誤影響範圍 → 先按節點模式和 enforcing 狀態分層。
- 只測掛載成功 → 應用運行時仍被拒絕 → 驗證實際 UID、標籤、讀寫和重啟。
- 直接放寬特權權限 → 安全邊界被擴大 → 修正安全域、共享關係和驅動設定。
- 忽略 CSI 差異 → 某類卷灰度失敗 → 按驅動、檔案系統和卷類型建立矩陣。
- 回滾時刪除所有 Pod → 丟失事故證據並中斷作業 → 先凍結新流量，保留狀態和日誌。
追問及應對
如果節點是 permissive，還需要同樣的遷移嗎？
仍應記錄並測試，因為 permissive 會記錄拒絕但通常不強制阻斷存取。它不能代表 enforcing 的結果；上線門檻必須在 enforcing 節點重現。
如何判斷是標籤問題還是 CSI 問題？
先在相同節點、映像和安全上下文下替換卷類型或驅動，比較掛載事件、核心拒絕日誌、檔案標籤和 CSI 日誌。只有跨驅動仍穩定重現，才把問題歸因到安全上下文路徑。
大卷啟動變快是否足以證明遷移成功？
不夠。效能只是一個指標，還要證明不同安全域的存取矩陣、重啟恢復、擴容、故障重連和審計日誌滿足門檻。
共享卷無法統一安全域怎麼辦？
優先拆分卷或改為顯式資料交換。若業務必須共享，應讓平台擁有安全域和生命週期決策，並把允許的 Pod 組合寫入准入策略與回歸測試。