【探索 Kubernetes|作业管理篇系列 13】StatefulSet 拓扑状态

大家好，我是秋意零。在上一篇中，我们讲解了 Deployment 这种无状态的控制器；而如果要部署有状态的应用，那么 Deployment 显然是达不到我们的需求的。今天讲解的是 StatefulSet 有状态控制器。最近搞了一个扣扣群，旨在技术交流、博客互助，希望各位大佬多多支持！获取方式：1.在我主页推广区域，如图：👿 简介🏠个人主页秋意零🧑个人介绍：在校期间参与众多云计算相关比赛，如：

秋意零

2207人浏览 · 2023-06-25 09:21:57

秋意零 · 2023-06-25 09:21:57 发布

前言

大家好，我是秋意零。

在上一篇中，我们讲解了 Deployment 这种无状态的控制器；而如果要部署有状态的应用，那么 Deployment 显然是达不到我们的需求的。

今天讲解的是 StatefulSet 有状态控制器。

最近搞了一个扣扣群，旨在技术交流、博客互助，希望各位大佬多多支持！

获取方式：

1.在我主页推广区域，如图：

👿 简介

🏠 个人主页：秋意零
🧑 个人介绍：在校期间参与众多云计算相关比赛，如：🌟 “省赛”、“国赛”，并斩获多项奖项荣誉证书
🎉 目前状况：24 届毕业生，拿到一家私有云（IAAS）公司 offer，暑假开始实习
🔥 账号：各个平台，秋意零账号创作者、云社区创建者
💕欢迎大家：欢迎大家一起学习云计算，走向年薪 30 万

系列文章目录

更多点击专栏查看：深入探索 Kubernetes

正文开始：

快速上船，马上开始掌舵了（Kubernetes），距离开船还有 3s，2s，1s...

无头服务 Headless Service

Headless Service 方式访问

总结

一、有状态、无状态应用

1.Deployment 不能覆盖所有应用编排的问题，在于 Deployment 对应用做了一个简单化假设：

Deployment 管理部署 Pod 中的应用，是完全一样的。所以，它们互相之间没有顺序，不管它们的任何物理环境，只有正常运行就可以了（不管在那台主机运行），删除时随便哪一个都能删除，没有顺序之分，因为它们之前没有任何关系，都是互相独立的存在。

这种对于实例之间都是对等的关系的应用，就被称为 “无状态应用”（Stateless application），如：Web 应用。

2.在实际中，有部分场景是不能满足，这样的需求：

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

所以对于实例之间不对等的关系（分布式类应用）；以及实例对外部数据有依赖关系的应用（数据存储类应用），就被称为 “有状态应用”（Stateful Application）。

二、StatefulSet

StatefulSet 的设计，是把现实世界里的应用状态，分为了两种：

1.拓扑状态：这种情况，也就对应的上述的“分布式类应用”。就是将两个或多个之间不对等关系的实例，严格按照某些启动顺序和删除顺序。如：应用 A 是主节点，应用 B 是从节点，这种情况下我们现实部署中，是按照 A 主节点（Pod）先启动，其次才是 B 从节点（Pod）；需要删除时，首先删除 B 从节点，其次才是 A 主节点。所以 StatefulSet 拓扑状态也是这样做的。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。
2.存储状态：这种情况，也就对应上述的“数据存储类应用”。多个应用实例分别绑定不同的存储空间；并且对于所有应用来说，每一个应用 Pod 第一次读取的数据和之后所有时间内所读取的数据都应该时同一份数据，哪怕是在此期间 Pod 被删除重新创建过。这种情况典型例子，一个数据库应用的多个存储实例，如：数据库主从、集群等。

所以 StatefulSet 的核心功能就是，记录这两种状态，当 Pod 被重新创建时，还能恢复到之前的一样状态。

无头服务 Headless Service

无头服务是 StatefulSet 一个重要的概念。无头服务是和 Service 对象配合使用的。

正是通过这种无头服务（DNS域名解析），保证了每次访问之前的 Pod 时都能访问到是同一个，不管它是否重建过。

1、Service 是 Kubernetes 项目中用来将一组 Pod 暴露给外界访问的一种机制。

如：一个 Deployment 有 3 个 Pod，那么我就可以定义一个 Service 与其绑定。然后，用户只要能访问到这个 Service，它就能访问到某个具体的 Pod。

Servcie 支持 2 种访问方式：

1.Service 的 VIP 方式（Virtual IP，即：虚拟 IP）。如：当我访问 10.0.23.1 这个 Service 的 IP 地址时，10.0.23.1 其实就是一个 VIP，它会把请求转发到该 Service 所代理的某一个 Pod 上。

2.Service 的 DNS 方式。如：这时候，只要我访问“my-svc.my-namespace.svc.cluster.local”这条 DNS 记录，就可以访问到名叫 my-svc 的 Service 所代理的某一个 Pod。

Service 的 DNS 方式，有两种处理方法：

1.Normal Service（普通服务）：你访问 <service-name>.<namespace>.svc.cluster.local解析到的，正是 <service-name> 这个 Service 的 VIP，后面的流程就跟 VIP 方式一致了。
2.Headless Service（无头服务）：你访问<pod-name>.<service-name>.<namespace>.svc.cluster.local解析到的，直接就是 <service-name> 代理的某一个 Pod 的 IP 地址。可以看到，这里的区别在于，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址。

2、这样的设计又有什么作用呢？

Service

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

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service-busybox
spec:
  clusterIP: None
  selector:
    app: my-app

