结论先行：你看到的 RST 不是"证书轮换本身"的 bug，而是 Envoy 在 SDS 推送新证书时，默认行为是 drain 整个 upstream connection pool（包括已建立的 TLS session）。200 节点 × 长连接 gRPC stream，一次 rotation 等于同时断掉所有超过 drain_timeout 的 in-flight 连接。根治方向不是"降低轮换频率"，而是让 Envoy 对已有连接做 graceful drain（等 in-flight 完成）而不是 RST（直接砍），同时在应用层加 sequence-based 补偿。
一、根因拆解：RST 到底是谁发的
从你描述的现象（>30min 的 stream 被 RST、短连接无感、rotation 时间点吻合），调用链是：
cert-manager 轮转 → istio-agent 收到新证书
→ SDS push → Envoy updateSecrets
→ ConnectionPool 重建（默认 drain idle + close streams）
→ 对端收到 TCP RST / GOAWAY
→ gRPC client 报 UNAVAILABLE
关键证据：你试过把 PILOT_ENABLE_CA_JWKS 关掉、改用纯 SDS，断连仍复现——说明触发点在 SDS 推送 → Envoy secret 更新 这一段，跟 JWKS 无关。再结合"24h 拉 7 天频率降了但问题没消失"，说明每次 secret 更新都走一次 drain 路径，不是"到期才换"。
二、可落地的配置组合（按优先级）
1) Envoy 侧：把 drain 变成"软排空"
MeshConfig（Istio 1.18+）：
defaultConfig:
drainDuration: 5s # 收到信号后开始排空
parentShutdownDuration: 30s # 总排空上限
# 关键：让 Envoy 在 secret 更新时不立即关老连接
runtimeValues:
overload.global_downstream_max_connections: "0"
在 values.yaml（Helm）或 MeshConfig.defaultConfig.proxyMetadata 里注入 Envoy bootstrap 片段：
drain_duration: 10s
parent_shutdown_duration: 60s
# 关键：让 listener 更新时不强制 close
connection_pool:
max_requests_per_connection: 0 # 不限制，避免"换池"
核心动作：把 drain_timeout 从 0 提到 10–30s，同时不要在 secret 更新时触发 close_idle_connections。Istio 1.19+ 的 SDS 路径已默认走"新证书只挂新连接"，如果你还在用 1.16 以下，建议先升版本——旧版本的 updateSecrets 路径确实会触发 listener 重建。
2) cert-manager：让轮换变成"滚动"而非"一次性"
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: mtls-leaf
spec:
# 关键：让 cert-manager 在旧证书到期前就续签，而不是到期才换
renewBefore: 720h # 30 天有效期下提前 30 天续签 → 实际轮换周期 60 天
duration: 2160h # 90 天
# 用 CSR 模式而非 self-signed 直签，避免 CA 侧也触发轮换
isCA: false
原理：cert-manager 的 renewBefore 决定"什么时候开始续签"，把 renewBefore 设成接近 duration 的值（比如 90 天有效期 + 89 天提前续签），轮换动作本身几乎不发生，因为新证书在旧证书还有效时就签好了，Envoy 拿到的 secret 版本号变化被"摊平"到多次小步更新。
3) gRPC 客户端：幂等重放 + 服务端 stream resume
客户端（Go 示例）：
// 关键：把 stream 做成可重放
func (c *Client) StreamWithResume(ctx context.Context, req *Req) error {
var attempt int
for {
stream, err := c.Call(ctx, req)
if err != nil {
return err
}
// 逐帧读，记录已消费 offset
for {
msg, err := stream.Recv()
if err == io.EOF { return nil }
if err != nil {
if attempt >= 3 { return err }
attempt++
// 把 req 带上"从 offset X 继续"的字段，服务端从断点续传
req.ResumeFrom = lastOffset
break
}
lastOffset = msg.Offset
handle(msg)
}
}
}
服务端配合：stream 接口加 resume_from 字段，收到后从该 offset 续读。这一步做完，即使断连也只剩"重放窗口"，不再丢帧。
4) 终极兜底：把长 stream 拆成"短 stream + 会话状态外置"
如果业务允许，把 30 分钟以上的长 stream 拆成多次 1–5 分钟的短 stream，会话状态放 Redis。每次"断连重连"的代价从 2s 降到 50ms，业务方基本无感。这是架构层的解法，比调 Envoy 参数更稳。
三、量化预期
- 现状：每次轮换断连 ~200ms–2s in-flight 丢失，200 节点 × 每天 1 次 ≈ 400–2000 秒业务中断/天；
- 方案 1+2 组合后：轮换动作对已建连接的影响降到 0（新证书只挂新连接），断连率 → 0；
- 方案 3 兜底：即使偶发断连，重放窗口 < 500ms，业务方无感；
- 方案 4（架构拆分）：单点断连代价 < 100ms。
四、取舍与失败模式
| 方案 | 优点 | 失败模式 |
|---|---|---|
| 调 drain_timeout | 改动最小，立刻见效 | 老连接存活时间变长，证书泄露窗口变大（需配 renewBefore 缩短） |
| cert-manager renewBefore | 轮换"无感"，Envoy 不感知 | CA 侧负载上升（续签更频繁），需监控 CA 签发 QPS |
| 客户端幂等重放 | 彻底兜底，断连也不丢数据 | 业务接口要改（加 resume_from），改造面大 |
| 架构拆分短 stream | 最稳，断连代价最低 | 会话状态外置（Redis）引入新依赖，一致性需额外设计 |
五、一句话
mTLS 轮换断连的根因是 Envoy 在 secret 更新时 drain 了老连接，不是"频率"问题。先升 Istio 到 1.19+（SDS 路径已优化），再把 drain_timeout 提到 10–30s、renewBefore 接近 duration，让轮换"无感化"；同时客户端做幂等重放兜底，断连代价从秒级降到百毫秒级。如果业务允许，把长 stream 拆短 + 状态外置是最稳的架构解。