2级片免费观看精品码一本A片,日韩无码国语对白,免费黄色网页大全

新聞中心

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

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

Deployments

一個 Deployment 為 Pod 和 ReplicaSet 提供聲明式的更新能力。

創(chuàng)新互聯(lián)是專業(yè)的廣饒網(wǎng)站建設(shè)公司，廣饒接單;提供網(wǎng)站設(shè)計、做網(wǎng)站,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行廣饒網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

你負(fù)責(zé)描述 Deployment 中的目標(biāo)狀態(tài)，而 Deployment 控制器（Controller）以受控速率更改實際狀態(tài)，使其變?yōu)槠谕麪顟B(tài)。你可以定義 Deployment 以創(chuàng)建新的 ReplicaSet，或刪除現(xiàn)有 Deployment，并通過新的 Deployment 收養(yǎng)其資源。

不要管理 Deployment 所擁有的 ReplicaSet 。如果存在下面未覆蓋的使用場景，請考慮在 Kubernetes 倉庫中提出 Issue。

用例

以下是 Deployments 的典型用例：

創(chuàng)建 Deployment 以將 ReplicaSet 上線。 ReplicaSet 在后臺創(chuàng)建 Pods。檢查 ReplicaSet 的上線狀態(tài)，查看其是否成功。
通過更新 Deployment 的 PodTemplateSpec，聲明 Pod 的新狀態(tài) 。新的 ReplicaSet 會被創(chuàng)建，Deployment 以受控速率將 Pod 從舊 ReplicaSet 遷移到新 ReplicaSet。每個新的 ReplicaSet 都會更新 Deployment 的修訂版本。
如果 Deployment 的當(dāng)前狀態(tài)不穩(wěn)定，回滾到較早的 Deployment 版本。每次回滾都會更新 Deployment 的修訂版本。
擴(kuò)大 Deployment 規(guī)模以承擔(dān)更多負(fù)載。
暫停 Deployment 以應(yīng)用對 PodTemplateSpec 所作的多項修改，然后恢復(fù)其執(zhí)行以啟動新的上線版本。
使用 Deployment 狀態(tài) 來判定上線過程是否出現(xiàn)停滯。
清理較舊的不再需要的 ReplicaSet 。

創(chuàng)建 Deployment

下面是一個 Deployment 示例。其中創(chuàng)建了一個 ReplicaSet，負(fù)責(zé)啟動三個 ?nginx? Pods：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

在該例中：

創(chuàng)建名為 ?nginx-deployment?（由 ?.metadata.name? 字段標(biāo)明）的 Deployment。
該 Deployment 創(chuàng)建三個（由 ?replicas ?字段標(biāo)明）Pod 副本。
?selector ?字段定義 Deployment 如何查找要管理的 Pods。在這里，你選擇在 Pod 模板中定義的標(biāo)簽（?app: nginx?）。不過，更復(fù)雜的選擇規(guī)則是也可能的，只要 Pod 模板本身滿足所給規(guī)則即可。

?spec.selector.matchLabels? 字段是 ?{key,value}? 鍵值對映射。在 ?matchLabels ?映射中的每個 ?{key,value}? 映射等效于 ?matchExpressions ?中的一個元素，即其 ?key ?字段是 “key”，?operator ?為 “In”，?values ?數(shù)組僅包含 “value”。在 ?matchLabels ?和 ?matchExpressions ?中給出的所有條件都必須滿足才能匹配。

?template ?字段包含以下子字段：

Pod 被使用 ?.metadata.labels? 字段打上 ?app: nginx? 標(biāo)簽。
Pod 模板規(guī)約（即 ?.template.spec? 字段）指示 Pods 運(yùn)行一個 ?nginx ?容器，該容器運(yùn)行版本為 1.14.2 的 ?nginx ?Docker Hub鏡像。
創(chuàng)建一個容器并使用 ?.spec.template.spec.containers[0].name? 字段將其命名為 ?nginx?。

開始之前，請確保的 Kubernetes 集群已啟動并運(yùn)行。按照以下步驟創(chuàng)建上述 Deployment ：

通過運(yùn)行以下命令創(chuàng)建 Deployment ：

kubectl apply -f https://K8S.io/examples/controllers/nginx-deployment.yaml

運(yùn)行 ?kubectl get deployments? 檢查 Deployment 是否已創(chuàng)建。如果仍在創(chuàng)建 Deployment，則輸出類似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s

在檢查集群中的 Deployment 時，所顯示的字段有：

?NAME ?列出了集群中 Deployment 的名稱。
?READY ?顯示應(yīng)用程序的可用的“副本”數(shù)。顯示的模式是“就緒個數(shù)/期望個數(shù)”。
?UP-TO-DATE? 顯示為了達(dá)到期望狀態(tài)已經(jīng)更新的副本數(shù)。
?AVAILABLE ?顯示應(yīng)用可供用戶使用的副本數(shù)。
?AGE ?顯示應(yīng)用程序運(yùn)行的時間。

請注意期望副本數(shù)是根據(jù) ?.spec.replicas? 字段設(shè)置 3。

要查看 Deployment 上線狀態(tài)，運(yùn)行 kubectl rollout status deployment/nginx-deployment。

輸出類似于：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

幾秒鐘后再次運(yùn)行 ?kubectl get deployments?。輸出類似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           18s

注意 Deployment 已創(chuàng)建全部三個副本，并且所有副本都是最新的（它們包含最新的 Pod 模板）并且可用。

要查看 Deployment 創(chuàng)建的 ReplicaSet（?rs?），運(yùn)行 ?kubectl get rs?。輸出類似于：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       18s

ReplicaSet 輸出中包含以下字段：

