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会为Kuberntes组件预留更多资源。
  • 由于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.18.8版本及以上的集群。
  • 该预留策略对新添加的节点自动生效,无需手动配置。
  • 出于稳定性考虑,该预留策略不会对已有节点自动生效。因为该资源预留的计算方式可能会造成节点的可分配资源变少,对于资源水位较高的节点,可能会触发节点驱逐。
  • 如果您希望对已有节点应用该资源预留策略,您可以通过容器服务管理控制台将该节点移除出集群,然后重新添加节点,新添加的节点会默认执行该资源预留策略。