statefulset 不支持 kubectl rollout restart，因其设计核心是“稳定身份”，需通过滚动更新或重建实现安全变更；盲目删除 pod 会破坏序号、网络标识和存储绑定，导致数据错乱或服务中断。
不能直接“重启”StatefulSet，必须通过滚动更新或重建来实现安全变更；盲目删除 Pod 会破坏序号、网络标识和存储绑定，导致数据错乱或服务中断。
为什么 StatefulSet 没有 kubectl rollout restart
StatefulSet 的设计核心是“稳定身份”：每个 Pod 有固定名称（my-sts-0、my-sts-1）、独立 PVC、DNS 可解析的 FQDN。Kubernetes 故意不提供类似 kubectl rollout restart 的命令，因为“重启”语义模糊——是只重建容器？还是重建 Pod 并保留 PVC？或是连 PVC 都要轮换？
直接调用 kubectl delete pod my-sts-0 看似简单，但风险明确：
- 如果 Pod 正在写入本地 PV，强制删除可能触发未刷盘数据丢失
- 新 Pod 启动时若依赖旧 Pod 的网络状态（如 Raft 成员发现），
my-sts-0重建后可能无法加入集群 - 某些应用（如 ZooKeeper、etcd）要求成员变更必须显式执行 remove/add 流程，而非靠控制器自动覆盖
安全更新的唯一推荐路径：rollout update + image 或 annotation
真正安全的方式，是触发 StatefulSet 的**受控滚动更新**，让 Kubernetes 按序停旧启新，并等待就绪才继续下一步。
最常用且低风险的操作是更新容器镜像或加一个无害 annotation：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 更新镜像：
kubectl set image statefulset/my-sts nginx=nginx:1.25.4 -n default - 打标记触发更新（无需改 spec）：
kubectl patch statefulset/my-sts -n default -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}}}}}'
该操作会触发 StatefulSet 控制器从索引最大（如 my-sts-2）开始逐个终止并重建 Pod，每次只操作一个，且默认等待新 Pod 进入 Running 且就绪探针成功后才继续下一个。你可用以下命令观察进度：
kubectl rollout status statefulset/my-sts -n default
必须手动干预的场景：PVC 需要重建或数据迁移
如果你实际想“清空状态重来”，比如升级数据库 schema 前需初始化新卷，那就不是“重启”，而是**有状态重建**。此时必须放弃自动化滚动，分步操作：
- 先备份现有 PVC 数据（如
kubectl exec my-sts-0 -- tar czf /tmp/data.tgz /var/lib/mysql） - 缩容到 0：
kubectl scale statefulset/my-sts --replicas=0 -n default，确认所有 Pod 已消失 - 手动删除旧 PVC（注意：StatefulSet 不管理 PVC 生命周期）：
kubectl delete pvc data-my-sts-0 -n default - 再扩容回原数量：
kubectl scale statefulset/my-sts --replicas=3 -n default，控制器会为每个 Pod 创建新的 PVC 并绑定
这一步极易误删数据——PVC 名称格式固定为 <volumeclaimtemplate.name>-<statefulset.name>-<ordinal></ordinal></statefulset.name></volumeclaimtemplate.name>，务必核对清楚，别删错序号。
Go client-go 中避免踩坑的关键点
如果你用 Golang 写 Operator 或脚本控制 StatefulSet 更新，注意这些硬约束：
- 不要调用
clientset.CoreV1().Pods(ns).Delete()去“重启”单个 Pod；应调用clientset.AppsV1().StatefulSets(ns).Update()修改Spec.Template - 更新前必须读取当前 ResourceVersion，否则并发修改会因版本冲突失败
- 检查
sts.Status.UpdatedReplicas == sts.Spec.Replicas和sts.Status.ReadyReplicas == sts.Spec.Replicas才算完成，不能只看 Pod 数量 - 若 StatefulSet 关联了 Headless Service，确保其
spec.selector与 StatefulSet 的 label selector 一致，否则新 Pod 不会被 DNS 解析
真正的难点不在命令怎么敲，而在于判断“这次更新到底要不要等应用层确认”。比如 Kafka broker 重启后需等 controller epoch 刷新，PostgreSQL 主从需等 WAL 同步完成——这些没法靠 Kubernetes 自动感知，得你在 Go 代码里集成健康检查或调用应用 API 校验。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