?NAME ?列出名字空間中 ReplicaSet 的名稱；
?DESIRED ?顯示應(yīng)用的期望副本個數(shù)，即在創(chuàng)建 Deployment 時所定義的值。此為期望狀態(tài)；
?CURRENT ?顯示當(dāng)前運(yùn)行狀態(tài)中的副本個數(shù)；
?READY ?顯示應(yīng)用中有多少副本可以為用戶提供服務(wù)；
?AGE ?顯示應(yīng)用已經(jīng)運(yùn)行的時間長度。

注意 ReplicaSet 的名稱始終被格式化為?[Deployment名稱]-[隨機(jī)字符串]?。其中的隨機(jī)字符串是使用 ?pod-template-hash? 作為種子隨機(jī)生成的。

要查看每個 Pod 自動生成的標(biāo)簽，運(yùn)行 ?kubectl get pods --show-labels?。返回以下輸出：

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453

所創(chuàng)建的 ReplicaSet 確?？偸谴嬖谌齻€ ?nginx ?Pod。

你必須在 Deployment 中指定適當(dāng)?shù)倪x擇算符和 Pod 模板標(biāo)簽（在本例中為 ?app: nginx?）。標(biāo)簽或者選擇算符不要與其他控制器（包括其他 Deployment 和 StatefulSet）重疊。 Kubernetes 不會阻止你這樣做，但是如果多個控制器具有重疊的選擇算符，它們可能會發(fā)生沖突執(zhí)行難以預(yù)料的操作。

Pod-template-hash 標(biāo)簽

不要更改此標(biāo)簽。

Deployment 控制器將 ?pod-template-hash? 標(biāo)簽添加到 Deployment 所創(chuàng)建或收留的每個 ReplicaSet 。

此標(biāo)簽可確保 Deployment 的子 ReplicaSets 不重疊。標(biāo)簽是通過對 ReplicaSet 的 ?PodTemplate ?進(jìn)行哈希處理。所生成的哈希值被添加到 ReplicaSet 選擇算符、Pod 模板標(biāo)簽，并存在于在 ReplicaSet 可能擁有的任何現(xiàn)有 Pod 中。

更新 Deployment

僅當(dāng) Deployment Pod 模板（即 ?.spec.template?）發(fā)生改變時，例如模板的標(biāo)簽或容器鏡像被更新，才會觸發(fā) Deployment 上線。其他更新（如對 Deployment 執(zhí)行擴(kuò)縮容的操作）不會觸發(fā)上線動作。

按照以下步驟更新 Deployment：

先來更新 nginx Pod 以使用 ?nginx:1.16.1? 鏡像，而不是 ?nginx:1.14.2? 鏡像。

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

或者使用下面的命令：

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

輸出類似于：

deployment/nginx-deployment image updated

或者，可以對 Deployment 執(zhí)行 ?edit ?操作并將 ?.spec.template.spec.containers[0].image? 從 ?nginx:1.14.2? 更改至 ?nginx:1.16.1?。

kubectl edit deployment/nginx-deployment

輸出類似于：

deployment/nginx-deployment edited

要查看上線狀態(tài)，運(yùn)行：

kubectl rollout status deployment/nginx-deployment

輸出類似于：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

或者

deployment "nginx-deployment" successfully rolled out

獲取關(guān)于已更新的 Deployment 的更多信息：

在上線成功后，可以通過運(yùn)行 ?kubectl get deployments? 來查看 Deployment：輸出類似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           36s

運(yùn)行 ?kubectl get rs? 以查看 Deployment 通過創(chuàng)建新的 ReplicaSet 并將其擴(kuò)容到 3 個副本并將舊 ReplicaSet 縮容到 0 個副本完成了 Pod 的更新操作：

kubectl get rs

輸出類似于：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       6s
nginx-deployment-2035384211   0         0         0       36s

現(xiàn)在運(yùn)行 ?get pods? 應(yīng)僅顯示新的 Pods:

kubectl get pods

輸出類似于：

NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-1564180365-khku8   1/1       Running   0          14s
nginx-deployment-1564180365-nacti   1/1       Running   0          14s
nginx-deployment-1564180365-z9gth   1/1       Running   0          14s

下次要更新這些 Pods 時，只需再次更新 Deployment Pod 模板即可。

Deployment 可確保在更新時僅關(guān)閉一定數(shù)量的 Pod。默認(rèn)情況下，它確保至少所需 Pods 75% 處于運(yùn)行狀態(tài)（最大不可用比例為 25%）。

Deployment 還確保僅所創(chuàng)建 Pod 數(shù)量只可能比期望 Pods 數(shù)高一點點。默認(rèn)情況下，它可確保啟動的 Pod 個數(shù)比期望個數(shù)最多多出 25%（最大峰值 25%）。

例如，如果仔細(xì)查看上述 Deployment ，將看到它首先創(chuàng)建了一個新的 Pod，然后刪除了一些舊的 Pods，并創(chuàng)建了新的 Pods。它不會殺死老 Pods，直到有足夠的數(shù)量新的 Pods 已經(jīng)出現(xiàn)。在足夠數(shù)量的舊 Pods 被殺死前并沒有創(chuàng)建新 Pods。它確保至少 2 個 Pod 可用，同時最多總共 4 個 Pod 可用。當(dāng) Deployment 設(shè)置為 4 個副本時，Pod 的個數(shù)會介于 3 和 5 之間。

獲取 Deployment 的更多信息

kubectl describe deployments

輸出類似于：

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=2
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
   Containers:
    nginx:
      Image:        nginx:1.16.1
      Port:         80/TCP
      Environment:  
      Mounts:       
    Volumes:        
  Conditions:
    Type           Status  Reason
    ----           ------  ------
    Available      True    MinimumReplicasAvailable
    Progressing    True    NewReplicaSetAvailable
  OldReplicaSets:  
  NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
  Events:
    Type    Reason             Age   From                   Message
    ----    ------             ----  ----                   -------
    Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
    Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
    Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
    Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
    Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
    Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
    Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0

