PVC支持在线扩容，PV不可直接修改；实际扩容由底层存储（如EBS、Ceph）执行，Kubernetes通过StorageClass和CSI Driver联动触发块设备扩展与文件系统伸展，全过程对Pod透明，但需满足K8s≥1.11、allowVolumeExpansion:true及底层存储支持三前提。
PVC 能扩，PV 不能直接扩；真正扩容的是底层存储块，Kubernetes 只负责同步状态和触发流程。 MySQL 挂载的 PV 扩容不是改 PV 对象本身，而是通过修改 PVC 的 resources.requests.storage，再由 StorageClass 和 CSI Driver 联动完成底层扩容与文件系统伸展。整个过程对 Pod 透明，但必须满足多个前提，漏掉一个就会卡在 Pending 或容量不生效。
确认 PVC 是否支持在线扩容
不是所有 PVC 都能扩——它取决于三要素是否同时满足：K8s 版本 ≥ 1.11、StorageClass 中 allowVolumeExpansion: true、底层存储后端（如 AWS EBS、Ceph RBD、vSphere CSI）明确支持该操作。
- 检查当前 PVC 状态：
kubectl get pvc mysql-pv-claim -n default，确保STATUS是Bound - 查 StorageClass 名：
kubectl get pvc mysql-pv-claim -n default -o jsonpath='{.spec.storageClassName}' - 验证扩容开关：
kubectl get storageclass，输出必须是-o yaml | grep allowVolumeExpansion true - 特别注意：NFS、hostPath、static PV（
ReclaimPolicy: Retain）基本不支持在线扩容，强行改 PVC 会卡住不动
修改 PVC 的 requests.storage 并触发扩容
扩容动作本质是 patch PVC 的 spec.resources.requests.storage 字段。Kubernetes 控制器检测到变更后，会调用 CSI Driver 的 ControllerExpandVolume 接口，再由 Driver 去扩展底层块设备（如 EBS 卷、RBD image）。
- 直接 patch（推荐，无需编辑 YAML）：
kubectl patch pvc mysql-pv-claim -n default -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}' - 或用
kubectl edit pvc mysql-pv-claim -n default，只改resources.requests.storage这一行，保存退出 - 改完立刻执行：
kubectl get pvc mysql-pv-claim -n default -w，观察CAPACITY列是否从20Gi变为30Gi - 如果卡在
FileSystemResizePending状态，说明底层块已扩，但容器内文件系统还没伸展——这需要 Pod 重启或手动执行resize2fs（见下一条）
MySQL Pod 内文件系统是否自动扩容？
绝大多数 CSI Driver（如 aws-ebs-csi-driver、rook-ceph）会在 Node 上自动调用 resize2fs 或 xfs_growfs，但前提是 Pod 使用的 volumeMount 没加 mountOptions 锁死挂载参数，且文件系统是 ext4/xfs。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 检查 Pod 是否在运行：
kubectl get pod -l app=mysql，若处于Running，通常 resize 已完成 - 进容器验证：
kubectl exec -it，看-- df -h /var/lib/mysql Size是否已更新 - 如果仍显示旧容量，且 PVC 状态是
FileSystemResizePending，最稳妥办法是滚动重启 Pod：kubectl rollout restart statefulset mysql（StatefulSet 场景）或删 Pod 让控制器重建 - ⚠️ 不要手动在容器里跑
resize2fs：MySQL 正在写数据时操作可能损坏文件系统；Node 层的 resize 才是安全路径
为什么扩容后 MySQL 写入还是报 No space left on device？
常见原因不是扩容失败，而是 MySQL 自身配置或数据目录外的临时路径占满磁盘。扩容只影响 PVC 挂载点（如 /var/lib/mysql），不影响 /tmp、/var/log 或容器 rootfs。
- 进 Pod 查全盘使用：
kubectl exec -it，重点看-- df -h /、/tmp、/var/log - 检查 MySQL 是否启用了
tmpdir指向非 PVC 路径（如tmpdir = /tmp），大排序/JOIN 会爆满/tmp - 确认日志轮转是否生效：
slow_query_log_file、general_log_file如果没配logrotate或指向 PVC 外，几个月就填满 - 还有一种隐形情况：扩容前已有大量未 purge 的 binlog 或 relay log，它们虽在
/var/lib/mysql下，但 MySQL 不自动清理，需人工PURGE BINARY LOGS
真正麻烦的从来不是改那一行 storage: 30Gi，而是确认 StorageClass 开关、底层存储兼容性、以及扩容后文件系统是否真正伸展到位——这三个环节任一出问题，都会让 PVC 卡在中间状态，而错误日志往往藏在 kubectl describe pvc 的 Events 里，不是 kubectl get pvc 能看出来的。
