全部产品
Search
文档中心

容器服务 Kubernetes 版 ACK:节点资源预留策略

更新时间:May 18, 2023

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参数后,默认应用资源预留。

    • 改变资源预留的值可能会造成节点的可分配资源变少。对于资源水位较高的节点,可能会触发节点驱逐。

    • 如果您希望对已存在节点应用该资源预留策略,您可以将已有节点移除出集群,然后重新添加节点,新添加的节点会默认执行该资源预留策略。移除节点,请参见移除节点