可以看到，當(dāng)?shù)谝淮蝿?chuàng)建 Deployment 時，它創(chuàng)建了一個 ReplicaSet（?nginx-deployment-2035384211?）并將其直接擴(kuò)容至 3 個副本。更新 Deployment 時，它創(chuàng)建了一個新的 ReplicaSet （nginx-deployment-1564180365），并將其擴(kuò)容為 1，等待其就緒；然后將舊 ReplicaSet 縮容到 2，將新的 ReplicaSet 擴(kuò)容到 2 以便至少有 3 個 Pod 可用且最多創(chuàng)建 4 個 Pod。然后，它使用相同的滾動更新策略繼續(xù)對新的 ReplicaSet 擴(kuò)容并對舊的 ReplicaSet 縮容。最后，你將有 3 個可用的副本在新的 ReplicaSet 中，舊 ReplicaSet 將縮容到 0。

Kubernetes 在計算 ?availableReplicas ?數(shù)值時不考慮終止過程中的 Pod， ?availableReplicas ?的值一定介于 ?replicas - maxUnavailable? 和 ?replicas + maxSurge? 之間。因此，你可能在上線期間看到 Pod 個數(shù)比預(yù)期的多，Deployment 所消耗的總的資源也大于 ?replicas + maxSurge? 個 Pod 所用的資源，直到被終止的 Pod 所設(shè)置的 ?terminationGracePeriodSeconds ?到期為止。

翻轉(zhuǎn)（多 Deployment 動態(tài)更新）

Deployment 控制器每次注意到新的 Deployment 時，都會創(chuàng)建一個 ReplicaSet 以啟動所需的 Pods。如果更新了 Deployment，則控制標(biāo)簽匹配 ?.spec.selector? 但模板不匹配 ?.spec.template? 的 Pods 的現(xiàn)有 ReplicaSet 被縮容。最終，新的 ReplicaSet 縮放為 ?.spec.replicas? 個副本，所有舊 ReplicaSets 縮放為 0 個副本。

當(dāng) Deployment 正在上線時被更新，Deployment 會針對更新創(chuàng)建一個新的 ReplicaSet 并開始對其擴(kuò)容，之前正在被擴(kuò)容的 ReplicaSet 會被翻轉(zhuǎn)，添加到舊 ReplicaSets 列表并開始縮容。

例如，假定你在創(chuàng)建一個 Deployment 以生成 ?nginx:1.14.2? 的 5 個副本，但接下來更新 Deployment 以創(chuàng)建 5 個 ?nginx:1.16.1? 的副本，而此時只有 3 個?nginx:1.14.2? 副本已創(chuàng)建。在這種情況下，Deployment 會立即開始?xì)⑺?nbsp;3 個 ?nginx:1.14.2? Pods，并開始創(chuàng)建 ?nginx:1.16.1? Pods。它不會等待 ?nginx:1.14.2? 的 5 個副本都創(chuàng)建完成后才開始執(zhí)行變更動作。

更改標(biāo)簽選擇算符

通常不鼓勵更新標(biāo)簽選擇算符。建議你提前規(guī)劃選擇算符。在任何情況下，如果需要更新標(biāo)簽選擇算符，請格外小心，并確保自己了解這背后可能發(fā)生的所有事情。

在 API 版本 ?apps/v1? 中，Deployment 標(biāo)簽選擇算符在創(chuàng)建后是不可變的。

添加選擇算符時要求使用新標(biāo)簽更新 Deployment 規(guī)約中的 Pod 模板標(biāo)簽，否則將返回驗證錯誤。此更改是非重疊的，也就是說新的選擇算符不會選擇使用舊選擇算符所創(chuàng)建的 ReplicaSet 和 Pod，這會導(dǎo)致創(chuàng)建新的 ReplicaSet 時所有舊 ReplicaSet 都會被孤立。
選擇算符的更新如果更改了某個算符的鍵名，這會導(dǎo)致與添加算符時相同的行為。
刪除選擇算符的操作會刪除從 Deployment 選擇算符中刪除現(xiàn)有算符。此操作不需要更改 Pod 模板標(biāo)簽。現(xiàn)有 ReplicaSet 不會被孤立，也不會因此創(chuàng)建新的 ReplicaSet，但請注意已刪除的標(biāo)簽仍然存在于現(xiàn)有的 Pod 和 ReplicaSet 中。

回滾 Deployment

有時，你可能想要回滾 Deployment；例如，當(dāng) Deployment 不穩(wěn)定時（例如進(jìn)入反復(fù)崩潰狀態(tài)）。默認(rèn)情況下，Deployment 的所有上線記錄都保留在系統(tǒng)中，以便可以隨時回滾（你可以通過修改修訂歷史記錄限制來更改這一約束）。

Deployment 被觸發(fā)上線時，系統(tǒng)就會創(chuàng)建 Deployment 的新的修訂版本。這意味著僅當(dāng) Deployment 的 Pod 模板（?.spec.template?）發(fā)生更改時，才會創(chuàng)建新修訂版本 -- 例如，模板的標(biāo)簽或容器鏡像發(fā)生變化。其他更新，如 Deployment 的擴(kuò)縮容操作不會創(chuàng)建 Deployment 修訂版本。這是為了方便同時執(zhí)行手動縮放或自動縮放。換言之，當(dāng)你回滾到較早的修訂版本時，只有 Deployment 的 Pod 模板部分會被回滾。

