时间戳

首页 > 解决方案 > Kubernetes 上的零停机更新。当有上传文件的请求时

kubernetes - Kubernetes 上的零停机更新。当有上传文件的请求时

问题描述

我的目标是对 Kubernetes 进行零停机更新。

但是，存在与文件上传有关的问题。

情况是当用户上传文件时，网络服务器首先存储它。WAS 将文件的元数据保存到 DB。

所以问题是当我们更新网络服务器时。网络服务器不会等待请求完成。并且文件上传/下载服务将失败（如果客户端连接到将关闭的网络服务器）。

我该怎么办？

标签： kubernetesfile-uploadwebserverfileserverdowntime

解决方案

简而言之，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来避免长文件传输 - 长连接

  • 架构更改策略，应该同时支持两个版本（例如，如果您向数据库添加新列，最好在第一个版本中添加它，然后在第二个版本中使用它以及许多其他技术）

申请（最后的手段）：

  • 一些无法承受停机时间但部署新版本很复杂/不可能的公司决定在应用程序升级时对新连接（附加代码）进行排队。因此，文件和数据库记录从旧版本导入新版本，以完成零停机部署。

推荐阅读