k8s工作负载控制器--Statefulset
一、概述
StatefulSet 是 Kubernetes 中用于管理有状态应用程序的工作负载资源对象。它提供了一种管理有状态服务的方式，确保每个 Pod 都有一个唯一的、持久的身份，并支持持久化存储。它在 Kubernetes v1.9 版本中成为 GA 版本。StatefulSet 设计用于管理和部署有状态服务，其管理的 Pod 拥有固定的名称（通常是
在 StatefulSet 中，Pod 名称可以用作网络标识符，并且通常与 Headless Service 结合使用。Headless Service 没有 Cluster IP，直接暴露 Pod 的 IP 地址或 DNS 名称。解析 Headless Service 的名称时，会返回所有 Pod 的 IP 地址或 DNS 名称。
此外，StatefulSet 在 Headless Service 的基础上为每个 Pod 创建了一个 DNS 域名，这些域名通常形如
StatefulSet 支持持久化存储，它可以使用多种持久化存储类型，包括本地存储、网络文件系统（NFS）等。
二、引入"有状态"需求
1、管理无状态服务的 Deployment 实现了什么
首先它支持定义一组 Pod 的期望数量，Controller 会为我们维持 Pod 的数量在期望的版本以及期望的数量；
第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照我们给出的策略来更新 Pod，同时在更新的过程中，也会保证不可用 Pod 数量在我们定义的范围内；
第三，如果我们在发布的过程中遇到问题，Deployment 也支持一键来回滚。
简单来说，Deployment 认为：它管理的所有相同版本的 Pod 都是一模一样的副本。也就是说，在 Deployment Controller 看来，所有相同版本的 Pod，不管是里面部署的应用还是行为，都是完全相同的。
1.1、创建 Deployment
cat >> web-app.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
annotations:
deployment.kubernetes.io/revision: "1"
spec:
containers:
- name: web-server
image: nginx:1.15.0
ports:
- containerPort: 80
EOF
kubectl apply -f web-app.yaml --record=true
1.2、验证 Pod 数量
通过 Deployment 控制器，我们可以验证 Pod 的数量是否维持在期望的数量（3 个）。
kubectl get pods -l app=web-app
1.3、配置更新策略（更新镜像版本）
kubectl set image deploy web-app web-server=nginx:1.16.0 --record=true
1.4、观察更新过程
kubectl rollout status deploy web-app
1.5、验证更新后 Pod 的状态
kubectl get pods -l app=web-app -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image,STATUS:.status.phase'
1.6、回滚 Deployment
以下就是回滚到指定版本的流程：
查看历史版本信息 --> 查看指定版本详细信息 --> 回滚到指定版本 --> 验证信息
kubectl rollout history deploy web-app
kubectl rollout history deploy web-app --revision=1
kubectl rollout undo deploy web-app --to-revision=1
kubectl get pods -l app=web-app -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image,STATUS:.status.phase'
以上就是管理无状态服务的
Deployment实现了什么功能展示
2、新需求分析
以下需求来自于一些有状态应用：
- Pod 之间并非相同的副本，每一个 Pod 都有一个独立标识
- Pod 独立标识要能够对应到一个固定的网络标识，并在发布升级后继续保持
- 每一个 Pod 有一块独立的存储盘，并在发布升级后还能继续挂载原有的盘（保留数据）
这些有状态应用的需求都是 Deploment 无法满足的，因此引入了管理有状态应用的 StatefulSet
三、StatefulSet：面向有状态应用管理的控制器
- 首先，每个 Pod 会有 Order 序号，会按照序号来创建，删除和更新 Pod；
- 其次，通过配置一个
headless Service，使每个 Pod 有一个唯一的网络标识 (hostname)； - 第三，通过配置 pvc 模板，就是
pvc template，使每个 Pod 有一块或者多块 pv 存储盘； - 最后，支持一定数量的灰度发布。比如现在有三个副本的
StatefulSet，我们可以指定只升级其中的一个或者两个，更甚至是三个到新版本。通过这样的方式，来达到灰度升级的目的。
1、创建 Service、Statefulset
cat >>service-nginx.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
clusterIP: None
ports:
- name: web
port: 80
selector:
app: nginx
EOF
这是一个 Service 的配置，我们通过配置 headless Service，其实想要达到的目标是：期望 StatefulSet 里面的 Pod 有独立的网络标识。这里的 Service name 叫 nginx。
cat >> nginx-web.yaml << EOF
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.0
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www-storage
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
EOF
这是一个 StatefulSet 的配置，在 spec 中有个 serviceName 也叫 nginx。通过这个 serviceName 来指定这个 StatefulSet 要对应哪一个 Service。
这个 spec 中还定义了 selector 和 template。selector 是一个标签选择器，selector 定义的标签选择逻辑，必须匹配 template 中 metadata 中 labels 包含 app: nginx。在 template 中定义一个 nginx container，这个 container 用的 image 版本是 1.16.0 版本，对外暴露的 80 端口作为一个 web 服务。
最后，template.spec 里面定义了一个 volumeMounts，这个 volumeMounts 并不是来源于 spec 中的一个 Volumes，而是来自于 volumeClaimTemplates，也就是 pvc 模板。我们在 pvc 模板中定义了一个叫 www-storage 的 pvc 名称。这个 pvc 名称，我们也会写到 volumeMounts 作为一个 volume name，挂载到 /usr/share/nginx/html 这个目录下。通过这样的方式来达到每个 Pod 都有独立的一个 pvc，并且挂载到容器中对应目录的一个需求。
kubectl apply -f service-nginx.yaml -f nginx-web.yaml
2、Service、StatefulSet 状态
kubectl get svc nginx
kubectl get endpoints nginx
kubectl get sts nginx-web
通过将上文中的两个对象创建之后，我们可以通过 get 命令可以看到 Service nginx 资源已经创建成功。
同时可以通过查看 endpoints 看到，这个后端已经注册了三个 IP 和端口，这三个 IP 对应了 Pod 的 IP，端口对应了之前 spec 中配置的 80 端口。
最后通过 get sts (StatefulSet 缩写) nginx-web。从结果可以看到有一列 READY，值为 3/3。分母 3 是 StatefulSet 中期望的数量，而分子 3 表示 Pod 已经达到期望 READY 的状态数量。
3、Pod、PVC 状态
kubectl get pods -l app=nginx
kubectl get pvc
通过 get pvc 可以看到 NAME 那一列名称，前缀为 www-storage，中间是 nginx-web，后缀是一个序号。通过分析可以知道 www-storage 是 volumeClaimTemplates 中定义的 name，中间为 StatefulSet 定义的 name，末尾的序号对应着 Pod 的序号，也就是三个 PVC 分别被三个 Pod 绑定。通过这样一种方式，达到不同的 Pod 享有不同的 PVC；PVC 也会绑定相应的一个 PV， 来达到不同的 Pod 绑定不同 PV 的目的。
4、Pod 的版本控制
不同于 Deployment 使用 ReplicaSet 来管理版本和维持副本数，StatefulSet controller 直接管理下属的 Pod ，而 Pod 中用一个 label 来标识版本
kubectl get pods -L controller-revision-hash
之前我们学到 Deployment 使用 ReplicaSet 来管理 Pod 的版本和所期望的 Pod 数量，但是在 StatefulSet 中，是由 StatefulSet Controller 来管理下属的 Pod，因此 StatefulSet 通过 Pod 的 label 来标识这个 Pod 所属的版本，这里叫 controller-revision-hash。这个 label 标识和 Deployment 以及 StatefulSet 在 Pod 中注入的 Pod template hash 是类似的。
如上图所示，通过 get pod 查看到 controller-revision-hash，这里的 hash 就是第一次创建 Pod 对应的 template 版本，可以看到后缀是6b558f6465。这里先记录一下，接下来会做 Pod 升级，再来看一下 controller-revision-hash 会不会发生改变。
5、更新镜像
kubectl set image statefulset nginx-web nginx=nginx:1.15.0
6、查看新版本的状态
kubectl get pods -L controller-revision-hash
kubectl get sts nginx-web -o json | jq '.status'
通过 get pod 命令查询 Revision hash，可以看到三个 Pod 后面的 controller-revision-hash 都已经升级到了新的 Revision hash，后缀由6b558f6465 变成了 84d64959d6。通过这三个 Pod 创建的时间可以发现：序号为 2 的 Pod 创建的是最早的，之后是序号是 1 和 0。这表示在升级的过程中，真实的升级顺序为 2-1-0，通过这么一个倒序的顺序来逐渐把 Pod 升级为新版本，并且我们升级的 Pod，还复用了之前 Pod 使用的 PVC。所以之前在 PV 存储盘中的数据，仍然会挂载到新的 Pod 上。
通过在 StatefulSet 的 status 中看到的数据，这里有几个重要的字段：
- currentReplica：表示当前版本的数量
- currentRevision： 表示当前版本号
- updateReplicas：表示新版本的数量
- updateRevision：表示当前要更新的版本号
当然这里也能看到 currentReplica 和 updateReplica，以及 currentRevision 和 updateRevision 都是一样的，这就表示所有 Pod 已经升级到了所需要的版本。
7、如何查看 Pod 是否复用了之前的网络标识
其实 headless Service 配置的 hostname 只是和 Pod name 挂钩的，所以只要升级后的 Pod 名称和旧的 Pod 名称相同，那么就可以沿用之前 Pod 使用的网络标识。
8、如何查看 Pod 是否复用了之前的存储盘
kubectl get pvc
关于存储盘，可以查看 PVC 的状态，它们的创建时间一直没有改变，还是第一次创建 Pod 时的时间，所以现在升级后的 Pod 使用的还是旧 Pod 中使用的 PVC。
kubectl get pods nginx-web-0 -o yaml
或者可以查看其中的某一个 Pod，这个 Pod 里面同样有个声明的 volumes，这个 persistentVolumeClaim 里的名称 www-storage-nginx-web-0，对应着 PVC 列表中看到的序号为 0 的 PVC，之前是被旧的 Pod 所使用。升级过程中 Controller 删除旧 Pod，并且创建了一个同名的新 Pod，新的 Pod 仍然复用了旧 Pod 所使用的 PVC。
通过这种方式来达到升级前后，网络存储都能复用的目的。
四、架构设计
1、管理模式
StatefulSet 一般会创建三种类型的资源
1.1、ControllerRevision
通过这个资源，StatefulSet 可以很方便地管理不同版本的 template 模板。
kubectl get controllerrevision -l app=nginx
kubectl get pods -l app=nginx --show-labels
比如上面例子中的 container nginx，在创建之初拥有的第一个 template 版本，会创建一个对应的 ControllerRevision。而当修改了 image 版本之后，StatefulSet Controller 会创建一个新的 ControllerRevision，可以理解为每一个 ControllerRevision 对应了每一个版本的 Template，也对应了每一个版本的 ControllerRevision hash。其实在 Pod label 中定义的 ControllerRevision hash，就是 ControllerRevision 的名字。通过这个资源 StatefulSet Controller 来管理不同版本的 template 资源。
1.2、PVC
如果在 StatefulSet 中定义了 volumeClaimTemplates，StatefulSet 会在创建 Pod 之前，先根据这个模板创建 PVC，并把 PVC 加到 Pod volume 中。
如果用户在 spec 的 pvc 模板中定义了 volumeClaimTemplates，StatefulSet 在创建 Pod 之前，根据模板创建 PVC，并加到 Pod 对应的 volume 中。当然也可以在 spec 中不定义 pvc template，那么所创建出来的 Pod 就不会挂载单独的一个 pv。
1.3、Pod
StatefulSet 按照顺序创建、删除、更新 Pod，每个 Pod 有唯一的序号。
2、OwnerReference
StatefulSet Controller 是 Owned 三个资源：ControllerRevision、Pod、PVC。
这里不同的地方在于，当前版本的 StatefulSet 只会在 ControllerRevision 和 Pod 中添加 OwnerReference，而不会在 PVC 中添加 OwnerReference。拥有 OwnerReference 的资源，在管理的这个资源进行删除的默认情况下，会关联级联删除下属资源。因此默认情况下删除 StatefulSet 之后，StatefulSet 创建的 ControllerRevision 和 Pod 都会被删除，但是 PVC 因为没有写入 OwnerReference，PVC 并不会被级联删除。
2.1、删除 StatefulSet
kubectl delete sts nginx-web
kubectl get pods -l app=nginx
kubectl get pvc
kubectl get controllerrevision -l app=nginx
可以看到由 StatefulSet 创建的 ControllerRevision、Pod 均被删除，但是 PVC 未被删除
3、StatefulSet 控制器工作流程
首先通过注册 Informer的 Event Handler(事件处理)，来处理 StatefulSet 和 Pod 的变化。在 Controller 逻辑中，每一次收到 StatefulSet 或者是 Pod 的变化，都会找到对应的 StatefulSet 放到队列。紧接着从队列取出来处理后，先做的操作是 Update Revision，也就是先查看当前拿到的 StatefulSet 中的 template，有没有对应的 ControllerRevision。如果没有，说明 template 已经更新过，Controller 就会创建一个新版本的 Revision，也就有了一个新的 ControllerRevision hash 版本号。
然后 Controller 会把所有版本号拿出来，并且按照序号整理一遍。这个整理的过程中，如果发现有缺少的 Pod，它就会按照序号去创建，如果发现有多余的 Pod，就会按照序号去删除。当保证了 Pod 数量和 Pod 序号满足 Replica 数量之后，Controller 会去查看是否需要更新 Pod。也就是说这两步的区别在于，Manger pods in order 去查看所有的 Pod 是否满足序号；而后者 Update in order 查看 Pod 期望的版本是否符合要求，并且通过序号来更新。
Update in order 其更新过程如上图所示，其实这个过程比较简单，就是删除 Pod。删除 Pod 之后，其实是在下一次触发事件，Controller 拿到这个 success 之后会发现缺少 Pod，然后再从前一个步骤 Manger pod in order 中把新的 Pod 创建出来。在这之后 Controller 会做一次 Update status，也就是之前通过命令行看到的 status 信息。
通过整个这样的一个流程，StatefulSet 达到了管理有状态应用的能力。
4、扩容能力
假设 StatefulSet 初始配置 replicas 为 1，有一个 Pod0。那么将 replicas 从 1 修改到 3 之后，其实我们是先创建 Pod1，默认情况是等待 Pod1 状态 READY 之后，再创建 Pod2。
通过上图可以看到每个 StatefulSet 下面的 Pod 都是从序号 0 开始创建的。因此一个 replicas 为 N 的 StatefulSet，它创建出来的 Pod 序号为 [0,N)，也就是当 N>0 的时候，序号为 0 到 N-1。
5、扩缩容管理策略
在 StatefulSet.spec 中，有一个字段名为 podManagementPolicy ，可选策略为 OrderedReady 和 Parallel，默认为前者
OrderedReady：扩缩容按照 order 顺序执行。扩容时，必须前面序号的 Pod 都 Ready 了才能扩下一个，缩容时按照倒序删除
Parallel：并行扩缩容，不需要等前面的 Pod Ready/删除后再处理下一个
上面创建的例子，没有在 spec 中定义 podMangementPolicy。那么 Controller 默认 OrderedReady 作为策略，然后在 OrderedReady 情况下，扩缩容就严格按照 Order 顺序来执行，必须要等前面的 Pod 状态为 Ready 之后，才能扩容下一个 Pod。在缩容的时候，倒序删除，序号从大到小进行删除。
在这个例子中，从 Pod0 扩容到 Pod0、Pod1、Pod2 的时候，必须先创建 Pod1，等 Pod1 Ready 之后再创建 Pod2。其实还存在一种可能性：比如在创建 Pod1 的时候，Pod0 因为某些原因，可能是宿主机的原因或者是应用本身的原因，Pod0 变成 NotReady 状态。这时 Controller 也不会创建 Pod2，所以不只是我们所创建 Pod 的前一个 Pod 要 Ready，而是前面所有的 Pod 都要 Ready 之后，才会创建下一个 Pod。上图中的例子，如果要创建 Pod2，那么 Pod0、Pod1 都要 ready。
6、发布模拟
假设这里的 StatefulSet template1 对应逻辑上的 Revision1，这时 StatefulSet 下面的三个 Pod 都属于 Revision1 版本。在我们修改了 template，比如修改了镜像之后，Controller 是通过倒序的方式逐一升级 Pod。上图中可以看到 Controller 先创建了一个 Revision2，对应的就是创建了 ControllerRevision2 这么一个资源，并且将 ControllerRevision2 这个资源的 name 作为一个新的 Revision hash。在把 Pod2 升级为新版本后，逐一删除 Pod0、Pod1，再去创建 Pod0、Pod1。
它的逻辑其实很简单，在升级过程中 Controller 会把序号最大并且符合条件的 Pod 删除掉，那么删除之后在下一次 Controller 在做 reconcile 的时候，它会发现缺少这个序号的 Pod，然后再按照新版本把 Pod 创建出来。
五、字段分析
git clone git@github.com:kubernetes/kubernetes.git
1、spec 字段解析
- Replica 主要是期望的数量；
- Selector 是事件选择器，必须匹配
spec.template.metadata.labels中定义的条件； - Template：Pod 模板，定义了所要创建的 Pod 的基础信息模板；
- VolumeClaimTemplates：PVC 模板列表，如果在 spec 中定义了这个，PVC 会先于 Pod 模板 Template 进行创建。在 PVC 创建完成后，把创建出来的 PVC name 作为一个 volume 注入到根据 Template 创建出来的 Pod 中。
- ServiceName：对应
Headless Service的名字。当然如果有人不需要这个功能的时候，会给Service定一个不存在的 value，Controller 也不会去做校验，所以可以写一个 fake 的ServiceName。但是这里推荐每一个 Service 都要配置一个Headless Service，不管StatefulSet下面的 Pod 是否需要网络标识； - PodMangementPolicy：Pod 管理策略。前面提到过这个字段的可选策略为
OrderedReady和Parallel，默认情况下为前者； - UpdataStrategy：Pod 升级策略。
- RevisionHistoryLimit：保留历史
ControllerRevision的数量限制(默认为 10)。需要注意的一点是，这里清楚的版本，必须没有相关的 Pod 对应这些版本，如果有 Pod 还在这个版本中，这个ControllerRevision是不能被删除的。
2、升级策略字段解析
可以看到 StatefulSetUpdateStrategy 有个 type 字段，这个 type 定义了两个类型：一个是 RollingUpdate；一个是 OnDelete。
- RollingUpdate 其实跟 Deployment 中的升级是有点类似的，就是根据滚动升级的方式来升级；
- OnDelete 是在删除的时候升级，叫做禁止主动升级，
Controller并不会把存活的 Pod 做主动升级，而是通过OnDelete的方式。比如说当前有三个旧版本的 Pod，但是升级策略是OnDelete，所以当更新 spec 中镜像的时候，Controller 并不会把三个 Pod 逐一升级为新版本，而是当我们缩小 Replica 的时候，Controller 会先把 Pod 删除掉，当我们下一次再进行扩容的时候，Controller 才会扩容出来新版本的 Pod。
在 RollingUpdateStatefulSetSetStrategy 中，可以看到有个字段叫 Partition。这个 Partition 表示滚动升级时，保留旧版本 Pod 的数量。不是灰度新版本的数量
举个例子：假设当前有个 replicas 为 10 的 StatefulSet，当我们更新版本的时候，如果 Partition 是 8，并不是表示要把 8 个 Pod 更新为新版本，而是表示需要保留 8 个 Pod 为旧版本，只更新 2 个新版本作为灰度。当 Replica 为 10 的时候，配置 Partition 为 8 的时候，其实还是保留 [0,8) 这 8 个 Pod 为旧版本，只有 [8,10) 进入新版本。
总结一下，假设 replicas=N，Partition=M (M<N) ，则最终旧版本 Pod 为 [0，M) ,新版本 Pod 为 [M,N)。通过这样一个 Partition 的方式来达到灰度升级的目的，这是目前 Deployment 所不支持的。