假設(shè)你在更新 Deployment 時犯了一個拼寫錯誤，將鏡像名稱命名設(shè)置為 ?nginx:1.161? 而不是 ?nginx:1.16.1?：

kubectl set image deployment/nginx-deployment nginx=nginx:1.161 --record=true

輸出類似于：

deployment/nginx-deployment image updated

此上線進(jìn)程會出現(xiàn)停滯。你可以通過檢查上線狀態(tài)來驗證：

kubectl rollout status deployment/nginx-deployment

輸出類似于：

Waiting for rollout to finish: 1 out of 3 new replicas have been updated...

按 Ctrl-C 停止上述上線狀態(tài)觀測。
你可以看到舊的副本有兩個（?nginx-deployment-1564180365? 和 ?nginx-deployment-2035384211?），新的副本有 1 個（?nginx-deployment-3066724191?）：

kubectl get rs

輸出類似于：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   1         1         0       6s

查看所創(chuàng)建的 Pod，你會注意到新 ReplicaSet 所創(chuàng)建的 1 個 Pod 卡頓在鏡像拉取循環(huán)中。

kubectl get pods

輸出類似于：

NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s

Deployment 控制器自動停止有問題的上線過程，并停止對新的 ReplicaSet 擴(kuò)容。這行為取決于所指定的 rollingUpdate 參數(shù)（具體為 ?maxUnavailable?）。默認(rèn)情況下，Kubernetes 將此值設(shè)置為 25%。

獲取 Deployment 描述信息：

kubectl describe deployment

輸出類似于：

Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.91
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
  1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1

要解決此問題，需要回滾到以前穩(wěn)定的 Deployment 版本。

檢查 Deployment 上線歷史

按照如下步驟檢查回滾歷史：

首先，檢查 Deployment 修訂歷史：

kubectl rollout history deployment/nginx-deployment

輸出類似于：

deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.161

?CHANGE-CAUSE? 的內(nèi)容是從 Deployment 的 ?kubernetes.io/change-cause? 注解復(fù)制過來的。復(fù)制動作發(fā)生在修訂版本創(chuàng)建時。你可以通過以下方式設(shè)置 ?CHANGE-CAUSE? 消息：

使用 ?kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"? 為 Deployment 添加注解。
手動編輯資源的清單。

要查看修訂歷史的詳細(xì)信息，運(yùn)行：

kubectl rollout history deployment/nginx-deployment --revision=2

輸出類似于：

deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
  Containers:
   nginx:
    Image:      nginx:1.16.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      
  No volumes.

回滾到之前的修訂版本

按照下面給出的步驟將 Deployment 從當(dāng)前版本回滾到以前的版本（即版本 2）。

假定現(xiàn)在你已決定撤消當(dāng)前上線并回滾到以前的修訂版本：

kubectl rollout undo deployment/nginx-deployment

輸出類似于：

deployment.apps/nginx-deployment

或者，你也可以通過使用 --to-revision 來回滾到特定修訂版本：

kubectl rollout undo deployment/nginx-deployment --to-revision=2

輸出類似于：

deployment.apps/nginx-deployment

與回滾相關(guān)的指令的更詳細(xì)信息，請參考 kubectl rollout。

現(xiàn)在，Deployment 正在回滾到以前的穩(wěn)定版本。正如你所看到的，Deployment 控制器生成了回滾到修訂版本 2 的 ?DeploymentRollback ?事件。

檢查回滾是否成功以及 Deployment 是否正在運(yùn)行，運(yùn)行：

kubectl get deployment nginx-deployment

輸出類似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           30m

獲取 Deployment 描述信息：

kubectl describe deployment nginx-deployment

輸出類似于：

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=4
                        kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.16.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  
NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
Events:
  Type    Reason              Age   From                   Message
  ----    ------              ----  ----                   -------
  Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
  Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
  Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
  Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0

縮放 Deployment

你可以使用如下指令縮放 Deployment：

kubectl scale deployment/nginx-deployment --replicas=10

輸出類似于：

deployment.apps/nginx-deployment scaled

假設(shè)集群啟用了Pod 的水平自動縮放，你可以為 Deployment 設(shè)置自動縮放器，并基于現(xiàn)有 Pod 的 CPU 利用率選擇要運(yùn)行的 Pod 個數(shù)下限和上限。

kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80

輸出類似于：

deployment.apps/nginx-deployment scaled

比例縮放

RollingUpdate 的 Deployment 支持同時運(yùn)行應(yīng)用程序的多個版本。當(dāng)自動縮放器縮放處于上線進(jìn)程（仍在進(jìn)行中或暫停）中的 RollingUpdate Deployment 時， Deployment 控制器會平衡現(xiàn)有的活躍狀態(tài)的 ReplicaSets（含 Pods 的 ReplicaSets）中的額外副本，以降低風(fēng)險。這稱為比例縮放（Proportional Scaling）。

例如，你正在運(yùn)行一個 10 個副本的 Deployment，其 maxSurge=3，maxUnavailable=2。

確保 Deployment 的這 10 個副本都在運(yùn)行。

kubectl get deploy

輸出類似于：

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

更新 Deployment 使用新鏡像，碰巧該鏡像無法從集群內(nèi)部解析。

kubectl set image deployment/nginx-deployment nginx=nginx:sometag

輸出類似于：

deployment.apps/nginx-deployment image updated

鏡像更新使用 ReplicaSet ?nginx-deployment-1989198191? 啟動新的上線過程，但由于上面提到的 ?maxUnavailable ?要求，該進(jìn)程被阻塞了。檢查上線狀態(tài)：

kubectl get rs

輸出類似于：

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

