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