Layerd cgroup

啟動 kubelet 之後，kubelet 會創建一個五層 cgroup，這篇文章介紹這五層 cgroup 的責任與角色

• root cgroup

  • systemreserved

  • kubereserved

  • kubepods

    • GuaranteedPod

    • BurstableQoS

      • BurstablePod

        • Container

    • BesteffortQoS

      • BesteffortPod

        • Container

Root cgroup

systemreserved

雖然我們佈署的時候會感覺不到 Node 存在， 但是 Node 本身除了 Pod 之外也有需要運行的Process，尤其是 systemd，所以這類資源需求會創建一個 cgroup，其名為 systemreserved 或是 system.slice

kubereserved

除了 OS 本身需要的 Process，kubelet 還有 Container Runtime 也需要一個 cgroup，這類型的需求會創建一個 cgroup，其名為 kubereserved 或是 kubelet

Allocatable Resources

而我們前面提到的 Allocatable Resources，就是減去前兩者在加上 HardEvictionThreshold 的資源。

   [Allocatable] = [Node Capacity] - [Kube-Reserved] - [System-Reserved] - [Hard-Eviction-Threshold]

再來第三種就是我們今天要深入討論的，給 Pod 使用的 cgroup，其名為 kubepods

kubepods cgroup

所有跟 pod 相關的 cgroup 都會放在這邊，裡面會有 QoS cgroup。

QoS cgroup

由於 Burstable 以及 BestEffort 有可能會使用過多資源，只要 kubelet 的參數 cgroups-per-qos=true，就會創建 Burstable 以及 BestEffort 這兩個 QoS cgroup。由於 Guaranteed 的有設定 limits，所以 Pod 自己獨立一個 cgroup。

Pod cgroup

一個 Pod 會對應到多個容器，會把多個容器放在同一個 Pod cgroup，這個需求蠻合理了，但是經常會遺漏的是，而除了多個容器之外，也需要處理 Pod 本身的運行資源，這通常會以 PodOverhead 來設定，常見於 katacontainer 以及 sandbox pod。

PodOverhead 會用 admission controller 的方式注入到 pod.spec.overhead 當中。

Container cgroup

這個就直覺很多了，我們在每個容器中設定的 resources 會落地到這邊。

這樣突然丟出五層架構容易造成認知負載，明天會伸進去 cgroup 檔案系統讓大家一窺全貌，這樣會比較有感覺。

今天發現鐵人賽結束之前，就算 30 天寫完了還是可以發文，這樣我可以安心說完我想說的事情了！