文本翻译自: https://medium.com/@danielepolencic/reserved-cpu-and-memory-i…
在 Kubernetes 中，运行多个集群节点是否存在隐形成本？
是的，因为并非 Kubernetes 节点中的所有 CPU 和内存都可用于运行 Pod。
在一个 Kubernetes 节点中，CPU 和内存分为：
- 操作系统
- Kubelet、CNI、CRI、CSI（+ 系统 daemons）
- Pods
- 驱逐阈值
这些预留的资源取决于实例的大小，并且可能会增加相当大的开销。
让我们举一个简单的例子。
想象一下，你有一个具有单个 1GiB / 1vCPU 节点的集群。
以下资源是为 kubelet 和操作系统保留的：
- 255MiB 内存。
- 60m 的 CPU。
最重要的是，为驱逐阈值预留了 100MB。
那么总共有 25% 的内存和 6% 的 CPU 不能使用。
在云厂商中的情况又是如何？
EKS 有一些（有趣的？）限制。
让我们选择一个具有 2vCPU 和 8GiB 内存的 m5.large 实例。
AWS 为 kubelet 和操作系统保留了以下内容：
- 574MiB 内存。
- 70m 的 CPU。
这一次，你很幸运。
你可以使用大约 93% 的可用内存。
但这些数字从何而来？
每个云厂商都有自己定义限制的方式，但对于 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。
这听起来更合理，并且与其他云厂商一致。
让我们看看 GKE 进行比较。
对于类似的实例类型（即 n1-standard-2，7.5GB 内存，2vCPU），kubelet 的预留如下：
- 1.7GB 内存。
- 70m 的 CPU。
换句话说，23% 的实例内存无法分配给运行的 Pod。
如果实例每月花费 48.54 美元，那么你将花费 11.16 美元来运行 kubelet。
其他云厂商呢？
你如何检查这些值？
我们构建了一个简单的工具来检查 kubelet 的配置并提取相关细节。
你可以在这里找到它：https://github.com/learnk8s/kubernetes-resource-inspector
如果你有兴趣探索更多关于节点大小的信息，我们还构建了一个简单的实例计算器，你可以在其中定义工作负载的大小，它会显示适合该大小的所有实例（及其价格）。
https://learnk8s.io/kubernetes-instance-calculator
我希望你喜欢这篇关于 Kubernetes 资源预留的短文；在这里，你可以找到更多链接以进一步探索该主题。
- Kubernetes instance calculator。
- Allocatable memory and CPU in Kubernetes Nodes
- Allocatable memory and CPU resources on GKE
- AWS EKS AMI reserved CPU and reserved memory
- AKS resource reservations
- 官方文档 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/
- Enabling prefix assignment in EKS and VPC CNI
