玄幻小说,好看的历史书籍推荐,玄幻小说排行榜完本

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

創(chuàng)新互聯(lián)kubernetes教程：KubernetesStatefulSets

StatefulSets

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

廣陽網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)于2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。

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

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

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

使用 StatefulSets

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

穩(wěn)定的、唯一的網(wǎng)絡(luò)標(biāo)識符。
穩(wěn)定的、持久的存儲。
有序的、優(yōu)雅的部署和縮放。
有序的、自動的滾動更新。

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

限制

給定 Pod 的存儲必須由 PersistentVolume 驅(qū)動基于所請求的 ?storage class? 來提供，或者由管理員預(yù)先提供。
刪除或者收縮 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)刪除 StatefulSets 時，StatefulSet 不提供任何終止 Pod 的保證。為了實現(xiàn) StatefulSet 中的 Pod 可以有序地且體面地終止，可以在刪除之前將 StatefulSet 縮放為 0。
在默認(rèn) Pod 管理策略(?OrderedReady?) 時使用滾動更新，可能進入需要人工干預(yù) 才能修復(fù)的損壞狀態(tài)。

組件

下面的示例演示了 StatefulSet 的組件。

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 # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: K8S.gcr.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 ?將通過 PersistentVolumes 驅(qū)動提供的 PersistentVolumes 來提供穩(wěn)定的存儲。

StatefulSet 的命名需要遵循DNS 子域名規(guī)范。

Pod選擇算符

你必須設(shè)置 StatefulSet 的 ?.spec.selector? 字段，使之匹配其在 ?.spec.template.metadata.labels? 中設(shè)置的標(biāo)簽。在 Kubernetes 1.8 版本之前，被忽略 ?.spec.selector? 字段會獲得默認(rèn)設(shè)置值。在 1.8 和以后的版本中，未指定匹配的 Pod 選擇器將在創(chuàng)建 StatefulSet 期間導(dǎo)致驗證錯誤。

Pod 標(biāo)識

StatefulSet Pod 具有唯一的標(biāo)識，該標(biāo)識包括順序標(biāo)識、穩(wěn)定的網(wǎng)絡(luò)標(biāo)識和穩(wěn)定的存儲。該標(biāo)識和 Pod 是綁定的，不管它被調(diào)度在哪個節(jié)點上。

有序索引

對于具有 N 個副本的 StatefulSet，StatefulSet 中的每個 Pod 將被分配一個整數(shù)序號，從 0 到 N-1，該序號在 StatefulSet 上是唯一的。

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

