我试图弄清楚如何根据 JSESSIONID cookie 提供具有长期交互用户会话的 web 应用程序的零停机滚动更新，这些会话应该是粘性的。
出于这个（和其他）原因，我正在研究容器技术，比如 Docker Swarm 或 Kubernetes。
我很难找到关于如何：
- 确保新会话转到最新版本的应用程序
- 虽然现有会话仍由它们启动的任何版本的应用程序提供服务
- 关闭旧版本的所有会话后，正确清理旧版本
更多信息：
- 请求链接到基于 JSESSIONID cookie 的会话
- 会话可能会持续数天，但可以在 24 小时内从应用程序中终止它们（向用户发送通知以“再次注销/登录，因为有新版本或它们会在下午 12 点自动注销“ 例如）
- 当然，对于每个版本的应用程序，已经有多个容器以负载平衡的方式运行
- 我不介意容器总数的增长，例如，如果每个旧版本的容器都仍在运行，因为它们仍然会托管 1 个会话，而大多数用户已经在使用新版本的应用程序
所以，我对所需流程的想法是这样的：
- 安装新版本的应用程序
- 让所有新连接（没有设置 JSESSIONID cookie 的连接）转到新版本的应用程序一次
- 旧版本应用程序的容器不再提供会话，删除容器/....
正如我所提到的，我正在研究 Kubernetes 和 Docker Swarm，但对其他建议持开放态度，但最终解决方案应该能够在云平台上运行（目前使用 Azure，但未来可能会使用谷歌或亚马逊云）
任何指示/提示/建议或想法表示赞赏
保罗
编辑：回答@Tarun 问题和一般说明：是的，我不想停机。我设想的方式是托管旧版本的容器将继续运行以服务所有现有会话。旧服务器上的所有会话结束后，旧服务器将被删除。
新容器只会为在新版本推出后启动应用程序的用户提供新会话。
因此，举个例子： - 我在上午 9 点启动旧版本应用程序的新会话 A - 上午 10 点推出新版本。- 我继续使用会话 A，其仍然托管在运行旧版本的容器上。- 中午我去吃午饭并注销 - 因为我是连接到运行旧版本的容器的最后一个会话，容器现在将被销毁 - 下午 1 点我回来，重新登录并获得新版本的应用程序
说得通？