滚动更新时证书同步延迟导致 TLS 握手失败，需通过 Secret 挂载、inotify 监听或 sidecar 重载、minReadySeconds 与 TLS readinessProbe 配合、cert-manager 统一管理及 Java 应用禁用 SSL 缓存来解决。
滚动更新时证书同步延迟，本质是新 Pod 启动后尚未加载或信任最新证书，而旧 Pod 已下线，导致服务短暂不可用或 TLS 握手失败。这不是单纯的配置问题，而是证书分发、加载时机与 Pod 生命周期未对齐的结果。
确保证书作为挂载卷实时注入
不要把证书硬编码进镜像或通过环境变量传递。应使用 Secret 挂载 方式，让 K8s 自动将证书文件以只读方式挂载到容器指定路径（如 /etc/tls/certs/）。Secret 更新后，K8s 会自动热更新挂载内容（默认 1 分钟内生效），但容器进程需主动重载——因此必须配合以下机制：
- 在容器启动脚本中监听挂载目录的 inotify 事件，检测证书变更后触发 reload（如 Nginx 的
nginx -s reload） - 或使用 sidecar 容器（如
cert-reloader）监控 Secret 变更，并向主容器发送信号 - 避免使用 initContainer 复制证书——它只在 Pod 启动时执行一次，无法响应后续 Secret 更新
滚动更新策略中预留证书就绪窗口
Deployment 的 rollingUpdate 需配合健康检查，确保新 Pod 不仅容器启动成功，还要确认证书已加载且服务能正常响应 TLS 请求：
- 设置
minReadySeconds（建议 ≥30s），强制新 Pod 运行足够时间再接收流量 - 定义带 TLS 验证的
readinessProbe：用exec调用openssl s_client -connect localhost:8443 -servername example.com 2>/dev/null | grep "Verify return code: 0" - 启用
maxUnavailable: 0和maxSurge: 1，实现“先扩后缩”，避免全量替换带来的证书空窗期
统一证书生命周期管理，避免人工干预断点
证书过期不是孤立事件，它必须与滚动更新节奏解耦。推荐做法：
- 所有服务共用由 cert-manager 管理的 Issuer + Certificate 资源，自动续签并更新对应 Secret
- 在 Deployment 中通过
volumeMounts引用该 Secret，不写死名称，依赖 K8s 自动注入最新版本 - 禁用手动替换证书文件、重启组件等运维操作——这些会打断自动化链路，造成不同 Pod 使用不同证书版本
- 若使用自签名 CA，确保根证书也通过 Secret 挂载，并在应用启动时显式配置信任库（如 Java 的
-Djavax.net.ssl.trustStore）
Java 类应用特别注意 JVM 证书缓存
Spring Boot 等 Java 应用默认启用 SSL 会话缓存和证书信任链缓存，即使挂载了新证书，JVM 可能仍沿用旧缓存：
- 启动参数加入
-Dcom.sun.net.ssl.checkRevocation=false（仅测试环境）或更稳妥地禁用会话复用：-Djdk.tls.client.enableSessionTicketExtension=false - 在应用层调用
SSLContext.getDefault().getSocketFactory()并重新初始化，或在证书更新后触发 JVM 的Security.setProperty("ssl.KeyManagerFactory.algorithm", "PKIX")刷新 - 优先采用
spring-boot-starter-webflux+ Netty，其 SSL 配置更易动态重载，比 Tomcat 更适合滚动场景
