本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.31：將 cgroup v1 支援移入維護模式
隨著 Kubernetes 不斷發展並適應容器編排領域的變化，社群決定在 v1.31 中將 cgroup v1 支援轉入維護模式。這一轉變與整個行業向 cgroup v2 的遷移保持一致，cgroup v2 提供了改進的功能：包括可擴充套件性和更一致的介面。在我們深入探討這對 Kubernetes 的影響之前，讓我們先回顧一下 cgroup 是什麼以及它們在 Linux 中的重要性。
瞭解 cgroups
控制組（cgroups）是 Linux 核心的一項功能，它允許在程序之間分配、優先排序、拒絕和管理系統資源（如 CPU、記憶體、磁碟 I/O 和網路頻寬）。此功能對於維持系統性能和確保沒有單個程序能夠獨佔系統資源至關重要，這在多租戶環境中尤為重要。
cgroups 有兩個版本：v1 和 v2。雖然 cgroup v1 提供了足夠的資源管理能力，但其侷限性導致了 cgroup v2 的發展。cgroup v2 在提供更好的資源控制功能的基礎上，還提供了更統一和一致的介面。
Kubernetes 中的 Cgroups
對於 Linux 節點，Kubernetes 嚴重依賴 cgroups 來管理和隔離 Pod 中執行的容器所消耗的資源。Kubernetes 中的每個容器都被放置在其自己的 cgroup 中，這使得 Kubernetes 能夠強制執行資源限制、監控使用情況並確保所有容器之間的公平資源分配。
Kubernetes 如何使用 cgroups
- 資源分配
- 確保容器不會超過其分配的 CPU 和記憶體限制。
- 隔離
- 將容器彼此隔離，以防止資源爭用。
- 監控
- 跟蹤每個容器的資源使用情況，以提供洞察和指標。
向 Cgroup v2 過渡
Linux 社群一直專注於 cgroup v2 的新功能和改進。主要的 Linux 發行版和像 systemd 這樣的專案都在過渡到 cgroup v2。使用 cgroup v2 相比 cgroup v1 提供了多種好處，例如統一的層級結構、改進的介面、更好的資源控制、cgroup 感知的 OOM killer、無根（rootless）支援等。
鑑於這些優勢，Kubernetes 也在採取行動，以更全面地擁抱 cgroup v2。然而，這一過渡需要謹慎處理，以避免中斷現有的工作負載，併為使用者提供平滑的遷移路徑。
將 cgroup v1 支援轉入維護模式
維護模式意味著什麼？
當 Kubernetes 中的 cgroup v1 進入維護模式時，這意味著：
- 功能凍結：不會再為 cgroup v1 支援新增新功能。
- 安全修復：仍會提供關鍵的安全修復。
- 盡力而為的錯誤修復：如果可行，可能會修復重大錯誤，但某些問題可能仍未解決。
為什麼要進入維護模式？
進入維護模式的動機是為了與更廣泛的生態系統保持一致，並鼓勵採用 cgroup v2，因為它提供了更好的效能、安全性和可用性。透過將 cgroup v1 過渡到維護模式，Kubernetes 可以專注於增強對 cgroup v2 的支援，並確保其滿足現代工作負載的需求。需要注意的是，維護模式並不意味著棄用；cgroup v1 將根據需要繼續接收關鍵的安全修復和重大錯誤修復。
這對叢集管理員意味著什麼
強烈建議當前依賴 cgroup v1 的使用者規劃向 cgroup v2 的過渡。這一過渡包括：
- 升級系統：確保底層的作業系統和容器執行時支援 cgroup v2。
- 測試工作負載：驗證工作負載和應用程式在 cgroup v2 下能正常執行。