Kubernetes 中 Go 应用滚动更新需显式配置 Deployment 的 maxSurge 和 maxUnavailable、正确处理 SIGTERM 并调用 http.Server.Shutdown()，同时手动释放资源并轮询 UpdatedReplicas 与 AvailableReplicas 确保就绪。
Go 应用在 Kubernetes 上的“部署”和“版本更新”是两件事：部署靠 Deployment 资源定义初始状态，版本更新靠修改其 spec.template.spec.containers[0].image 字段触发滚动更新——不是重启进程，也不是热替换二进制。
Go 程序必须自己处理 SIGTERM 才能真正优雅退出
容器终止时 K8s 默认发 SIGTERM，不是 SIGKILL。如果你的 Go 服务没监听它，进程会立刻被杀，所有活跃 HTTP 连接硬断开，前端看到的就是 502/504。
-
http.Server.Shutdown()是唯一正确做法：拒绝新请求、等待 handler 返回 -
http.Server.Close()是暴力关闭，别用 - 超时 context 必须设，且
context.WithTimeout(..., 30*time.Second)的值要小于 Deployment 的terminationGracePeriodSeconds（比如后者配 45s） - 别在 handler 里起 goroutine 后立刻返回——
Shutdown()不等后台 goroutine - 记得手动关 DB 连接池、取消长轮询 context、释放文件句柄等资源
Deployment 的 rollingUpdate 参数不能依赖默认值
这两个字段直接决定滚动是否卡住、是否秒级不可用：maxSurge 和 maxUnavailable 必须显式写死，别留空或设成 0。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
maxSurge: 1允许临时多跑 1 个 Pod（比如从 3→4），否则新 Pod 拉不起来就卡住 -
maxUnavailable: 1保证任何时候至少有 2 个 Pod 在服务（3−1），避免流量断崖 -
maxSurge: 0是无效配置，会导致 rollout 卡住——新 Pod 根本起不来 - 低副本数（如
replicas: 2）下，maxSurge: 25%实际为 0，可能退化成“先删后启” - 务必显式写
strategy.type: RollingUpdate，别信默认值
用 client-go 触发更新后必须轮询 status 判断完成
clientset.AppsV1().Deployments().Update() 成功只代表 API Server 接收了变更，不代表滚动已完成。
立即学习“go语言免费学习笔记（深入）”；
- 要轮询
deployment.Status.UpdatedReplicas == deployment.Status.Replicas - 同时检查
deployment.Status.AvailableReplicas == deployment.Status.Replicas - 仅靠
UpdatedReplicas不够——Pod 可能已更新但还没就绪，流量仍无法接入 - 别用
kubectl rollout status封装逻辑，生产代码里应自己 watch 或 poll
最容易被忽略的是：滚动更新过程中，新旧 Pod 共存期间，如果接口不兼容或数据库迁移没同步，问题会静默发生。探针设置不准、minReadySeconds 太短、资源限制过紧，都可能导致新 Pod 频繁重启却始终不就绪——此时滚动看似在动，实际服务已半瘫痪。
