必须通过 resize 子资源调用 Patch，使用 StrategicMergePatchType 和 JSON 格式 patchData；扩容后需 Watch PVC 状态变更而非立即 Get；并发需限流；文件系统需驱动支持或手动执行 resize。
Go 程序调用 Kubernetes API 扩容 PVC 时，Patch 操作失败报 Invalid value: "patch"
这是最常卡住的第一步：直接用 clientset.CoreV1().PersistentVolumeClaims(ns).Patch(...) 发起扩容请求，却收到 Invalid value: "patch" 错误。根本原因不是权限或字段写错，而是 Kubernetes 对 PVC 容量更新只接受 strategic merge patch 或 json merge patch，且必须通过 /resize 子资源 —— 原生 Patch 方法默认走的是主资源路径，K8s 拒绝该路径上的容量变更。
- 必须用
clientset.CoreV1().PersistentVolumeClaims(ns).Patch(ctx, name, types.StrategicMergePatchType, patchData, metav1.PatchOptions{SubResource: "resize"}) -
patchData必须是 JSON 格式字节切片，形如[]byte(`{"spec":{"resources":{"requests":{"storage":"15Gi"}}}}`)，不能用 map 序列化（易漏字段或类型错） - 集群版本需 ≥ v1.11（
resize子资源引入版本），低于此版本会直接返回NotFound - StorageClass 必须设置
allowVolumeExpansion: true，否则 API 层校验直接拒绝，错误信息是the StorageClass does not allow volume expansion
扩容后 PVC.Status.Capacity 长时间不更新，Go 程序误判为“扩容失败”
调用 resize 成功只代表请求已提交，PVC 实际扩容由 CSI 驱动和底层存储系统异步完成。Kubernetes 控制器会在扩容完成后更新 PVC.Status.Capacity，这个过程可能耗时数秒到数分钟 —— 如果 Go 程序在 Patch 返回后立刻 Get 并比对 Status.Capacity.Storage，几乎必然失败。
- 不要轮询
Get，改用Watch监听PersistentVolumeClaim的MODIFIED事件，过滤出Status.Capacity变更 - Watch 超时建议设为 5–10 分钟，超时后查
PVC.Status.Conditions中是否有Resizing或ResizeFailed条件 - 注意
Status.Capacity是resource.Quantity类型，比较时用q.Cmp(otherQ)，别用字符串或 float64 转换（精度丢失、单位未归一） - 某些 CSI 驱动（如 ceph-csi）在扩容中会把
Status.Phase设为Bound不变，仅靠 Phase 判断不可靠
Go 客户端并发调用多个 PVC 扩容，触发 Kubernetes API Server 限流或 etcd 压力突增
批量扩容场景下，若用 goroutine 直接并发调用 Patch(..., "resize")，容易被 API Server 的 mutating 请求限流拦截（默认 QPS 较低），或导致 etcd 写入毛刺，表现为部分请求返回 TooManyRequests 或延迟飙升。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 务必限制并发数，推荐使用带缓冲 channel 或
semaphore（如golang.org/x/sync/semaphore）控制，单批次 ≤ 5–10 个 PVC - 每次
Patch后加 100–500ms 微小 jitter（非固定 sleep），避免请求在服务端排队形成尖峰 - 不要复用同一个
rest.Config创建多个 clientset，应共用一个 clientset 实例（它本身是线程安全的） - 如果目标 PVC 属于同一 StorageClass 且底层存储支持批处理（如某些云盘 API），优先考虑调用云厂商 SDK 批量操作，绕过 K8s 层
扩容后 Pod 挂载点文件系统未生效，df -h 仍显示旧容量
这是最隐蔽的“假成功”：PVC Status.Capacity 已更新，但容器内 df 看不到变化。本质是文件系统未在线扩容 —— 大多数 CSI 驱动只负责块设备扩容，不自动执行 resize2fs 或 xfs_growfs，需应用层配合或依赖特定驱动能力。
立即学习“go语言免费学习笔记（深入）”；
- 确认 CSI 驱动是否支持在线 FS 扩容（查其文档，如
aws-ebs-csi-driverv1.25+ 支持 ext4/xfs 自动 resize，gce-pd-csi-driver需手动 exec） - 若驱动不支持，需在 Pod 内执行
exec.Command("resize2fs", "/dev/xxx")（ext4）或exec.Command("xfs_growfs", "/mount/path")（xfs），注意挂载点路径和设备名来源 - Pod 必须有
CAP_SYS_ADMIN权限才能执行resize2fs；xfs_growfs 则依赖挂载选项（如inode64）和内核支持 - 不要在 InitContainer 中做 FS 扩容：InitContainer 运行时卷尚未被主容器 mount，
df不可见，且可能因顺序问题重复执行
