kubernetes学习控制器之StatefulSet控制器

StatefulSet介绍

1、StatefulSet概述

StatefulSet是用来管理stateful(有状态)应用的
StatefulSet管理Pod时,确保Pod有一个按序增加的ID
与Deployment最大的不一样是StatefulSet始终将一系列不变的名字分配给Pod.这些Pod从一个模板建立,可是并不能相互替换

2、StatefulSet使用场景

对于有以下要求的应用程序,StatefulSet很是适用
须要稳定、惟一的网络标识(dnsname)
每一个Pod始终对应各自的存储路径（PersistantVolumeClaimTemplate）
按顺序的增长副本、减小副本,并在减小副本时执行清理
安顺序自动的执行滚动更新

若是一个应用不须要一个稳定的网络标识,或者不须要按顺序部署、删除、增长副本,应该用deployment(无状态)控制器

3、StatefulSet的限制

Pod的存储要么由storage clas对应的PersistentVolume Provisioner提供,要么由集群管理员事先建立

删除或scale down一个StatefulSet将不会删除其对应的数据卷,这样保证数据安全

删除StatefulSet时,将没法保证Pod正常终止.若是要按顺序优雅的终止StatefulSet中的Pod,能够在删除StatefulSet以前,将scale down 到0 

当使用默认的Pod Management Policy(OrderedReady)进行滚动更新时,可能进入一个错误状态,并须要人工介入

用一个StatefulSet实例深刻了解

建立StatefulSet实例

1、下面是一个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

2、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的部署和伸缩

1、部署和伸缩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-一、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

2、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