Kubernetes如何通过StatefulSet支持有状态应用？

Kubernetes如何通过StatefulSet支持有状态应用？
Kubernetes如何通过StatefulSet支持有状态应用？

为什么Deployment不能编排所有类型应用？

Deployment认为一个应用中所有的Pod是完全一样的，所以他们之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Deployment就可以通过Pod模板创建新的Pod;不需要的时候，Deployment就可以"杀掉"任意一个Pod。

但是，在实际的场景中，并不是所有的应用都可以满足这样的要求。

尤其是分布式应用，它的多个实例之间，往往有依赖关系，比如：主从关系、主备关系。还有就是数据存储类应用，它的多个实例，往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用失败。

所以，这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就被称为“有状态应用”（Stateful Application）。

得益于“控制器模式”的设计思想，Kubernetes 项目很早就在 Deployment 的基础上，扩展出了对“有状态应用”的初步支持。这个编排功能，就是：StatefulSet。

StatefulSet 的设计其实非常容易理解。它把真实世界里的应用状态，抽象为了两种情况：
1. 拓扑状态。这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。
2. 存储状态。这种情况意味着，应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和隔了十分钟之后再次读取到的数据，应该是同一份，哪怕在此期间 Pod A 被重新创建过。这种情况最典型的例子，就是一个数据库应用的多个存储实例。
所以，StatefulSet 的核心功能，就是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态。

Headless Service

在开始讲述 StatefulSet 的工作原理之前，我们必须先了解一个 Kubernetes 项目中非常实用的概念：Headless Service。

Service 是 Kubernetes 项目中用来将一组 Pod 暴露给外界访问的一种机制。比如，一个 Deployment 有 3 个 Pod，那么我就可以定义一个 Service。然后，用户只要能访问到这个 Service，它就能访问到某个具体的 Pod。

Service被访问有两种方式：
1. 以Service的VIP(Virtual IP,虚拟IP) 方式。比如：当我访问10.0.23.1这个Service的IP时，10.0.23.1其实就是一个VIP,它会把请求转发到该Service所代理的某一个Pod上。
2. Headless Service, 这种情况下，访问“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是 my-svc 代理的某一个 Pod 的 IP 地址。
可以看到，这里的区别在于，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址。

那么，这样的设计又有什么作用呢？想要回答这个问题，我们需要从 Headless Service 的定义方式看起。下面是一个标准的 Headless Service 对应的 YAML 文件：
```
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
    - port: 80
      name: web
  clusterIP: None
  selector:
    app: nginx
```
可以看到，所谓的 Headless Service，其实仍是一个标准 Service 的 YAML 文件。只不过，它的 clusterIP 字段的值是：None，即：这个 Service，没有一个 VIP 作为“头”。这也就是 Headless 的含义。所以，这个 Service 被创建后并不会被分配一个 VIP，而是会以 DNS 记录的方式暴露出它所代理的 Pod。

而它所代理的Pod,依然采用的是Label Selector机制选择出来的，即所有携带了app=nginx标签的Pod，都会被这个Service代理起来。

当我们按照这样的方式创建了一个 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录，如下所示：
```
<pod-name>.<svc-name>.<namespace>.svc.cluster.local
```
这个 DNS 记录，正是 Kubernetes 项目为 Pod 分配的唯一的“可解析身份”（Resolvable Identity）。

有了这个“可解析身份”，只要知道了一个 Pod 的名字，以及它对应的 Service 的名字，就可以非常确定地通过这条 DNS 记录访问到 Pod 的 IP 地址。

StatefulSet的拓扑状态

那么，StatefulSet又是如何使用DNS记录来维持Pod的拓扑状态呢？

我们来编写一个StatefulSet的yaml文件，如下所示：
```
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.17.1
          ports:
            - containerPort: 80
              name: web
```
这个yaml文件，和我们deployment的唯一区别就是多了个serviceName=nginx字段，这个字段的作用，就是告诉StatefulSet控制器，在执行控制循环的时候，请使用nginx这个Headless Service来保证Pod的"可解析身份"。

所以当我们通过kubectl create创建上面这个Service和StatefulSet 之后，就会看到如下两个对象：
```
# kubectl get service nginx
NAME    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   None         <none>        80/TCP    2m54s

# kubectl get statefulset web
NAME   READY   AGE
web    2/2     72s
```
我们通过查看StatefulSet的Events来查看Pod的创建过程：
```
# kubectl describe statefulset web

Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  66s   statefulset-controller  create Pod web-0 in StatefulSet web successful
  Normal  SuccessfulCreate  64s   statefulset-controller  create Pod web-1 in StatefulSet web successful
```
我们不难看到，StatefulSet 给它所管理的所有 Pod 的名字，进行了编号，编号规则是：-。而且这些编号都是从 0 开始累加，与 StatefulSet 的每个 Pod 实例一一对应，绝不重复。更重要的是，这些 Pod 的创建，也是严格按照编号顺序进行的。