然后，出現(xiàn)了新的 Deployment 擴(kuò)縮請求。自動縮放器將 Deployment 副本增加到 15。 Deployment 控制器需要決定在何處添加 5 個新副本。如果未使用比例縮放，所有 5 個副本都將添加到新的 ReplicaSet 中。使用比例縮放時，可以將額外的副本分布到所有 ReplicaSet。較大比例的副本會被添加到擁有最多副本的 ReplicaSet，而較低比例的副本會進(jìn)入到副本較少的 ReplicaSet。所有剩下的副本都會添加到副本最多的 ReplicaSet。具有零副本的 ReplicaSets 不會被擴(kuò)容。

在上面的示例中，3 個副本被添加到舊 ReplicaSet 中，2 個副本被添加到新 ReplicaSet。假定新的副本都很健康，上線過程最終應(yīng)將所有副本遷移到新的 ReplicaSet 中。要確認(rèn)這一點，請運(yùn)行：

kubectl get deploy

輸出類似于：

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m

上線狀態(tài)確認(rèn)了副本是如何被添加到每個 ReplicaSet 的。

kubectl get rs

輸出類似于：

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

暫停、恢復(fù) Deployment 的上線過程

在你更新一個 Deployment 的時候，或者計劃更新它的時候，你可以在觸發(fā)一個或多個更新之前暫停 Deployment 的上線過程。當(dāng)你準(zhǔn)備行應(yīng)用這些變更時，你可以重新恢復(fù) Deployment 上線過程。這樣做使得你能夠在暫停和恢復(fù)執(zhí)行之間應(yīng)用多個修補(bǔ)程序，而不會觸發(fā)不必要的上線操作。

例如，對于一個剛剛創(chuàng)建的 Deployment：

獲取該 Deployment 信息：

kubectl get deploy

輸出類似于：

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     3         3         3            3           1m

獲取上線狀態(tài)：

kubectl get rs

輸出類似于：

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         1m

使用如下指令暫停上線：

kubectl rollout pause deployment/nginx-deployment

輸出類似于：

deployment.apps/nginx-deployment paused

接下來更新 Deployment 鏡像：

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

輸出類似于：

deployment.apps/nginx-deployment image updated

注意沒有新的上線被觸發(fā)：

kubectl rollout history deployment/nginx-deployment

輸出類似于：

deployments "nginx"
REVISION  CHANGE-CAUSE
1

獲取上線狀態(tài)驗證現(xiàn)有的 ReplicaSet 沒有被更改：

kubectl get rs

輸出類似于：

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         2m

你可以根據(jù)需要執(zhí)行很多更新操作，例如，可以要使用的資源：

kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

輸出類似于：

deployment.apps/nginx-deployment resource requirements updated

暫停 Deployment 上線之前的初始狀態(tài)將繼續(xù)發(fā)揮作用，但新的更新在 Deployment 上線被暫停期間不會產(chǎn)生任何效果。

最終，恢復(fù) Deployment 上線并觀察新的 ReplicaSet 的創(chuàng)建過程，其中包含了所應(yīng)用的所有更新：

kubectl rollout resume deployment/nginx-deployment

輸出類似于這樣：

deployment.apps/nginx-deployment resumed

觀察上線的狀態(tài)，直到完成。

kubectl get rs -w

輸出類似于：

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   2         2         2         2m
nginx-3926361531   2         2         0         6s
nginx-3926361531   2         2         1         18s
nginx-2142116321   1         2         2         2m
nginx-2142116321   1         2         2         2m
nginx-3926361531   3         2         1         18s
nginx-3926361531   3         2         1         18s
nginx-2142116321   1         1         1         2m
nginx-3926361531   3         3         1         18s
nginx-3926361531   3         3         2         19s
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         20s

獲取最近上線的狀態(tài)：

kubectl get rs

輸出類似于：

NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         28s

你不可以回滾處于暫停狀態(tài)的 Deployment，除非先恢復(fù)其執(zhí)行狀態(tài)。

Deployment 狀態(tài)

Deployment 的生命周期中會有許多狀態(tài)。上線新的 ReplicaSet 期間可能處于 Progressing（進(jìn)行中），可能是 Complete（已完成），也可能是 Failed（失?。┮灾劣跓o法繼續(xù)進(jìn)行。

進(jìn)行中的 Deployment

執(zhí)行下面的任務(wù)期間，Kubernetes 標(biāo)記 Deployment 為進(jìn)行中（Progressing）：

Deployment 創(chuàng)建新的 ReplicaSet
Deployment 正在為其最新的 ReplicaSet 擴(kuò)容
Deployment 正在為其舊有的 ReplicaSet(s) 縮容
新的 Pods 已經(jīng)就緒或者可用（就緒至少持續(xù)了 MinReadySeconds 秒）。

當(dāng)上線過程進(jìn)入“Progressing”狀態(tài)時，Deployment 控制器會向 Deployment 的? .status.conditions? 中添加包含下面屬性的狀況條目：

?type: Progressing ?
?status: "True" ?
?reason: NewReplicaSetCreated? | ?reason: FoundNewReplicaSet? | ?reason: ReplicaSetUpdated?

你可以使用 ?kubectl rollout status? 監(jiān)視 Deployment 的進(jìn)度。

完成的 Deployment

當(dāng) Deployment 具有以下特征時，Kubernetes 將其標(biāo)記為完成（Complete）：

與 Deployment 關(guān)聯(lián)的所有副本都已更新到指定的最新版本，這意味著之前請求的所有更新都已完成。
與 Deployment 關(guān)聯(lián)的所有副本都可用。
未運(yùn)行 Deployment 的舊副本。

當(dāng)上線過程進(jìn)入“Complete”狀態(tài)時，Deployment 控制器會向 Deployment 的 ?.status.conditions? 中添加包含下面屬性的狀況條目：

