【K8S系列】深入解析StatefulSet(一)

序言

那些看似不起波澜的日复一日，一定会在某一天让你看见坚持的意义。

文章标记颜色说明：

• 黄色：重要标题
• 红色：用来标记结论
• 绿色：用来标记一级论点
• 蓝色：用来标记二级论点

Kubernetes (k8s) 是一个容器编排平台，允许在容器中运行应用程序和服务。今天学习一下StatefulSet-拓扑状态。

希望这篇文章能让你不仅有一定的收获，而且可以愉快的学习，如果有什么建议，都可以留言和我交流

这是这篇文章所在的专栏，欢迎订阅：【深入解析k8s】专栏

专栏介绍

简单介绍一下这个专栏要做的事：

主要是深入解析每个知识点，帮助大家完全掌握k8s,一下是已更新的章节

序号文章第一讲深入解析 k8s：入门指南(一)第二讲深入解析 k8s：入门指南(二)第三讲深入解析Pod对象(一)第四讲深入解析Pod对象(二)第五讲深入解析无状态服务第六讲深入解析有状态服务第七讲深入解析控制器
第八讲
深入解析 ReplicaSet第九讲深入解析滚动升级

1 基础介绍

有状态应用：

1. 实例之间有不对等关系
2. 实例对外部数据有依赖关系的应用

就被称为“有状态应用”（Stateful Application）。

1.1 StatefulSet 介绍

Kubernetes StatefulSet是一种用于运行有状态应用的控制器。

StatefulSet是一个有序的、可标识的Pod组，并且每个Pod都有一个独特的标识符。

这使得StatefulSet能够管理有状态应用程序，例如数据库或队列服务，这些应用程序需要稳定的网络标识符或持久性存储，并且需要有序的、逐个更新的部署方式。

下面是关于Kubernetes StatefulSet的详细介绍：

• 稳定的网络标识符：在StatefulSet中，每个Pod都有一个稳定的网络标识符，可以通过DNS或其他服务发现机制进行访问。这个标识符由StatefulSet控制器在Pod创建时自动分配，并且在Pod重新启动时保持不变。这使得有状态应用程序能够在网络上稳定地被访问。
• 有序的、逐个更新的部署方式：StatefulSet能够按照一定的顺序逐个更新Pod。这意味着当需要更新有状态应用程序时，可以确保新的Pod在旧的Pod停止之前启动，并且在新的Pod启动之前，旧的Pod仍然可以提供服务。这种有序的、逐个更新的部署方式使得有状态应用程序在更新时更加稳定。
• 持久性存储：StatefulSet能够管理有状态应用程序的持久性存储。每个Pod都可以有自己的持久性存储卷，并且这些存储卷可以在Pod重新启动时保持不变。这使得有状态应用程序能够在重新启动时保留其状态和数据。
• 适合于有状态应用程序：StatefulSet适用于运行有状态应用程序，例如数据库或队列服务，这些应用程序需要稳定的网络标识符或持久性存储，并且需要有序的、逐个更新的部署方式。与Deployment不同，StatefulSet不适用于运行无状态应用程序。

总之，Kubernetes StatefulSet是一种用于运行有状态应用程序的控制器，它具有稳定的网络标识符、有序的、逐个更新的部署方式以及持久性存储等特点，适用于需要这些特性的有状态应用程序。

1.2 StatefulSet资源状态

StatefulSet 资源的状态主要包括以下几个方面:

1. Replicas: 指定的副本数,即 .spec.replicas字段的值。表示 StatefulSet 管理的副本数量。
2. ReadyReplicas: 表示已经就绪的副本数量,即当前运行且已经READY的Pod数。
3. CurrentReplicas: 表示当前正在运行的副本数量,即运行中的Pod总数。
4. UpdatedReplicas: 表示已经更新的副本数量,即最近一次更新中,更新成功的Pod数。
5. CurrentRevision: 当前正在执行的修订版本号。
6. UpdateRevision: StatefulSet 的当前修订版本号。 StatefulSet 的模板(.spec.template)每次更新时,这个值就会增加1
7. collisionCount：表示在创建 Pod 时发生的命名冲突的次数。
8. UpdateStatus: 最近一次更新的状态,可以是"Running"或者"Failed"。
9. ObservedGeneration: 最近一次对 StatefulSet 资源的更改,已经被看到的 Generation 数。也就是说如果 StatefulSet 的 .spec 字段被修改,该值会更新。

1.3 示例讲解

1 yaml文件

