Kubernetes StatefulSets

系列文章目录

Kubernetes StatefulSets

---

---

前言

StatefulSets, PetSets, Deployment

StatefulSets（有状态系统服务设计）在Kubernetes 1.7中还是beta特性，同时StatefulSets是1.4 版本中PetSets的替代品。

---

一、什么情况使用StatefulSets

1. 稳定且唯一的网络标识符

如: Redis集群, 在Redis集群中，它是通过槽位来存储数据的，假如:第一个节点是0_{1000,第二个节点是1001}2000,第三个节点2001~3000…等等，这就使得Redis集群中每个节点要通过ID来标识自己，如: 第二个节点宕机了，重建后它必须还叫第二个节点，或者说第二个节点叫R2，它必须还叫R2，这样在获取1001~2000槽位的数据时，才能找到数据，否则Redis集群将无法找到这段数据。

2. 稳定且持久的存储

3. 有序、平滑的部署和扩展

如 MySQL集群,要先启动主节点, 若从节点没有要求,则可一起启动,若从节点有启动顺序要求，可先启动第一个从节点，接着第二从节点等；这个过程就是有顺序，平滑安全的启动。

4. 有序的删除和终止

我们先终止从节点,若从节点是有启动顺序的，那么关闭时，也要按照逆序终止，即启动时是从S1~S4以此启动，则关闭时，则是先关闭S4,然后时S3，依次关闭，最后在关闭主节点。

5. 有序的滚动更新

如： MySQL在更新时，应该先更新从节点，全部的从节点都更新完了，最后在更新主节点，因为新版本一般可兼容老版本，但是一定要注意，若新版本不兼容老版本就很很麻烦

二、部署&扩展

• 对于具有N个副本的StatefulSet，当部署Pod时，将会顺序从{0…N-1}开始创建。
  Pods被删除时，会从{N-1…0}的相反顺序终止。 在将缩放操作应用于Pod之前，它的所有前辈必须运行和就绪。
  对Pod执行扩展操作时，前面的Pod必须都处于Running和Ready状态。 在Pod终止之前，所有successors都须完全关闭。

三、发布流程

RollingUpdate模式：该模式的默认行为是从标号为N的pod滚动更新到标号为0的pod，直到所有的pod都被更新为新版本。例如：当前集群共有9个pod，设置partition为5，则当sts中pod模板发生变更时，从标号为8的pod开始自动更新，待更新到标号为4的pod时停止更新（4号pod未更新）；

OnDelete模式：该模式和RollingUpdate模式最大的区别在于OnDelete不会在sts中pod模板发生变更时自动触发更新，只有等到用户主动删除pod后拉起新pod时才会更新该pod的信息；