目次
一、概述
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 域名，这些域名通常形如 ...svc.cluster.local。
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
以上就是管理无状态服务的 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
- kubectl get pods -l app=web-app
- 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 |
