问题描述
我的目标是在 kubernetes 上实现零停机更新。
情况是当用户上传文件时，网络服务器首先存储它。 WAS 将文件的元数据保存到数据库中。
所以问题是当我们更新网络服务器时。网络服务器不会等待请求完成。并且文件上传/下载服务将失败（如果客户端连接到将关闭的网络服务器）。
我该怎么办？
解决方法
简而言之，Kubernetes 中没有任何神奇的工具可以为任何类型的应用程序解决这个问题。
主要目标是什么？
-
删除一个 Pod（如果你能优雅地删除一个 Pod，那是一大步）
-
应用同时支持两个版本（用于推出和回滚）
那么如何实现零停机部署和更新？
Kubernetes/Docker：
-
应用程序作为特殊的 PID 1 运行，因此它可以直接接收
SIGTERM（标准正常关机）信号 -
您在
terminationGracePeriodSeconds或StatefulSet中指定Deployment。当您缩小应用程序（或删除一个 Pod 以替换为新 Pod）时，不会路由任何新连接，它会向应用程序发送SIGTERM并等待terminationGracePeriodSeconds时间。通常排空连接最多需要 5-10 分钟，但完成长连接可能甚至需要几个小时。如果应用按照您的意愿理解SIGTERM，它可以更早完成。 -
刚刚工作
readinessProbe检查
应用：
-
理想情况下理解
SIGTERM并优雅地关闭操作 -
如果第一次尝试失败（例如从前端到后端的 API 调用、从后端的数据库查询等），应用程序应该能够重试连接或操作 - 这有助于在新 pod 上重试操作，一般来说在高可用系统中重试是一件好事
-
应用以较小的块完成其工作，并具有提到的重试需求，例如使用 http://resumablejs.com 来避免长文件传输 - 长连接
-
模式更改策略，应该同时支持两个版本（例如，如果您向数据库添加新列，最好在第一个版本中添加它，然后在第二个版本中使用它等等其他技术）
申请（最后的手段）：
- 有些公司无法承受停机时间，但部署新版本很复杂/无法部署，因此决定在应用升级时将新连接（附加代码）排队。因此文件和数据库记录从旧版本导入到新版本以完成零停机部署。