K8s 存储在线扩容：PVC 扩容后文件系统未扩展 / 只读文件系统排查

业务数据增长，10Gi 的 PVC 快满了，你在 kubectl edit pvc 里把 storage 改大，结果文件系统根本没变大，甚至有的卷直接变成只读——这是 K8s 存储扩容的两个经典坑。

一、扩容的前提：StorageClass 允许扩容

kubectl get storageclass <name> -o yaml | grep allowVolumeExpansion

必须是 allowVolumeExpansion: true，否则改 PVC 大小会不生效（控制器直接忽略）。

二、扩容操作步骤

kubectl edit pvc <pvc-name>   # 把 spec.resources.requests.storage 改大
kubectl get pvc <pvc-name>    # 状态应变为 FileSystemResizePending / Bound（容量更新）

扩容由 external-resizer（CSI sidecar）完成底层卷扩展，再由 kubelet 在节点上对文件系统执行 resize。

三、坑 1：文件系统没跟着扩大

底层块设备扩大了，但文件系统（ext4/xfs）不会自动变大，需要在线扩展：

# 进到挂载该卷的 Pod / 节点
resize2fs /dev/<device>     # ext4
xfs_growfs /mount/point     # xfs

现代 CSI 驱动（如 resizefs: true 的 node-expand）通常会自动做这步；若没配，就必须手动扩文件系统，否则 df -h 看到的还是老大小。

四、坑 2：文件系统变只读（read-only filesystem）

卷在节点侧发生 I/O 错误（底层存储抖动、网络块存储断连）时，Linux 会把文件系统强制置为只读以保护数据。表现：Read-only file system 报错，写入全部失败。

• 根因通常是后端存储链路异常，而非 K8s 本身；
• 恢复：修复存储链路后，往往需要重启 Pod 让卷重新挂载（重新 mount 才会解除只读标记）；
• 预防：监控节点 dmesg 中的 I/O error、对网络存储配置多路径/高可用。

五、缩容不支持

绝大多数存储后端只支持扩容、不支持缩容（RWO 卷尤其如此）。改小 storage 会被忽略或报错，不要尝试缩容，只能新建大卷 + 迁移数据。

小结

扩容三要素：StorageClass 开 allowVolumeExpansion → 改 PVC → 文件系统 resize2fs/xfs_growfs（或靠驱动自动）。只读文件系统多由后端 I/O 错误触发，修链路 + 重启 Pod 恢复；缩容基本不支持。