滚动更新由Deployment控制器驱动，需设spec.strategy.type为"RollingUpdate"并修改template.image触发；用client-go Update()全量替换、配readinessProbe、Golang服务须支持优雅关闭与就绪等待。
滚动更新的本质是控制 Deployment 的 rollingUpdate 策略参数
Kubernetes 本身不提供“Golang 实现滚动更新”的 API，滚动更新由 Deployment 控制器驱动，Golang 的作用是调用 Kubernetes API（如通过 client-go）提交符合要求的资源定义。关键不是“用 Golang 写更新逻辑”，而是确保你提交的 Deployment 对象中，spec.strategy.type 设为 "RollingUpdate"，并合理配置其子字段。
常见错误是只改了镜像但没触发更新：必须修改 spec.template.spec.containers[*].image 字段（哪怕只是加个空格），否则 Deployment 认为模板未变，不会创建新 ReplicaSet。
-
maxSurge控制扩容上限（可设为"25%"或1），值太大会导致资源超限 -
maxUnavailable控制不可用副本数（建议设为1或"0%"实现零停机），设为0时需配合就绪探针（readinessProbe），否则新 Pod 卡在ContainerCreating或Running但不就绪，旧 Pod 又不敢删 - 若未定义
readinessProbe，Kubernetes 默认认为 Pod 启动即就绪，可能导致流量打到未初始化完成的服务上
用 client-go 提交新版 Deployment 需要 patch 还是 replace
直接调用 clientset.AppsV1().Deployments(namespace).Update(ctx, deploy, metav1.UpdateOptions{}) 是最稳妥的方式 —— 它属于全量替换（replace），语义明确、幂等性好、且能触发滚动更新（只要 spec.template 有变更）。不要用 Patch 去局部更新镜像，容易因 JSON Merge Patch 行为不一致导致失败（例如字段被意外清空）。
实操中应：
立即学习“go语言免费学习笔记（深入）”；
- 读取现有
Deployment对象：Get(ctx, name, metav1.GetOptions{}) - 深拷贝后修改
deploy.Spec.Template.Spec.Containers[0].Image（注意索引和容器名匹配） - 调用
Update()提交；若报错"the object has been modified"，说明并发更新冲突，需重试（用retry.RetryOnConflict辅助） - 避免手动构造
ResourceVersion，让 API Server 自动处理版本控制
如何确认滚动更新真正完成且无流量丢失
不能只看 kubectl rollout status deploy/name 返回 successfully rolled out 就认为安全 —— 这个命令只检查新 ReplicaSet 的 updatedReplicas == replicas，不验证 Pod 是否通过就绪探针、是否已接入 Service Endpoints。
必须交叉验证：
- 查新 ReplicaSet 的
status.availableReplicas是否等于期望副本数（说明所有新 Pod 已就绪） - 查
Endpoints对象：kubectl get endpoints，确认 IP 列表已完全切换为新 Pod 的 IPname-o jsonpath='{.subsets[*].addresses[*].ip}' - 查旧 ReplicaSet 的
status.replicas是否降为 0（若还有残留副本，说明maxUnavailable或控制器延迟导致旧 Pod 未被清理） - 在应用层埋点记录启动完成时间，并比对服务端日志中首次收到请求的时间差，确认冷启动延迟是否在容忍范围内
Golang 应用自身需适配滚动更新的三个细节
客户端代码写得再规范，应用不配合也会出问题。Golang HTTP 服务必须主动支持优雅关闭与就绪等待，否则滚动更新时必然丢请求。
- HTTP Server 启动后，先运行初始化逻辑（如连接 DB、加载配置），再监听端口；同时暴露
/readyz接口，仅在初始化完成后返回 200 - 注册
os.Interrupt和syscall.SIGTERM信号，收到后调用server.Shutdown()，并等待活跃连接超时（建议30s） - 在
main()中使用context.WithTimeout包裹启动流程，避免初始化卡死导致就绪探针持续失败
srv := &http.Server{Addr: ":8080", Handler: mux}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
ready.Store(true) // 就绪标志
// 收到 SIGTERM 后
signal.Notify(sigChan, syscall.SIGTERM, os.Interrupt)
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal(err)
}
就绪探针和存活探针的 initialDelaySeconds 必须大于应用冷启动耗时，否则 Kubelet 会反复重启容器。
