从零开始入门 K8s | 有状态应用编排 - StatefulSet

做者 | 酒祝  阿里巴巴技术专家

本文整理自《CNCF x Alibaba 云原生技术公开课》第 22 讲。

关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，便可下载从零入门 K8s 系列文章 PPT。

导读：有状态应用的部署交付向来都是应用运维领域的难点之一，常见的有状态需求如在磁盘持久化状态、每一个机器须要独立且稳定的网络标识、发布顺序肯定性等。针对这类问题 Kubernetes 提供了 StatefulSet 控制器，做为帮助有状态应用部署和在 K8s 环境落地的 Workload。

1、“有状态”需求

咱们以前讲到过 Deployment 做为一个应用编排管理工具，它为咱们提供了哪些功能？

以下图所示：

• 首先它支持定义一组 Pod 的指望数量，Controller 会为咱们维持 Pod 的数量在指望的版本以及指望的数量；
• 第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照咱们给出的策略来更新 Pod，同时在更新的过程当中，也会保证不可用 Pod 数量在咱们定义的范围内；
• 第三，若是咱们在发布的过程当中遇到问题，Deployment 也支持一键来回滚。

能够简单地说，**Deployment 认为：它管理的全部相同版本的 Pod 都是如出一辙的副本。**也就是说，在 Deployment Controller 看来，全部相同版本的 Pod，不论是里面部署的应用仍是行为，都是彻底相同的。

这样一种能力对于无状态应用是支持知足的，若是咱们遇到一些有状态应用呢？

需求分析

好比下图所示的一些需求：

以上的这些需求都是 Deployment 没法知足的，所以 Kubernetes 社区为咱们提供了一个叫 StatefluSet 的资源，用来管理有状态应用。

StatefulSet：主要面向有状态应用管理的控制器

其实如今社区不少无状态应用也经过 StatefulSet 来管理，经过本文的学习，你们也会明白为何咱们将部分无状态应用也经过 StatefulSet 来管理。

如上图右侧所示，StatefulSet 中的 Pod 都是有序号的，从 0 开始一直到定义的 replica 数量减一。每一个 Pod 都有独立的网络标识：一个 hostname、一块独立的 pvc 以及 pv 存储。这样的话，同一个 StatefulSet 下不一样的 Pod，有不一样的网络标识、有本身独享的存储盘，这就能很好地知足了绝大部分有状态应用的需求。

如上图右侧所示：

• 首先，每一个 Pod 会有 Order 序号，会按照序号来建立，删除和更新 Pod；
• 其次，经过配置一个 headless Service，使每一个 Pod 有一个惟一的网络标识 (hostname)；
• 第三，经过配置 pvc 模板，就是 pvc template，使每一个 Pod 有一块或者多块 pv 存储盘；
• 最后，支持必定数量的灰度发布。好比如今有三个副本的 StatefulSet，咱们能够指定只升级其中的一个或者两个，更甚至是三个到新版本。经过这样的方式，来达到灰度升级的目的。

2、用例解读

StatefulSet 范例建立

上图左侧是一个 Service 的配置，咱们经过配置 headless Service，其实想要达到的目标是：指望 StatefulSet 里面的 Pod 有独立的网络标识。这里的 Service name 叫 nginx。

上图右侧是一个 StatefulSet 的配置，在 spec 中有个 serviceName 也叫 nginx。经过这个 serviceName 来指定这个 StatefulSet 要对应哪个 Service。

这个 spec 中还有其它几个很熟悉的字段，好比 selector 和 template。selector 是一个标签选择器，selector 定义的标签选择逻辑，必须匹配 template 中 metadata 中 labels 包含 app: nginx。在 template 中定义一个 nginx container，这个 container 用的 image 版本是 alpine 版本，对外暴露的 80 端口做为一个 web 服务。

最后，template.spec 里面定义了一个 volumeMounts，这个 volumeMounts 并非来源于 spec 中的一个 Volumes，而是来自于 volumeClaimTemplates，也就是 pvc 模板。咱们在 pvc 模板中定义了一个叫 www-storage 的 pvc 名称。这个 pvc 名称，咱们也会写到 volumeMounts 做为一个 volume name，挂载到  /usr/share/nginx/html 这个目录下。经过这样的方式来达到每一个 Pod 都有独立的一个 pvc，而且挂载到容器中对应目录的一个需求。

