引言
Kubernetes 中的 Kubelet Probes 是確保 Pod 健康狀態的核心機制，其功能與穩定性直接影響應用程序的可用性與系統可靠性。然而，隨著網路架構的複雜化與安全性需求的提升，現有探針設計在多網路環境、雙棧支援與安全風險等方面逐漸暴露出限制。本文探討 Kubelet Probes 的重設計方向，分析現有問題與潛在解決方案，並評估技術考量與實現挑戰。
主要內容
技術定義與核心功能
Kubelet Probes 透過三種探針類型監測 Pod 狀態：
- Startup Probes：確認應用啟動完成，避免過早終止啟動中的 Pod。
- Readiness Probes：判斷 Pod 是否準備接收流量，未通過時會將 Pod 排除於服務端點之外。
- Liveness Probes：檢查應用存活狀態，失敗時觸發 Pod 重啟。
這些探針透過 HTTP/TCP/gRPC 協議與 Pod 互動，其語義定義為「Pod 是否可達」，但現有實現方式在網路策略、雙棧支援與安全風險方面存在不足。
現有問題與挑戰
網路策略兼容性
- 網路策略（Network Policies）預設允許 kubelet 探針訪問所有 Pod，但需為探針開設通孔，導致安全風險與管理複雜性。
- 使用 Admin Network Policy API 時，需明確允許探針流量，否則探針無法正常運作。
雙棧（Dual Stack）支援不足
- 當 Pod 僅支援 IPv6 時，預設使用 IPv4 進行探針檢查會導致失敗。
- 無明確機制指定探針使用的 IP 家族（IPv4/IPv6）。
多網路與 IP 重疊問題
- Kubernetes 核心預設每個 Pod 擁有唯一 IP，但部分 CNI 實現支援多 IP 或 IP 重疊（如 Uvnet）。
- kubelet 無法識別多 IP 情況，導致探針無法正確選擇目標 IP。
安全漏洞（Host 字段風險）
- 探針的
host 字段可設定任意 IP，可能被濫用於伺服器端請求偽造（SSRF）攻擊。
- 當前無驗證機制，僅依賴使用者設定，存在安全風險。
潛在解決方案
利用 CRI 端口轉發（Port Forwarding）
- 透過 CRI 的端口轉發功能，建立 Pod 網路命名空間內的本地連接（如
localhost），繞過網路策略限制。
- 優點：不需修改網路策略，支援 IPv4/IPv6 自動適配，兼容現有架構。
- 缺點：需 Pod 監聽所有接口或本地地址，可能影響性能，增加 CRI 的 CPU 使用率。
改用 Exec 探針（Exec Probes）
- 將 HTTP/TCP/gRPC 探針轉換為執行命令（如
curl）在 Pod 內部執行。
- 優點：避免網路策略限制，減少 CPU 使用率。
- 缺點：需 Pod 內部安裝
curl 等工具，增加依賴性，執行效率較低。
新增 CRI 探針 API
- 在 CRI 中新增專用探針 API，由 kubelet 調用並定期報告狀態。
- 優點：提升探針效率，減少 kubelet 與 CRI 的頻繁互動。
- 缺點：需引入新 CRI API，增加實現複雜度，可能導致版本兼容性問題。
創建探針專用 Pod
- 由 kubelet 啟動專用 Pod 進行探針檢查，並透過 Admin Network Policy 允許其訪問其他 Pod。
- 優點：明確區分探針流量，提升安全性與管理靈活性。
- 缺點：增加系統負載，需額外資源支援專用 Pod。
臨時解決方案（PSA）
- 當前透過 Pod Security Admission（PSA）限制
host 字段的使用，防止 SSRF 攻擊。
- 管理員可設定策略（如
enforced 或 restricted）阻擋或警告不安全的探針配置。
技術考量與風險
- API 兼容性：改變探針語義可能導致現有應用不兼容，需評估是否需引入新探針類型。
- 性能影響：端口轉發或 Exec 探針可能增加 CPU 使用率或延遲。
- 安全風險：需嚴格驗證
host 字段，避免未經授權的外部流量訪問。
- 多網路支援：需與 SIG Network 多網路工作組協調，解決 IP 重疊與多 IP 管理問題。
技術討論與爭議點
- 探針語義與實現分離：探針語義應明確定義為「Pod 是否可達」，而非僅內部可達性。現有方案可能僅解決部分問題，需明確設計目標。
- 網路策略與可達性：主機網路探針無法區分 Kubelet 連線，需透過 Pod 網路或 Admin 策略解決。網路策略需確保探針 Pod 能訪問目標 Pod，但可能導致安全風險。
- 性能與效率：
exec 探針啟動耗時，需優化執行流程（如使用 nsenter 或 CRI API）。避免頻繁呼叫 CRI，減少資源消耗。
- 跨平臺與運行時兼容性：解決方案需兼容 Linux/Windows 等不同運行時，避免硬編碼實現細節。例如 Windows 環境可能需使用 Port Forwarding 或其他機制。
其他建議與問題
- 靜態 Pod 與 Ephemeral 容器：靜態 Pod 可能不適用於探針 Pod，需明確設計。Ephemeral 容器管理複雜，需處理 Crash、IP 變更等問題。
- SNMP 協議探討：建議使用 SNMP 協議進行網路監測，因其輕量且兼容性高。需評估是否整合至 Kubelet 或其他監控系統。
- 語義明確性：避免探針結果誤導使用者，需確保探針語義與現有行為一致。當前探針可能因網路策略或配置錯誤導致誤判，需加強驗證機制。
待解決的關鍵問題
- 語義與實現分離：明確探針語義（如「可達性」）與實現方式（如 CRI API、Sidecar）的區別。
- 網路策略整合：如何在不影響現有策略的情況下，讓探針流量被正確允許。
- 性能與安全性平衡：降低探針執行開銷，同時避免引入新安全風險（如 Admin 策略過度授權）。
- 兼容性與擴展性：確保方案兼容現有 CRI 與 Kubelet，並支持未來擴展（如新增探針類型）。
總結
Kubelet Probes 的重設計需在語義明確性、網路策略兼容性、安全性與性能之間取得平衡。現有方案如 CRI 端口轉發、Exec 探針與探針專用 Pod 各有優缺點，需根據實際場景選擇。未來方向應著重於容器運行時接口（gRPC API）整合，提升跨運行時兼容性，並明確探針語義與實現的分離原則。在實踐中，需嚴格驗證 host 字段，優化探針執行效率，並與 SIG Network 協作解決多網路與 IP 重疊問題，以確保探針機制的穩定與安全。