StatefulSet 中的每個 Pod 根據(jù) StatefulSet 的名稱和 Pod 的序號派生出它的主機名。組合主機名的格式為?$(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 主機名查詢時，就會發(fā)生這種情況。負(fù)緩存 (在 DNS 中較為常見) 意味著之前失敗的查詢結(jié)果會被記錄和重用至少若干秒鐘，即使 Pod 已經(jīng)正常運行了也是如此。

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

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

正如限制中所述，你需要負(fù)責(zé)創(chuàng)建無頭服務(wù) 以便為 Pod 提供網(wǎng)絡(luò)標(biāo)識。

下面給出一些選擇集群域、服務(wù)名、StatefulSet 名、及其怎樣影響 StatefulSet 的 Pod 上的 DNS 名稱的示例：

集群域名	服務(wù)（名字空間/名字）	StatefulSet（名字空間/名字）	StatefulSet 域名	Pod DNS	Pod 主機名
cluster.local	default/nginx	default/web	nginx.default.svc.cluster.local	web-{0..N-1}.nginx.default.svc.cluster.local	web-{0..N-1}
cluster.local	foo/nginx	foo/web	nginx.foo.svc.cluster.local	web-{0..N-1}.nginx.foo.svc.cluster.local	web-{0..N-1}
kube.local	foo/nginx	foo/web	nginx.foo.svc.kube.local	web-{0..N-1}.nginx.foo.svc.kube.local	web-{0..N-1}

集群域會被設(shè)置為 ?cluster.local?，除非有其他配置。

穩(wěn)定的存儲

對于 StatefulSet 中定義的每個 VolumeClaimTemplate，每個 Pod 接收到一個 PersistentVolumeClaim。在上面的 nginx 示例中，每個 Pod 將會得到基于 StorageClass ?my-storage-class? 提供的 1 Gib 的 PersistentVolume。如果沒有聲明 StorageClass，就會使用默認(rèn)的 StorageClass。當(dāng)一個 Pod 被調(diào)度（重新調(diào)度）到節(jié)點上時，它的 ?volumeMounts ?會掛載與其 PersistentVolumeClaims 相關(guān)聯(lián)的 PersistentVolume。請注意，當(dāng) Pod 或者 StatefulSet 被刪除時，與 PersistentVolumeClaims 相關(guān)聯(lián)的 PersistentVolume 并不會被刪除。要刪除它必須通過手動方式來完成。

Pod 名稱標(biāo)簽

當(dāng) StatefulSet 控制器（Controller）創(chuàng)建 Pod 時，它會添加一個標(biāo)簽 ?statefulset.kubernetes.io/pod-name?，該標(biāo)簽值設(shè)置為 Pod 名稱。這個標(biāo)簽允許你給 StatefulSet 中的特定 Pod 綁定一個 Service。

部署和擴縮保證

對于包含 N 個副本的 StatefulSet，當(dāng)部署 Pod 時，它們是依次創(chuàng)建的，順序為 ?0..N-1?。
當(dāng)刪除 Pod 時，它們是逆序終止的，順序為 ?N-1..0?。
在將縮放操作應(yīng)用到 Pod 之前，它前面的所有 Pod 必須是 Running 和 Ready 狀態(tài)。
在 Pod 終止之前，所有的繼任者必須完全關(guān)閉。

StatefulSet 不應(yīng)將 ?pod.Spec.TerminationGracePeriodSeconds? 設(shè)置為 0。這種做法是不安全的，要強烈阻止。

在上面的 nginx 示例被創(chuàng)建后，會按照 web-0、web-1、web-2 的順序部署三個 Pod。在 web-0 進入 Running 和 Ready 狀態(tài)前不會部署 web-1。在 web-1 進入 Running 和 Ready 狀態(tài)前不會部署 web-2。如果 web-1 已經(jīng)處于 Running 和 Ready 狀態(tài)，而 web-2 尚未部署，在此期間發(fā)生了 web-0 運行失敗，那么 web-2 將不會被部署，要等到 web-0 部署完成并進入 Running 和 Ready 狀態(tài)后，才會部署 web-2。

如果用戶想將示例中的 StatefulSet 收縮為 ?replicas=1?，首先被終止的是 web-2。在 web-2 沒有被完全停止和刪除前，web-1 不會被終止。當(dāng) web-2 已被終止和刪除、web-1 尚未被終止，如果在此期間發(fā)生 web-0 運行失敗，那么就不會終止 web-1，必須等到 web-0 進入 Running 和 Ready 狀態(tài)后才會終止 web-1。

Pod 管理策略

在 Kubernetes 1.7 及以后的版本中，StatefulSet 允許你放寬其排序保證，同時通過它的 ?.spec.podManagementPolicy? 域保持其唯一性和身份保證。

OrderedReady Pod 管理

?OrderedReady ?Pod 管理是 StatefulSet 的默認(rèn)設(shè)置。它實現(xiàn)了上面描述的功能。

并行 Pod 管理

?Parallel ?Pod 管理讓 StatefulSet 控制器并行的啟動或終止所有的 Pod，啟動或者終止其他 Pod 前，無需等待 Pod 進入 Running 和 ready 或者完全停止?fàn)顟B(tài)。這個選項只會影響伸縮操作的行為，更新則不會被影響。

更新策略

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 終止相同的順序（從最大序號到最小序號）進行，每次更新一個 Pod。

Kubernetes 控制面會等到被更新的 Pod 進入 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ù)之前的版本進行重建。如果 StatefulSet 的 ?.spec.updateStrategy.rollingUpdate.partition? 大于它的 ?.spec.replicas?，對它的 ?.spec.template? 的更新將不會傳遞到它的 Pod。在大多數(shù)情況下，你不需要使用分區(qū)，但如果你希望進行階段更新、執(zhí)行金絲雀或執(zhí)行分階段上線，則這些分區(qū)會非常有用。

強制回滾

在默認(rèn) Pod 管理策略(?OrderedReady?) 下使用滾動更新，可能進入需要人工干預(yù)才能修復(fù)的損壞狀態(tài)。

如果更新后 Pod 模板配置進入無法運行或就緒的狀態(tài)（例如，由于錯誤的二進制文件或應(yīng)用程序級配置錯誤），StatefulSet 將停止回滾并等待。

在這種狀態(tài)下，僅將 Pod 模板還原為正確的配置是不夠的。由于已知問題，StatefulSet 將繼續(xù)等待損壞狀態(tài)的 Pod 準(zhǔn)備就緒（永遠不會發(fā)生），然后再嘗試將其恢復(fù)為正常工作配置。

恢復(fù)模板后，還必須刪除 StatefulSet 嘗試使用錯誤的配置來運行的 Pod。這樣， StatefulSet 才會開始使用被還原的模板來重新創(chuàng)建 Pod。

最短就緒秒數(shù)

FEATURE STATE: Kubernetes v1.22 [alpha]

?.spec.minReadySeconds? 是一個可選字段，用于指定新創(chuàng)建的 Pod 就緒（沒有任何容器崩潰）后被認(rèn)為可用的最小秒數(shù)。默認(rèn)值是 0（Pod 就緒時就被認(rèn)為可用）。

請注意只有當(dāng)你啟用 ?StatefulSetMinReadySeconds ?特性門控時，該字段才會生效。

名稱欄目：創(chuàng)新互聯(lián)kubernetes教程：KubernetesStatefulSets
文章轉(zhuǎn)載：http://m.fisionsoft.com.cn/article/dhpcjoc.html