StatefulSet介绍
一、StatefulSet概述
StatefulSet是用来管理stateful(有状态)应用的
StatefulSet管理Pod时,确保Pod有一个按序增长的ID
与Deployment最大的不同是StatefulSet始终将一系列不变的名字分配给Pod.这些Pod从一个模板创建,但是并不能相互替换
二、StatefulSet使用场景
对于有如下要求的应用程序,StatefulSet非常适用
需要稳定、唯一的网络标识(dnsname)
每个Pod始终对应各自的存储路径（PersistantVolumeClaimTemplate）
按顺序的增加副本、减少副本,并在减少副本时执行清理
安顺序自动的执行滚动更新
如果一个应用不需要一个稳定的网络标识,或者不需要按顺序部署、删除、增加副本,应该用deployment(无状态)控制器
三、StatefulSet的限制
Pod的存储要么由storage clas对应的PersistentVolume Provisioner提供,要么由集群管理员事先创建
删除或scale down一个StatefulSet将不会删除其对应的数据卷,这样保证数据安全
删除StatefulSet时,将无法保证Pod正常终止.如果要按顺序优雅的终止StatefulSet中的Pod,可以在删除StatefulSet之前,将scale down 到0
当使用默认的Pod Management Policy(OrderedReady)进行滚动更新时,可能进入一个错误状态,并需要人工介入
用一个StatefulSet实例深入了解
创建StatefulSet实例
一、下面是一个StatefulSet的例子,由如下内容组成:
- 一个名为nginx-service的Headless service,用于控制网络域
- 一个名为web的StatefulSet,副本为2
apiVersion: v1 kind: Service metadata: name: nginx-service #headless service的名称 labels: app: nginx #自定义标签 spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx #关联app: nginx的pod --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web-d #statefulset控制器的名称 spec: selector: matchLabels: app: nginx #关联app: nginx的pod进行控制 serviceName: "nginx-service" #指定headless service replicas: 2 template: metadata: labels: app: nginx #pod的标签 spec: terminationGracePeriodSeconds: 10 containers: - name: nginx #pod里容器的名称 image: nginx:1.7.9 ports: - containerPort: 80 name: web
二、Pod的标识
StatefulSet中的Pod具备一个唯一标识,该标识由以下几部分组成
- 序号
- 稳定的网络标识
- 稳定的存储
2.1序号
假设一个StatefulSet的副本数为N,其中每个Pod都会被分配一个需要,序号的取值范围从0开始,并且该需要在StatefulSet是唯一的.
Pod的Name是StatefulSet的Name + 序号;比如这个配置文件里,有两个副本,第一个Pod的Name就是web-d-0,第二个Pod的Name就是web-d-1
2.2稳定的网络ID
1)StatefulSet中Pod的hostname格式为$(statefulSet name)-$(Pod序号),上面的例子将要创建2个Pod,第一个Pod的Name为：web-d-0,第二个Pod的Name为web-d-1
2)StatefulSet可以使用Headless service来控制其Pod所在的域;该域(domain)的格式为: $(service name).$(namespace).svc.cluster.local;
上面例子的域就是:nginx-service.defaule.svc.cluster.local
3)StatefulSet中每个Pod都被分配一个dnsNmae,格式为:$(pod name).$(所在域)
上面的例子 Pod的dnsName就是 web-d-0.nginx-server.default.svc.cluster.local,其他pod可以通过这个地址找到它
2.3稳定的存储
kubernetes为每一个VolumeClaimTemplate创建一份PersistentVolum(存储卷).在上面的例子中,每一个Pod都将由StorageClass(存储类)my-storage-class为其创建一个1GB大小的存储卷.
- 当Pod或StatefulSet被删除时,其关联的PersistentVolumeClaim(存储卷声明)以及背后的PersistentVolume(存储卷)仍然存在
- 如果相同的Pod或StatefulSet被再次创建,则新建的web-d-0的Pod扔将挂载到原来名为web-d-0的Pod所挂载的存储卷声明及存储卷
- 这确保了web-d-0、web-d-1等,不管被删除多少次,都将"稳定"的使用各自的所对应的存储内容
StatefulSet的部署和伸缩
一、部署和伸缩StetafulSet时的执行顺序
- 在创建一个副本数为 N 的 StatefulSet 时，其 Pod 将被按 {0 ... N-1} 的顺序逐个创建
- 在删除一个副本数为 N 的 StatefulSet （或其中所有的 Pod）时，其 Pod 将按照相反的顺序（即 {N-1 ... 0}）终止和删除
- 在对 StatefulSet 执行扩容（scale up）操作时，新增 Pod 所有的前序 Pod 必须处于 Running（运行）和 Ready（就绪）的状态
- 终止和删除 StatefulSet 中的某一个 Pod 时，该 Pod 所有的后序 Pod 必须全部已终止
StatefulSet 中 pod.spec.terminationGracePeriodSeconds 不能为 0
上面例子中StatefulSet被创建时:
- Pod web-0、web-1、web-2 将被按顺序部署
- web-0 处于 Running 和 Ready 状态之前，web-1 不会创建；web-1 处于 Running 和 Ready 状态之前，web-2 不会创建
- 如果 web-1 已处于 Running 和 Ready 的状态，web-2 尚未创建，此时 web-0 发生了故障，则在 web-0 成功重启并达到 Running 和 Ready 的状态之前，web-2 不会创建
- 如果用户对这个 StatefulSet 执行缩容（scale down）操作，将其副本数调整为 1，则：
- web-2 将被首先终止；在 web-2 已终止并删除之后，才开始终止 web-1
- 假设在 web-2 终止并删除之后，web-1 终止之前，此时 web-0 出现故障，则，在 web-0 重新回到 Running 和 Ready 的状态之前，kubernetes 将不会终止 web-1
二、Pod管理策略
-
OrderedReady
OrderedReady 是
.spec.podManagementPlicy的默认值。其对 Pod 的管理方式已经在 部署和伸缩 StatefulSet 时的执行顺序 详细描述 -
Parallel
.spec.podManagementPlicy的取值为 Parallel，则 StatefulSet Controller 将同时并行地创建或终止其所有的 Pod。此时 StatefulSet Controller 将不会逐个创建 Pod，等待 Pod 进入 Running 和 Ready 状态之后再创建下一个 Pod，也不会逐个终止 Pod。
注意:此选项只影响到伸缩（scale up/scale down）操作。更新操作不受影响。
StatefulSet的更新策略
On Delete
如果StatefulSet的.spec.updateStrategy.type字段被设置为OnDelete,当修改.spce.template的内容时,StatefulSet Controller将不会自动更新Pod.必须得手动删除Pod,重新用修改的过得配置文件创建的时候,才会按照修改过得配置文件 创建Pod
Rolling Updates
.spec.updateStrategy字段的默认值是RollingUpdates,该策略为StatefulSet实现了Pod的自动滚动更新,在用户更新StatefulSet的.spec.template字段的时候,StatefulSet Controller将自动的删除并重建StatefulSet中的每个Pod,处理顺序如下:
1)从序号最大的Pod开始,逐个删除和更新每一个Pod,直到序号最小的Pod被更新
2)当正在更新的Pod达到了Running和Ready状态后,才继续更新其前序Pod
Partitions参数:
通过指定.spce.updateStrtegy.rollingUpdate.partition字段,可以分片(partitioned)执行rolling update更新策略;当更新StatefulSet的.spec.template时:
··序号大于或等于.spce.updateStrtegy.rollingUpdate.partition的Pod将被删除重建
··序号小于.spce.updateStrtegy.rollingUpdate.partition的Pod将不会更新,即使手工删除该Pod,kubernetes也会使用前一个版本的.spec.template重建该Pod
··如果.spce.updateStrtegy.rollingUpdate.partition大于.spec.replicas,更新.spec.template将不会影响任何Pod
大部分情况,都用不到.spce.updateStrtegy.rollingUpdate.partition参数,除非:执行预发布、执行金丝雀更新、执行按阶段更新
参考以下文档:https://kuboard.cn/learning/k8s-intermediate/workload/wl-statefulset/#statefulset-%E6%A6%82%E8%BF%B0