Deployment适用于无状态Golang服务，版本变更需更新image标签并配置滚动策略；StatefulSet仅用于有状态场景，v1.24+才支持RollingUpdate，需谨慎处理PVC兼容性；client-go更新时须避免全量重建和ResourceVersion冲突。
StatefulSet 和 Deployment 的版本管理逻辑完全不同，不能套用同一套策略。Golang 应用本身没有“内置版本号”，它的版本控制完全依赖 Kubernetes 资源对象的镜像标签、滚动更新行为和状态一致性保障机制。
用 Deployment 管理无状态 Golang 服务的版本
绝大多数 Golang 微服务属于无状态应用，应使用 Deployment，而非 StatefulSet。版本变更的核心是镜像标签更新 + 滚动更新策略配置。
-
image字段必须使用具体语义化标签（如v1.2.3），严禁用latest—— 否则kubectl rollout history查不到历史，回滚会失效 - 更新时只改
spec.template.spec.containers[0].image，其他字段（如labels、env）不变，否则触发全量重建而非滚动更新 - 设置
strategy.rollingUpdate.maxSurge和maxUnavailable控制更新节奏；生产环境建议设为1或25%，避免雪崩 - 更新后立即执行
kubectl rollout status deployment/go-app等待就绪，不要靠 sleep 猜测
用 StatefulSet 管理有状态 Golang 应用的版本
只有当你的 Golang 应用需要稳定网络标识、有序启停、独立 PVC（比如自研分布式缓存节点或带本地状态的聚合服务），才考虑 StatefulSet。它的版本升级更谨慎，且默认不支持滚动更新（v1.24+ 才支持 OnDelete 和 RollingUpdate 策略）。
- 确认集群 Kubernetes 版本 ≥ v1.24，否则
updateStrategy.type: RollingUpdate不生效，只会卡在第一个 Pod -
revisionHistoryLimit默认为 10，但StatefulSet的历史版本不直接对应镜像，而是由controller-revision-hash标签追踪，需配合kubectl get controllerrevisions查看 - 更新前必须确保新镜像兼容旧 PVC 中的数据格式；否则先停机迁移数据，再改
image并手动逐个删除 Pod 触发重建 - 禁止在更新过程中修改
serviceName或volumeClaimTemplates—— 这些字段不可变，会直接报错field is immutable
client-go 编程更新 Golang 应用版本的坑点
如果你用 Golang 写控制器或 CI 工具自动更新版本，client-go 的写法稍有不慎就会导致更新静默失败或部分 Pod 卡住。
- 更新
Deployment时，必须用clientset.AppsV1().Deployments(namespace).Update(ctx, dep, metav1.UpdateOptions{})，不能用Create或Replace—— 后者会丢掉历史 revision - 读取当前
Deployment后，只改.Spec.Template.Spec.Containers[0].Image，别碰.Spec.Template.ObjectMeta.Labels，否则触发全量重建 - 调用
Update前务必检查dep.ResourceVersion是否过期；并发更新时可能因409 Conflict失败，需加重试逻辑 - 如果目标是灰度发布，不要手写分批逻辑，改用
canary类型的Deployment配合Service权重，或直接上Argo Rollouts等成熟方案
Deployment 更新？更新失败时，是否能自动告警并 rollback 到上一版？这些细节比语法本身更决定成败。 
