Go管理Kubernetes存储必须用client-go操作PV/PVC，严格区分集群级PV与命名空间级PVC；PVC Pending主因是storageClassName或accessModes不匹配后端配置；PV创建需cluster-admin权限及spec.capacity、spec.accessModes等必填字段；监控绑定需同时检查pvc.Status.Phase、pvc.Spec.VolumeName及对应PV状态；清理数据须按后端类型分治，云盘依赖reclaimPolicy=Delete，本地存储需手动清理。
Go 程序直接管理 Kubernetes 持久化存储卷（PV/PVC）时，不能靠手写 YAML 或调用 kubectl 命令硬编码实现——必须用 client-go 操作 API 对象，且要严格区分 PV（集群资源）和 PVC（命名空间级请求），否则会绑定失败、权限报错或状态卡在 Pending。
创建 PVC 时为什么总是 Pending？
绝大多数问题出在 PVC 的 storageClassName 和访问模式不匹配后端 PV 或 StorageClass 配置。
- 检查集群是否有默认
StorageClass：kubectl get storageclass；若没有，PVC 必须显式指定storageClassName字段，否则无法动态供给 - PVC 的
accessModes（如ReadWriteOnce）必须被底层 PV 或 StorageClass 支持；NFS 类型通常支持ReadOnlyMany和ReadWriteMany，而大多数块存储只支持ReadWriteOnce - Go 中用 client-go 创建 PVC 时，
ResourceRequirements.Requests["storage"]的值必须是合法 quantity 格式，例如"10Gi"，写成"10G"或10240会触发验证失败
用 client-go 创建 PV 要注意哪些权限和字段？
PV 是集群级资源，需要 cluster-admin 权限；普通命名空间用户默认无权创建。即使有权限，字段缺失也会导致 PV 无法进入 Available 状态。
-
spec.capacity和spec.accessModes是必填项，缺一不可；spec.persistentVolumeReclaimPolicy默认是Retain，删 PVC 后数据不会自动清理 - 如果是
hostPath类型 PV，spec.hostPath.path必须已在节点上存在且 kubelet 有读写权限；路径中不能含符号链接，否则 PV 状态会卡在Failed - 云厂商 CSI 驱动（如
disk.csi.azure.com）的 PV 必须通过 StorageClass 动态创建，手动构造 PV YAML 并用 Go 提交大概率被拒绝——应改为创建 PVC 并设置对应storageClassName
如何用 Go 监控 PVC 绑定状态？
不要轮询 pvc.Status.Phase == "Bound" 就认为可用；要同时检查 pvc.Spec.VolumeName 是否非空，以及对应 PV 的 status.phase 是否为 Bound。
立即学习“go语言免费学习笔记（深入）”；
- client-go 中推荐用
Watch+MetaV1.ListOptions{FieldSelector: "metadata.name=xxx"}实时监听 PVC 变更，比定时Get更高效、低延迟 - 若 PVC 长时间处于
Pending，需立刻查kubectl describe pvc <name>输出的 Events，常见原因是 StorageClass 不存在、PV 容量不足、或节点标签不匹配（如 PV 带nodeAffinity但节点没对应 label） - Go 代码里解析 Events 需调用
corev1.EventList，注意 Events 是 namespace-scoped，必须指定 PVC 所在命名空间
删除 PVC 后数据还在，怎么安全清理？
这是 PV reclaimPolicy: Retain 的预期行为，不是 bug。Go 程序不能直接删底层存储（比如 NFS 目录或云盘），必须按后端类型分情况处理。
- 对于
hostPath或本地 NFS，需在对应节点上执行rm -rf，Go 可通过 SSH 或节点上部署的 sidecar 清理，但要注意权限和路径一致性 - 云存储（AWS EBS / Azure Disk）通常随 PV 删除自动释放，前提是 PV 的
reclaimPolicy设为Delete，且 CSI 驱动版本支持该行为 - 最稳妥的做法：在 Go 控制器中监听 PVC
Deleted事件，触发自定义 finalizer，等外部清理完成后再移除 finalizer，避免误删正在使用的数据
真正麻烦的从来不是调用 client-go 创建对象，而是理解 PV/PVC 绑定逻辑、StorageClass 参数含义、以及不同存储后端对 accessModes 和 reclaimPolicy 的实际约束——这些细节不验证清楚，Go 代码跑得再快也没用。
