迷迷糊糊中拿起手机,眼皮还没完全睁开，就看到满屏的告警,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"]
最终状态
后续研发通过Redis事务补偿机制自动修复2,317笔中断交易。叉会腰,这次可给我牛批坏了!
