StatefulSet客户端初始化必须使用appsv1 API组，extensions/v1beta1在Kubernetes 1.16+已移除；serviceName必须指向已存在的Headless Service，podManagementPolicy默认OrderedReady；字段如serviceName、volumeClaimTemplates不可更新，删除时默认不级联Pod和PVC。
StatefulSet客户端初始化必须用appsv1而不是extensions/v1beta1
Go客户端操作StatefulSet时，如果用错API组，clientset.AppsV1().StatefulSets(ns)会 panic 或返回 nil。Kubernetes 1.16+ 已彻底移除 extensions/v1beta1 中的 StatefulSet，所有新版集群必须用 appsv1。旧代码里写 clientset.ExtensionsV1beta1().StatefulSets(ns) 在 1.16+ 集群上直接报 Method not allowed 或空对象。
初始化示例：
config, _ := rest.InClusterConfig()
clientset := kubernetes.NewForConfigOrDie(config)
stsClient := clientset.AppsV1().StatefulSets("default") // 注意是 AppsV1()，不是 ExtensionsV1beta1()
- 本地开发调试时，用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)替代InClusterConfig - 若项目还兼容 1.9–1.15，需按集群版本动态选择 API 组（不推荐，维护成本高）
- 生成 clientset 时，确保 vendor 或 go.mod 中依赖的是
k8s.io/client-go@v0.26.0+（对应 K8s 1.26+），低版本可能缺失某些字段支持
创建StatefulSet要特别注意serviceName和podManagementPolicy
StatefulSet 的 serviceName 字段不是可选的——它必须指向一个已存在的 Headless Service（clusterIP: None）。漏设或设错会导致 Pod 卡在 Pending 状态，且 kubectl describe sts 不报明显错误，只在 Events 里有 FailedCreatePodSandBox 类似提示。
podManagementPolicy 默认是 OrderedReady，意味着 Pod 必须按 0→1→2 顺序启动、且前一个 Ready 后才启下一个。若想并行启动（如纯计算型无依赖场景），需显式设为 Parallel，否则扩容卡住。
立即学习“go语言免费学习笔记（深入）”；
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
serviceName必须与已有 Service 的metadata.name完全一致，大小写敏感 - Headless Service 的
selector必须匹配 StatefulSet 的spec.selector.matchLabels - 修改
podManagementPolicy不会触发滚动更新，仅影响后续扩缩容行为
Update和Patch对StatefulSet的字段限制很严格
StatefulSet 的部分字段不可更新，比如 spec.serviceName、spec.replicas（可更新但受 PDB 和 PodDisruptionBudget 影响）、spec.template.spec.containers[0].name。直接调 stsClient.Update() 修改这些字段会返回 Invalid: spec.template.spec.containers[0].name: Invalid value 错误。
更安全的做法是用 Patch 更新可变字段（如镜像、环境变量），配合 types.StrategicMergePatchType：
patchData := []byte(`{"spec":{"template":{"spec":{"containers":[{"name":"web","image":"nginx:1.25"}]}}}}`)
_, err := stsClient.Patch(context.TODO(), "my-sts", types.StrategicMergePatchType, patchData, metav1.PatchOptions{})
-
spec.replicas可用Update修改，但需确保新值 ≥ 当前 Pod 数量，否则会删 Pod -
spec.updateStrategy.type（RollingUpdate / OnDelete）只能在创建时指定，后续不可改 - 对
spec.volumeClaimTemplates的任何变更都会被拒绝，必须删重建
删除StatefulSet时cascading行为容易被忽略
默认调 stsClient.Delete() 不会自动删 Pod 和 PVC——这是 StatefulSet 和 Deployment 的关键区别。它只会删 StatefulSet 对象本身，Pod 变成“孤儿”，PVC 保留（因 volumeClaimTemplates 创建的 PVC 有 ownerReference 指向 StatefulSet，但删除时默认不级联）。
若要连带删 Pod，必须传 metav1.DeletePropagationBackground 或 DeletePropagationForeground：
deletePolicy := metav1.DeletePropagationBackground
err := stsClient.Delete(context.TODO(), "my-sts", metav1.DeleteOptions{PropagationPolicy: &deletePolicy})
- 即使设了
PropagationPolicy，PVC 仍不会被自动删除（除非 PVC 的persistentVolumeReclaimPolicy是Delete且 PV 支持） - 生产环境删 StatefulSet 前，务必先确认 PVC 是否含重要数据；盲目加
PropagationPolicy可能导致数据丢失 - 用
kubectl delete sts my-sts --cascade=background行为等价于上述 Go 调用
