StatefulSet

StatefulSet 是用來管理有狀態(tài)應(yīng)用的工作負(fù)載 API 對象

StatefulSet 用來管理某 Pod 集合的部署和擴(kuò)縮， 并為這些 Pod 提供持久存儲和持久標(biāo)識符

和 Deployment 類似， StatefulSet 管理基于相同容器規(guī)約的一組 Pod。但和 Deployment 不同的是， StatefulSet 為它們的每個 Pod 維護(hù)了一個有粘性的 ID。這些 Pod 是基于相同的規(guī)約來創(chuàng)建的， 但是不能相互替換：無論怎么調(diào)度，每個 Pod 都有一個永久不變的 ID

如果希望使用存儲卷為工作負(fù)載提供持久存儲，可以使用 StatefulSet 作為解決方案的一部分。 盡管 StatefulSet 中的單個 Pod 仍可能出現(xiàn)故障， 但持久的 Pod 標(biāo)識符使得將現(xiàn)有卷與替換已失敗 Pod 的新 Pod 相匹配變得更加容易

使用 StatefulSet

StatefulSet 對于需要滿足以下一個或多個需求的應(yīng)用程序很有價值：

• 穩(wěn)定的、唯一的網(wǎng)絡(luò)標(biāo)識符。
• 穩(wěn)定的、持久的存儲。
• 有序的、優(yōu)雅的部署和擴(kuò)縮。
• 有序的、自動的滾動更新。
  在上面描述中，“穩(wěn)定的”意味著 Pod 調(diào)度或重調(diào)度的整個過程是有持久性的。 如果應(yīng)用程序不需要任何穩(wěn)定的標(biāo)識符或有序的部署、刪除或擴(kuò)縮， 則應(yīng)該使用由一組無狀態(tài)的副本控制器提供的工作負(fù)載來部署應(yīng)用程序，比如 Deployment 或者 ReplicaSet 可能更適用于你的無狀態(tài)應(yīng)用部署需要

限制

• 給定 Pod 的存儲必須由 PersistentVolume Provisioner 基于所請求的 storage class 來制備，或者由管理員預(yù)先制備。
• 刪除或者擴(kuò)縮 StatefulSet 并不會刪除它關(guān)聯(lián)的存儲卷。 這樣做是為了保證數(shù)據(jù)安全，它通常比自動清除 StatefulSet 所有相關(guān)的資源更有價值。
• StatefulSet 當(dāng)前需要無頭服務(wù)來負(fù)責(zé) Pod 的網(wǎng)絡(luò)標(biāo)識。你需要負(fù)責(zé)創(chuàng)建此服務(wù)。
• 當(dāng)刪除一個 StatefulSet 時，該 StatefulSet 不提供任何終止 Pod 的保證。 為了實現(xiàn) StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。
• 在默認(rèn) Pod 管理策略(OrderedReady) 時使用滾動更新， 可能進(jìn)入需要人工干預(yù)才能修復(fù)的損壞狀態(tài)

示例

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必須匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默認(rèn)值是 1
  minReadySeconds: 10 # 默認(rèn)值是 0
  template:
    metadata:
      labels:
        app: nginx # 必須匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

上述示例中：

• nginx 的 Headless Service 用來控制網(wǎng)絡(luò)域名。
• web 的 StatefulSet 有一個 Spec，它表明將在獨立的 3 個 Pod 副本中啟動 nginx 容器。
• volumeClaimTemplates 將通過 PersistentVolume 制備程序所準(zhǔn)備的 PersistentVolumes 來提供穩(wěn)定的存儲

穩(wěn)定的網(wǎng)絡(luò) ID

StatefulSet 中的每個 Pod 根據(jù) StatefulSet 的名稱和 Pod 的序號派生出它的主機(jī)名。 組合主機(jī)名的格式為$(StatefulSet名稱)?$(序號)。 上例將會創(chuàng)建三個名稱分別為 web-0、web-1、web-2 的 Pod。 StatefulSet 可以使用無頭服務(wù)控制它的 Pod 的網(wǎng)絡(luò)域。管理域的這個服務(wù)的格式為： $(服務(wù)名稱).$(名字空間).svc.cluster.local，其中 cluster.local 是集群域。 一旦每個 Pod 創(chuàng)建成功，就會得到一個匹配的 DNS 子域，格式為： $(pod名稱).$(所屬服務(wù)的 DNS 域名)，其中所屬服務(wù)由 StatefulSet 的 serviceName 域來設(shè)定。