?type: Progressing ?
?status: "True" ?
?reason: NewReplicaSetAvailable?

這一 ?Progressing ?狀況的狀態(tài)值會持續(xù)為 ?"True"?，直至新的上線動作被觸發(fā)。即使副本的可用狀態(tài)發(fā)生變化（進(jìn)而影響 ?Available ?狀況），?Progressing ?狀況的值也不會變化。

你可以使用 ?kubectl rollout status? 檢查 Deployment 是否已完成。如果上線成功完成，?kubectl rollout status? 返回退出代碼 0。

kubectl rollout status deployment/nginx-deployment

輸出類似于：

Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

從 ?kubectl rollout? 命令獲得的返回狀態(tài)為 0（成功）：

$ echo $?

失敗的 Deployment

你的 Deployment 可能會在嘗試部署其最新的 ReplicaSet 受挫，一直處于未完成狀態(tài)。造成此情況一些可能因素如下：

配額（Quota）不足
就緒探測（Readiness Probe）失敗
鏡像拉取錯誤
權(quán)限不足
限制范圍（Limit Ranges）問題
應(yīng)用程序運(yùn)行時的配置錯誤

檢測此狀況的一種方法是在 Deployment 規(guī)約中指定截止時間參數(shù)：（[?.spec.progressDeadlineSeconds?]（#progress-deadline-seconds））。 ?.spec.progressDeadlineSeconds? 給出的是一個秒數(shù)值，Deployment 控制器在（通過 Deployment 狀態(tài)）標(biāo)示 Deployment 進(jìn)展停滯之前，需要等待所給的時長。

以下 ?kubectl ?命令設(shè)置規(guī)約中的 ?progressDeadlineSeconds?，從而告知控制器在 10 分鐘后報告 Deployment 沒有進(jìn)展：

kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

輸出類似于：

deployment.apps/nginx-deployment patched

超過截止時間后，Deployment 控制器將添加具有以下屬性的 Deployment 狀況到 Deployment 的 ?.status.conditions? 中：

Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded

這一狀況也可能會比較早地失敗，因而其狀態(tài)值被設(shè)置為 ?"False"?，其原因為 ?ReplicaSetCreateError?。一旦 Deployment 上線完成，就不再考慮其期限。

參考 Kubernetes API Conventions 獲取更多狀態(tài)狀況相關(guān)的信息。

除了報告 ?Reason=ProgressDeadlineExceeded? 狀態(tài)之外，Kubernetes 對已停止的 Deployment 不執(zhí)行任何操作。更高級別的編排器可以利用這一設(shè)計并相應(yīng)地采取行動。例如，將 Deployment 回滾到其以前的版本。

如果你暫停了某個 Deployment 上線，Kubernetes 不再根據(jù)指定的截止時間檢查 Deployment 進(jìn)展。你可以在上線過程中間安全地暫停 Deployment 再恢復(fù)其執(zhí)行，這樣做不會導(dǎo)致超出最后時限的問題。

Deployment 可能會出現(xiàn)瞬時性的錯誤，可能因為設(shè)置的超時時間過短，也可能因為其他可認(rèn)為是臨時性的問題。例如，假定所遇到的問題是配額不足。如果描述 Deployment，你將會注意到以下部分：

kubectl describe deployment nginx-deployment

輸出類似于：

<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

如果運(yùn)行 ?kubectl get deployment nginx-deployment -o yaml?，Deployment 狀態(tài)輸出將類似于這樣：

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

最終，一旦超過 Deployment 進(jìn)度限期，Kubernetes 將更新狀態(tài)和進(jìn)度狀況的原因：

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

可以通過縮容 Deployment 或者縮容其他運(yùn)行狀態(tài)的控制器，或者直接在命名空間中增加配額來解決配額不足的問題。如果配額條件滿足，Deployment 控制器完成了 Deployment 上線操作， Deployment 狀態(tài)會更新為成功狀況（?Status=True? and ?Reason=NewReplicaSetAvailable?）。

Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable

?type: Available? 加上 ?status: True? 意味著 Deployment 具有最低可用性。最低可用性由 Deployment 策略中的參數(shù)指定。 ?type: Progressing? 加上 ?status: True? 表示 Deployment 處于上線過程中，并且正在運(yùn)行，或者已成功完成進(jìn)度，最小所需新副本處于可用。請參閱對應(yīng)狀況的 Reason 了解相關(guān)細(xì)節(jié)。在我們的案例中 ?reason: NewReplicaSetAvailable? 表示 Deployment 已完成。

你可以使用 ?kubectl rollout status? 檢查 Deployment 是否未能取得進(jìn)展。如果 Deployment 已超過進(jìn)度限期，?kubectl rollout status? 返回非零退出代碼。

kubectl rollout status deployment/nginx-deployment

輸出類似于：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline

?kubectl rollout? 命令的退出狀態(tài)為 1（表明發(fā)生了錯誤）：

$ echo $?

對失敗 Deployment 的操作

可應(yīng)用于已完成的 Deployment 的所有操作也適用于失敗的 Deployment。你可以對其執(zhí)行擴(kuò)縮容、回滾到以前的修訂版本等操作，或者在需要對 Deployment 的 Pod 模板應(yīng)用多項調(diào)整時，將 Deployment 暫停。

清理策略

你可以在 Deployment 中設(shè)置 ?.spec.revisionHistoryLimit? 字段以指定保留此 Deployment 的多少個舊有 ReplicaSet。其余的 ReplicaSet 將在后臺被垃圾回收。默認(rèn)情況下，此值為 10。

顯式將此字段設(shè)置為 0 將導(dǎo)致 Deployment 的所有歷史記錄被清空，因此 Deployment 將無法回滾。

金絲雀部署

