在生产环境中,Kubernetes 集群的稳定性很大程度上取决于底层节点的磁盘状况。磁盘空间不足、inode 耗尽、磁盘 IO 饱和或磁盘故障都会导致 Pod 被驱逐、调度失败或应用性能严重下降。要把握集群健康,就必须对节点磁盘状态进行系统化的监控与管理,从指标采集、告警策略、自动化处置到容量规划与恢复流程,构建一套可操作的流程和工具链。 理解需要监控的核心指标是第一步。磁盘使用率包括文件系统级别的总容量、可用空间和已用空间,常见指标名称来自 node-exporter,例如 node_filesystem_size_bytes、node_filesystem_free_bytes、node_filesystem_avail_bytes。inode 使用是另一个常被忽视的维度,node_filesystem_files 和 node_filesystem_files_free 能反映文件数量是否接近上限。
磁盘 IO 性能则体现在读写吞吐量与延迟上,node_disk_read_bytes_total、node_disk_write_bytes_total、node_disk_read_time_seconds_total 与 node_disk_write_time_seconds_total、node_disk_io_time_seconds_total 等指标能帮助判断磁盘是否出现 IO 饱和或延迟增大。另外,容器和卷层面的指标也很重要,kubelet 和 cAdvisor 暴露的 container_fs_usage_bytes、container_fs_limit_bytes 以及 kubelet_volume_stats_available_bytes、kubelet_volume_stats_used_bytes 可以监控 Pod 卷和容器文件系统的使用情况。 搭建监控采集链路时,常见且成熟的组合是 Prometheus + node-exporter + kube-state-metrics + cAdvisor,再配合 Grafana 做可视化和告警。node-exporter 以 DaemonSet 形式运行并挂载宿主机的 /proc、/sys 和需要观察的文件系统路径,确保可以采集到 host 的文件系统数据。kube-state-metrics 提供与 Kubernetes 对象状态相关的指标,帮助把磁盘使用与 PVC、Pod、DaemonSet 等资源关联起来,从而定位问题来源。对于硬盘健康状态(SMART)类指标,可在需要时部署 smartctl-exporter 或自定义脚本,通过 Prometheus node-exporter textfile 模块接入。
告警策略需要结合使用场景与业务宽容度来设定。容量类告警通常分为预警与临界两档,建议对文件系统可用空间设置预警阈值为小于 15% 或可用空间小于几 GB(视节点盘大小而定),临界阈值设置为小于 5% 或可用空间不足以启动关键服务时触发。inode 使用同样需要设定阈值,部分文件密集型场景下 inode 率先耗尽,预警阈值可以设为 15% 以下剩余 inode。IO 性能相关的告警可以监控磁盘 IOPS、读写吞吐量及平均等待时间,IO 等待占比(例如 cpu_iowait 或 disk_io_time 占比)持续高于 20%-30% 可以纳入告警范围。告警表达式在 Prometheus 中可以直接基于 node-exporter 指标写规则,通过 Alertmanager 推到 Slack、邮件或 PagerDuty,确保值班人员能够及时响应。 在预防与自动化处置方面,Kubernetes 本身提供了 kubelet 的驱逐机制(eviction)用于在节点资源紧张时保护关键组件。
通过调整 kubelet 的 evictionHard 和 evictionSoft 配置项,可以在磁盘可用空间或 inode 低于某个阈值时触发 Pod 驱逐。常见配置包括 nodefs.available、imagefs.available、nodefs.inodesFree 等键,合理设置能够在磁盘进入临界前逐步释放空间。除此之外,应在调度层面对容器设置 requests 与 limits,特别是为需要临时存储的任务设置 ephemeral-storage 的资源请求和限制,避免单个 Pod 占满节点磁盘导致全局瘫痪。 日常运维还需要掌握一套快速处置流程。当收到磁盘相关告警时,首先通过 kubectl top nodes 或自定义的监控面板确认是否为节点磁盘压力而非应用层问题。接着使用 kubectl describe node <node-name> 查询节点事件,看是否有 kubelet 的驱逐或警告信息。
若节点确实空间紧张,可先对节点进行 cordon(禁止调度)并逐步 drain(驱逐 Pod),将关键负载搬迁到其他节点以争取手动处理时间。磁盘清理工作要尽量减少对业务影响,可先清理临时文件、旧容器镜像、无效的日志文件。针对容器运行时,可以执行 docker system prune 或对 CRI-O/containerd 使用相应清理命令,同时注意镜像垃圾回收策略以及 kubelet 的 imageGCHighThresholdPercent 与 imageGCLowThresholdPercent 的设置。 日志与指标的治理是防止磁盘问题重复发生的长期对策。将应用日志集中化到外部系统(例如 Elasticsearch、Loki、云对象存储)能显著降低节点本地磁盘压力。配置合理的日志轮转和压缩策略,例如使用 logrotate 或 journald 的 SystemMaxUse 限制,避免单个服务日志无限膨胀。
在容器层面,通过 sidecar 或 log driver 将日志流出集群节点,减少本地日志占用。与此同时,持续采集并分析磁盘相关指标,建立容量增长预估模型,结合业务增长节奏提前扩容。 对于使用云盘或网络存储的场景,监控同时要包含底层存储的性能与容量指标。云厂商一般提供磁盘延迟、IOPS、吞吐量与容量增长的监控 API,应与集群监控对接以实现端到端可视化和告警。对于使用 CSI 驱动的卷,监控 kubelet_volume_stats_* 指标可以反映 PVC 在节点上的使用情况,并应结合 k8s 的 StorageClass、PVC 与 PV 状态来判断是否需要扩容或迁移卷。支持在线扩容的存储后端可以通过扩容 PVC 或改变 StorageClass 策略来解决容量短缺问题,注意扩容后要触发相应的文件系统扩展操作。
在磁盘性能问题排查上,需要同时从系统工具与监控指标两个方向进行验证。利用 iostat、ioping、fio 等工具可以做短时的性能基准测试与延迟测量,从而判断是否存在磁盘故障或物理层瓶颈。SMART 检测可以早期发现硬盘健康问题,针对机械硬盘和 SSD 的 SMART 指标差异要有针对性的解读。将这些诊断结果写进运维台账,并结合 Prometheus 历史指标,可以快速判断问题是短时突发还是长期趋势性恶化。 容量规划和扩容策略需与集群架构相结合。对使用本地磁盘的集群,应避免将系统盘、容器运行时盘与业务数据盘放在同一分区,划分独立分区或独立磁盘可以降低互相影响的风险。
对云原生环境,推荐使用云磁盘或网络存储做持久化数据存储,将节点本地盘主要用于临时文件和容器运行时,降低持久数据因节点故障而受影响的概率。扩容可以通过增加节点、扩容磁盘或调整 Pod 资源分布来实现。自动化扩容建议与集群自动伸缩器结合:在监控到磁盘压力趋势并确认无法通过清理或迁移解决时,触发 Cluster Autoscaler 或云端 API 扩容磁盘。 治理层面的制度同样关键。制定节点磁盘命名空间与配额策略,对需要大量文件创建的任务实施文件管理规范,严格审核对 hostPath、本地 PV 以及 node-level 特权操作的使用权限。在 CI/CD 流程中加入对镜像体积的检查,禁止推送超大镜像到容器仓库或强制使用精简基础镜像,减少镜像拉取和本地缓存带来的磁盘压力。
最后,构建演练与应急预案以减少磁盘事件的业务影响。定期演练节点磁盘满负荷场景、故障迁移与恢复流程,确保运维与开发团队熟悉 cordon、drain、Pod 迁移以及 PV 数据恢复流程。建立稳定的监控与告警闭环,确保告警不被淹没并且可以触达合适的处理人群。通过数据驱动的容量预测、自动化扩容与合理的资源配额,可以将磁盘相关风险降到最低。 综合来看,监控和管理 Kubernetes 节点磁盘状态需要技术手段与流程治理并重。通过完善的指标采集(node-exporter、kubelet、cAdvisor、kube-state-metrics)、合理的告警与自动化驱逐策略、有效的日志与镜像治理、以及针对性的问题排查和容量扩容策略,平台团队可以在磁盘问题发生前预警、发生时快速处置、发生后深挖根因并改进体系。
将这些实践融入日常运维中,能够显著提升 Kubernetes 集群的稳定性与可用性,让底层存储不再成为业务可靠性的短板。 。
