K8s 從 cgroupv1 升級到 cgroupb2 的踩雷經驗
https://zouyee.medium.com/a-tragedy-caused-by-a-single-kubernetes-command-7b6126b06513
隨者 CentOS EOF 的到來，團隊決定轉移整個 OS 的同時順便將 Cgroup v1 給轉移到 Cgroup v2，然而轉移過去時，過去用來收集 CPU 使用情況的參數 "-enable_laod_reader" 則會使得 kubelet panic，沒有辦法正常運作。
本篇文章主要著重於
1. Container Metrics 如何被產生
2. Kubernetes 如何監控 Container Metrics
3. CPU Load 是如何被計算的
文章開頭先簡介 CAdvisor 的概念，透過程式碼解術 "-enable_load_reader" 該參數是如何影響 CAdvisor 要不要收集 CPU 的指標。
此外，自從 K8s 1.19 後， CAdvisor 已經被內建於 Kubelet 內，所以使用者也都不需要自行安裝，
當 CAdvisor 要收集 CPU Load Average 時，會透過 netlink 的方式去跟 kernel 溝通來獲取資訊，使用的指令是 "CGROUPSTATS_CMD_GET"，結果底層的實作只有
支援 cgroup v1 的類型，遇到 v2 就會回傳 EINVAL 的錯誤。
作者諮詢過 cgroup2 的維護者，其推薦改使用 PSI 的指標來獲得 CPU 的資訊，不在需要透過 CAdvisor 的方式來獲取 CPU 的資訊，文章內也有附上其他相關 ｉｓｓｕｅ．
Medium
A Tragedy Caused by a Single Kubernetes Command
DescDue to the Centos EOL, last year we were busy migrating to a new OS internally. We decided to take this opportunity to transition from…
July 8, 2024 1K 1