Service、StatefulSet 状态

经过将上文中的两个对象建立以后，咱们能够经过 get 命令能够看到 Service nginx 资源已经建立成功。

同时能够经过查看 endpoints 看到，这个后端已经注册了三个 IP 和端口，这三个 IP 对应了 Pod 的 IP，端口对应了以前 spec 中配置的 80 端口。

最后经过 get sts (StatefulSet 缩写) nginx-web。从结果能够看到有一列叫作 READY，值为 3/3。分母 3 是 StatefulSet 中指望的数量，而分子 3 表示 Pod 已经达到指望 READY 的状态数量。

Pod、PVC 状态

下图中的 get pod 能够看到三个 Pod 的状态都是 Running 状态，而且已经 READY。它的 IP 就是前面看到的 endpoint 地址。

经过 get pvc 能够看到 NAME 那一列名称，前缀为 www-storage，中间是 nginx-web，后缀是一个序号。经过分析能够知道 www-storage 是 volumeClaimTemplates 中定义的 name，中间为 StatefulSet 定义的 name，末尾的序号对应着 Pod 的序号，也就是三个 PVC 分别被三个 Pod 绑定。经过这样一种方式，达到不一样的 Pod 享有不一样的 PVC；PVC 也会绑定相应的一个 PV， 来达到不一样的 Pod 绑定不一样 PV 的目的。

Pod 的版本

以前咱们学到 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 版本，能够看到后缀是 677759c9b8。这里先记录一下，接下来会作 Pod 升级，再来看一下 controller-revision-hash 会不会发生改变。

更新镜像

经过执行上图的命令，能够看到上图下方的 StatefulSet 配置中，已经把 StatefulSet 中的 image 更新到了 mainline 新版本。

查看新版本状态

经过 get pod 命令查询 Revision hash，能够看到三个 Pod 后面的 controller-revision-hash 都已经升级到了新的 Revision hash，后面变成了 7c55499668。经过这三个 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 已经升级到了所须要的版本。

3、操做演示

StatefulSet 编排文件

首先这里已经链接到了阿里云的一个集群，集群中有三个节点。

如今开始建立一个 StatefulSet 和对应的 Service，首先看一下对应的编排文件。

如上图中的例子所示，Service 对应的 nginx 对外暴露的 80 端口。StatefulSet 配置中 metadata 定义了 name 为 nginx-web；template 中的 containers 定义了镜像信息；最后定义了一个 volumeClaimTemplates 做为 PVC 模板。

开始建立

执行上面的命令后，咱们就把 Service 和 StatefulSet 建立成功了。经过 get pod 能够看到首先建立的 Pod 序号为 0；经过 get pvc 能够看到序号为 0 的 PVC 已经和 PV 进行了绑定。

此时序号为 0 的 Pod 已经开始建立了，状态为 ContainerCreating。

当序号为 0 的 Pod 建立完成后，开始建立序号为 1 的 Pod，而后看到新的 PVC 也已经建立成功，紧接着是序号为 2 的 Pod。

能够看到每个 Pod 建立以前，会先建立 PVC。PVC 建立完成后，Pod 从 Pending 状态和 PV 进行绑定，而后变成了 ContainerCreating，最后达到 Running。

查看状态

而后经过 kubectl get sts nginx-web -o yaml 查看 StatefulSet 的状态。

如上图所示，指望的 replicas 数量为 3 个，当前可用数量为 3 个，而且达到最新的版本。

接着来看一下 Service 和 endpoints，能够看到 Service 的 Port 为 80，endpoint 有三个对应的 IP 地址。

再来 get pod ，能够看到三个 Pod 对应了上面的 endpoints 的 IP 地址。

以上的操做结果为：三个 PVC 和三个 Pod 已经达到了所指望的状态，而且 StatefulSet 上报的 status 中，replicas 以及 currentReplicas 都为三个。

升级操做

