滚动更新时Pod仍处理旧请求，因默认策略直接发SIGTERM且不等待请求完成；需应用监听SIGTERM并调用Shutdown()，配合适当的readinessProbe、terminationGracePeriodSeconds及ConfigMap版本管理。
滚动更新时 Pod 为什么还在处理旧请求？
因为默认的 rollingUpdate 策略只管删旧 Pod、起新 Pod，不等旧 Pod 主动退出服务就直接发 SIGTERM。Kubernetes 不知道你的应用是否已停止接收新连接，更不会等正在处理的 HTTP 请求完成。
实操建议：
- 在应用里监听
os.Interrupt和syscall.SIGTERM，收到后关闭 HTTP server 的Shutdown()方法，给活跃请求留出超时窗口（比如 10 秒） - 在 Deployment 的
spec.template.spec.containers.livenessProbe和readinessProbe中，确保readinessProbe在服务真正就绪前返回失败——否则流量会提前打到未初始化完的 Pod - 设置
terminationGracePeriodSeconds: 30（别用默认 30 秒就不管了），确保它 ≥ 应用Shutdown()超时时间
readinessProbe 失败导致滚动卡住？
这是最常被忽略的阻塞点：K8s 默认等待新 Pod 的 readinessProbe 成功后才删下一个旧 Pod。如果 probe 配置不合理，整个滚动会停在“1 个新 Pod 一直 not ready”上。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 新 Pod 一直处于
ContainerCreating或Running但READY 0/1 -
kubectl rollout status deploy/myapp卡住不动，日志里反复出现Readiness probe failed
检查重点：
-
initialDelaySeconds是否太小？Go HTTP server 启动慢（尤其带 DB 连接池预热），设成15比5更稳妥 -
periodSeconds和failureThreshold组合是否过于激进？比如periodSeconds: 2+failureThreshold: 3= 6 秒内失败就踢出，容易误判 - probe endpoint 是否真能反映服务就绪？别用
/healthz返回固定200，应检查 DB 连接、依赖服务连通性等真实依赖
回滚时为啥新旧版本配置不一致？
因为 kubectl rollout undo 只还原 Deployment 的 spec.template 字段，但 ConfigMap、Secret、Service、Ingress 这些外部资源不会自动同步回滚——它们可能已被手动改过，或由 CI/CD 流水线单独更新。
使用场景：
- 上线后发现接口返回格式错乱，怀疑是新版本读取了旧版 ConfigMap 里的错误字段名
- 回滚后日志里仍出现新版本的 trace ID 格式，说明某个 sidecar 或 initContainer 镜像没跟着回退
实操建议：
- 把 ConfigMap/Secret 的版本号写进 Deployment 的 annotation（如
configmap-version: v2.1），回滚脚本里一并替换 - 避免直接
kubectl apply -f configmap.yaml手动更新配置；改用 Kustomize 或 Helm，让所有资源版本受同一 commit 控制 - 回滚前先确认
kubectl get deploy/myapp -o yaml输出里revisionHistoryLimit是否 ≥ 2，否则旧 revision 可能已被 GC 掉
Go 应用里怎么安全地 reload TLS 证书？
滚动更新时如果证书文件是挂载进 Pod 的 volume，旧进程拿不到新证书内容——os.Open 打开的是 inode，而 kubectl rollout 更新 ConfigMap 后，K8s 实际是新建文件再原子替换 symlink，老进程仍读旧 inode。
性能与兼容性影响：
- 硬重启（删 Pod）能解决，但破坏零宕机目标
- 轮询
stat文件修改时间再重载，有延迟且增加 syscall 开销
推荐做法：
- 用
fsnotify监听证书文件所在目录，事件触发后调用http.Server.TLSConfig.GetCertificate动态更新（注意加锁） - 或者更简单：让 Go 应用定期（如每 5 分钟）重新
os.ReadFile证书内容并重建tls.Config，比监听更可靠 - 千万别在
main()里一次性读证书然后复用——那是静态加载，滚动更新后永远不变
复杂点在于证书重载和连接平滑迁移需要配合：新证书生效后，旧连接仍走老密钥，新连接才用新证书，这本身没问题；但你要确保 GetCertificate 函数不 panic，否则整个 HTTPS server 会挂掉。
