3. kubelet预留配置详解
在 Kubernetes 节点容量规划中，kubelet 的预留配置是决定节点实际可用资源（Allocatable）的核心机制。如果预留不足，系统组件或 kubelet 本身可能因资源竞争导致节点不稳定；预留过多，则造成 Pod 调度资源浪费。本章深入解析三个关键参数：--system-reserved、--kube-reserved 和 --eviction-hard，并说明它们如何协同工作以保障节点健康。
3.1 节点资源预留模型
Kubernetes 节点资源分配遵循分层模型：
- Node Capacity：节点物理资源总量（CPU、内存、磁盘等）。
- System Reserved：为操作系统守护进程（sshd、systemd、内核等）预留的资源。
- Kube Reserved：为 Kubernetes 组件（kubelet、容器运行时、node-problem-detector 等）预留的资源。
- Eviction Threshold：触发 Pod 驱逐的硬性资源阈值。
- Allocatable：最终可供调度 Pod 使用的资源量。
计算公式如下：
Allocatable = Node Capacity - System Reserved - Kube Reserved - Eviction Threshold3.2 --system-reserved：操作系统资源预留
该参数为节点上的非 Kubernetes 系统进程预留资源。典型占用包括：
| 组件类别 | 典型进程 | 资源消耗特征 |
|---|---|---|
| 系统初始化 | systemd、init | 固定少量内存，CPU 低 |
| 远程管理 | sshd、监控 Agent | 连接数相关，内存波动 |
| 日志与审计 | rsyslog、auditd | 磁盘 I/O 与内存缓冲 |
| 内核与网络 | kworker、netd | CPU 突发，内存稳定 |
配置建议：对于通用 Linux 节点，推荐预留 5%~10% 的 CPU 和 10%~15% 的内存。生产环境应通过 systemd-cgtop 或 top 持续观察 7 天，取 P95 值作为基准。
3.3 --kube-reserved：Kubernetes 组件资源预留
该参数为 kubelet、容器运行时（containerd/docker）、以及 DaemonSet 形式的系统组件（如 kube-proxy、node-problem-detector）预留资源。
| 组件 | CPU 典型值 | 内存典型值 | 说明 |
|---|---|---|---|
| kubelet | 100m ~ 200m | 200Mi ~ 500Mi | 随 Pod 数量线性增长 |
| containerd | 100m ~ 300m | 300Mi ~ 800Mi | 镜像拉取时 CPU 突发 |
| kube-proxy | 50m ~ 100m | 50Mi ~ 150Mi | 随 Service 数量增长 |
| 监控/日志 Agent | 100m ~ 200m | 200Mi ~ 500Mi | 视采集量而定 |
最佳实践：将 --kube-reserved 与 --system-reserved 分开配置，便于审计和调整。如果节点同时运行多个 DaemonSet，需在 kube-reserved 中一并计入。
3.4 --eviction-hard：驱逐硬阈值
当节点资源低于该阈值时，kubelet 立即开始驱逐 Pod，不等待软阈值优雅期。常用驱逐信号：
| 信号 | 默认值 | 单位 | 触发行为 |
|---|---|---|---|
memory.available |
100Mi | 值 | 驱逐 Pod 释放内存 |
nodefs.available |
10% | 百分比 | 驱逐 Pod 释放本地磁盘 |
nodefs.inodesFree |
5% | 百分比 | 防止 Inode 耗尽 |
imagefs.available |
15% | 百分比 | 触发镜像垃圾回收 |
注意：--eviction-hard 设置过低会导致节点 OOM 或磁盘写满，设置过高则浪费资源。建议内存硬阈值不低于 100Mi，磁盘硬阈值不低于 5%。对于镜像拉取密集的节点，imagefs.available 应适当提高至 20% 以上，避免拉取镜像时因磁盘不足失败。
3.5 三参数协同配置示例
以下是一个 16GB 内存、4 核 CPU、100GB 磁盘的节点配置示例：
--system-reserved=cpu=500m,memory=1Gi,ephemeral-storage=10Gi
--kube-reserved=cpu=500m,memory=1.5Gi,ephemeral-storage=10Gi
--eviction-hard=memory.available<500Mi,nodefs.available<10%,imagefs.available<15%
--eviction-soft=memory.available<800Mi,nodefs.available<15%
--eviction-soft-grace-period=memory.available=1m30s,nodefs.available=1m30s计算 Allocatable：
- CPU：4 - 0.5 - 0.5 = 3 核
- 内存：16Gi - 1Gi - 1.5Gi - 0.5Gi（硬阈值）= 13Gi
- 临时存储：100Gi - 10Gi - 10Gi - 10%（10Gi）= 70Gi
关键原则：预留总量（system + kube + eviction）不应超过节点总资源的 30%~40%，否则 Pod 调度密度过低。对于镜像拉取加速场景，建议在 --kube-reserved 中为容器运行时预留充足的磁盘 I/O 和内存，避免拉取时触发驱逐。
3.6 验证与调优方法
- 查看当前预留值：登录节点执行
kubectl describe node <node-name>，查看Capacity与Allocatable差值。 - 监控实际使用：使用
kubectl top node或 Prometheus 采集node_memory_MemAvailable_bytes等指标。 - 压力测试：在测试环境模拟高负载，观察是否触发驱逐或 OOM。
- 调整策略：根据 7 天 P95 使用量，将 system-reserved 和 kube-reserved 设置为该值的 1.2 倍，保留安全余量。
镜像拉取加速关联：当 imagefs.available 硬阈值设置过低时，kubelet 可能在拉取大镜像前就因磁盘不足而驱逐 Pod。建议将 imagefs.available 硬阈值设为 20%，并配合 --image-gc-high-threshold=80 提前触发垃圾回收，保障拉取空间。