如果要使用 Deployment 向用戶子集或服務(wù)器子集上線版本，則可以遵循資源管理所描述的金絲雀模式，創(chuàng)建多個 Deployment，每個版本一個。

編寫 Deployment 規(guī)約

同其他 Kubernetes 配置一樣， Deployment 需要 ?apiVersion?，?kind ?和 ?metadata ?字段。

Deployment 對象的名稱必須是合法的 DNS 子域名。 Deployment 還需要 ?.spec? 部分。

Pod 模板

?.spec? 中只有 ?.spec.template? 和 ?.spec.selector? 是必需的字段。

?.spec.template? 是一個 Pod 模板。它和 Pod 的語法規(guī)則完全相同。只是這里它是嵌套的，因此不需要 ?apiVersion ?或 ?kind?。

除了 Pod 的必填字段外，Deployment 中的 Pod 模板必須指定適當(dāng)?shù)臉?biāo)簽和適當(dāng)?shù)闹匦聠硬呗浴?nbsp;對于標(biāo)簽，請確保不要與其他控制器重疊。

只有 ?.spec.template.spec.restartPolicy? 等于 ?Always ?才是被允許的，這也是在沒有指定時的默認(rèn)設(shè)置。

副本

?.spec.replicas? 是指定所需 Pod 的可選字段。它的默認(rèn)值是1。

如果你對某個 Deployment 執(zhí)行了手動擴(kuò)縮操作（例如，通過 ?kubectl scale deployment deployment --replicas=X?），之后基于清單對 Deployment 執(zhí)行了更新操作（例如通過運(yùn)行 ?kubectl apply -f deployment.yaml?），那么通過應(yīng)用清單而完成的更新會覆蓋之前手動擴(kuò)縮所作的變更。

如果一個 HorizontalPodAutoscaler （或者其他執(zhí)行水平擴(kuò)縮操作的類似 API）在管理 Deployment 的擴(kuò)縮，則不要設(shè)置 ?.spec.replicas?。

恰恰相反，應(yīng)該允許 Kubernetes 控制面來自動管理 ?.spec.replicas? 字段。

選擇算符

?.spec.selector? 是指定本 Deployment 的 Pod 標(biāo)簽選擇算符的必需字段。

?.spec.selector? 必須匹配 ?.spec.template.metadata.labels?，否則請求會被 API 拒絕。

在 API ?apps/v1?版本中，?.spec.selector? 和 ?.metadata.labels? 如果沒有設(shè)置的話，不會被默認(rèn)設(shè)置為 ?.spec.template.metadata.labels?，所以需要明確進(jìn)行設(shè)置。同時在 ?apps/v1?版本中，Deployment 創(chuàng)建后 ?.spec.selector? 是不可變的。

當(dāng) Pod 的標(biāo)簽和選擇算符匹配，但其模板和 ?.spec.template? 不同時，或者此類 Pod 的總數(shù)超過 ?.spec.replicas? 的設(shè)置時，Deployment 會終結(jié)之。如果 Pods 總數(shù)未達(dá)到期望值，Deployment 會基于 ?.spec.template? 創(chuàng)建新的 Pod。

你不應(yīng)直接創(chuàng)建與此選擇算符匹配的 Pod，也不應(yīng)通過創(chuàng)建另一個 Deployment 或者類似于 ReplicaSet 或 ReplicationController 這類控制器來創(chuàng)建標(biāo)簽與此選擇算符匹配的 Pod。如果這樣做，第一個 Deployment 會認(rèn)為它創(chuàng)建了這些 Pod。 Kubernetes 不會阻止你這么做。

如果有多個控制器的選擇算符發(fā)生重疊，則控制器之間會因沖突而無法正常工作。

策略

?.spec.strategy? 策略指定用于用新 Pods 替換舊 Pods 的策略。 ?.spec.strategy.type? 可以是 “Recreate” 或 “RollingUpdate”?！癛ollingUpdate” 是默認(rèn)值。

重新創(chuàng)建 Deployment

如果 ?.spec.strategy.type==Recreate?，在創(chuàng)建新 Pods 之前，所有現(xiàn)有的 Pods 會被殺死。

這只會確保為了升級而創(chuàng)建新 Pod 之前其他 Pod 都已終止。如果你升級一個 Deployment，所有舊版本的 Pod 都會立即被終止。控制器等待這些 Pod 被成功移除之后，才會創(chuàng)建新版本的 Pod。如果你手動刪除一個 Pod，其生命周期是由 ReplicaSet 來控制的，后者會立即創(chuàng)建一個替換 Pod（即使舊的 Pod 仍然處于 Terminating 狀態(tài)）。如果你需要一種“最多 n 個”的 Pod 個數(shù)保證，你需要考慮使用 StatefulSet。

滾動更新 Deployment

Deployment 會在 ?.spec.strategy.type==RollingUpdate?時，采取滾動更新的方式更新 Pods。你可以指定 ?maxUnavailable ?和 ?maxSurge ?來控制滾動更新過程。

最大不可用

?.spec.strategy.rollingUpdate.maxUnavailable? 是一個可選字段，用來指定更新過程中不可用的 Pod 的個數(shù)上限。該值可以是絕對數(shù)字（例如，5），也可以是所需 Pods 的百分比（例如，10%）。百分比值會轉(zhuǎn)換成絕對數(shù)并去除小數(shù)部分。如果 ?.spec.strategy.rollingUpdate.maxSurge? 為 0，則此值不能為 0。默認(rèn)值為 25%。

