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

IT运维技术圈

发布于 2025-07-02 18:50:38

1920

事件起因 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=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 fi 修改k8s集群配置 • 启用特性门控（/etc/kubernetes/kubelet.conf）：featureGates: LocalStorageCapacityIsolation:true • 部署存储限额策略：apiVersion:scheduling.k8s.io/v1 kind:PriorityClass metadata: name:high-storage value:1000000 ephemeral-storage-limit:5Gi # 每个Pod限制5GB临时存储 日志生态系统重构 • 部署 Loki+Promtail 替代Docker原生日志：helm upgrade --install loki grafana/loki-stack --set promtail.enabled=true • 添加日志自动清理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"] 最终状态 后续研发通过 Redis事务补偿机制 自动修复2,317笔中断交易。叉会腰,这次可给我牛批坏了!