运维人的日常之一次 K8s 磁盘故障的惊魂夜

首页

科技数码

热心网友

转载

2025-09-05

迷迷糊糊中拿起手机,眼皮还没完全睁开，就看到满屏的告警,Prometheus那边已经炸了——trade-service的错误率飙到了85%以上。没办法拿人钱财与人消灾,操练起来吧。

事件起因

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

23年3月的某个该死的一天,而且是该死的凌晨两点，值班人员忽然来电话，公司主力产品的某大型在线对战游戏部分玩家在拍卖行交易时，界面一直停在“提交中”，页面卡死，整个流程卡住了。”好!知道了~“，迷迷糊糊中拿起手机,眼皮还没完全睁开，就看到满屏的告警,Prometheus那边已经炸了——trade-service的错误率飙到了85%以上。没办法拿人钱财与人消灾,操练起来吧。

废话少说直接来干货!先声明这个K8s集群的版本是v1.24.8。

排查过程

先从集群角度看看都什么情况!

kubectl get nodes -o wide显示worker-node-7状态为DiskPressure该节点运行着交易服务的核心事务处理的Pod。

执行驱逐检查：

kubectl describe node worker-node-7 | grep -i evicted # 发现12个Pod因磁盘压力被驱逐

Elastic Stack日志分析发现连续错误：[FATAL] Transaction commit failed: Input/output error

再从问题节点上看看什么情况。

SSH登录worker-node-7随手就是一个技能：

df -hT /var/lib/kubelet # 显示使用率100%

嚯!~接下来必须看看是哪个或者哪些大文件导致的?：

ncdu -x /var/lib/docker/overlay2 # 发现某容器日志文件占用52GB

那我删?别忙,别动!老运维的直觉,感觉有埋伏.那我必须再一个技能

sudo smartctl -a /dev/nvme0n1 | grep -e 'Media_Wearout_Indicator' -e 'Reallocated_Sector_Ct'

Reallocated_Sector_Ct 0x0033 086 086 000 Pre-fail Always FAILING_NOW 142

我勒个去.迷糊不?子母雷呀!磁盘有142个坏道。

这时候不能处理奥!这时候就想起了IT运维技术圈的博主老杨对我的谆谆教诲:“不要看到一个毛病就下手,一定要尽量的查,全查明白了,然后再反馈,然后再按照领导的决定去执行”记得前一阵子刚升级了k8s集群版本,咋就这么巧出了问题呢?我再仔细摸一下集群的配置.那边总监已经开始在群里各种哀嚎了.不过一定要稳住,稳住!

我再确认一下集群的配置：

ps aux | grep kubelet | grep -o 'eviction-hard=.*' # 输出'imagefs.available<10%,nodefs.available<5%'第三颗雷被我找到了.查了一下K8s v1.24.8的新特性,默认是禁用SMART的journalctl -u kubelet | grep 'eviction_manager'显示日志轮转失效警告

到这可以做阶段总结了：

硬件老化失效：NVMe SSD出现严重坏道，I/O故障直接影响服务。K8s存储感知缺失：集群未启用本地存储容量隔离特性，无法及时预警磁盘异常。资源限额与日志治理缺陷：Pod未设定存储限额，日志文件无轮转，导致磁盘空间被单一容器异常占用。

行了,该总监上场了,把自己看到的和认为合理的处理办法告诉它,得到了“汪汪“的回复,并且给出了“汪汪”的建议,以及“汪汪”的指导后，开始操作。

一顿反摇拳

干掉worker-node-7节点,但一定要优雅。

标记节点不可调度：

kubectl taint nodes worker-node-7 diskfailure=true:NoSchedule

驱逐Pod：

kubectl drain worker-node-7 --ignore-daemonsets --grace-period=300

临时用badblocks和e2fsck标记坏块，强行让文件系统跳过这些坑bash badblocks -sv /dev/nvme0n1 # 标记坏块 e2fsck -c /dev/nvme0n1 # 强制文件系统跳过坏道。

日志全清空：

truncate -s 0 /var/lib/docker/containers/*/*-json.log

直接用ArgoCD把trade-service重新部署了一遍。

使用ArgoCD触发自动重部署：

argocd app actions run trade-service --kind Rollout --action restart

数据库那边也没敢大意，特地跑了个一致性校验：

kubectl exec trade-db-0 -- pg_checkconsistency -v

等到凌晨四点半，监控大屏上的交易成功率终于回升，玩家投诉也慢慢消停了。第二天直接休了一天!~

复盘

复盘会上没什么好撕的,根因就上面那些!做了下面的几个方向的改进。

写了个磁盘检查脚本(罗列一下大概意思,不喜勿喷)disk_health_monitor.sh：

#!/bin/bash# 设备自动发现（兼容NVMe/SATA）DEVICES=$(lsblk -d -o NAME,TYPE | grep disk | awk '{print "/dev/"$1}')ALERT_FLAG=0for DEV in$DEVICES; do# SMART健康检查（带重试机制）for i in {1..3}; do SMART_REPORT=$(smartctl -H $DEV 2>/dev/null) [ $? -eq 0 ] && break || sleep 5done# 关键参数解析 REALLOC=$(smartctl -A $DEV | grep 'Reallocated_Sector_Ct' | awk '{print $10}') WEAR_LEVEL=$(smartctl -A $DEV | grep 'Wear_Leveling_Count' | awk '{print $4}' | tr -d '%')# 多维度健康评估ifecho$SMART_REPORT | grep -q "FAILED"; then logger "[DISK CRITICAL] $DEV SMART failed!" ALERT_FLAG=1elif [ $REALLOC -gt 50 ]; then logger "[DISK WARNING] $DEV Realloc sectors: $REALLOC" ALERT_FLAG=1elif [ $WEAR_LEVEL -lt 10 ]; then logger "[DISK WARNING] $DEV Wear level: $WEAR_LEVEL%" ALERT_FLAG=1fidone# 联动K8s节点标记if [ $ALERT_FLAG -eq 1 ]; then NODE_NAME=$(hostname) kubectl label nodes $NODE_NAME disk-status=critical --overwrite curl -X POST -H "Content-Type: application/json" -d '{"text":"磁盘健康告警！"}'$WEBHOOK_URLfi

(1) 修改k8s集群配置

启用特性门控（/etc/kubernetes/kubelet.conf）：

featureGates: LocalStorageCapacityIsolation:true

部署存储限额策略：

apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata: name:high-storagevalue:1000000ephemeral-storage-limit:5Gi # 每个Pod限制5GB临时存储

(2) 日志生态系统重构

部署Loki+Promtail替代Docker原生日志：

helm upgrade --install loki grafana/loki-stack --set promtail.enabled=true

添加日志自动清理CronJob：

apiVersion:batch/v1kind:CronJobspec:schedule:"0 */4 * * *"jobTemplate: spec: containers: -name:log-cleaner image:alpine:3.14 command: ["find", "/var/log/containers", "-size +500M", "-delete"]