当这两个 Pod 都进入了 Running 状态之后，我们就可以查看到它们各自唯一的“网络身份”了。我们使用 kubectl exec 命令进入到容器中查看它们的 hostname：
```
# kubectl exec web-0 -- sh -c 'hostname'
web-0
# kubectl exec web-1 -- sh -c 'hostname'
web-1
```
可以看到，这两个 Pod 的 hostname 与 Pod 名字是一致的，都被分配了对应的编号。

接下来，我们再试着以 DNS 的方式，访问一下这个 Headless Service：
```
# kubectl run -it --image busybox:1.28.3 test --restart=Never --rm /bin/sh
```
通过这条命令，我们启动了一个一次性的 Pod，因为–-rm 意味着 Pod 退出后就会被删除掉。然后，在这个 Pod 的容器里面，我们尝试用 nslookup 命令，解析一下 Pod 对应的 Headless Service：
```
/ # nslookup web-0.nginx
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx
Address 1: 192.168.166.138 web-0.nginx.default.svc.cluster.local

/ # nslookup web-1.nginx
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-1.nginx
Address 1: 192.168.166.140 web-1.nginx.default.svc.cluster.local
```
从 nslookup 命令的输出结果中，我们可以看到，在访问 web-0.nginx 的时候，最后解析到的，正是 web-0 这个 Pod 的 IP 地址；而当访问 web-1.nginx 的时候，解析到的则是 web-1 的 IP 地址。

这时候，我们在另外一个 Terminal 里把这两个“有状态应用”的 Pod 删掉：
```
# kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
```
在当前 Terminal 里 Watch 一下这两个 Pod 的状态变化，就会发现一个有趣的现象：
```
# kubectl get pod -w -l app=nginx
NAME    READY   STATUS        RESTARTS   AGE
web-0   0/1     Terminating   0          3m5s
web-1   0/1     Terminating   0          2m55s
web-0   0/1     Terminating   0          3m10s
web-0   0/1     Terminating   0          3m10s
web-0   0/1     Pending       0          0s
web-1   0/1     Terminating   0          3m
web-0   0/1     Pending       0          0s
web-1   0/1     Terminating   0          3m
web-0   0/1     ContainerCreating   0          1s
web-0   0/1     ContainerCreating   0          1s
web-0   1/1     Running             0          2s
web-1   0/1     Pending             0          0s
web-1   0/1     Pending             0          0s
web-1   0/1     ContainerCreating   0          0s
web-1   0/1     ContainerCreating   0          0s
web-1   1/1     Running             0          2s
```
可以看到，当我们把这两个 Pod 删除之后，Kubernetes 会按照原先编号的顺序，创建出了两个新的 Pod。并且，Kubernetes 依然为它们分配了与原来相同的“网络身份”：web-0.nginx 和 web-1.nginx。

通过这种严格的对应规则，StatefulSet 就保证了 Pod 网络标识的稳定性。比如，如果 web-0 是一个需要先启动的主节点，web-1 是一个后启动的从节点，那么只要这个 StatefulSet 不被删除，你访问 web-0.nginx 时始终都会落在主节点上，访问 web-1.nginx 时，则始终都会落在从节点上，这个关系绝对不会发生任何变化。

所以，如果我们再用 nslookup 命令，查看一下这个新 Pod 对应的 Headless Service ：
```
/ # nslookup web-0.nginx
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx
Address 1: 192.168.166.147 web-0.nginx.default.svc.cluster.local

/ # nslookup web-1.nginx
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-1.nginx
Address 1: 192.168.166.145 web-1.nginx.default.svc.cluster.local
```
我们可以看到，在这个 StatefulSet 中，这两个新 Pod 的“网络标识”（比如：web-0.nginx 和 web-1.nginx），再次解析到了正确的 IP 地址（比如：web-0 Pod 的 IP 地址 192.168.166.147）。

通过这种方法，Kubernetes 就成功地将 Pod 的拓扑状态（比如：哪个节点先启动，哪个节点后启动），按照 Pod 的“名字 + 编号”的方式固定了下来。此外，Kubernetes 还为每一个 Pod 提供了一个固定并且唯一的访问入口，即：这个 Pod 对应的 DNS 记录。这些状态，在 StatefulSet 的整个生命周期里都会保持不变，绝不会因为对应 Pod 的删除或者重新创建而失效。