例如，當(dāng)此值設(shè)置為 30% 時，滾動更新開始時會立即將舊 ReplicaSet 縮容到期望 Pod 個數(shù)的70%。新 Pod 準(zhǔn)備就緒后，可以繼續(xù)縮容舊有的 ReplicaSet，然后對新的 ReplicaSet 擴(kuò)容，確保在更新期間可用的 Pods 總數(shù)在任何時候都至少為所需的 Pod 個數(shù)的 70%。

最大峰值

?.spec.strategy.rollingUpdate.maxSurge? 是一個可選字段，用來指定可以創(chuàng)建的超出期望 Pod 個數(shù)的 Pod 數(shù)量。此值可以是絕對數(shù)（例如，5）或所需 Pods 的百分比（例如，10%）。如果 ?MaxUnavailable ?為 0，則此值不能為 0。百分比值會通過向上取整轉(zhuǎn)換為絕對數(shù)。此字段的默認(rèn)值為 25%。

例如，當(dāng)此值為 30% 時，啟動滾動更新后，會立即對新的 ReplicaSet 擴(kuò)容，同時保證新舊 Pod 的總數(shù)不超過所需 Pod 總數(shù)的 130%。一旦舊 Pods 被殺死，新的 ReplicaSet 可以進(jìn)一步擴(kuò)容，同時確保更新期間的任何時候運(yùn)行中的 Pods 總數(shù)最多為所需 Pods 總數(shù)的 130%。

進(jìn)度期限秒數(shù)

?.spec.progressDeadlineSeconds? 是一個可選字段，用于指定系統(tǒng)在報告 Deployment 進(jìn)展失敗之前等待 Deployment 取得進(jìn)展的秒數(shù)。這類報告會在資源狀態(tài)中體現(xiàn)為 ?type: Progressing?、?status: False?、 ?reason: ProgressDeadlineExceeded?。Deployment 控制器將持續(xù)重試 Deployment。將來，一旦實現(xiàn)了自動回滾，Deployment 控制器將在探測到這樣的條件時立即回滾 Deployment。

如果指定，則此字段值需要大于 ?.spec.minReadySeconds? 取值。

最短就緒時間

?.spec.minReadySeconds? 是一個可選字段，用于指定新創(chuàng)建的 Pod 在沒有任意容器崩潰情況下的最小就緒時間，只有超出這個時間 Pod 才被視為可用。默認(rèn)值為 0（Pod 在準(zhǔn)備就緒后立即將被視為可用）。要了解何時 Pod 被視為就緒，可參考容器探針。

修訂歷史限制

Deployment 的修訂歷史記錄存儲在它所控制的 ReplicaSets 中。

?.spec.revisionHistoryLimit? 是一個可選字段，用來設(shè)定出于會滾目的所要保留的舊 ReplicaSet 數(shù)量。這些舊 ReplicaSet 會消耗 etcd 中的資源，并占用 ?kubectl get rs? 的輸出。每個 Deployment 修訂版本的配置都存儲在其 ReplicaSets 中；因此，一旦刪除了舊的 ReplicaSet，將失去回滾到 Deployment 的對應(yīng)修訂版本的能力。默認(rèn)情況下，系統(tǒng)保留 10 個舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩(wěn)定性。

更具體地說，將此字段設(shè)置為 0 意味著將清理所有具有 0 個副本的舊 ReplicaSet。在這種情況下，無法撤消新的 Deployment 上線，因為它的修訂歷史被清除了。

paused（暫停的）

?.spec.paused? 是用于暫停和恢復(fù) Deployment 的可選布爾字段。暫停的 Deployment 和未暫停的 Deployment 的唯一區(qū)別是，Deployment 處于暫停狀態(tài)時， PodTemplateSpec 的任何修改都不會觸發(fā)新的上線。 Deployment 在創(chuàng)建時是默認(rèn)不會處于暫停狀態(tài)。

文章標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：KubernetesDeployments
網(wǎng)站鏈接：http://m.5511xx.com/article/dhpigpc.html

日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

新聞中心

Deployments

用例

創(chuàng)建 Deployment

Pod-template-hash 標(biāo)簽

更新 Deployment

翻轉(zhuǎn)（多 Deployment 動態(tài)更新）

更改標(biāo)簽選擇算符

回滾 Deployment

檢查 Deployment 上線歷史

回滾到之前的修訂版本

縮放 Deployment

比例縮放

暫停、恢復(fù) Deployment 的上線過程

Deployment 狀態(tài)

進(jìn)行中的 Deployment

完成的 Deployment

失敗的 Deployment

對失敗 Deployment 的操作

清理策略

金絲雀部署

編寫 Deployment 規(guī)約

Pod 模板

副本

選擇算符

策略

重新創(chuàng)建 Deployment

滾動更新 Deployment

最大不可用

最大峰值

進(jìn)度期限秒數(shù)

最短就緒時間

修訂歷史限制

paused（暫停的）

其他資訊

新聞中心

Deployments

用例

創(chuàng)建 Deployment

Pod-template-hash 標(biāo)簽

更新 Deployment

翻轉(zhuǎn)（多 Deployment 動態(tài)更新）

更改標(biāo)簽選擇算符

回滾 Deployment

檢查 Deployment 上線歷史

回滾到之前的修訂版本

縮放 Deployment

比例縮放

暫停、恢復(fù) Deployment 的上線過程

Deployment 狀態(tài)

進(jìn)行中的 Deployment

完成的 Deployment

失敗的 Deployment

對失敗 Deployment 的操作

清理策略

金絲雀部署

編寫 Deployment 規(guī)約

Pod 模板

副本

選擇算符

策略

重新創(chuàng)建 Deployment

滾動更新 Deployment

最大不可用

最大峰值

進(jìn)度期限秒數(shù)

最短就緒時間

修訂歷史限制

paused（暫停的）

其他資訊

暫停、恢復(fù) Deployment 的上線過程