使用 K8S 实现高可用的有状态会话答案

【问题标题】：Highly available stateful session implementation with K8S使用 K8S 实现高可用的有状态会话
【发布时间】：2022-01-10 19:39:08
【问题描述】：

如何使用 K8S 实现内存状态/会话复制？例如，一个网络购物车系统通过网络在集群节点之间复制用户 HTTP 会话，这样如果一个节点出现故障，另一个节点中的进程可以接管用户会话。

我认为 K8S 有 StatefulSet，它使用磁盘存储来确保状态持久性。如果一个 pod 宕机，重新启动的 pod 会接管磁盘的状态。但是，将内存中的用户会话持久保存到磁盘的开销很高，并且可能不够快。

我想解决方案可能是使用内存缓存服务器或类似 etcd 的系统。是既定的惯例吗？据我了解，K8S 在规模上适合无状态处理，并且引入了 StatefulSet 来解决有状态的情况，但不确定它是否适合需要快速状态切换的情况。

请指教。

【问题讨论】：

我认为我们通常使用statefulset 作为数据库服务之类的永久存储。在您的情况下，deployment 和内存缓存中的 etcd 或 redis 将是合适的。

【解决方案1】：

如何使用 K8S 实现内存状态/会话复制？为了例如，网络购物车系统复制用户 HTTP 会话在网络上的集群节点之间，如果一个节点关闭，一个另一个节点中的进程可以接管用户会话。

要存储状态，最好使用 Redis 或内存数据库。

K8S 有 StatefulSet，它使用磁盘存储来保证状态坚持，我想。如果一个 pod 宕机，重启的 pod 会接管状态形成磁盘。但是，持久化内存的开销用户到磁盘的会话数很高，可能不够快。

您是对的，但也许您之前没有尝试过，我在 K8s 中使用 Redis 进行生产，拥有数百万用户，但从未遇到过问题。如果您在 K8s 上部署，Redis 有两种备份密钥的选项。

RDB和Append only-AOF，到现在还没有遇到过Redis崩溃左右，只是Out才崩溃内存，因此请确保您的 Key policy 设置正确，例如 LRU 左右。

在我的理解中，K8S 有利于规模化的无状态处理

您是对的，但人们一直在使用 Deployment 和 Statefulsets 在 K8s 中运行 Redis 集群和 Elasticsearch 集群，并提供所有备份和扩展选项。

使用 K8s 配置和管理 DB 很容易，而 VM 没有太多的可扩展性。

长期以来，我们一直在 Prod 中使用 Redis、Elasticsearch、RabbitMQ 运行有状态集，但还没有看到很多问题。确保将 SSD 高 IOPS 磁盘连接到 POD，一切顺利。

【讨论】：