K8s 滚动发布后 gRPC 客户端仍持有旧 Pod IP 长连接：DNS 缓存叠加 Netty 连接池如何系统性治理

【背景】 我负责一个交易清算服务，K8s 1.28（containerd 1.7），gRPC 1.60（Netty 4.1.100），Java 17。上游 6 个微服务通过 gRPC 调用清算服务，服务 4 副本（Deployment，maxSurge=1 / maxUnavailable=0），走 ClusterIP Service + headless Service（部分直连 Pod IP 做分片路由）。

【现象】 每次滚动发布，旧 Pod 被删除、新 Pod 起来后，约 30%~40% 的客户端实例在 30~120 秒内出现 gRPC UNAVAILABLE 或 DEADLINE_EXCEEDED，错误日志里 target 地址是旧 Pod IP（比如 10.244.3.77），而不是新 Pod IP（10.244.3.112）。重启客户端 Pod 后立刻恢复。

【已尝试的排查与结果】

1. 把 CoreDNS 的 cache TTL 调到 30s 并重启 CoreDNS——有效但只减短了窗口，没有根治。DNS 层面确实返回了新 IP，但客户端 Netty 连接池里已经 hold 住的 TCP 连接仍然指向旧 IP。
2. 在 gRPC 客户端加了 keepalive_time=30s / keepalive_timeout=10s——能探测到连接死了，但 Netty 的 PooledConnectionProvider 不会自动 re-resolve DNS，只是把这条连接标记 dead，下一条请求可能又拿到另一条指向旧 IP 的连接。
3. 试了 Envoy sidecar（Istio 1.20）——EDS 能感知 Endpoints 变化，窗口缩到 5 秒以内，但引入了 sidecar P99 额外 2~3ms 延迟，业务侧不同意。

【期望得到的答案形态】 希望看到不引入 service mesh 的前提下，gRPC / Netty 客户端侧的系统性治理方案：

• DNS 解析层：Endpoints 变更后如何做秒级 re-resolve（CoreDNS 配置、JVM networkaddress.cache.ttl、Netty DnsNameResolver 配置）；
• 连接池层：如何让 Netty PooledConnectionProvider 在对端已 dead 时主动驱逐并触发 re-resolve，而不是等下一次请求超时；
• 重试层：gRPC retryPolicy + hedgingPolicy 在「target 地址过期」场景下怎么配才能既不死循环重试旧 IP，又不放大故障；
• headless Service + 直连 Pod IP 场景下，本地缓存的分片路由表失效后如何安全刷新。

最好能带一段可运行的 gRPC 客户端配置（proto + Java 代码片段），让我能直接对着改。