apiVersion: apps/v1
kind: StatefulSet  #资源类型
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
  status:
    observedGeneration: 2
    replicas: 3
    readyReplicas: 3
    currentReplicas: 3
    updatedReplicas: 3
    updateRevision: "2"
    currentRevision: "2"

从上面这个例子可以看出:

• observedGeneration 是 2,表示 StatefulSet 的 .spec 字段已经修改过两次。
• replicas 是 3,表示指定的副本数为 3。
• readyReplicas, currentReplicas 和 updatedReplicas 都是 3,表示所有的 3 个副本都已经准备就绪。
• updateRevision 和 currentRevision 都是 "2",表示 StatefulSet 的模板已经更新两次,当前正在运行的也是第 2 个版本。
• updateStatus 没有出现,表示最近一次更新状态是正常的。

2 StatefulSet 两种状态

StatefulSet 的设计，它把真实世界里的应用状态，抽象为了两种：

• 拓扑状态
• 存储状态

2.1拓扑状态简介

拓扑状态 ：应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。

2.2 存储状态简介

存储状态。应用 的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和隔了十分钟之后再次读取到的数据，应该是同一份，哪怕在此期间 Pod A 被重新创建过。这种情况最典型的例子，就是一个数据库应用的多个存储实例。

也可以说：StatefulSet 的核心功能，是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态

3 Headless Service

讲拓扑状态之前，先讲一下 k8s Headless Service

3.1Headless Service 介绍

在Kubernetes中，Headless Service是一种特殊类型的服务，它不会为Pods提供负载均衡或者访问IP，而是在DNS层面提供了一种服务发现的机制。

当一个Service被定义为Headless Service时，它将会返回与该Service关联的所有Pod的DNS记录，而不是一个虚拟IP地址。

这使得客户端可以直接访问每个Pod，而不需要经过负载均衡器。

3.2 使用场景

Headless Service可以被用来实现一些特定的功能，例如：

1. 集群内部通信：Headless Service可以被用来实现Pod之间的直接通信，例如数据库集群中的各个节点之间的通信。
2. 分布式计算：Headless Service可以被用来实现分布式计算中的任务分发和结果收集，例如MapReduce中的Map和Reduce节点之间的通信。
3. 自定义服务发现：Headless Service可以被用来实现一些自定义的服务发现机制，例如一些复杂的应用程序中的服务发现和路由。

3.2 yaml示例讲解

下面是一个标准的 Headless Service 对应的 YAML 文件：

apiVersion: v1
kind: Service #资源类型
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None # 为none，思考一下
  selector:
    app: nginx

可以看到，这个 Headless Service，其实仍是一个标准 Service 的 YAML 文件。只不过，它的 clusterIP 字段的值是：None，

即：这个 Service，没有一个 VIP 作为“头”。这也就是 Headless 的含义。

所以，这个 Service 被创建后并不会被分配一个 VIP，而是会以 DNS 记录的方式暴露出它所代理的 Pod。

当你按照这样的方式创建了一个 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录，如下所示：

<pod-name>.<svc-name>.<namespace>.svc.cluster.local

这个 DNS 记录，是 Kubernetes 项目为 Pod 分配的唯一的“可解析身份”（Resolvable Identity）。

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

3.3 Headless Service 与Service对比

下图为Headless Service 与Service的简单对比

​

3.4 总结

总之，Headless Service是一种特殊类型的服务，它不提供负载均衡或者访问IP，而是在DNS层面提供了一种服务发现的机制。

Headless Service通常与StatefulSet一起使用，用于管理有状态应用程序的Pod。

当一个StatefulSet被创建时，Kubernetes会自动为它创建一个与之关联的Headless Service，以便客户端可以直接访问每个Pod。

在StatefulSet中，每个Pod都会被分配一个唯一的标识符和DNS记录，例如web-0.web.default.svc.cluster.local、web-1.web.default.svc.cluster.local等。

4 拓扑状态

4.1 问题：

思考一个问题：我们今天讲的是拓扑状态，那么………………

​

解答：

StatefulSet使用一个基于DNS的标识符来定义Pod的网络标识符。每个Pod都有一个唯一的标识符，由以下格式组成：

$(podname)-$(ordinal).$(servicename).$(namespace).svc.cluster.local

其中：

1. $(podname)是Pod的名称
2. $(ordinal)是Pod的序号
3. $(servicename)是Service的名称
4. $(namespace)是命名空间

这个标识符可以通过DNS查找进行访问。

通过这种方式，StatefulSet可以将Pod的状态维护在整个集群中。当Pod重新启动时，它将保留其唯一的网络标识符，并且其他应用程序可以使用这个标识符来发现和访问Pod。

