- 当前位置：首页 >系统运维 >运维人的日常之一次 K8s 磁盘故障的惊魂夜
运维人的日常之一次 K8s 磁盘故障的惊魂夜
发布时间：2025-11-04 23:37:19 来源：技术快报 作者：IT科技
-
事件起因
23年3月的人的日常某个该死的一天,而且是该死的凌晨两点，值班人员忽然来电话，磁盘公司主力产品的故障某大型在线对战游戏部分玩家在拍卖行交易时，界面一直停在“提交中”，魂夜页面卡死，人的日常整个流程卡住了。磁盘”好!知道了~“，故障迷迷糊糊中拿起手机,魂夜眼皮还没完全睁开，就看到满屏的人的日常告警,Prometheus那边已经炸了——trade-service的错误率飙到了85%以上。没办法拿人钱财与人消灾,磁盘操练起来吧。
废话少说直接来干货!先声明这个K8s集群的故障版本是v1.24.8。
先从集群角度看看都什么情况!
kubectl get nodes -o wide 显示 worker-node-7 状态为 DiskPressure该节点运行着交易服务的魂夜核心事务处理的WordPress模板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笔中断交易。叉会腰,这次可给我牛批坏了!
- Copyright © 2025 Powered by 运维人的日常之一次 K8s 磁盘故障的惊魂夜,技术快报 滇ICP备2023006006号-46sitemap