@TOC
1 为什么需要StatefulSet
常规的应用通常使用Deployment，如果需要在所有机器上部署则使用DaemonSet，但是有这样一类应用，它们在运行时需要存储一些数据，并且当Pod在其它节点上重建时也希望这些数据能够在重建后的Pod上获取，毕竟没有哪个运维希望Pod重建后数据却丢失了。
对于Deployment和DaemonSet来说，它们创建的Pod是一模一样的，如果将PV关联到Pod的PVC，这两种资源都无法对多个Pod的PVC进行区分，因此，对于这种场景，最基本的需求就是每个Pod可以设置不同的PVC，同时，Pod在重建时最好主机名等也一样，因为多个存储之间需要进行数据同步，所有的Pod都需要知道其他Pod的主机名，如果Pod的名称变化了，其他Pod的配置都需要调整。
因此，对于这类应用至少有两个需求：
- 每个Pod可以使用不同的PVC，绑定到不同的PV
- Pod重建后，Pod名称和主机名不变
这就要使用到StatefulSet，简称sts。
2 StatefulSet的Yaml的关键字段
与Deployment相比，StatefulSet有几个比较特别的字段：
- sts.spec.podManagementPolicy：Pod被创建和删除的顺序，可选的值有OrderedReady（按照0～N-1的顺序创建Pod，按照N-1~0的顺序删除Pod）、Parallel（并行创建和删除Pod）
- sts.spec.serviceName：StatefulSet关联的服务名
- sts.spec.updateStrategy.rollingUpdate.partition：分区滚动更新
- sts.spec.volumeClaimTemplates：PVC模板，也就是说，这里不是单个PVC，而是一个模板，会根据Pod的数量创建对应的PVC
这里借用一本书里面的例子的镜像：luksa/kubia-pet，它运行一个nodejs应用，监听容器的8080端口，当发送POST请求时会将数据写入本地的/var/data/kubia.txt，当发送GET请求时，会从本地的/var/data/kubia.txt获取数据。
下面是用docker run启动该镜像后的使用方式：
可以发现：在保存数据时，会打印Pod的主机名；而在读取数据时，会打印读取数据的Pod的主机名以及写入的数据。
用以下的yaml创建StatefulSet以及对应的Service：
apiVersion: v1
kind: Service
metadata:
name: kubia-svc
spec:
clusterIP: None
selector:
app: kubia
ports:
- name: http
targetPort: 8080
port: 80
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: kubia
labels:
app: kubia
spec:
selector:
matchLabels:
app: kubia
serviceName: kubia-svc
replicas: 3
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia-ctr
image: luksa/kubia-pet
ports:
- name: http
containerPort: 8080
volumeMounts:
- name: data
mountPath: /var/data
volumeClaimTemplates:
- metadata:
name: data
spec:
resources:
requests:
storage: 1Mi
accessModes:
- ReadWriteOnce
可以发现：
- Pod名称跟Pod中的主机名相同，都是StatefulSet资源名称和一个索引号，这里给定的replicas是3，因此，索引号就是0~2
- 创建了3个Pod的同时，也创建了3个PVC和PV，kubia-0这个Pod绑定的PVC是data-kubia-0，开始的data就是PVC模板中的名称
然后再创建一个nginx的Pod，就可以在nginx的Pod上访问服务：
在原来服务的DNS前面再加一个Pod名称就可以直接解析到对应的Pod，然后就可以直接访问对应的Pod，而且，访问者可以认为，无论目标Pod是重启还是重建，目标Pod都是同一个：主机名和域名没有变化、存储也没有变化（PVC在关联PV后，只要PV不被删除，就会一致关联；由于Pod名称没有变化，因此，同一个PVC还是会关联到同一个Pod）。如果需要这些Pod组成集群，那么每个主机的名称是可以预期且不变的。
在Pod启动过程中，也会发现，3个Pod中，一定是kubia-0最先启动，kubia-2最后启动，同时，只有kubia-0正常运行了，才会继续创建kubia-1；而删除StatefulSet过程中，一定是kubia-2最先删除，kubia-0最后删除。
与Deployment类似，StatefulSet也可以使用kubectl scale进行扩容和缩容，与启动和删除过程类似，当扩容时，一定是从当前最大的序号的下一个序号的Pod开始创建，例如，现在就会从kubia-3开始创建，当缩容时，一定是从当前最大的序号的Pod开始删除，例如，现在就会从kubia-2开始删除。
3 扩缩容失败的处理
在扩容过程中，如果Pod运行异常，则可以直接进行重建或者调度到其他机器上重建。
在缩容过程中，StatefulSet需要保证运行的Pod状态都是正常的。如果Pod运行异常，则缩容过程会阻塞，因为kubernetes无法判断Pod异常状态到底是瞬时状态还是永久性状态，如果是永久性状态，需要解决该问题才能继续推进缩容操作，如果此时继续推进缩容操作，那么运行的Pod数量可能跟实际期望的不同；如果是瞬时状态， 通常过一会儿就会恢复。总的来说就是，只有当Pod运行正常时才进行扩缩容操作。
4 分区滚动更新
ds.spec.updateStrategy.rollingUpdate可以设置Pod的最大超过数量和最大不可用的数量，但是在sts.spec.updateStrategy.rollingUpdate则用于设置分区滚动更新（1.24版本也提供了最大不可用数的设置）。
分区滚动更新就是分段更新，将StatefulSet的所有Pod分成两部分，在进行更新时一部分更新，另一部分不更新，因此，设置分区就是设置一个索引位置，也就是sts.spec.updateStrategy.rollingUpdate.partition：当该值为n时，索引值大于或者等于n的Pod才会被更新，小于n的Pod不会被更新。而且，当小于n的Pod重建时，还是会用旧的配置进行重建。
分区滚动更新的主要使用场景就是实现金丝雀部署，也就是新老版本需要同时运行，运行过程中，可以通过观察新版本的监控指标判断是否继续进行升级。
5 总结
对于需要持久化数据的应用，或者需要多Pod构成集群的应用，可以使用StatefulSet进行部署，每个Pod的主机名和域名在Pod重建后保持不变，也会绑定到同一个PV存储，这就使得Pod在异常重建或者漂移后可以认为还是同一个Pod，这就满足了“有状态服务”的需求。
