ACK的节点资源的预留策略和注意事项_容器服务Kubernetes版-阿里云帮助中心

ACK需要占用一定的节点资源来运行相关组件（例如kubelet、kube-proxy、Terway、Container Runtime等），从而使节点作为集群的一部分来运行。这会造成节点的资源总数与ACK集群中可分配的资源数之间存在差异。本文介绍ACK的节点资源预留策略、相关注意事项，以便在部署应用时合理设置Pod的请求资源量和限制资源量。

查询节点可分配资源

执行以下命令，查看节点的资源总量和可分配资源。

kubectl describe node [NODE_NAME] | grep Allocatable -B 7 -A 6

预期输出：

Capacity:
  cpu:                4                 #节点的CPU总核数。
  ephemeral-storage:  123722704Ki       #节点的临时存储总量，单位KiB。
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             7925980Ki         #节点的内存总量，单位KiB。
  pods:               64
Allocatable:
  cpu:                3900m             #节点可分配的CPU核数。
  ephemeral-storage:  114022843818      #节点可分配的临时存储，单位KiB。
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             5824732Ki         #节点可分配的内存，单位KiB。
  pods:               64

计算节点可分配资源

可分配资源的计算公式：可分配资源（Allocatable） = 总资源（Capacity）-预留资源（Reserved）-驱逐阈值（Eviction-Threshold）

公式说明：

总资源对应查询节点命令输出中的Capacity字段。
关于预留资源的相关信息，请参见资源预留策略。
关于驱逐阈值的相关信息，请参见节点压力驱逐。

资源预留策略

节点的预留资源量通常要考虑以下因素：

由于规格较高的ECS节点通常会运行更多的Pod，为了保证节点的性能，ACK会为Kubernetes组件预留更多资源。
由于Windows节点需要使用额外的资源来运行Windows操作系统和Windows Server相关组件，Windows节点通常会比Linux节点需要更多的预留资源。更多信息，请参见创建Windows节点池。

ACK会根据CPU和内存所在的不同区间来计算预留的资源量，节点的总预留资源量等于各区间的预留资源量之和。

CPU：计算节点的总CPU预留量示意图如下。
以32核的节点为例，总的CPU预留量计算如下：
100+（32000-4000）×2.5%=800 milliCore
内存：计算节点的总内存预留量示意图如下所示。
以256 GiB内存的节点为例，总的内存预留量计算如下：
4×25%+（8-4）×20%+（16-8）×10%+（128-16）×6%+（256-128）×2%=11.88 GiB

资源预留注意事项

该预留策略仅适用于1.16.9版本及以上的集群。
修改资源预留的值，请参见节点池自定义Kubelet配置。
该预留策略对新添加的节点自动生效，无需手动配置。
对于已存在节点：
- 如果已存在节点没有进行过节点池运维操作，例如，自定义配置、节点池升级等，出于稳定性考虑，该预留策略不会对此类已存在节点自动生效。
- 即使节点未配置过资源预留，已存在节点会在集群升级、节点池升级、修改节点池自定义Kubelet参数后，默认应用资源预留。
- 改变资源预留的值可能会造成节点的可分配资源变少。对于资源水位较高的节点，可能会触发节点驱逐。
- 如果您希望对已存在节点应用该资源预留策略，您可以将已有节点移除出集群，然后重新添加节点，新添加的节点会默认执行该资源预留策略。移除节点，请参见移除节点。