使用 Statefulset 部署组件

对于kubernetes老玩家而言，StatefulSet这种资源类型并不陌生。对于很多有状态服务而言，都可以使用 StatefulSet 这种资源类型来部署。那么问题来了：挖掘机技术哪家强？额，不对。

如何在 Rainbond 使用 StatefulSet 资源类型来部署服务呢？

组件部署类型

通过在服务组件的其他设置中，更改 组件部署类型 即可选择使用 StatefulSet 资源类型部署服务，操作之前要注意以下几点：

• 组件需要处于关闭的状态；
• 对于有持久化存储的服务组件，切换组件部署类型会导致存储挂载的变更，一定要做好数据备份；

Rainbond 默认提供四种组件部署类型：

• 有状态单实例：使用 StatefulSet 部署服务，不可以进行实例的横向伸缩，实例数量始终为1；
• 有状态多实例：使用 StatefulSet 部署服务，实例数量可以进行横向伸缩；
• 无状态单实例：使用 Deployment 部署服务，不可以进行实例的横向伸缩，实例数量始终为1；
• 无状态多实例：使用 Deployment 部署服务，实例数量可以进行横向伸缩；

当你在 Rainbond 中将组件部署类型指定为有状态 （StatefulSet） 之后，服务组件将体现以下特性：

• 多实例状态下，所有实例将具备顺序性，实例的命名将类似于 gr6ec114-0 gr6ec114-1 ，这一顺序性将体现为全生命周期的层面，顺序的启动、更新、重启、关闭。
• 上述的主机名在集群中将可以被解析，同团队下，尝试在任意 POD 中执行nslookup gr6ec114-0。不同团队下，需要指定命名空间，可解析地址的完全地址为：gr6ec114-0.gr6ec114.3be96e95700a480c9b37c6ef5daf3566.svc.cluster.local 其中 3be96e95700a480c9b37c6ef5daf3566 为命名空间。
• 多实例状态下，每个实例的持久化存储将被单独挂载，这意味着持久化数据在实例之间不再共享。
• 单实例状态下，执行更新操作时，实例将会在完全关闭之后，启动新的实例，这意味着服务会出现中断。
• 出于对持久化数据一致性的保护，运行了有状态服务的 k8s 节点一旦失去和管理节点的联络，处于 notready 状态时，其有状态服务的实例不会自动迁移。

整体来看，利用 StatefulSet 资源类型来部署服务，带来了新的特性的同时，会显得呆板了一些，但接下来的探讨，会发现这些限制是有意义的。

细心如你一定会发现，我们将 StatefulSet 这种资源类型和 “有状态” 绑定在了一起。那么，一个新的问题冒了出来：什么是服务的 “状态”。

服务的“状态”

有状态（Stateful）服务 = 无状态（Stateless）的应用程序 + 有状态的数据

从有状态服务的名字就可以看出， 它和 StatefulSet 这种资源类型是有关联的。

单纯说概念，可能很难理解什么是有状态服务。让我来举几个例子：

• 最常见的有状态服务，就是DB类的数据库中间件。

对于常见数据库 Mysql 而言，同一份数据，在同一时刻只可以被一个 Mysql 程序使用。Mysql 在启动后，会在自己的数据目录下生成唯一的锁文件，并把这个文件“锁死”。这样一来，其他想要使用这份数据的 Mysql 程序，会因为发现这个锁文件被“锁死”，而中断启动的过程。这样做的好处，是保证了数据的强一致性，因为同一份数据在同一时刻，绝对只会被同一个 Mysql 应用程序所读写。

请回忆下 StatefulSet 资源类型带来的特性之一就是每个实例都会挂载独立的持久化存储，这样可以确保 Mysql 服务可以被扩展成多个实例运行起来，不会因为锁文件的原因被终止启动，但是因为彼此之间数据不共享，所以本质上实例之间没有什么关系。使用有状态单实例的方式运行 Mysql 看起来是最正确的选择。