不过，相信你也已经注意到了，尽管 web-0.nginx 这条记录本身不会变，但它解析到的 Pod 的 IP 地址，并不是固定的。这就意味着，对于“有状态应用”实例的访问，你必须使用 DNS 记录或者 hostname 的方式，而绝不应该直接访问这些 Pod 的 IP 地址。

StatefulSet 这个控制器的主要作用之一，就是使用 Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。而当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。

与此同时，通过 Headless Service 的方式，StatefulSet 为每个 Pod 创建了一个固定并且稳定的 DNS 记录，来作为它的访问入口。

StatefulSet的存储状态

在开始之前，我们先准备两个1G存储卷（PV）:
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /tmp/pv001

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /tmp/pv002
```
然后直接创建pv即可：
```
# kubectl create -f pv.yaml 
persistentvolume/pv001 created
persistentvolume/pv002 created

# kubectl get pv
NAME    CAPACITY  ACCESS MODES   RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS   REASON  AGE
pv001   1Gi       RWO            Retain          Available          				   13s
pv002   1Gi       RWO            Retain          Available                              13s
```
可以看到成功创建了两个 PV 对象，状态是：Available 。

然后接下来声明一个如下所示的StatefulSet资源清单：（nginx-sts.yaml）
```
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.17.1
          ports:
            - containerPort: 80
              name: web
          volumeMounts:
            - name: ww
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: ww
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
```
这次，我们为这个 StatefulSet 额外添加了一个 volumeClaimTemplates 字段。从名字就可以看出来，它跟 Deployment 里 Pod 模板（PodTemplate）的作用类似。也就是说，凡是被这个StatefulSet管理的 Pod，都会声明一个对应的 PVC；而这个 PVC 的定义，就来自于 volumeClaimTemplates 这个模板字段。

更重要的是，这个 PVC 的名字，会被分配一个与这个 Pod 完全一致的编号。这个自动创建的 PVC，与 PV 绑定成功后，就会进入 Bound 状态，这就意味着这个 Pod 可以挂载并使用这个 PV 了。

PVC 其实就是一种特殊的 Volume。只不过一个 PVC 具体是什么类型的 Volume，要在跟某个 PV 绑定之后才知道。当然，PVC 与 PV 的绑定得以实现的前提是，已经在系统里创建好了符合条件的 PV（比如，我们在前面用到的 pv.yaml）

所以，我们在使用 kubectl create 创建了 StatefulSet 之后，就会看到 Kubernetes 集群里出现了两个 PVC：
```
# kubectl get pvc -l app=nginx
NAME       STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ww-web-0   Bound    pv001    1Gi        RWO                           8m45s
ww-web-1   Bound    pv002    1Gi        RWO                           8m41s
```
可以看到，这些 PVC，都"<PVC名字>-<StatefulSet名字>-< 编号 >”的方式命名，并且处于 Bound 状态。

由于我们这里用volumeClaimTemplates声明的模板是挂载点的方式，并不是 volume，所有实际上是把 PV 的存储挂载到容器中，所以会覆盖掉容器中的数据，在容器启动完成后我们可以手动在 PV 的存储里面新建 index.html 文件来保证容器的正常访问，当然也可以进入到容器中去创建，这样更加方便：
```
for i in 0 1; do kubectl exec web-$i -- sh -c 'echo hello $(hostname) > /usr/share/nginx/html/index.html'; done
```
如上所示，通过 kubectl exec 指令，我们在每个 Pod 的 Volume 目录里，写入了一个 index.html 文件。这个文件的内容，正是 Pod 的 hostname。比如，我们在 web-0 的 index.html 里写入的内容就是 "hello web-0"。
```
# for i in 0 1; do kubectl exec -it web-$i -- sh -c "cat /usr/share/nginx/html/index.html"; done
hello web-0
hello web-1
```
如果使用kubectl delete删除这两个pod,这些volume文件会不会丢失呢？
```
# kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
```
我们知道，上面删除的两个pod会被按照编号的循环重新创建，那么我们写入的index.html文件是否还在？
```
# for i in 0 1; do kubectl exec -it web-$i -- sh -c "cat /usr/share/nginx/html/index.html"; done
hello web-0
hello web-1
```
这个请求依然会返回：hello web-0，hello web-1。也就是说，原先与名叫 web-0 的 Pod 绑定的 PV，在这个 Pod 被重新创建之后，依然同新的名叫 web-0 的 Pod 绑定在了一起。对于 Pod web-1 来说，也是完全一样的情况。

这是怎么做到的呢？

首先，当把一个 Pod，比如 web-0，删除之后，这个 Pod 对应的 PVC 和 PV，并不会被删除，而这个 Volume 里已经写入的数据，也依然会保存在远程存储服务里。

此时，StatefulSet 控制器发现，一个名叫 web-0 的 Pod 消失了。所以，控制器就会重新创建一个新的、名字还是叫作 web-0 的 Pod 来，“纠正”这个不一致的情况。需要注意的是，在这个新的 Pod 对象的定义里，它声明使用的 PVC 的名字，还是叫作：ww-web-0。

这个 PVC 的定义，还是来自于 PVC 模板（volumeClaimTemplates），这是 StatefulSet 创建 Pod 的标准流程。

所以，在这个新的 web-0 Pod 被创建出来之后，Kubernetes 为它查找名叫 ww-web-0 的 PVC 时，就会直接找到旧 Pod 遗留下来的同名的 PVC，进而找到跟这个 PVC 绑定在一起的 PV。这样，新的 Pod 就可以挂载到旧 Pod 对应的那个 Volume，并且获取到保存在 Volume 里的数据。

通过这种方式，Kubernetes 的 StatefulSet 就实现了对应用存储状态的管理。

更新策略

在 StatefulSet 中同样也支持两种升级策略：onDelete 和 RollingUpdate，同样可以通过设置 .spec.updateStrategy.type 进行指定。
- OnDelete: 该策略表示当更新了 StatefulSet 的模板后，只有手动删除旧的 Pod 才会创建新的 Pod。
- RollingUpdate：该策略表示当更新 StatefulSet 模板后会自动删除旧的 Pod 并创建新的Pod，如果更新发生了错误，这次“滚动更新”就会停止。不过需要注意 StatefulSet 的 Pod 在部署时是顺序从 0~n 的，而在滚动更新时，这些 Pod 则是按逆序的方式即 n~0 依次删除并创建。
另外SatefulSet 的滚动升级还支持 Partitions特性，通过.spec.updateStrategy.rollingUpdate.partition 进行设置，在设置 partition 后，SatefulSet 的 Pod 中序号大于或等于 partition 的 Pod 会在 StatefulSet 的模板更新后进行滚动升级，而其余的 Pod 保持不变。
```
......
updateStrategy:
  rollingUpdate: # 如果更新的策略是OnDelete，那么rollingUpdate就失效
    partition: 2 # 表示从第2个分区开始更新，默认是0
  type: RollingUpdate /OnDelete # 滚动更新/删除之后更新