总的来说，StatefulSet通过使用DNS标识符来维护Pod的状态，并确保它们在重新启动时保持不变，从而实现了有状态应用程序的可扩展性和健壮性。

4.2示例讲解

4.2.1 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.9.1
        ports:
        - containerPort: 80
          name: web

这个 YAML 文件，和在前面用到的 nginx-deployment 的唯一区别，就是多了一个 serviceName=nginx 字段。

这个字段的作用，是告诉 StatefulSet 控制器，在执行控制循环（Control Loop）的时候，请使用 nginx 这个 Headless Service 来保证 Pod 的“可解析身份”。

所以，当通过 kubectl create 创建了上面这个 Service 和 StatefulSet 之后，就会看到如下两个对象：

4.2.2 创建

$ kubectl create -f svc.yaml
$ kubectl get service nginx
NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx     ClusterIP    None         <none>        80/TCP    10s

$ kubectl create -f statefulset.yaml
$ kubectl get statefulset web
NAME      DESIRED   CURRENT   AGE
web       2         1         19s

StatefulSet 会给它所管理的所有 Pod 的名字，进行了编号，编号规则是：-。

这些编号都是从 0 开始累加，与 StatefulSet 的每个 Pod 实例一一对应，绝不重复。

更重要的是，这些 Pod 的创建，也是严格按照编号顺序进行的。

比如，在 web-0 进入到 Running 状态、并且细分状态（Conditions）成为 Ready 之前，web-1 会一直处于 Pending 状态。

4.2.3 查看hostname

使用 kubectl exec 命令进入到容器中查看它们的 hostname：

$ kubectl exec web-0 -- sh -c 'hostname'
web-0
$ kubectl exec web-1 -- sh -c 'hostname'
web-1

用 nslookup 命令，解析一下 Pod 对应的 Headless Service：

$ kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
$ nslookup web-0.nginx
Server:    *.*.*.*
Address 1: *.*.*.* kube-dns.kube-system.svc.cluster.local
 
Name:      web-0.nginx
Address 1: *.*.*.*
 
$ nslookup web-1.nginx
Server:    *.*.*.*
Address 1: *.*.*.* kube-dns.kube-system.svc.cluster.local
 
Name:      web-1.nginx
Address 1: *.*.*.*

可以看到，在访问 web-0.nginx 的时候，最后解析到的，正是 web-0 这个 Pod 的 IP 地址；而当访问 web-1.nginx 的时候，解析到的则是 web-1 的 IP 地址。

4.2.3 测试

新开一个窗口，把这两个“有状态应用”的 Pod 删掉，执行命令如下：

kubectl delete pod -l app=nginx

结果如下：

pod "web-0" deleted
pod "web-1" deleted

在上一个窗口，Watch 一下这两个 Pod 的状态变化，就会发现一个现象，执行命令如下：

kubectl get pod -w -l app=nginx

结果如下：

NAME      READY     STATUS              RESTARTS   AGE
web-0     0/1       ContainerCreating   0          0s
NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          2s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         32s

4.2.4 测试总结

可以看到，当把那两个 Pod 删除之后，Kubernetes 会按照原先编号的顺序，创建出了两个新的 Pod。

并且，Kubernetes 依然为它们分配了与原来相同的“网络身份”：web-0.nginx 和 web-1.nginx。

通过这种严格的对应规则，StatefulSet 就保证了 Pod 网络标识的稳定性。

通过这种方法，Kubernetes 就成功地将 Pod 的拓扑状态（比如：哪个节点先启动，哪个节点后启动），按照 Pod 的“名字 + 编号”的方式固定了下来。

此外，Kubernetes 还为每一个 Pod 提供了一个固定并且唯一的访问入口，即：这个 Pod 对应的 DNS 记录。

这些状态，在 StatefulSet 的整个生命周期里都会保持不变，绝不会因为对应 Pod 的删除或者重新创建而失效。

不过，尽管 web-0.nginx 这条记录本身不会变，但它解析到的 Pod 的 IP 地址，并不是固定的。

这就意味着，对于“有状态应用”实例的访问，必须使用 DNS 记录或者 hostname 的方式，而绝不应该直接访问这些 Pod 的 IP 地址。

5 总结

StatefulSet 这个控制器的主要作用之一，就是使用 Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。

而当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。

换句话，我们可以认为StatefulSet 其实是对 Deployment 的改良。

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

总之，在部署“有状态应用”的时候，应用的每个实例拥有唯一并且稳定的“网络标识”，是一个非常重要的假设。

6 投票