kubernetes 节点磁盘空间 剩余不足10% 15% 时触发驱逐,跟k8s磁盘空间阈值 nodefs.available 和imagefs.available有关
关于 Kubernetes 中 nodefs.available
的详细解析如下:
1. 基本定义与作用
-
nodefs
是什么
nodefs
是 Kubernetes 节点的主文件系统,通常对应根文件系统(/
),用于存储以下内容:- 本地持久化卷(
Local Persistent Volume
) - 非内存介质的
emptyDir
卷 - Kubernetes 组件日志(如 kubelet 日志)
-
/var/lib/kubelet
目录(Pod 的元数据、Volume 挂载信息等)。
- 本地持久化卷(
nodefs.available
的含义
nodefs.available
表示节点主文件系统的可用空间百分比或绝对值。当该值低于设定阈值时,kubelet 会触发驱逐 Pod 的流程以回收磁盘资源。
2. 默认阈值与版本差异
默认硬驱逐阈值
根据 Kubernetes 官方文档,默认硬驱逐阈值为nodefs.available < 10%
(Linux 节点)。这与用户提到的 15% 不同,可能混淆了其他参数(如imagefs.available
默认阈值为 15%)。-
版本差异
- Kubernetes 1.15 及之前版本:根目录默认阈值为 90%(即使用量超过 90% 触发驱逐)。
- Kubernetes 1.16 及之后版本:默认阈值调整为
nodefs.available < 10%
。
3. 驱逐触发行为
硬驱逐(Hard Eviction)
达到硬阈值时,kubelet 会立即终止 Pod,不等待优雅终止期(terminationGracePeriodSeconds
),直接使用0s
宽限期强制删除。-
驱逐顺序
kubelet 按以下优先级驱逐 Pod:- 非关键本地存储卷 Pod:优先驱逐使用本地存储但无副本的 Pod。
- 最近最少使用(LRU)的 Pod:选择最久未活跃的低优先级 Pod。
- 低优先级运行中的 Pod:基于 QoS 等级(BestEffort → Burstable → Guaranteed)。
4. 配置与调优
-
修改阈值
通过修改 kubelet 启动参数中的--eviction-hard
或--eviction-soft
调整阈值:--eviction-hard=nodefs.available<5%,memory.available<500Mi
可通过百分比或绝对值指定(如
10%
或1Gi
)。 -
软驱逐配置(Soft Eviction)
允许设置宽限期(grace period),例如:--eviction-soft=nodefs.available<15% --eviction-soft-grace-period=nodefs.available=2m
若资源压力持续超过宽限期,则会触发驱逐。
5. 监控与日志
-
查看驱逐日志
- 检查 kubelet 日志:
journalctl -xu kubelet | grep "eviction"
- 系统日志关键字:
grep -i "nodefs.available" /var/log/messages
- 检查 kubelet 日志:
-
节点状态更新
当触发驱逐时,节点状态会更新为DiskPressure
,可通过以下命令查看:kubectl describe node <节点名> | grep Conditions -A 5
6. 注意事项
-
版本兼容性
不同 Kubernetes 版本的默认阈值可能不同,需根据集群版本确认阈值配置。 -
资源预留
建议预留部分磁盘空间(如通过--system-reserved
)避免频繁触发驱逐。 -
静态 Pod 处理
静态 Pod 被驱逐后会尝试重建,但若节点资源持续紧张,可能无法恢复。
总结
nodefs.available
是 Kubernetes 节点磁盘压力的核心监控指标,默认阈值为 10%。合理配置驱逐策略、结合 Pod 优先级与 QoS 等级,可有效平衡集群稳定性和资源利用率。具体实践中需结合日志监控与节点状态调整参数。
关于 Kubernetes 中 nodefs.available
的详细解析如下:
一、基本定义与作用
-
imagefs
是什么
imagefs
是 Kubernetes 节点上的可选文件系统,由容器运行时(如 Docker、Containerd)管理,主要用于存储 容器镜像的只读层 和容器可写层的临时数据(如 OverlayFS 的写入层)。- 典型路径示例:Docker 默认的镜像存储路径为
/var/lib/docker
,Containerd 为/var/lib/containerd
。 - 若未显式配置
imagefs
,容器运行时可能与nodefs
(节点根文件系统)共用同一分区。
- 典型路径示例:Docker 默认的镜像存储路径为
imagefs.available
的含义
imagefs.available
表示imagefs
文件系统的可用磁盘空间百分比或绝对值。当该值低于设定的阈值时,kubelet 会触发驱逐机制,回收资源以缓解磁盘压力。
二、默认阈值与驱逐规则
-
默认硬驱逐阈值
-
imagefs.available < 15%
(Linux 节点):当镜像文件系统的可用空间低于 15% 时,kubelet 会立即强制驱逐 Pod。 -
软驱逐阈值(需手动配置):可通过
--eviction-soft
定义并配合宽限期(如imagefs.available=10%
+eviction-soft-grace-period=2m
),允许资源在超阈值后一定时间内恢复。
-
-
驱逐行为
- 触发驱逐时:kubelet 优先删除未使用的容器镜像以释放空间;若仍无法缓解压力,则按 QoS 等级驱逐 Pod(顺序:BestEffort → Burstable → Guaranteed)。
-
终止策略:硬驱逐会立即终止 Pod,软驱逐则遵循
terminationGracePeriodSeconds
或eviction-max-pod-grace-period
。
三、与 nodefs
的区别
对比项 | imagefs |
nodefs |
---|---|---|
存储内容 | 容器镜像、容器可写层 | kubelet 日志、Pod 元数据、本地持久化卷 |
驱逐阈值 | 默认 15%(硬驱逐) | 默认 10%(硬驱逐) |
优先级 | 次要(优先清理镜像) | 主要(可能直接驱逐 Pod) |
典型路径 |
/var/lib/docker (Docker) |
/var/lib/kubelet |
共用分区影响 | 若与 nodefs 共用,可能导致镜像清理与 Pod 驱逐同时触发 |
需单独监控避免连带影响 |
四、配置与优化建议
-
分区规划
- 建议将
imagefs
与nodefs
隔离到不同磁盘分区,防止镜像膨胀影响节点核心功能。 - 若必须共用分区,需预留充足空间(如不低于 30%)并设置更高驱逐阈值。
- 建议将
-
调整阈值参数
-
硬驱逐阈值:通过 kubelet 参数
--eviction-hard=imagefs.available<10%
自定义。 -
软驱逐阈值:结合宽限期配置(如
--eviction-soft=imagefs.available<20% --eviction-soft-grace-period=imagefs.available=5m
)。
-
硬驱逐阈值:通过 kubelet 参数
-
容器运行时配置
- 调整容器运行时的镜像存储路径(如 Docker 的
--data-root
),确保指向专用磁盘。 - 定期清理无用镜像:通过
docker image prune
或自动化工具(如 CronJob)回收空间。
- 调整容器运行时的镜像存储路径(如 Docker 的
五、监控与异常处理
-
监控指标
-
Prometheus 指标:
kubelet_volume_stats_available_bytes{fs_type="imagefs"}
。 -
节点状态:触发驱逐时节点状态会标记为
DiskPressure
,可通过kubectl describe node
查看。
-
Prometheus 指标:
-
日志排查
-
kubelet 日志:过滤关键词
eviction_manager
或imagefs
,查看驱逐决策过程:journalctl -u kubelet | grep "imagefs.available"
-
容器运行时日志:检查镜像删除操作(如 Docker 的
/var/log/docker.log
)。
-
kubelet 日志:过滤关键词
六、与其他组件的关系
-
containerfs
新特性
Kubernetes v1.33 引入containerfs
概念,进一步拆分容器可写层存储(与imagefs
分离),需启用KubeletSeparateDiskGC
特性门控并配合 CRI-O 运行时。- 优势:更精细的磁盘资源管理,避免镜像与容器数据互相影响。
-
垃圾回收联动
- 旧版垃圾回收参数(如
--maximum-dead-containers
)已废弃,建议通过驱逐机制统一管理。
- 旧版垃圾回收参数(如
总结
imagefs.available
是 Kubernetes 节点存储管理的关键指标,直接影响容器镜像的存储与节点稳定性。合理规划分区、设定阈值并配合监控工具,可有效预防因镜像膨胀导致的集群故障。实际运维中需结合 nodefs
状态综合分析,避免资源争用引发的连锁反应。