情况类似的常见数据库中间件还有 Mongo、Postgresql、Redis、Etcd等。

• 另一种常见的有状态服务场景，是 Web 类的服务提供的粘性 Session。

这种粘性 Session 在某些情况下会保存在内存中，用来提供会话保持，本身也是一种数据。一旦将这种服务扩展多个实例，一旦访问到不正确的实例，那么就会因为找不到 Session 而丢失登陆态。在负载均衡中使用 IP Hash 算法进行流量的分发可以在某种程度上解决这个问题，来自同个 IP 的流量会被分发到指定的实例。但是我们更希望流量的分发是轮询的，这样可以确保每个实例的负载都是相近的，不会出现某个实例负载过高，而其他实例无所事事的情况。

这两种有状态服务场景，都向我们指出，对有状态服务而言，不同实例的数据是相互独立的。数据即“状态”。

相比较而言，无状态的服务就灵活很多。它们没有持久化数据，或者持久化数据支持共享。对于客户端而言，请求哪一个实例获得的返回都是一致的。这样的特性意味着可以随意扩展无状态服务的实例数量，灵活的应对流量。

使用云服务最大的好处之一，就是它提供的弹性和灵活性，在业务遭遇流量高峰时，可以快速扩展实例进行应对。从这个角度出发，我们希望服务都是 “无状态” 的。那么，一个新的问题冒了出来：我们可以去掉服务的 “状态”，使之变成无状态服务么？

处理服务的 “状态”

利用粘性 Session 保持登陆态的这类 Web 服务，其状态是可以被去掉的。

原理比较简单，把 Session 和 Web 应用程序剥离，存储到其他中间件中去即可，比如保存到Mysql、 Redis、Memcached等数据库中间件中去。市面上常见的 Web 框架都会支持这种功能，甚至把这种处理方式作为默认选项，因为这实在太棒了！

处理完的 Web 服务，就变成了无状态服务，可以任意扩展实例数量了。来自客户端的请求无论被分配到哪一个实例，其登陆态都到后端数据库中调取，返回正确的登陆态。在部署时，可以选择无状态多实例进行部署，即使用 Deployment 这种资源类型。

但是对于DB类的数据库中间件而言，其状态是不可以被随意去除的。

原因在于这类数据库中间件使用自己的机制来确保数据强一致性，就比如 Mysql 的锁文件机制，指定的实例只能去读写对应自己的那一份数据。对这一类有状态服务而言，每个实例独享一份持久化数据可以算作是必须的条件。并且随意扩展实例数量，会遭遇很多致命的问题：比如数据不一致，或者程序运行失败等等。这一类的有状态服务只能单点部署吗？

这些数据库中间件的出品厂商或者社区，也都很关注如何实现高可用方案，来解决上述的问题。甚至近些年推出的数据库中间件，在设计阶段就会被设计成分布式架构。比如 Etcd 对自己的定义就是：可靠的强一致性分布式键值数据库。其内部使用 Raft 协议进行实例间选举来明确统一的leader。而对于 Mysql 这样比较老牌的数据库中间件，也具备基于 Binlog 复制实现的主从集群方案。

所以针对这一类无法去除状态的服务而言，我们的思路与宗旨，就是遵循其自身支持的集群方案，来实现高可用以及实例数量扩展。

实际部署这些集群方案时，可以总结出，大多数集群方案需要满足以下条件：

• 每个实例挂载单独的持久化数据；
• 实例间需要获取彼此的通信地址，来进行选举或者数据同步等动作，比如可解析的主机名或域名。获取地址时一定要使用主机名或域名而非实例 IP，因为随着实例的重启，主机名或域名不会改变，但是IP可能会改变，这很重要；
• 实例数量是有要求的，一般情况下选择 3、5、7··· 等奇数，来保证集群不会出现脑裂；

回想一下 StatefulSet 资源类型的特性，它可以满足上述的所有条件，就是为了有状态服务而生的。所以这一类有状态服务，其组件部署类型无论如何要使用有状态单/多实例。