ACK需要占用一定的节点资源来为kube组件和system进程预留资源，从而保证OS内核和系统服务、Kubernetes守护进程的正常运行。这会导致节点的资源总数Capacity与可分配的资源数Allocatable之间存在差异。ACK存在默认的资源预留策略，也支持通过kubelet配置自定义资源预留。
使用限制
仅1.20及以上版本的ACK集群支持自定义节点资源预留策略。如果您的集群版本为1.20以下，请参见手动升级集群升级集群。
影响范围
自定义资源预留及其影响范围
您可以参见自定义节点池kubelet配置修改资源预留的取值。修改后，节点池中的已有节点将即时生效，新增节点（例如扩缩容的新节点、通过添加已有节点新增的ECS实例）也会使用该配置。
不支持通过黑屏手动修改kubelet配置文件，以避免配置冲突，导致后续节点池运维过程中的非预期结果。
改变资源预留的值可能会造成节点的可分配资源变少。对于资源水位较高的节点，可能会触发节点驱逐。请合理配置取值。
默认资源预留影响范围
ACK可能会迭代节点资源预留的默认取值。迭代后，如果您在节点池维度更新了节点配置，例如集群升级、节点池升级、修改节点池自定义kubelet参数等，节点将自动使用新的资源预留策略。如果您没有相关运维操作，出于稳定性考量，节点池中的已有节点不会自动生效新的资源预留策略。
如果某个已有节点需要使用新的资源预留策略，您可以将该节点移除出集群，再重新添加已有节点。新添加的节点会默认执行新的资源预留策略。移除节点和添加节点的标准操作及带来的影响，请参见移除节点、添加已有节点。
查询节点可分配资源
执行以下命令，查看节点的资源总量和可分配资源。
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 #节点可分配的临时存储，单位Byte。
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 5824732Ki #节点可分配的内存，单位KiB。
pods: 64计算节点可分配资源
可分配资源的计算公式：可分配资源（Allocatable） = 总资源（Capacity）-预留资源（Reserved）-驱逐阈值（Eviction-Threshold）
公式说明：
资源预留策略说明
节点的预留资源量通常要考虑以下因素：
由于较高规格的ECS节点通常会运行更多的Pod，为了保证节点的性能，ACK会为Kubernetes组件预留更多资源。
由于Windows节点需要使用额外的资源来运行Windows操作系统和Windows Server相关组件，Windows节点通常会比Linux节点需要更多的预留资源。更多信息，请参见创建Windows节点池。
ACK会根据CPU和内存所在的不同区间来计算预留的资源量，节点的总预留资源量等于各区间的预留资源量之和。ACK在1.28进行了资源预留策略算法的调优，减少了CPU和内存资源的预留。推荐您升级集群，请参见手动升级集群。
预留资源包括为kube组件预留的资源（kubeReserved）和为system进程预留的资源（systemReserved）。kubeReserved和systemReserved各占预留资源的50%。例如，节点总CPU 4 Core，则在1.28及以上的集群中，预留CPU资源为80 millicore，其中kubeReserved占用40 milliCore，systemReserved占用40 milliCore；在1.20及以上至1.28以下的集群中，预留CPU为100 milliCore，其中kubeReserved占用50 milliCore，systemReserved占用50 millicore。
CPU资源预留策略
1.28及以上
计算节点的总CPU预留量示意图如下所示。
以32核的节点为例，总的CPU预留量计算如下：
1000 x 6% +1000 x 1% + 1000 x 2 x 0.5% + (32000-4000) × 0.25% = 150 milliCore
1.20及以上至1.28以下
计算节点的总CPU预留量示意图如下所示。
以32核的节点为例，总的CPU预留量计算如下：
100+（32000-4000）× 2.5%=800 milliCore
内存资源预留策略
1.28及以上
计算节点的总内存预留量计算公式为节点总内存预留量 = min(11 x $max_num_pods + 255, 节点内存资源 x 25%)。其中，$max_num_pods为节点支持的最大Pod数量，节点内存资源单位为MiB，最终取11 * $max_num_pods + 255与节点内存资源的 25%的较小值。
集群使用不同的网络插件时，节点支持的最大Pod数量计算方式也不同。
如果集群网络插件为Terway，节点允许创建的最大Pod数量依赖于ECS实例规格所提供的弹性网卡数量。关于不同Terway模式下如何计算节点支持的最大Pod数量，请参见使用Terway网络插件；关于如何查看节点支持的最大Pod数量，请参见使用Terway网络插件。您也可以登录容器服务管理控制台，在节点页面的节点列表查看最大Pod数量。
如果集群网络插件为Flannel，节点支持的最大Pod数量由您在创建集群时自行设置。您可以登录容器服务管理控制台，在节点页面的节点列表查看最大Pod数量。
例如，如果您的集群使用Terway网络插件的共享ENI多IP模式，节点规格为256 GiB的ecs.g7.16xlarge，此时节点支持的最大Pod数量为(8 - 1) x 30 = 210个，则节点总内存预留量 = min(11 x 210 + 255 , 256 x 1024 x 25%) = 2565 MiB。
1.20及以上至1.28以下
计算节点的总内存预留量示意图如下所示。
以256 GiB内存的节点为例，总的内存预留量计算如下：
4 × 25%+（8-4）× 20%+（16-8）× 10%+（128-16）× 6%+（256-128）× 2%=11.88 GiB
ACK节点默认预留资源示例
关于ECS实例规格的详细信息，请参见实例规格族。
节点总资源 | 预留资源（1.28及以上） | 预留资源（1.20及以上至1.28以下） | |||||
示例实例规格 | CPU（Core） | Memory （GiB） | 节点最大Pod数 （以Terway共享ENI多IP模式为例） | CPU （milicore） | Memory （MiB） | CPU（millicore） | Memory（MiB） |
ECS c7实例规格 | 2 | 4 | 12 | 70 | 387 | 100 | 1024 |
4 | 8 | 45 | 80 | 750 | 100 | 1843 | |
8 | 16 | 45 | 90 | 750 | 200 | 2662 | |
16 | 32 | 210 | 110 | 2565 | 400 | 3645 | |
32 | 64 | 210 | 150 | 2565 | 800 | 5611 | |
64 | 128 | 210 | 230 | 2565 | 1600 | 9543 | |
128 | 256 | 420 | 390 | 4875 | 2400 | 12164 | |
ECS ebmc7a实例规格 | 256 | 512 | 450 | 710 | 5205 | 3040 | 17407 |
常见问题
如何查看节点总CPU和内存？
CPU
执行如下命令，查询节点总CPU。
cat /proc/cpuinfo | grep processor预期输出：
processor : 0
processor : 1
processor : 2
processor : 3内存
执行如下命令，查询节点总内存。
cat /proc/meminfo | grep MemTotal预期输出：
MemTotal: 7660952 kB相关文档
关于如何配置自定义资源预留和驱逐阈值以及相关注意事项，请参见自定义节点池kubelet配置。
根据可分配资源，您可以为业务Pod设置所需资源（request），节点上所有业务Pod所需资源之和不应该大于节点的可分配资源，否则业务Pod会因节点容量不足而调度失败。ACK为K8s原生的工作负载提供了资源画像能力，通过对资源使用量历史数据的分析，辅助您填写Pod所需资源。设置业务Pod所需资源的具体操作，请参见创建无状态工作负载Deployment。
如果您希望对已存在节点应用自定义资源预留策略，您可以将已有节点移除出集群，然后重新添加节点。新添加的节点会默认执行自定义资源预留策略。移除节点和添加节点的标准操作及带来的影响，请参见移除节点、添加已有节点。