可以看到 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 地址。

StatefulSet

StatefulSet 又是如何使用这个 DNS 记录来维持 Pod 的拓扑状态的呢？如下：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset
spec:
  serviceName: my-headless-service-busybox
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          args:
          - sleep
          - "3600"

StatefulSet 这个 YAML 文件，与之前 Deployment 的唯一区别，就是多了 serviceName: my-headless-service-busybox字段。这个字段告诉 StatefulSet 控制器，使用 Headless Service 来保证 Pod 的“可解析身份”。

现在，我们执行 kubectl apply 命令创建 StatefulSet：

你可以看到，创建 StatefulSet 后，将 Pod 名字，进行了编号，编号的规则是：<statefulset name>-<ordinal index>。
而且这些编号都是从 0 开始累加，与 StatefulSet 的每个 Pod 实例一一对应，绝不重复。
并且 Pod 的创建，也是严格按照编号顺序进行的。当编号为 0 的 Pod ，状态没有 Running 时，编号 0 之后的 Pod 是不会继续创建的。

[root@master01 yaml]# kubectl apply -f statefulset-busybox.yaml
statefulset.apps/my-statefulset created
service/my-headless-service-busybox created

[root@master01 yaml]# kubectl get pod -w
NAME               READY   STATUS    RESTARTS   AGE
my-statefulset-0   0/1     Pending   0          0s
my-statefulset-0   0/1     ContainerCreating   0          0s
my-statefulset-0   1/1     Running             0          2s

my-statefulset-1   0/1     Pending             0          0s
my-statefulset-1   0/1     ContainerCreating   0          0s
my-statefulset-1   1/1     Running             0          2s

my-statefulset-2   0/1     Pending             0          0s
my-statefulset-2   0/1     ContainerCreating   0          1s
my-statefulset-2   1/1     Running             0          2s

我们可以将 Pod 删掉，看看它的删除顺序：

首先，Pod 从最高编号-最低编号删除后；
其次，就会按照，最低编号-最高编号创建。

[root@master01 yaml]# kubectl delete pod --all

当这两个 Pod 都进入了 Running 状态之后，你就可以查看到它们各自唯一的“网络身份”了。

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

[root@master01 yaml]# kubectl exec -it my-statefulset-0 -- sh -c 'hostname'
my-statefulset-0
[root@master01 yaml]# kubectl exec -it my-statefulset-1 -- sh -c 'hostname'
my-statefulset-1
[root@master01 yaml]# kubectl exec -it my-statefulset-2 -- sh -c 'hostname'
my-statefulset-2

Headless Service 方式访问

可以看到，这 3 个 Pod 的 hostname 与 Pod 名字是一致的，都被分配了对应的编号。接下来，我们再以 DNS 的方式，访问一下这个 Headless Service。

我们可以进入，这 3 个 Pod 中的一个，进入之前查看 Pod 的 IP 地址：

用于直接访问无头服务中的每个 Pod 的 IP 地址列表：<pod-name>.<svc-name>

[root@master01 yaml]# kubectl exec -it my-statefulset-0 -- sh -c 'ping my-statefulset-0.my-headless-service-busybox'
PING my-statefulset-0.my-headless-service-busybox (10.244.5.53): 56 data bytes
64 bytes from 10.244.5.53: seq=0 ttl=64 time=0.054 ms
64 bytes from 10.244.5.53: seq=1 ttl=64 time=0.101 ms
64 bytes from 10.244.5.53: seq=2 ttl=64 time=0.084 ms

Normal Service 的 DNS 访问格式为：<svc-name>.<namespace>.svc.cluster.local

/ # ping my-headless-service-busybox.default.svc.cluster.local
PING my-headless-service-busybox.default.svc.cluster.local (10.244.241.122): 56 data bytes
64 bytes from 10.244.241.122: seq=0 ttl=62 time=1.002 ms
64 bytes from 10.244.241.122: seq=1 ttl=62 time=0.752 ms
64 bytes from 10.244.241.122: seq=2 ttl=62 time=1.138 ms

/ # ping my-headless-service-busybox.default.svc.cluster.local
PING my-headless-service-busybox.default.svc.cluster.local (10.244.5.58): 56 data bytes
64 bytes from 10.244.5.58: seq=0 ttl=63 time=0.227 ms
64 bytes from 10.244.5.58: seq=1 ttl=63 time=0.128 ms

/ # ping my-headless-service-busybox.default.svc.cluster.local
PING my-headless-service-busybox.default.svc.cluster.local (10.244.5.57): 56 data bytes
64 bytes from 10.244.5.57: seq=0 ttl=64 time=0.068 ms
64 bytes from 10.244.5.57: seq=1 ttl=64 time=0.090 ms
64 bytes from 10.244.5.57: seq=2 ttl=64 time=0.093 ms

Headless Service 的 DNS 访问格式：<pod-name>.<svc-name>.<namespace>.svc.cluster.local

[root@master01 yaml]# kubectl exec -it my-statefulset-0 -- sh
/ # ping my-statefulset-0.my-headless-service-busybox.default.svc.cluster.local
PING my-statefulset-0.my-headless-service-busybox.default.svc.cluster.local (10.244.5.57): 56 data bytes
64 bytes from 10.244.5.57: seq=0 ttl=64 time=0.306 ms
64 bytes from 10.244.5.57: seq=1 ttl=64 time=0.097 ms
64 bytes from 10.244.5.57: seq=2 ttl=64 time=0.074 ms