VKE 提供节点放大能力，基于 Katalyst 框架虚拟放大节点可分配资源，在不修改业务负载声明的前提下提升节点部署密度。本文介绍如何为集群开启并使用节点放大能力。 ## 功能介绍节点放大能力指通过虚拟放大节点的 Capacity/Allocatable，让调度器"看到"更大的节点容量，从而把更多 Pod 调度到节点上，充分利用闲置的物理资源，实现 Pod 零侵入的密度提升。该能力由放大策略、调度水位、压力驱逐三组互相独立的策略配合实现，通过三套 CRD 分别管理，用户可以按需组合使用： |**CRD** |**职责** |**配置内容** | |---|---|---| |NodeOvercommitConfig（NOC） |放大策略 |选择节点池、设置放大系数（静态/动态）和目标负载水位。 | |NodeSchedulingConfig |调度水位 |按节点池维度配置负载感知调度的调度停止线阈值。 | |AdminQoSConfiguration（AQC） |压力驱逐 |分层压力驱逐：Label 精细化驱逐 + 系统压力 QoS 感知兜底驱逐。 | ## 前提条件 * 集群已安装 katalyst 组件，并在组件参数配置页面开启 **节点放大** 开关。详情请参见 [katalyst](https://www.volcengine.com/docs/6460/2276751)。 * 动态放大及预测能力依赖 VMP 提供历史指标查询，动态预测按照用户设置的放大系数估算负载。请在 VKE 开启云原生可观测，详情请参见 [开启观测](https://www.volcengine.com/docs/6460/1213992)。相关核心指标名称，请参见本文下方 [附录](https://www.volcengine.com/docs/6460/2553543#bOMJcfTK)。 ## 注意事项开启节点放大能力前请确认以下功能限制，避免因限制违反导致业务中断或资源争抢： |**限制项** |**说明** | |---|---| |与 Cluster Autoscaler（CA）互斥 |同一节点池不可同时开启 **节点放大** 与 **弹性伸缩**。放大后的 Allocatable 会让 CA 误判节点真实容量，导致错误缩容或扩容延迟。放大节点池与 CA 节点池须分开。 | |放大系数硬上限 |默认放大系数为 CPU ≤ 3.0，Memory ≤ 2.0，超出后系统拒绝生效。建议从 CPU 1.5~2.0、Memory 1.2~1.5 起步，观察后逐步上调。 | |不支持 GPU 资源放大 |当前仅支持 CPU 和 Memory 放大，GPU/NPU 等加速器资源不在支持范围。 | |绑核节点（cpuManagerPolicy: static） |开启`cpuManagerPolicy: static`策略的节点，仅对共享 CPU 池进行放大，独占核 Pod 的 CPU 和 Memory 资源不参与放大计算。 | |kubelet 重启风险 |katalyst 组件卸载或者调低放大系数时，节点上已调度的 Pod 不受影响，但此时如果节点上的 kubelet 重启，可能会引发 Pod 的驱逐，因为此时节点上 Pod 的 Request 之和可能已超过节点当前的规格。 | |单节点池单 NOC |同一节点池被多个 NOC 匹配时，仅最新创建的 NOC 生效。 | ## 操作步骤 ### 步骤一：为节点池添加放大 Label 1. 登录 [容器服务控制台](https://console.volcengine.com/vke)。 2. 在左侧导航栏选择 **集群**，单击目标集群名称。 3. 在集群管理页面左侧导航栏选择 **节点管理** \> **节点池**。 4. 在 **节点池** 页面找到目标节点池，单击对应 **操作** 列下的 **编辑**。 5. 在 **编辑节点池** 页面的 **①节点池配置** 步骤 **高级配置** 模块下配置 2 个 **节点标签（Labels）** 并勾选 **开启节点标签及污点自动更新**。 * Label 1： * 标签键：`katalyst.kubewharf.io/overcommit_node_pool` * 标签值：节点池标识，例如节点池名称、ID 等，用户可以自定义。 * Label 2： * 标签键：`vke.node.katalyst.deploy` * 标签值：`true` ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_9cd51ebd025c55de3d80513c04e96b6d.png) ### 步骤二：下发 NOC 设置放大系数 1. 通过 kubectl 连接集群，详情请参见 [使用 kubectl 连接集群](https://www.volcengine.com/docs/6460/100942)。 2. 通过下发 NOC 来定义节点池的放大策略。NOC 的示例 YAML 文件`nodeovercommit-test.yaml`如下所示。 ```YAML apiVersion: overcommit.katalyst.kubewharf.io/v1alpha1 kind: NodeOvercommitConfig metadata: name: nodeovercommit-test # 自定义放大策略名称 labels: vke.node.katalyst.deploy: "true" # 固定值 spec: nodeOvercommitSelectorVal: "test-pool" # 目标节点池名称，与节点上的 katalyst.kubewharf.io/overcommit_node_pool 对应的 value 匹配 resourceOvercommitRatio: # 放大系数配置 cpu: "2" memory: "1.5" # overcommitStrategyType: dynamic # 是否动态调整放大系数，取值：dynamic（动态调整，根据实时负载和历史负载计算一个推荐值）、static（静态调整，按上面放大系数配置调整）。如需动态调整，需要设置 targetLoadThreshold，最终生效的放大系数为 min(dynamic,static) targetLoadThreshold: # 放大节点的目标负载水位，动态调整时会根据这个目标水位对空闲资源进行放大，以使得节点的真实负载向目标水位靠近 cpu: 80 memory: 90 ```

