tencent cloud

容器服务

动态与公告
产品动态
公告
产品发布记录
产品简介
产品概述
产品优势
产品架构
应用场景
产品功能
基本概念
原生 Kubernetes 名词对照
容器服务高危操作
地域和可用区
开源组件
购买指南
购买指引
购买 TKE 标准集群
购买原生节点
购买超级节点
快速入门
新手指引
快速创建一个标准集群
入门示例
容器应用部署 Check List
集群配置
标准集群概述
集群管理
网络管理
存储管理
节点管理
GPU 资源管理
远程终端
应用配置
工作负载管理
服务和配置管理
组件和应用管理
弹性伸缩
容器登录方式
可观测配置
运维可观测性
成本洞察和优化
调度配置
调度组件概述
资源利用率优化调度
业务优先级保障调度
Qos 感知调度
安全和稳定性
容器服务安全组设置
身份验证和授权
应用安全
多集群管理
计划升级
备份中心
云原生服务指南
云原生 etcd
Prometheus 监控服务
TKE Serverless 集群指南
TKE 注册集群指南
实践教程
集群
Serverless 集群
调度
安全
服务部署
网络
发布
日志
监控
运维
Terraform
DevOps
弹性伸缩
容器化
微服务
成本管理
混合云
AI
故障处理
节点磁盘爆满排障处理
节点高负载排障处理
节点内存碎片化排障处理
集群 DNS 解析异常排障处理
集群 Kube-Proxy 异常排障处理
集群 API Server 网络无法访问排障处理
Service&Ingress 网络无法访问排障处理
Service&Ingress 常见报错和处理
Nginx Ingress 偶现 Connection Refused
CLB Ingress 创建报错排障处理
Pod 网络无法访问排查处理
Pod 状态异常与处理措施
授权腾讯云售后运维排障
CLB 回环问题
API 文档
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
常见问题
TKE 标准集群
TKE Serverless 集群
运维类
隐患处理
服务类
镜像仓库类
远程终端类
事件类
资源管理类
服务协议
TKE Service Level Agreement
TKE Serverless Service Level Agreement
联系我们
词汇表
文档容器服务集群配置节点管理常用操作节点资源预留算法（新）

节点资源预留算法（新）

PDF
聚焦模式
字号
最后更新时间： 2024-12-26 17:57:19
TKE 需要占用节点的一部分资源来运行相关组件（例如：kubelet、kube-proxy、Runtime 等），因此节点的总资源与集群中可分配的资源之间会存在差异。本文主要介绍 TKE 集群中 Kubernetes 版本在1.30及以上节点的新资源预留算法，帮助用户在部署应用时合理设置 Pod 的请求资源量和限制资源量。

适用范围

本算法适用于集群 kubernetes 版本在1.30及以上的普通和原生节点。

定义

整机使用资源 = 维持节点运行的系统进程占用资源 + Pod 运行占用资源
注意：
本文主要讨论“维持节点运行的系统进程占用资源”的预留算法。

节点 CPU 预留规则

由于 CPU 是可压缩资源且存在部分 perCPU 的内核线程，我们尽量保持算法的一致性，并在大规格机型上提供更多的资源。更新后的算法如下：
第一个核心的6%。
下一个核心（最多2个核心）的1%。
接下来2个核心（最多4个核心）的0.5%。
4个以上任何核心数量的0.25%。
需注意，在小规格机器上创建过多的 Pod 可能会导致预留的 CPU 过少，从而影响系统稳定性。以下行为也可能会占用系统资源，可以使用自定义参数适当调整预留的资源情况：
容器打印过多日志（容器日志通过 pipe 交给 containerd，最终由 kubelet 压缩落盘）。
exec probe 执行过于频繁（如每秒一次，exec probe 通过 runc 在容器中执行命令，因此可能会占用大量的 CPU）。
在节点上部署其他服务（非 Pod 管理的服务会占用节点预留资源，从而导致系统不稳定）。
新旧算法在 CPU 资源占用情况的对比如下：
CPU（核）
旧算法
新算法
1
0.1
0.06
2
0.1
0.07
4
0.1
0.08
8
0.2
0.09
16
0.4
0.11
32
0.8
0.15
64
1.6
0.23
128
2.4
0.39
256
3.04
0.71

节点 Mem 预留规则

Memory 是不可压缩资源，设置预留内存时应较为谨慎。经过测试内存和 Pod 数量、机器规格紧密相关，调整新算法为：min(旧算法，20MiB * Pod 数量 + 256MiB)。注意在节点上部署其他服务也可能会占用节点预留资源，导致节点稳定性降低。如果需要部署非 Pod 管理的服务，建议调整预留资源。
新旧算法在 Mem 资源占用情况的对比如下：
内存大小
（GiB）
旧算法
16个 pod
（GiB）
32个 pod
（GiB）
64个 pod
（GiB）
128个 pod
（GiB）
256个 pod
（GiB）
1
0.25
0.25
0.25
0.25
0.25
0.25
2
0.5
0.5
0.5
0.5
0.5
0.5
4
1
0.58
0.9
1
1
1
8
1.8
0.58
0.9
1.54
1.8
1.8
16
2.6
0.58
0.9
1.54
2.6
2.6
32
3.56
0.58
0.9
1.54
2.82
3.56
64
5.48
0.58
0.9
1.54
2.82
5.38
128
9.32
0.58
0.9
1.54
2.82
5.38
256
11.88
0.58
0.9
1.54
2.82
5.38

常见问题

新旧算法有什么差异？

旧算法：根据机器规格为资源预留固定值，详情请参见 资源预留说明。算法相对保守，预留资源量较大，用户可以给业务使用的资源量较低。
新算法：通过调整 Pod 数在不同规格机器上进行大规模压测获得资源预留公式，新算法在大规格机型上提供更多的资源给业务使用。

关于设置 kube-reserved 且不设置 system-reserved 的解释

kubelet 将 capacity - kubeReserved - systemReserved - evictionHard 作为节点可分配资源，用来控制 Pod 可用到的资源量。按照文档，kubeReserved 可用来限制 kubelet 和运行时组件的资源使用量、systemReserved 可用来限制系统服务资源量，但生效的前提是需要开启 enforce-node-allocatable 并指定 kube-reserved-cgroup 和 system-reserved-cgroup ，这对系统的 cgroup 布局有额外要求。同时，社区官方和众多云厂商出于对整体稳定性考量，并不会启用这两种限制。因此 TKE 也不会对 kubelet 组件和系统组件进行资源限制，同样 reserved 的资源完全设置在 kube-reserved 上还是 kube-reserved 和 system-reserved 各占一部分实际的效果没有区别。

新算法是否支持对低版本节点生效？

暂不支持。存量节点后续可以通过节点升级来体验新算法。
上一篇: 节点生命周期下一篇: 节点资源预留说明

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