滚动更新需显式启用RollingUpdate策略并修改Pod模板，Golang客户端提交Update后须轮询状态判断完成，回滚应重写模板而非使用已弃用的rollback。
滚动更新触发条件：RollingUpdate 策略必须显式启用
默认情况下，Kubernetes 的 Deployment 并不会自动滚动更新——它只在你明确修改了 Pod 模板（比如 spec.template.spec.containers[0].image）且策略为 RollingUpdate 时才触发。Golang 客户端（如 k8s.io/client-go）本身不“管理”更新逻辑，它只是提交变更；真正的滚动行为由 kube-controller-manager 中的 Deployment 控制器执行。
关键点：
-
spec.strategy.type必须设为"RollingUpdate"（不是"Recreate"） - 必须修改
spec.template下的字段（如镜像、环境变量、注解），否则控制器认为无变更，跳过更新 - Golang 中调用
clientset.AppsV1().Deployments(namespace).Update(ctx, deploy, metav1.UpdateOptions{})即可提交，无需额外“启动滚动”操作
MaxUnavailable 和 MaxSurge 决定滚动节奏
这两个字段控制滚动过程中可用副本数和临时超出期望副本的数量，直接影响服务中断风险与资源开销。它们在 Golang 中通过 appsv1.DeploymentStrategy 设置：
deploy.Spec.Strategy = appsv1.DeploymentStrategy{
Type: appsv1.RollingUpdateDeploymentStrategyType,
RollingUpdate: &appsv1.RollingUpdateDeployment{
MaxUnavailable: &intstr.IntOrString{Type: intstr.String, StrVal: "25%"},
MaxSurge: &intstr.IntOrString{Type: intstr.String, StrVal: "25%"},
},
}
常见配置陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 设
MaxUnavailable: "0"可避免服务中断（先扩再缩），但需确保节点有足够资源启动新 Pod - 设
MaxSurge: "0"会导致滚动变慢（必须等旧 Pod 完全终止后才启新 Pod），且无法实现零停机 - 数值用
intstr.IntOrString表示：字符串形式（如"25%"）或整数（如1），不能直接传int
如何用 Golang 等待滚动完成？别依赖 Update() 返回值
Update() 调用成功只表示 API Server 接收了变更，不代表滚动已结束。真正判断完成需轮询 status.updatedReplicas == status.replicas 且 status.availableReplicas == status.replicas。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 使用
clientset.AppsV1().Deployments(ns).Get(ctx, name, metav1.GetOptions{})获取最新状态 - 检查
deploy.Status.UpdatedReplicas和deploy.Status.AvailableReplicas是否等于deploy.Spec.Replicas - 加入超时和重试（例如 5 分钟内每 2 秒查一次），避免无限等待
- 注意：若 Deployment 处于
ProgressDeadlineExceeded条件下，AvailableReplicas会长期小于期望值
升级失败时如何回滚？Golang 中用 RollbackTo 不再推荐
Kubernetes 1.19+ 已弃用 rollback 子资源，官方推荐方式是：将历史 Revision 对应的镜像（或模板）重新写入 spec.template 并 Update()。
获取历史 Revision：
rev, found := deploy.Annotations["deployment.kubernetes.io/revision"] // 或从 rollout history 命令解析（需 exec kubectl 或调用 server-side history endpoint）
回滚要点：
- 通过
clientset.AppsV1().Deployments(ns).Get(ctx, name, metav1.GetOptions{ResourceVersion: "0"})获取当前对象，再手动还原spec.template - 不要试图 PATCH
revision字段——它只读，由控制器维护 - 如果想保留某次部署快照，应在 Golang 中提前备份
deploy.DeepCopy()的spec.template
滚动更新的边界其实很清晰：它只是控制器对 Pod 模板差异的响应机制。Golang 的角色就是准确提交变更、合理设置策略参数、并主动观察状态。最易忽略的是把 Update() 当作“执行完成”，而实际它连 Pod 创建都没开始。