说明

静态调整和动态调整放大系数后的资源计算方法不同，详情请参见本文下方附录。

3. 执行如下命令，创建下发 NOC。 ```Bash kubectl apply -f nodeovercommit-test.yaml ``` ### 步骤三：（可选）开启负载感知调度策略如需解决节点池维度非放大节点和放大节点的调度优先级低的问题，可以配合使用 [负载感知调度](https://www.volcengine.com/docs/6460/185594) 和 NodeSchedulingConfig 对象： * 当节点没有 NodeSchedulingConfig 与之匹配时，采用全局的配置；当有与之匹配的 Custom Resource 时，优先采用 Custom Resource 里的配置。 * 当节点被多个 NodeSchedulingConfig 匹配时，采用创建时间最新的配置生效。

说明

若未开启负载感知调度，将无法有效管控节点利用率，存在业务运行风险。VKE 默认仅基于 Pod 的request值进行调度，当节点真实资源使用量（usage）超过放大后的可分配资源时，会触发 OOM 等故障，因此强烈建议开启负载感知调度。

1. 在负载感知调度插件（scheduler\-plugin 组件）配置界面，配置全局的节点资源利用率阈值。更多操作说明，请参见 [负载感知调度](https://www.volcengine.com/docs/6460/185594)。 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_881a6cc79787479795e1f590f3157478.png) 2. 通过下发 NodeSchedulingConfig，自定义对应节点池的资源利用率的阈值。示例 YAML 文件`nodeschedulingconfig-test.yaml`如下所示。 ```YAML apiVersion: scheduling.vke.volcengine.com/v1beta1 kind: NodeSchedulingConfig metadata: name: nodeschedulingconfig-test # 自定义 NodeSchedulingConfig 名称 spec: nodeSelector: matchLabels: katalyst.kubewharf.io/overcommit_node_pool: test-pool # 节点选择器，对应资源利用率阈值的生效范围，例如：配置为对应的放大节点池 targetLoadThreshold: cpu: 70 # CPU 的资源使用率阈值（百分比） memory: 70 # Memory 的资源使用率阈值（百分比） ``` 3. 执行如下命令，下发 NodeSchedulingConfig。 ```Bash kubectl apply -f nodeschedulingconfig-test.yaml ``` ### 步骤四：（可选）开启节点压力感知与驱逐策略节点放大场景下，由于单机可以容纳超过自身容量的工作负载，当放大比配置过大或容器实际负载超过预期时，可能导致单机负载过高，影响整机的服务性能。建议通过下发 AQC 来配置节点侧的压力感知与驱逐策略，并配套创建 KatalystCustomConfig（KCC）将节点池 Label 加入白名单。 1. 创建 AQC，配置压力感知与驱逐。示例 YAML 文件`adminqosconfiguration-test.yaml`如下所示。 ```YAML apiVersion: config.katalyst.kubewharf.io/v1alpha1 kind: AdminQoSConfiguration metadata: name: katalyst-config # 固定值，KatalystCustomConfig 对象名称 namespace: katalyst-system labels: vke.node.katalyst.deploy: "true" # 固定值 spec: # 放大节点池筛选器，与节点上的 katalyst.kubewharf.io/overcommit_node_pool Label 对应的 Value 匹配 nodeLabelSelector: "katalyst.kubewharf.io/overcommit_node_pool=test-pool" priority: 10 # 需要与 KatalystCustomConfig 中定义的 nodeLabelSelectorAllowedKeyList 相互对应 config: evictionConfig: cpuSystemPressureEvictionConfig: enableCPUSystemPressureEviction: true # 开启系统 CPU 压力感知与驱逐策略 usageUpperBoundRatio: 0.8 # 节点 CPU Usage 使用率阈值，1 对应 100% evictionWorkloadScope: declaredEvictable # 开启后，只会在有 katalyst.kubewharf.io/evictable=true 这个 Annotations 的 Pod 中选择驱逐 memoryPressureEvictionConfig: evictionWorkloadScope: declaredEvictable # 开启后，只会在有 katalyst.kubewharf.io/evictable=true 这个 Annotations 的 Pod 中选择驱逐 enableNumaLevelEviction: true # 开启按照 Per Numa 的内存压力感知与驱逐策略 ``` 2. 执行如下命令，创建 AQC。 ```Bash kubectl apply -f adminqosconfiguration-test.yaml ``` 3. 创建 KCC 对象，用于描述 AQC 的 Group、Version、Resource（GVR）信息和托管行为。示例 YAML 文件`katalystcustomconfig-test.yaml`如下所示。 ```YAML apiVersion: config.katalyst.kubewharf.io/v1alpha1 kind: KatalystCustomConfig metadata: name: katalyst-config # 固定值，KatalystCustomConfig 对象名称 namespace: katalyst-system # 固定值，KatalystCustomConfig 对象所属的命名空间 labels: vke.node.katalyst.deploy: "true" # 固定值，节点池配置精细化资源管理特性相关 Label spec: nodeLabelSelectorAllowedKeyList: #开启 AdminQoSConfiguration，支持通过 nodeLabelSelector 选择节点的 Label 白名单 - priority: 10 # 用于定义当多个 adminqosconfigurations 匹配一个节点时，下面 Label Key 的优先级，数值越大优先级越高 keyList: # 定义对应优先级下支持的 Label Key 列表 - katalyst.kubewharf.io/overcommit_node_pool targetType: # 固定值，描述 AdminQosConfiguration 的 GVR 信息 group: config.katalyst.kubewharf.io resource: adminqosconfigurations version: v1alpha1 ``` 4. 执行如下命令，创建 KCC。 ```Bash kubectl apply -f katalystcustomconfig-test.yaml ``` 完成上述配置后，系统进行压力感知与驱逐行为，具体说明如下： * CPU 压力感知与驱逐策略： * 每 5s 进行一次 CPU 的压力探测，如果过去 10 个探测周期有 8 个及以上的 CPU usage 指标达到 usageUpperBoundRatio（上方示例配置为 0.8），则触发驱逐。 * 两次驱逐 Pod 的冷却时间间隔为 300s，即如果发生一次驱逐，则 300s 内不会再驱逐 Pod。 * 发生驱逐时，会给对应的节点打上`node.katalyst.kubewharf.io/SystemCPU`污点，表示禁止调度到该节点。 * DaemonSet Pod 不会被驱逐。 * Per Numa 内存压力感知与驱逐策略： * 读取`/porc/zoneinfo`中的 NUMA 内存水位值`free`、`low`、`min`值。 * 当连续 12 个周期（每个周期 5s）探测到`min`<`free`<`low` 时，触发内存驱逐。 * 当探测到`free`<`min`时，快速增加计数到驱逐前一周期，即下一周期再探测到`free`<`low`则触发驱逐。 * DaemonSet Pod 不会被驱逐。 ## 验证结果 1. 查看 NOC 的`status` 字段，验证节点与 NOC 的匹配关系。 ```Bash kubectl get noc nodeovercommit-test -o jsonpath='{.status.matchedNodeList}' ``` 预期输出如下图： ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_e77a19b47eaff5e79ebf658f7fe03b33.png) 2. 若指定了节点的 CPU 和内存的放大系数，可以查看对应 Node 上和放大系数相关的 Annotation。 ```Bash kubectl get node ${NODE_NAME} -o jsonpath='{.metadata.annotations}' ``` 预期输出如下： ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_b8f8bf15fdf14f547f19004f97aefa92.png) 3. 验证节点的 Capacity/Allocatable 是否被放大。 ```Bash # 查看节点实际资源量 kubectl get node ${NODE_NAME} -o jsonpath='{.status.capacity}' kubectl get node ${NODE_NAME} -o jsonpath='{.status.allocatable}' ``` 预期输出如下： ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_fc29165931d298340ad10573147626b2.png) ## 附录 ### 核心指标动态放大及预测能力相关核心指标如下所示。 Controller 指标 Controller 的指标名称及含义如下表所示。 |**指标名** |**类型** |**标签** |**含义与度量方式** | |---|---|---|---| |noc_matched_nodes |Gauge |config_name |每个 NodeOvercommitConfig 当前匹配的节点数。 | |noc_realtime_cpu_overcommit_ratio |Gauge |node |实时 CPU 放大系数。 | |noc_realtime_memory_overcommit_ratio |Gauge |node |实时 Memory 放大系数。 | |noc_predict_cpu_overcommit_ratio |Gauge |node |预测 CPU 放大系数。 | |noc_predict_memory_overcommit_ratio |Gauge |node |预测 Memory 放大系数。 | Webhook 指标 Webhook 的指标名称及含义如下表所示。 |**指标名** |**类型** |**标签** |**含义与度量方式** | |---|---|---|---| |node_mutator_request_total |Counter |type=nodeAllocatableMutator |Webhook 请求总数（含成功和失败）。 | |node_mutator_request_fail |Counter |type=nodeAllocatableMutator |mutate 处理失败数。 | |node_mutator_latency |Counter |type=nodeAllocatableMutator |mutate 耗时，递增值，使用 irate 函数。 | Agent 指标 Agent 的指标名称及含义如下表所示。 |**指标名** |**类型** |**标签** |**含义与度量方式** | |---|---|---|---| |realtime_overcommit_advisor_update_fail |Counter |node |实时放大系数上报（update）失败次数。 | |realtime_overcommit_advisor_update_total |Counter |node |实时放大系数上报（update）总次数。 | ### 放大资源计算 |

符号

含义

计算方式说明

| |---|---|---| |A₀ |节点放大前可分配资源 |A₀ = 节点规格 \- 系统预留

说明

系统预留资源说明，请参见节点预留资源策略。

说明

动态放大系数不会超过静态放大系数。

| |O |独占资源

|目前仅计算独占核 Pod 的资源，即节点 kubelet 参数已配置`cpu-manager-policy=static`。

说明

节点 kubelet 参数cpu-manager-policy相关说明，请参见配置节点池 Kubelet 参数。

| |Q |节点已分配 Request |节点上所有 Pod 的 CPU 或 Memory 请求总和（排除独占核 Pod 的资源）。 | |L |Pod 平均负载率 |L = U ÷ Q

说明

为了避免放大系数过于激进，VKE 在计算节点上 Pod 平均负载率时设置了如下下限值：

内存：1/2

CPU：1/3