空间扩容无效？9年容器运维揭秘3大存储盲区

发布时间：2026-11-10 14:54:57 所属栏目：空间来源：DaWei

导读：　　去年春节，除夕下午三点十七分，我盯着监控面板上那个飘红的 PVC 状态，手边泡面汤已经凉透，浮着一层油花。小孟在微信弹窗里甩来截图：“后台编辑说专题页上传视频总卡住，转圈三分钟——是不是 CDN 问题？” 我没回，把泡面叉

　　去年春节，除夕下午三点十七分，我盯着监控面板上那个飘红的 PVC 状态，手边泡面汤已经凉透，浮着一层油花。小孟在微信弹窗里甩来截图：“后台编辑说专题页上传视频总卡住，转圈三分钟——是不是 CDN 问题？” 我没回，把泡面叉子插进塑料盖里，咔一声。

　　机房空调修了两次，第三次还没修好，冷风从左边风口嘶嘶漏气，右边却热得能烤馒头。老张蹲在 rack 底下换 SATA 线，后脖颈全是汗，他衬衫第三颗纽扣崩开了，但没管——人往后仰的时候，喉结一跳一跳，跟那台挂掉的 Ceph OSD 心跳灯节奏一致。我原以为是 StorageClass 配错了副本数，结果进去一看，replicas: 3 好好的；再查 pv bound 状态……bound 是 bound 了，可 bound 的是块三年前挂过一次坏道、被标记为 degraded 后手动加白名单放行的老盘。这事儿没人提过，连 Kubelet 日志里都只写“volume attached”，不写“attached to disk with SMART errors”。

　　我说这话不是杠，是真见过。上周二凌晨一点，运维群突然炸开——有人执行了 kubectl patch pvc xxx -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'，然后截图发群：“扩容成功！” 结果十分钟不到，业务日志里全在报 write timeout。我连上节点，df -h 看 /var/lib/kubelet/pods/…/volumes/… 还剩 4.3G；du -sh 深挖下去，发现某个 sidecar 把 /dev/shm 占满，用的是 tmpfs，压根不走 PV；它写完还不删，就挂那儿，像个便秘的缓存。你扩 PVC？它根本不吃那套。扩的是 PersistentVolume，它吃的是 shmfs。一个字都不通。

　　那天值班的是阿哲，穿双洗到发灰的蓝拖鞋，脚后跟裂口，走路啪嗒啪嗒。他接了个电话，听两秒就把手机塞进裤兜，说“客户说视频转码队列堵死，让我看 NFS 服务”。我点头，他转身时袖口蹭掉桌上半块瓜子壳——那壳还是腊月二十三我嗑的，一直没扫。后来我们翻了三个小时 CSI driver 的 log，最后发现根本不是 NFS 的事：是本地 hostPath volume mount options 里漏了 nodev,nosuid,noexec，导致某个 Python 脚本偷偷在 /tmp 下解压了一个带 setuid 的 bzip2 包，接着反复 fork 出三百七十二个僵尸进程占满 inodes……而监控只告警 disk usage，不告警 inode usage。谁会想到？没人想。包括我。我原以为只是镜像层太深拉取慢，结果 debug 到凌晨四点，看到 top 里排第一的 PID 对应的 cmdline 居然是 /usr/bin/python3 /tmp/.X11-unix/x.py —— 你看它叫 x.py，但它干的是 rm -rf /tmp/ && sleep 0.3 的循环，还带 backoff jitter。

　　还有更滑稽的：某次扩完空间，业务侧高兴坏了，立刻往新卷里灌数据，灌到第十八秒，Pod 就开始 OOMKilled。他们以为内存配少了，连夜改 requests/limits。其实呢？是 VolumeMount 的 subPath 设错了，指向了个嵌套 symlink 链：/mnt/data → /data → /data-vol → /host/ssd1/vol-7。而 /host/ssd1 本身是 LVM 逻辑卷，底层 PE 已碎片化到单次 allocate 需跨三十多个物理块。K8s 不报错，只悄悄慢；慢到容器启动时 init 容器等不下去，超时退出；退出后 controller 又重建，重建又等，等死循环。这不是 bug，是路径里埋了五层抽象后的自然腐烂。你查 events？Events 写着 “Pod scheduled”，没错；你查 describe？describe 显示 “ContainerCreating”，也没错；错的是你默认“Creating”等于“快好了”。

文章配图，仅供参考

　　小孟昨天又来问，说转载视频的元数据丢了两帧，后台预览黑屏，问我是不是对象存储的 multipart upload 断了。我没答。倒不是不想说，是想起上季度末，我们团队给内容中台推了个自动清理 empty-dir 的 cronjob，结果上线当晚，栏目责编大刘直接冲进机房，手里捏着半张打印纸，纸角卷边，上面手写着“稿子预览打不开！！！”。他站在机柜前抖那张纸，空调漏风声忽大忽小，旁边实习生正蹲着拧一颗滑丝的螺丝，拧了六次，第七次才咬住。那晚我没说话，只默默把 cronjob 的 --exclude=“.mp4” 加了三遍。加完，心里清楚：空间扩容无效？不是扩不动，是你扩的从来不是业务真正卡住的地方。是 path，是 inodes，是那个你以为关机就消失、其实还在内核里赖着不走的 /dev/shm 的鬼影。

　　所以现在，只要看见“扩容成功”的截图，我第一反应不是点开 dashboard，是摸手机看天气——去年春节那会儿，杭州下雨，雨丝斜着扑在机房玻璃上，一道道水痕，像没擦净的日志滚动条。我就盯着那几道水痕，等它自己流干。反正，再点 refresh，也刷不出真正的可用空间。

　　下回要是真得动存储……我打算先去楼下买包烟，坐在消防通道台阶上抽完一支，再回来改 configmap。不是仪式感，是给自己留出十五秒——够我把所有 subPath、所有 mountPropagation、所有宿主机上的 umask 和 fsync 行为，在脑子里重走一遍。毕竟，有些坑，填了十年，还是湿的。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!