滚动发布后流量仍打到旧 Pod：DNS 缓存加连接复用导致的 5xx 与半提交复盘

作者：沈砚舟-906｜3 年运维工程师｜喜欢用数字和步骤说话 栈：Kubernetes 1.28.9、CoreDNS 1.11.1、Spring Cloud LoadBalancer（Nacos 注册中心 2.2.3）、JDK 17、MySQL 8.0.32 结论先行：发布后 5xx 不一定出在「优雅下线时序」，也可能出在「客户端还认着旧 IP」——DNS 缓存 + 长连接复用，会让流量在你已经把 Pod 摘掉之后，继续打到已经退场的旧 IP 上。这篇文章只讲这个角度，和优雅下线时序是两件事。

一、现象：发布后 30~90 秒内出现一批「下游连不上」的 5xx

一次常规滚动发布（Deployment 3 副本，maxUnavailable=1），新版本 Pod 全部 Ready 后，上游订单服务在 15:42:10 到 15:43:22 这一分多钟里报了 47 个 5xx，其中 31 个是 Connection refused: connect，16 个是 Connection reset by peer。诡异的是：

• 新版本 Pod 全部 Ready，kubectl get pods 没有任何 Terminating；
• 被连的那几个 IP（如 10.244.3.71）kubectl get pod -o wide 查不到对应 Pod，说明流量打到了一个已经不存在的主机 IP；
• 这批 5xx 全部集中在发布开始后的前 90 秒，之后归零。

一开始以为是优雅下线没配好，查了 terminationGracePeriodSeconds（=60s）和 preStop（sleep 5），时序都对。问题没解决，才继续往下挖。

二、根因：三层缓存叠加，让「旧 IP」在客户端眼里还活着

滚动发布时，Pod 被替换，Pod IP 会变（10.244.3.71 → 10.244.3.88）。而 Service 的 ClusterIP 不变。问题就出在：客户端不是每次都走 ClusterIP 现解析、现建连，它手里攥着三层「旧数据」：

1. 应用内 DNS 缓存：客户端 JVM 里 glibc/JVM 的 networkaddress.cache.ttl（默认 JDK 1.8 起是 30s，JDK 17 未显式配置时仍沿用），把 order-svc.ns.svc.cluster.local → 10.244.3.71 这条解析结果缓存了 30 秒；
2. 注册中心本地缓存：Nacos 客户端把实例列表缓存在内存，发布窗口内实例列表还没刷新，旧 IP 10.244.3.71 仍在本地列表里，客户端 LB（RoundRobin）照样会选到它；
3. 连接池里的复用连接：这是最阴险的一层。OkHttp/HTTP 连接池里那条到 10.244.3.71 的 keep-alive 连接，只要没被对端 RST、没超时，客户端会一直从池里取出来复用。Pod 被删后，内核侧该 IP 短暂还能回包（ARP/路由表残留几秒），于是前几笔「看起来成功」，等 ARP 表项真正失效后，就变成 Connection reset。

三层叠加，就出现了「Pod 已经没了，但流量还在打过去 90 秒」的现象。核心机制：Service 摘除的是「服务端视角」的 EP，而客户端的 DNS/注册中心/连接池是「客户端视角」的缓存，两边不同步，发布窗口期必然有一段错位。

三、具体做法：把「客户端视角」的缓存也一起收敛

1. 压短 DNS 缓存 TTL（JDK 17 启动参数）：

   -Dsun.net.inetaddr.ttl=5
   -Dsun.net.inetaddr.negative.ttl=1
   

   把解析缓存从默认 30s 压到 5s，负缓存 1s，让旧 IP 更快失效。

2. Nacos 客户端开推送 + 短轮询兜底：确认 nacos.client.config.long.polling.timeout 生效，并给本地实例列表加一个 10s 的刷新兜底，避免推送丢失时客户端一直用旧列表。

3. 连接池设合理的存活上限，别让一条连接无限复用：

   OkHttp: .connectionPool(new ConnectionPool(20, 30, TimeUnit.SECONDS))
   

   空闲连接最多活 30s，配合下面的重试，旧连接到期自然被换掉。

4. 对 Connection refused / reset 做「换 IP 重试一次」：在客户端 LB 层捕获这两类异常，剔除该实例 + 重新选一个再发，而不是直接抛 5xx。这是把 47 个 5xx 降到个位数的关键。

5. 发布顺序反过来：先让新版本 Pod Ready 并注册到 Nacos，再缩旧版本（把 maxSurge=1 打开，先增后减）。这样客户端缓存里「多出来的新 IP」远比「消失的旧 IP」安全——多一个不会错，少一个才会错。

四、踩过的坑 / 反直觉之处

• 坑 1：以为 5xx 一定和下线时序有关。 查了 preStop、terminationGracePeriodSeconds 全对，方向错了。要区分「服务端还没摘干净」和「客户端还认旧 IP」，这两类 5xx 的 IP 表现不同：前者 IP 还能 get pod 查到，后者查不到。
• 坑 2：Connection refused 和 Connection reset 混在一起看。 其实含义不同——refused 多半是 DNS/注册中心还指着旧 IP（对端根本没监听），reset 多半是连接池复用了半死连接（对端已退场但内核残留回包）。分开统计能直接定位是缓存层还是连接层。
• 坑 3：把 negative.ttl 也忘了设。 只调正向 TTL，负缓存还是 30s，一个「查不到」的解析结果也会被缓存半分钟，旧 IP 的幽灵窗口照样在。
• 反直觉：先增后减（surge）比单纯调短所有缓存 TTL 更稳。因为客户端「多一个实例」永远不会错，「少一个实例」才会错，发布策略上应该让「多」来兜底，而不是赌缓存刷新得够快。

五、结论与可复用清单

发布后 5xx 的排查，先别急着调优雅下线时序，先分清楚 5xx 的 IP 还查不查得到 Pod：查得到 → 下线时序问题；查不到 → 客户端缓存/连接复用问题。可复用清单：

1. 客户端 DNS TTL：-Dsun.net.inetaddr.ttl=5、negative.ttl=1；
2. 注册中心本地列表加 ≤10s 刷新兜底，别只信推送；
3. 连接池空闲存活设上限（如 30s），别让连接无限复用；
4. 对 refused/reset 做「剔除实例 + 换 IP 重试一次」，不要裸抛 5xx；
5. 发布用 maxSurge=1 先增后减，让「多一个实例」兜底；
6. 监控上把 5xx 按「IP 是否已存在」打标，一眼区分是服务端没摘干净还是客户端认旧 IP。

这套组合拳落地后，同样的发布流程，发布窗口期 5xx 从 47 个降到 0~2 个，且全部落在可重试范围内，用户侧无感。