Kubernetes 節點的預留資源

文字翻譯自: https://medium.com/@danielepolencic/reserved-cpu-and-memory-i...

在 Kubernetes 中，執行多個叢集節點是否存在隱形成本？

是的，因為並非 Kubernetes 節點中的所有 CPU 和記憶體都可用於執行 Pod。

在一個 Kubernetes 節點中，CPU 和記憶體分為：

作業系統
Kubelet、CNI、CRI、CSI（+ 系統 daemons）
Pods
驅逐閾值

Kubernetes 節點中的可分配資源

這些預留的資源取決於例項的大小，並且可能會增加相當大的開銷。

讓我們舉一個簡單的例子。

想象一下，你有一個具有單個 1GiB / 1vCPU 節點的叢集。

以下資源是為 kubelet 和作業系統保留的：

255MiB 記憶體。
60m 的 CPU。

最重要的是，為驅逐閾值預留了 100MB。

那麼總共有 25% 的記憶體和 6% 的 CPU 不能使用。

在 1GiB / 1vCPU Kubernetes 節點中，25% 的記憶體由 kubelet 保留

在雲廠商中的情況又是如何？

EKS 有一些（有趣的？）限制。

讓我們選擇一個具有 2vCPU 和 8GiB 記憶體的 m5.large 例項。

AWS 為 kubelet 和作業系統保留了以下內容：

574MiB 記憶體。
70m 的 CPU。

這一次，你很幸運。

你可以使用大約 93% 的可用記憶體。

如果將 EKS 與 m5.large 節點一起使用，則可以使用 93% 的可用記憶體來執行 pod

但這些數字從何而來？

每個雲廠商都有自己定義限制的方式，但對於 CPU，他們似乎都同意以下值：

第一個核心的 6%。
下一個核心的 1%（最多 2 個核心）。
接下來 2 個核心的 0.5%（最多 4 個核心）。
四核以上任何核的 0.25%。

至於記憶體限制，雲廠商之間差異很大。

Azure 是最保守的，而 AWS 則是最不保守的。

Azure 中 kubelet 的預留記憶體為：

前 4 GB 記憶體的 25%。
4 GB 以下記憶體的 20%（最大 8 GB）。
8 GB 以下記憶體的 10%（最大 16 GB）。
下一個 112 GB 記憶體的 6%（最多 128 GB）。
超過 128 GB 的任何記憶體的 2%。

這對於 GKE 是相同的，除了一個值：逐出閾值在 GKE 中為 100MB，在 AKS 中為 750MiB。

在 EKS 中，使用以下公式分配記憶體：

255MiB + (11MiB * MAX_NUMBER OF POD)

不過，這個公式提出了一些問題。

在前面的示例中，m5.large 保留了 574MiB 的記憶體。

這是否意味著 VM 最多可以有 (574–255) / 11 = 29 個 pod？

如果你沒有在 VPC-CNI 中啟用 prefix 字首分配模式，這是正確的。

如果這樣做，結果將大不相同。

對於多達 110 個 pod，AWS 保留：

1.4GiB 記憶體。
（仍然）70m 的 CPU。

這聽起來更合理，並且與其他雲廠商一致。

如果你將 EKS 與 m5.large 節點和字首分配模式一起使用，則 kubelet 會保留 1.4GiB 的記憶體

讓我們看看 GKE 進行比較。

對於類似的例項型別（即 n1-standard-2，7.5GB 記憶體，2vCPU），kubelet 的預留如下：

1.7GB 記憶體。
70m 的 CPU。

如果你將 GKE 與 n1-standard-2 節點一起使用，則 kubelet 會保留 1.7GiB 的記憶體

換句話說，23% 的例項記憶體無法分配給執行的 Pod。

如果例項每月花費 48.54 美元，那麼你將花費 11.16 美元來執行 kubelet。

其他雲廠商呢？

你如何檢查這些值？

我們構建了一個簡單的工具來檢查 kubelet 的配置並提取相關細節。

你可以在這裡找到它：https://github.com/learnk8s/kubernetes-resource-inspector

如果你有興趣探索更多關於節點大小的資訊，我們還構建了一個簡單的例項計算器，你可以在其中定義工作負載的大小，它會顯示適合該大小的所有例項（及其價格）。

https://learnk8s.io/kubernetes-instance-calculator

我希望你喜歡這篇關於 Kubernetes 資源預留的短文；在這裡，你可以找到更多連結以進一步探索該主題。

Kubernetes 節點的預留資源

相關文章