k8s生产配置中的systemReserved 与 kubeReserved

设置原则按硬件规格动态调整而非固定值这两个预留值不应是固定值而应基于节点硬件规格CPU 核数、内存大小和节点角色master/worker动态设定。原因如下系统进程和 Kubernetes 系统组件的资源消耗会随节点规模、运行负载变化。预留过小无法保护系统过大会浪费可分配资源特别是小规格节点上。不同角色节点master vs worker承载的系统组件不同预留需求也不同。因此正确做法是在节点规格确定后根据该规格按比例或经验公式计算预留值并对同构节点池使用相同配置。一旦硬件规格固定且节点池同构该值就可以作为固定配置应用于所有相同规格的节点。推荐的计算方法1. 基于比例的参考值systemReserved为操作系统保留。CPU节点总 CPU 的5% ~ 10%最低不低于100m内存节点总内存的5% ~ 10%最低不低于256MikubeReserved为 Kubernetes 系统组件kubelet、容器运行时、CSI 等保留。CPU节点总 CPU 的5% ~ 10%最低不低于200m内存节点总内存的5% ~ 10%最低不低于256Mi对于k8s的节点2 CPU / 3.5 GiB 内存按上述比例计算systemReserved.cpu 2 × 5% 100m正好最低值systemReserved.memory 3.5Gi × 5% ≈ 179Mi → 取 256Mi最低值kubeReserved.cpu 2 × 5% 100m → 但官方建议 kubeReserved.cpu 不低于 200mkubeReserved.memory 3.5Gi × 5% ≈ 179Mi → 取 256Mi2. 特殊组件额外预留Master 节点需要额外考虑 etcd、kube-apiserver、kube-controller-manager、kube-scheduler 等控制平面组件的资源消耗。etcd 对内存和磁盘 I/O 敏感建议预留更多内存如 512Mi。因此 master 节点的 kubeReserved 可适当调高。Worker 节点系统组件相对较少按基础比例即可。但如果运行了额外的系统级 DaemonSet如监控 agent、日志采集、安全代理也应计入 kubeReserved 或通过资源请求/限制由调度器管理。3. 结合驱逐阈值kubelet 的evictionHard阈值如memory.available 100Mi应与预留值配合确保节点在 OOM 前有足够的缓冲。编辑配置文件重启验证sudo vi /var/lib/kubelet/config.yaml在文件顶层与apiVersion、kind对齐添加配置如下-实际配置示例。sudo systemctl restart kubelet确认 Allocatable 已减少kubectl describe node node-name | grep -A 5 Allocatable实际配置示例小型节点2 CPU / 3.5 GiBsystemReserved: cpu: 100m memory: 256Mi kubeReserved: cpu: 200m memory: 256Mi中型节点4 CPU / 8 GiBsystemReserved: cpu: 200m memory: 512Mi kubeReserved: cpu: 300m memory: 512Mi大型节点8 CPU / 32 GiBsystemReserved: cpu: 400m memory: 1Gi kubeReserved: cpu: 800m memory: 2GiMaster 节点额外考虑 etcdsystemReserved: cpu: 200m memory: 512Mi kubeReserved: cpu: 500m # 包含 etcd、apiserver 等 memory: 1Gi何时可以使用固定值当节点规格完全相同且节点角色一致如同构的 worker 节点池时可以设定统一的固定值。例如所有 worker 节点都是 4C/8G则可以统一配置。但一旦引入不同规格的节点如混合部署 2C/4G 和 4C/8G就需要分别设置。最佳实践将预留值写入自动化配置中如 Ansible、Terraform、kubeadm 配置根据节点规格计算避免人为固定导致不适配。总结预留值应基于硬件规格按比例计算并满足最低值要求。角色不同master/worker需分别考虑。同构节点池可以使用固定值但规格变化时必须调整。配置后应监控节点 Allocatable 使用率必要时动态调整。这样既能保护系统稳定性又能最大化资源利用率。