文本翻译自: 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