在 Go 中用 client-go 动态创建 PVC 需正确设置命名空间、AccessModes、storage requests（用 resource.MustParse）、StorageClassName；挂载时 volumeMounts 与 volumes 名称必须一致；PVC 状态以 Status.Phase 为准；扩容需 StorageClass 支持且仅限 Bound 状态。
如何在 Go 中动态创建 PersistentVolumeClaim
直接用 client-go 创建 PVC，核心是构造正确的 PersistentVolumeClaim 对象并提交到 API Server。注意命名空间必须显式指定，否则默认提交到 default，而你的 Pod 可能运行在其他命名空间。
- 确保
meta.Name和meta.Namespace都非空； -
spec.AccessModes至少包含一个值（如["ReadWriteOnce"]），空切片会导致校验失败； -
spec.Resources.Requests["storage"]必须用resource.MustParse("10Gi")，不能传字符串或 float64； - 若集群启用了 StorageClass 且你希望自动绑定 PV，需设置
spec.StorageClassName（注意：设为nil表示使用默认 StorageClass，设为空字符串""表示不使用任何 StorageClass）。
挂载 PVC 到 Pod 时常见的 volumeMount 错误
Go 构建 Pod Spec 时，volumeMounts 和 volumes 必须严格配对，且 volumeMounts[i].Name 必须等于 volumes[j].Name —— 名字不一致不会报错，但挂载失败且无明确日志提示，Pod 启动后目录为空。
-
volumeMounts的mountPath推荐用绝对路径（如"/data"），相对路径行为未定义； - 不要复用同一
volume.Name多次出现在volumes列表中，Kubernetes 不允许； - 如果 Pod 使用
initContainer，它也需要单独声明volumeMounts才能访问该卷； - 挂载点目录权限受容器镜像
USER和fsGroup影响，调试时可临时加securityContext.fsGroup = 0看是否是权限问题。
用 client-go 列出所有 PVC 并按状态过滤
调用 clientset.CoreV1().PersistentVolumeClaims(namespace).List() 返回的是完整列表，但 PersistentVolumeClaim.Status.Phase 才反映真实绑定状态（"Pending" / "Bound" / "Lost"），别依赖 Conditions 字段做判断 —— 它可能为空或滞后。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 遍历结果时，先检查
pvc.Status.Phase != ""，再比较字符串； - 跨命名空间查询需循环调用，
client-go不支持全局 list PVC； - 如果要等 PVC 绑定完成，不要轮询
Status.Conditions，直接轮询Status.Phase == "Bound"更可靠； - 注意
metav1.ListOptions{FieldSelector: "status.phase=Bound"}在部分 Kubernetes 版本中不生效（尤其是 v1.22+ 默认禁用 status field selector），应避免依赖。
为什么 Update PVC 的 storage request 总是失败
从 Kubernetes v1.11 起，PVC 的 spec.resources.requests.storage 允许扩容，但前提是底层 StorageClass 显式启用 allowVolumeExpansion: true，且 PVC 当前处于 Bound 状态、对应 PV 也支持扩容（如 CSI 驱动实现）。否则 Patch 或 Update 操作会返回 Forbidden 错误，消息类似："field is immutable after creation"。
立即学习“go语言免费学习笔记（深入）”；
- 扩容前务必检查
StorageClass.AllowVolumeExpansion字段值为true； - 更新只能增大不能减小，且新值必须是原值的整数倍（某些存储后端有此限制）；
- 扩容触发后，PV 的
spec.capacity.storage不会立刻改变，需等待 CSI Controller 完成底层操作，之后PVC.Status.Capacity才更新； - Go 中用
clientset.CoreV1().PersistentVolumeClaims(ns).Patch(...)发起 patch 时，推荐用types.StrategicMergePatchType，传入 map 结构比构造完整对象更安全。
Status.Phase，大概率还是 Pending；或者扩容后马上重启 Pod，却发现挂载点大小没变，其实是文件系统还没 resize。这些都不是 Go 代码的问题，而是 Kubernetes 控制面延迟和存储插件行为导致的。 
