kubernetes学习控制器之StatefulSet控制器

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:

    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:

  template:

    metadata:

      labels:

        app: nginx  #pod的标签

    spec:

      terminationGracePeriodSeconds:

      containers:

      - name: nginx   #pod里容器的名称

        image: nginx:1.7.

        ports:

        - containerPort:

          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