这里重复说一下，kubectl set image 为声明镜像的固定写法；StatefulSet 表示自愿类型；nginx-web是资源名称；nginx=nginx:mainline，等号前面的 nginx 是咱们在 template 中定义的 container 名称，后面的nginx:mainline是所指望更新的镜像版本。

经过上面的命令，已经成功的将 StatefulSet 中的镜像更新为新的版本。

经过 get pod 看一下状态，nginx-web-1,nginx-web-2 已经进入了 Running 状态。对应的 controller-revision-hash 已是新的版本。那么 nginx-web-0 这个 Pod，旧的 Pod 已经被删除了，新 Pod 还在 Createing 状态。

再次查看一下状态，全部的 Pod 都已经 Running 状态了。

查看一下 StatefulSet 信息，目前 StatefulSet 中的 status 里定义的 currentRevision 已经更新到了新的版本，表示 StatefulSet 已经获取到的三个 Pod 都已经进入了新版本。

如何查看这三个 Pod 是否还复用了以前的网络标识和存储盘呢？

其实 headless Service 配置的 hostname 只是和 Pod name 挂钩的，因此只要升级后的 Pod 名称和旧的 Pod 名称相同，那么就能够沿用以前 Pod 使用的网络标识。

关于存储盘，由上图能够看到 PVC 的状态，它们的建立时间一直没有改变，仍是第一次建立 Pod 时的时间，因此如今升级后的 Pod 使用的仍是旧 Pod 中使用的 PVC。

好比能够查看其中的某一个 Pod，这个 Pod 里面一样有个声明的 volumes，这个 persistentVolumeClaim 里的名称 www-storage-nginx-web-0，对应着 PVC 列表中看到的序号为 0 的 PVC，以前是被旧的 Pod 所使用。升级过程当中 Controller 删除旧 Pod，而且建立了一个同名的新 Pod，新的 Pod 仍然复用了旧 Pod 所使用的 PVC。

经过这种方式来达到升级先后，网络存储都能复用的目的。

4、架构设计

管理模式

StatefulSet 可能会建立三种类型的资源。 

• 第一种资源：ControllerRevision

经过这个资源，StatefulSet 能够很方便地管理不一样版本的 template 模板。

举个例子：好比上文中提到的 nginx，在建立之初拥有的第一个 template 版本，会建立一个对应的 ControllerRevision。而当修改了 image 版本以后，StatefulSet Controller 会建立一个新的 ControllerRevision，你们能够理解为每个 ControllerRevision 对应了每个版本的 Template，也对应了每个版本的 ControllerRevision hash。其实在 Pod label 中定义的 ControllerRevision hash，就是 ControllerRevision 的名字。经过这个资源 StatefulSet Controller 来管理不一样版本的 template 资源。

• 第二个资源：PVC

若是在 StatefulSet 中定义了 volumeClaimTemplates，StatefulSet 会在建立 Pod 以前，先根据这个模板建立 PVC，并把 PVC 加到 Pod volume 中。

若是用户在 spec 的 pvc 模板中定义了 volumeClaimTemplates，StatefulSet 在建立 Pod 以前，根据模板建立 PVC，并加到 Pod 对应的 volume 中。固然也能够在 spec 中不定义 pvc template，那么所建立出来的 Pod 就不会挂载单独的一个 pv。

• 第三个资源：Pod

StatefulSet 按照顺序建立、删除、更新 Pod，每一个 Pod 有惟一的序号。

如上图所示，StatefulSet Controller 是 Owned 三个资源：ControllerRevision、Pod、PVC。

这里不一样的地方在于，当前版本的 StatefulSet 只会在 ControllerRevision 和 Pod 中添加 OwnerReference，而不会在 PVC 中添加 OwnerReference。以前的系列文章中提到过，拥有 OwnerReference 的资源，在管理的这个资源进行删除的默认状况下，会关联级联删除下属资源。所以默认状况下删除 StatefulSet 以后，StatefulSet 建立的 ControllerRevision 和 Pod 都会被删除，可是 PVC 由于没有写入 OwnerReference，PVC 并不会被级联删除。

StatefulSet 控制器

上图为 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 达到了管理有状态应用的能力。

