零停机部署需go应用优雅关闭、正确配置readinessprobe及k8s滚动策略协同：go须实现http.server.shutdown()响应sigterm，readinessprobe需严格检查依赖并设合理initialdelayseconds，maxunavailable应设为0且配合minreadyseconds，确保流量切换与实例终止无缝衔接。
零停机部署在 Kubernetes 上不是靠“配置一次就完事”，而是由 Go 应用自身行为、探针设置、K8s 资源策略三者协同决定的。单独改 Deployment 的 strategy.type: RollingUpdate 不保证零停机；没写好 http.Server.Shutdown() 或漏配 readinessProbe，哪怕蓝绿切换也会丢请求。
Go 服务必须实现优雅关闭（http.Server.Shutdown()）
Pod 收到 SIGTERM 后，Kubernetes 会等待 terminationGracePeriodSeconds（默认 30 秒）再强制 kill。这段时间里，你的 Go 服务得自己把活干完：
-
srv.Shutdown()必须被调用，且传入带超时的context.Context，不能只靠os.Exit()或 panic 退出 - 启动时监听
os.Interrupt和syscall.SIGTERM，别只监听 Ctrl+C - 关闭前要等 DB 连接池空闲、gRPC 客户端 graceful shutdown、消息队列确认发送完成
- 避免在
Shutdown()期间新建 goroutine —— 它们可能没机会执行完就被进程终止
示例关键片段：
srv := &http.Server{Addr: ":8080"}
go srv.ListenAndServe()
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
<h3>readinessProbe 配置错误是丢流量的头号原因</h3>
<p>Kubernetes 不会把流量打给还没就绪的 Pod，但很多人误以为 “Pod 状态变成 Running 就等于 ready”。实际取决于 <code>readinessProbe</code> 是否返回成功：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill3927" title="Colly Golang Web Scraper and Crawler Framework"><img
src="https://img.php.cn/upload/skill/000/000/081/178986975225346.jpg" alt="Colly Golang Web Scraper and Crawler Framework" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill3927" title="Colly Golang Web Scraper and Crawler Framework" class="overflowclass">Colly Golang Web Scraper and Crawler Framework</a>
<p class="overflowclass">Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。</p>
</div>
<a rel="nofollow" href="/xiazai/skill3927" title="Colly Golang Web Scraper and Crawler Framework" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
-
initialDelaySeconds必须 ≥ Go 应用冷启动耗时（比如 DB 连接池初始化、配置加载、依赖健康检查），建议设为 5–10 秒 -
path推荐用/ready，且该 handler 必须检查所有关键依赖：DB ping、Redis ping、下游 gRPC 服务连通性 - 不要用
/health兼容 readiness 和 liveness —— liveness 可以更宽松，但 readiness 必须严格反映“能否收请求” - 如果用了 Istio，还需确认
readinessProbe的路径未被 sidecar 拦截或重写
Service selector 切换不等于瞬时生效
蓝绿部署中把 Service 的 selector 从 version: v1 改成 version: v2 是原子操作，但流量真正切过去有延迟：
-
EndpointSlice更新需要时间，kube-proxy 同步 iptables/ipvs 规则通常有 100–500ms 滞后（高负载集群更明显） - 客户端已建立的长连接（尤其是 HTTP/2 多路复用）仍会复用旧连接，直到超时或主动断开
- DNS 缓存（如 CoreDNS TTL、客户端本地 DNS 缓存）可能导致部分请求继续打到旧 IP
- 解决办法不是“更快切”，而是让旧 Pod 在切流后仍能处理完残留请求 —— 这又回到优雅关闭和足够长的
terminationGracePeriodSeconds
滚动更新时 maxSurge 和 maxUnavailable 要按真实容量设
默认 RollingUpdate 策略下，Kubernetes 会先扩新 Pod、再删旧 Pod。但如果资源紧张或副本数少，容易出现短暂不可用：
-
maxSurge: 1表示允许临时多起 1 个 Pod；若节点资源不足，新 Pod 会 Pending，导致更新卡住 -
maxUnavailable: 0才能确保任意时刻至少有replicas个 Pod 在提供服务；设为1时，3 副本部署可能只剩 2 个可用 - 配合
minReadySeconds（比如设为 10），可避免新 Pod 就绪后立刻被当作“可用”而参与负载分发，实际它可能刚通过 readinessProbe 还没热起来
真正难的不是写对 YAML，而是让 Go 服务在 SIGTERM 到来那一刻，清楚自己手头还有几个请求没回、哪些连接该关、哪些资源该释放 —— 这些逻辑一旦漏掉，再完美的 K8s 配置也救不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
