Kubernetes：带指纹文件的滚动更新最优方案探讨

1. 就绪探针（Readiness Probe）+ 滚动更新参数调优 #

这是解决新旧Pod共存时文件不兼容问题的核心手段：

• 给新Pod配置就绪探针，确保Pod完全加载所有静态资源、完成初始化后才标记为「就绪」，Service才会将流量路由到该Pod。比如可以探测某个带新版本指纹的静态文件是否存在，或者调用健康检查接口确认资源加载完成：

  readinessProbe:
    httpGet:
      path: /static/v2/xxx.[指纹].js
      port: 80
    initialDelaySeconds: 10
    periodSeconds: 5
  

• 调整Deployment的滚动更新策略，限制新旧Pod的共存数量，比如设置maxUnavailable: 0（不允许任何旧Pod在新Pod就绪前销毁）、maxSurge: 1（每次只启动一个新Pod），确保只有新Pod完全就绪后，才逐步替换旧Pod，从源头减少跨版本请求的概率。

2. Recreate 更新策略（无新旧版本共存） #

如果你的副业项目可以接受短暂服务中断，直接使用Deployment的Recreate更新策略：

• 该策略会先销毁所有旧Pod，再启动新Pod，从根本上避免新旧版本同时运行的情况，自然不会出现新Pod请求旧Pod文件的404问题。配置示例：

  strategy:
    type: Recreate
  

• 缺点是更新期间服务不可用，适合对可用性要求不高、更新频率低的副业项目。

3. PreStop 钩子 + 终止宽限期 #

针对旧Pod的终止流程做优化，确保旧Pod在退出前完成所有请求处理，同时给新Pod足够的就绪时间：

• 给旧Pod配置preStop钩子，让Pod在收到终止信号后先等待一段时间，确保当前请求处理完成，同时新Pod有足够时间就绪：

  lifecycle:
    preStop:
      exec:
        command: ["sleep", "30"]
  

• 配合terminationGracePeriodSeconds延长终止宽限期，确保旧Pod有足够时间处理完剩余请求，同时新Pod已经就绪并接管流量。

4. 静态资源镜像内打包 #

将静态资源直接打包进Pod镜像，而非挂载共享存储或依赖外部服务。这样每个Pod只访问自身镜像内的同版本静态文件，彻底避免跨Pod请求不同版本文件的问题。

内容的提问来源于stack exchange，提问作者methodical