kubernetes - 如何使用容器为具有(长期)粘性 session 的应用程序进行零停机滚动更新

Question

我试图弄清楚如何基于 JSESSIONID cookie 为具有长期交互式用户 session 的 web 应用程序提供零停机滚动更新，这些 session 应该是粘性的。

出于这个(和其他)原因，我正在研究容器技术，比如 Docker Swarm 或 Kubernetes。

我很难找到关于如何的好答案:

确保新 session 转到最新版本的应用程序

虽然现有 session 仍由任何版本的
他们在

上启动的应用程序

一旦所有 session 都到/在旧版本上，请正确清理旧版本
已关闭

更多信息:

请求链接到基于 JSESSIONID cookie 的 session

session 可能会持续数天，但可以在 24 小时内从应用程序内终止它们(向用户发送通知“注销/再次登录，因为有新版本，否则会在下午 12 点自动注销” ” 例如)

当然，对于每个版本的应用程序，已经有多个容器以负载平衡的方式运行

我不介意容器总数的增长，例如，如果每个旧版本的容器都仍在运行，因为它们仍然会托管 1 个 session ，而大多数用户已经在使用新版本的应用程序

所以，我对所需流程的想法是这样的:

挂上新版app

让所有新连接(没有 JSESSIONID cookie 集的连接)转到应用程序的新版本一次

旧版本应用程序的容器不提供 session 服务
再移除容器/....

正如我提到的，我正在研究 Kubernetes 和 Docker Swarm，但对其他建议持开放态度，但最终解决方案应该能够在云平台上运行(目前使用 Azure，但 future 可能会使用谷歌或亚马逊云)

任何指示/提示/建议或想法表示赞赏

保罗

编辑:
回答@Tarun 问题和一般说明:是的，我不想停机。我设想的方式是托管旧版本的容器将继续运行以服务所有现有 session 。一旦旧服务器上的所有 session 结束，旧服务器就会被移除。

新容器只会为在新版本开始推出后启动应用程序的用户提供新 session 。

所以，举个例子:
- 我在上午 9 点启动了旧版本应用程序的新 session A
- 上午 10 点推出新版本。
- 我继续使用 session A，并保留托管在运行旧版本的容器上。
- 中午我去吃午饭然后注销
- 因为我是最后一个连接到运行旧版本的容器的 session ，容器现在将被销毁
- 下午 1 点我回来，重新登录并获得新版本的应用程序

说得通？

Answer 1

您的工作负载可能不适合 Kubernetes/容器及其当前架构。我能想出解决这个问题的最好方法是将状态移动到 PV/PVC 并将 PV 迁移到新容器，以便新容器可以拥有旧 session 的状态，现在如何将该 session 的调用迁移到正确的节点我不确定如何有效地做到这一点。

理想情况下，您将您的数据/缓存层与您的服务分离成类似 redis 的东西，然后哪个节点为请求提供服务就无关紧要了。