在 Kubernetes 中，为节点上的系统组件（如 kubelet、containerd、内核进程等）预留资源是保障集群稳定性的关键配置。通过kubelet的启动参数（--system-reserved、--kube-reserved等）可实现资源预留，避免应用容器耗尽节点资源导致系统组件崩溃。以下是详细配置方法和资源预留建议：
一、核心配置参数：系统资源预留的关键参数
kubelet通过以下参数控制节点资源预留，需在节点的kubelet配置文件（通常是
/var/lib/kubelet/config.yaml）或启动参数中设置：
参数 | 作用范围 | 典型配置项（示例） |
--system-reserved | 为节点级系统组件预留资源（如内核进程、containerd、sshd 等 OS 级进程） | cpu=500m,memory=1Gi,ephemeral-storage=10Gi |
--kube-reserved | 为Kubernetes 自身组件预留资源（如 kubelet、kube-proxy、coredns 等） | cpu=100m,memory=256Mi |
--eviction-hard | 节点资源不足时的硬驱逐阈值（触发后立即驱逐 Pod），间接保护系统资源 | memory.available<500Mi,nodefs.available<10% |
--eviction-soft | 节点资源不足时的软驱逐阈值（给予宽限期后驱逐 Pod） | memory.available<1Gi（配合 |
二、配置步骤（以config.yaml为例）
- 修改 kubelet 配置文件
在每个节点上编辑kubelet的配置文件（路径可能因部署方式不同而变化，如/var/lib/kubelet/config.yaml或/etc/kubernetes/kubelet.conf），添加资源预留参数：
systemReserved:
cpu: 500m # 为系统组件预留0.5核CPU
memory: 1Gi # 为系统组件预留1GB内存
ephemeral-storage: 10Gi # 为临时存储预留10GB磁盘空间
kubeReserved:
cpu: 100m # 为K8s组件预留0.1核CPU
memory: 256Mi # 为K8s组件预留256MB内存
evictionHard:
memory.available: "500Mi" # 当节点可用内存低于500Mi时，立即驱逐Pod
nodefs.available: "10%" # 当节点根目录可用空间低于10%时，立即驱逐Pod
imagefs.available: "15%" # 当容器镜像存储可用空间低于15%时，立即驱逐Pod- 重启 kubelet 服务
配置生效需重启kubelet：
systemctl daemon-reload
systemctl restart kubelet- 验证配置
kubectl get --raw /api/v1/nodes/$(hostname)/proxy/configz | jq '.kubeletconfig|.systemReserved, .kubeReserved'或者通过命令查看：
journalctl -u kubelet | grep -i "systemReserved"三、资源预留的合理数值建议
预留资源的多少取决于节点的总资源（CPU 核心数、内存大小）和节点角色（如是否为控制平面节点、是否运行核心应用），以下是通用参考：
1. 按节点总资源比例预留（适用于业务节点）
节点总资源 | CPU 预留（system + kube） | 内存预留（system + kube） | 临时存储（ephemeral-storage） |
2 核 4GB（小型节点） | 500m（0.5 核） | 1Gi（25% 总内存） | 10Gi |
4 核 8GB（中型节点） | 1000m（1 核） | 2Gi（25% 总内存） | 20Gi |
8 核 16GB（大型节点） | 2000m（2 核） | 4Gi（25% 总内存） | 50Gi |
16 核 32GB 及以上 | 4000m（4 核） | 8Gi（25% 总内存） | 100Gi |
2. 控制平面节点（Master）需额外预留
控制平面节点运行 apiserver、etcd、scheduler 等核心组件，资源消耗更高，建议预留更多资源：
- CPU：至少 2 核（专用控制平面节点）
- 内存：至少 4Gi（etcd 对内存需求较高，避免因内存不足导致数据丢失）
四、关键注意事项
- 内存预留必须优先保证
系统组件（如 containerd）和 K8s 组件（如 kubelet）对内存不足非常敏感：内存不足会导致 containerd 崩溃（无法启动容器）、kubelet 与 apiserver 通信中断。因此，内存预留需 “保守”，建议不低于节点总内存的 20%~25%。 - CPU 预留可适当灵活
CPU 资源是 “可压缩资源”（不足时会被限流，不会直接崩溃），因此 CPU 预留可略低，但需确保系统组件在高负载时能获得足够 CPU（如节点压力大时，kubelet 需要 CPU 处理 Pod 驱逐逻辑）。 - 临时存储（ephemeral-storage）不可忽视
容器的日志、临时文件会占用节点的本地存储（通常是/var/lib/docker或/var/lib/containerd目录）。若不预留临时存储，可能导致节点磁盘满，进而引发容器启动失败、日志写入失败等问题。建议预留节点总磁盘的 10%~20%。 - 结合驱逐阈值（Eviction Thresholds）
资源预留是 “预防”，驱逐阈值是 “最后防线”。例如，即使配置了内存预留 1Gi，若应用异常占用内存，仍可能耗尽剩余资源，此时eviction-hard会触发 Pod 驱逐，释放资源给系统组件。内存驱逐阈值建议设置为：memory.available < 500Mi（小型节点）或1Gi（大型节点）。磁盘驱逐阈值建议：nodefs.available < 10%（根目录）和imagefs.available < 15%（镜像存储目录）。 - 不同节点差异化配置
生产环境中，节点可能分为 “核心应用节点” 和 “非核心应用节点”，核心节点需预留更多资源（例如内存预留提高到 30%），避免核心业务受影响。
总结
为 K8s 节点的系统组件预留资源是生产环境的强制配置，核心原则是：内存优先、保守预留，CPU 适度、灵活调整。具体数值需根据节点规格和业务重要性调整，并通过监控（如 Prometheus 的
node_memory_MemAvailable_bytes指标）持续验证预留是否合理，避免因资源不足导致集群稳定性问题。