Kubernetes 1.31：將 cgroup v1 支援移至維護模式
隨著 Kubernetes 持續發展並適應不斷變化的容器編排環境，社群已決定在 v1.31 中將 cgroup v1 支援移至 維護模式。此轉變與更廣泛的產業趨勢一致，即轉向 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、無 root 支援 等。
鑑於這些優勢，Kubernetes 也正在更全面地轉向 cgroup v2。但是，此轉換需要謹慎處理，以避免中斷現有的工作負載，並為使用者提供平穩的遷移路徑。
將 cgroup v1 支援移至維護模式
維護模式是什麼意思？
當 cgroup v1 在 Kubernetes 中置於維護模式時，表示：
- 功能凍結：不會為 cgroup v1 支援新增任何新功能。
- 安全性修復：仍將提供重要的安全性修復。
- 盡力修復錯誤：主要錯誤可能會在可行的情況下進行修復，但某些問題可能仍未解決。
為何要移至維護模式？
移至維護模式的原因是需要與更廣泛的生態系統保持一致，並鼓勵採用 cgroup v2，因為 cgroup v2 提供更好的效能、安全性和可用性。透過將 cgroup v1 轉換為維護模式，Kubernetes 可以專注於增強對 cgroup v2 的支援，並確保其滿足現代工作負載的需求。重要的是要注意，維護模式並不意味著棄用；cgroup v1 將繼續接收重要的安全性修復和主要錯誤修復（如果需要）。
這對叢集管理員意味著什麼
強烈建議目前依賴 cgroup v1 的使用者規劃轉換到 cgroup v2。此轉換涉及：
- 升級系統：確保底層作業系統和容器執行時支援 cgroup v2。
- 測試工作負載：驗證工作負載和應用程式在 cgroup v2 上是否正常運作。