扩容模拟

假设 StatefulSet 初始配置 replicas 为 1，有一个 Pod0。那么将 replicas 从 1 修改到 3 以后，其实咱们是先建立 Pod1，默认状况是等待 Pod1 状态 READY 以后，再建立 Pod2。

经过上图能够看到每一个 StatefulSet 下面的 Pod 都是从序号 0 开始建立的。所以一个 replicas 为 N 的 StatefulSet，它建立出来的 Pod 序号为 [0,N)，0 是开曲线，N 是闭曲线，也就是当 N>0 的时候，序号为 0 到 N-1。

扩缩容管理策略

可能有的同窗会有疑问：若是我不想按照序号建立和删除，那 StatefulSet 也支持其它的建立和删除的逻辑，这也就是为何社区有些人把无状态应用也经过 StatefulSet 来管理。它的好处是它能拥有惟一的网络标识以及网络存储，同时也能经过并发的方式进行扩缩容。

StatefulSet.spec 中有个字段叫 podMangementPolicy 字段，这个字段的可选策略为 OrderedReady 和 Parallel，默认状况下为前者。

如咱们刚才建立的例子，没有在 spec 中定义 podMangementPolicy。那么 Controller 默认 OrderedReady 做为策略，而后在 OrderedReady 状况下，扩缩容就严格按照 Order 顺序来执行，必需要等前面的 Pod 状态为 Ready 以后，才能扩容下一个 Pod。在缩容的时候，倒序删除，序号从大到小进行删除。

举个例子，上图右侧中，从 Pod0 扩容到 Pod0、Pod一、Pod2 的时候，必须先建立 Pod1，等 Pod1 Ready 以后再建立 Pod2。其实还存在一种可能性：好比在建立 Pod1 的时候，Pod0 由于某些缘由，多是宿主机的缘由或者是应用自己的缘由，Pod0 变成 NotReady 状态。这时 Controller 也不会建立 Pod2，因此不仅是咱们所建立 Pod 的前一个 Pod 要 Ready，而是前面全部的 Pod 都要 Ready 以后，才会建立下一个 Pod。上图中的例子，若是要建立 Pod2，那么 Pod0、Pod1 都要 ready。

另外一种策略叫作 Parallel，顾名思义就是并行扩缩容，不须要等前面的 Pod 都 Ready 或者删除后再处理下一个。

发布模拟

假设这里的 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 建立出来。

spec 字段解析

首先来看一下 spec 中前几个字段，Replica 和 Selector 都是咱们比较熟悉的字段。

• 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 是不能被删除的。

升级策略字段解析

在上图右侧能够看到 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 的数量。不少刚结束 StatefulSet 的同窗可能会认为这个是灰度新版本的数量，这是错误的。

举个例子：假设当前有个 replicas 为 10 的 StatefulSet，当咱们更新版本的时候，若是 Partition 是 8，并非表示要把 8 个 Pod 更新为新版本，而是表示须要保留 8 个 Pod 为旧版本，只更新 2 个新版本做为灰度。当 Replica 为 10 的时候，下面的 Pod 序号为 [0,9)，所以当咱们配置 Partition 为 8 的时候，其实仍是保留 [0,7) 这 8个 Pod 为旧版本，只有 [8,9) 进入新版本。

总结一下，假设 replicas=N，Partition=M (M < N) ，则最终旧版本 Pod 为 [0，M) ,新版本 Pod 为 [M,N)。经过这样一个 Partition 的方式来达到灰度升级的目的，这是目前 Deployment 所不支持的。

5、本节总结

本文的主要内容就到此为止了，这里为你们简单总结一下：

• StatefulSet 是 Kubernetes 中常见的一种 Workload，其初始目标是面向有状态应用部署，但也支持部署无状态应用；
• 与 Deployment 不一样，StatefulSet 是直接操做 Pod 来作扩缩容/发布，并无经过相似 ReplicaSet 的其余 workload 来管控；
• StatefulSet 的特色是：支持每一个 Pod 独享 PVC、有一个惟一网络标识，且在升级发布后还能复用 PVC 和网络标识；

直播推荐

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”