```
总结

1、 StatefulSet 的控制器直接管理的是 Pod。这是因为，StatefulSet 里的不同 Pod 实例，不再像 ReplicaSet 中那样都是完全一样的，而是有了细微区别的。

比如，每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式，就是通过在 Pod 的名字里加上事先约定好的编号。

2、Kubernetes 通过 Headless Service，为这些有编号的 Pod在 DNS 服务器中生成带有同样编号的 DNS 记录。只要 StatefulSet 能够保证这些 Pod 名字里的编号不变。

那么 Service 里类似于web-0.nginx.default.svc.cluster.local这样的 DNS 记录也就不会变，而这条记录解析出来的 Pod 的 IP 地址，则会随着后端 Pod 的删除和再创建而自动更新。

这当然是 Service 机制本身的能力，不需要 StatefulSet 操心。

3、StatefulSet 还为每一个 Pod 分配并创建一个同样编号的 PVC。这样，Kubernetes 就可以通过 Persistent Volume 机制为这个 PVC 绑定上对应的 PV，从而保证了每一个 Pod 都拥有一个独立的 Volume。

在这种情况下，即使 Pod 被删除，它所对应的 PVC 和 PV 依然会保留下来。所以当这个 Pod 被重新创建出来之后，Kubernetes 会为它找到同样编号的 PVC，挂载这个 PVC 对应的 Volume，从而获取到以前保存在 Volume 里的数据。
相关阅读:
STL——increment/decrement/dereference操作符
 STL——静态常量整数成员在class内部直接初始化
 STL——临时对象的产生与运用
 C++中模板类使用友元模板函数
 模板编程中的技巧
 plsql 表数据中文显示乱码（配置环境变量）
plsql 常用快捷键（自动替换）
javascript 跳出（终止）forEach循环
 plsql 快捷键配置
 plsql oracle client没有正确安装（plsql连接远程数据库）
原文地址：https://www.cnblogs.com/huiyichanmian/p/15715998.html

Kubernetes如何通过StatefulSet支持有状态应用？

Kubernetes如何通过StatefulSet支持有状态应用？

为什么Deployment不能编排所有类型应用？

Headless Service

StatefulSet的拓扑状态

StatefulSet的存储状态

更新策略

总结