事件起因
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因磁盘压力被驱逐1.
Elastic Stack 日志分析发现连续错误：[FATAL] Transaction commit failed: Input/output error
再从问题节点上看看什么情况。
SSH登录worker-node-7随手就是一个技能：
复制
df -hT /var/lib/kubelet # 显示使用率100%1.
嚯!~接下来必须看看是哪个或者哪些大文件导致的?：
复制
ncdu -x /var/lib/docker/overlay2 # 发现某容器日志文件占用52GB1.
那我删?别忙,别动!老运维的直觉,感觉有埋伏.那我必须再一个技能
复制
sudo smartctl -a /dev/nvme0n1 | grep -e Media_Wearout_Indicator -e Reallocated_Sector_Ct1.
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
显示日志轮转失效警告1.2.3.4.5.
到这可以做阶段总结了：
硬件老化失效：NVMe SSD出现严重坏道，I/O故障直接影响服务。K8s存储感知缺失：集群未启用本地存储容量隔离特性，无法及时预警磁盘异常。资源限额与日志治理缺陷：Pod未设定存储限额，日志文件无轮转，导致磁盘空间被单一容器异常占用。
行了,该总监上场了,把自己看到的和认为合理的处理办法告诉它,得到了“汪汪“的回复,并且给出了“汪汪”的建议,以及“汪汪”的指导后，开始操作。
一顿反摇拳
干掉worker-node-7节点,但一定要优雅。
标记节点不可调度：
复制
kubectl taint nodes worker-node-7 diskfailure=true:NoSchedule1.
驱逐Pod：
复制
kubectl drain worker-node-7 --ignore-daemonsets --grace-period=3001.
临时用badblocks和e2fsck标记坏块，强行让文件系统跳过这些坑bash badblocks -sv /dev/nvme0n1 # 标记坏块 e2fsck -c /dev/nvme0n1 # 强制文件系统跳过坏道。
日志全清空：
复制
truncate -s 0 /var/lib/docker/containers/*/*-json.log1.
直接用ArgoCD把trade-service重新部署了一遍。
使用 ArgoCD 触发自动重部署：
复制
argocd app actions run trade-service --kind Rollout --action restart1.
数据库那边也没敢大意，特地跑了个一致性校验：
复制
kubectl exec trade-db-0 -- pg_checkconsistency -v1.
等到凌晨四点半，监控大屏上的交易成功率终于回升，玩家投诉也慢慢消停了。第二天直接休了一天!~
复盘
复盘会上没什么好撕的,根因就上面那些!做了下面的几个方向的改进。
写了个磁盘检查脚本(罗列一下大概意思,不喜勿喷)disk_health_monitor.sh：
复制
#!/bin/bash
# 设备自动发现（兼容NVMe/SATA）
DEVICES=$(lsblk -d -o NAME,TYPE | grep disk | awk {print "/dev/"$1})
ALERT_FLAG=0
for DEV in$DEVICES; do
# SMART健康检查（带重试机制）
for i in {1..3}; do
SMART_REPORT=$(smartctl -H $DEV 2>/dev/null)
[ $? -eq 0 ] && break || sleep 5
done
# 关键参数解析
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=1
elif [ $REALLOC -gt 50 ]; then
logger "[DISK WARNING] $DEV Realloc sectors: $REALLOC"
ALERT_FLAG=1
elif [ $WEAR_LEVEL -lt 10 ]; then
logger "[DISK WARNING] $DEV Wear level: $WEAR_LEVEL%"
ALERT_FLAG=1
fi
done
# 联动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_URL
fi1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.
(1) 修改k8s集群配置
启用特性门控（/etc/kubernetes/kubelet.conf）：
复制
featureGates:
LocalStorageCapacityIsolation:true1.2.
部署存储限额策略：
复制
apiVersion:scheduling.k8s.io/v1
kind:PriorityClass
metadata:
name:high-storage
value:1000000
ephemeral-storage-limit:5Gi # 每个Pod限制5GB临时存储1.2.3.4.5.6.
(2) 日志生态系统重构
部署 Loki+Promtail 替代Docker原生日志：
复制
helm upgrade --install loki grafana/loki-stack --set promtail.enabled=true1.
添加日志自动清理CronJob：
复制
apiVersion:batch/v1
kind:CronJob
spec:
schedule:"0 */4 * * *"
jobTemplate:
spec:
containers:
-name:log-cleaner
image:alpine:3.14
command: ["find", "/var/log/containers", "-size +500M", "-delete"]1.2.3.4.5.6.7.8.9.10.
最终状态
后续研发通过 Redis事务补偿机制 自动修复2,317笔中断交易。叉会腰,这次可给我牛批坏了!