取決于集群域內(nèi)部 DNS 的配置，有可能無法查詢一個剛剛啟動的 Pod 的 DNS 命名。 當(dāng)集群內(nèi)其他客戶端在 Pod 創(chuàng)建完成前發(fā)出 Pod 主機(jī)名查詢時，就會發(fā)生這種情況。 負(fù)緩存 (在 DNS 中較為常見) 意味著之前失敗的查詢結(jié)果會被記錄和重用至少若干秒鐘， 即使 Pod 已經(jīng)正常運(yùn)行了也是如此。

如果需要在 Pod 被創(chuàng)建之后及時發(fā)現(xiàn)它們，可使用以下選項：

• 直接查詢 Kubernetes API（比如，利用 watch 機(jī)制）而不是依賴于 DNS 查詢
• 縮短 Kubernetes DNS 驅(qū)動的緩存時長（通常這意味著修改 CoreDNS 的 ConfigMap，目前緩存時長為 30 秒）

更新策略

StatefulSet 的 .spec.updateStrategy 字段讓你可以配置和禁用掉自動滾動更新 Pod 的容器、標(biāo)簽、資源請求或限制、以及注解。有兩個允許的值：

OnDelete
當(dāng) StatefulSet 的 .spec.updateStrategy.type 設(shè)置為 OnDelete 時， 它的控制器將不會自動更新 StatefulSet 中的 Pod。 用戶必須手動刪除 Pod 以便讓控制器創(chuàng)建新的 Pod，以此來對 StatefulSet 的 .spec.template 的變動作出反應(yīng)
RollingUpdate
RollingUpdate 更新策略對 StatefulSet 中的 Pod 執(zhí)行自動的滾動更新。這是默認(rèn)的更新策略

滾動更新

當(dāng) StatefulSet 的 .spec.updateStrategy.type 被設(shè)置為 RollingUpdate 時， StatefulSet 控制器會刪除和重建 StatefulSet 中的每個 Pod。 它將按照與 Pod 終止相同的順序（從最大序號到最小序號）進(jìn)行，每次更新一個 Pod

Kubernetes 控制平面會等到被更新的 Pod 進(jìn)入 Running 和 Ready 狀態(tài)，然后再更新其前身。 如果你設(shè)置了 .spec.minReadySeconds（查看最短就緒秒數(shù)）， 控制平面在 Pod 就緒后會額外等待一定的時間再執(zhí)行下一步

分區(qū)滾動更新

通過聲明 .spec.updateStrategy.rollingUpdate.partition 的方式，RollingUpdate 更新策略可以實現(xiàn)分區(qū)。 如果聲明了一個分區(qū)，當(dāng) StatefulSet 的 .spec.template 被更新時， 所有序號大于等于該分區(qū)序號的 Pod 都會被更新。 所有序號小于該分區(qū)序號的 Pod 都不會被更新，并且，即使它們被刪除也會依據(jù)之前的版本進(jìn)行重建。 如果 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于它的 .spec.replicas，則對它的 .spec.template 的更新將不會傳遞到它的 Pod。 在大多數(shù)情況下，你不需要使用分區(qū)，但如果你希望進(jìn)行階段更新、執(zhí)行金絲雀或執(zhí)行分階段上線，則這些分區(qū)會非常有用

最大不可用 Pod

特性狀態(tài)： Kubernetes v1.24 [alpha]
你可以通過指定 .spec.updateStrategy.rollingUpdate.maxUnavailable 字段來控制更新期間不可用的 Pod 的最大數(shù)量。 該值可以是絕對值（例如，“5”）或者是期望 Pod 個數(shù)的百分比（例如，10%）。 絕對值是根據(jù)百分比值四舍五入計算的。 該字段不能為 0。默認(rèn)設(shè)置為 1

該字段適用于 0 到 replicas - 1 范圍內(nèi)的所有 Pod。 如果在 0 到 replicas - 1 范圍內(nèi)存在不可用 Pod，這類 Pod 將被計入 maxUnavailable 值文章來源地址http://www.zghlxwxcb.cn/news/detail-608419.html

到了這里，關(guān)于【云原生】Kubernetes工作負(fù)載-StatefulSet的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！