【云原生】Kubernetes中deployment是什么？

這篇具有很好參考價(jià)值的文章主要介紹了【云原生】Kubernetes中deployment是什么？。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請(qǐng)大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-628405.html

【云原生】Kubernetes中deployment是什么？,kubernetes,云原生,kubernetes,容器

Deployments

更新 Deployment

回滾 Deployment

縮放 Deployment

Deployment 狀態(tài)

清理策略

金絲雀部署

編寫 Deployment 規(guī)約

Deployments

一個(gè) Deployment 為?Pod?和?ReplicaSet?提供聲明式的更新能力。

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

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。該名稱將成為后續(xù)創(chuàng)建 ReplicaSet 和 Pod 的命名基礎(chǔ)。參閱編寫 Deployment 規(guī)約獲取更多詳細(xì)信息。
該 Deployment 創(chuàng)建一個(gè) ReplicaSet，它創(chuàng)建三個(gè)（由?.spec.replicas?字段標(biāo)明）Pod 副本。
.spec.selector?字段定義所創(chuàng)建的 ReplicaSet 如何查找要管理的 Pod。在這里，你選擇在 Pod 模板中定義的標(biāo)簽（app: nginx）。不過，更復(fù)雜的選擇規(guī)則是也可能的，只要 Pod 模板本身滿足所給規(guī)則即可。
說明：
.spec.selector.matchLabels?字段是?{key,value}?鍵值對(duì)映射。在?matchLabels?映射中的每個(gè)?{key,value}?映射等效于?matchExpressions?中的一個(gè)元素，即其?key?字段是 “key”，operator?為 “In”，values?數(shù)組僅包含 “value”。在?matchLabels?和?matchExpressions?中給出的所有條件都必須滿足才能匹配。

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

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

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

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

2.運(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

3.在檢查集群中的 Deployment 時(shí)，所顯示的字段有：

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

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

4.要查看 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

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

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

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

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

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

7.ReplicaSet 輸出中包含以下字段：

注意 ReplicaSet 的名稱格式始終為?[Deployment 名稱]-[哈希]。該名稱將成為所創(chuàng)建的 Pod 的命名基礎(chǔ)。其中的哈希字符串與 ReplicaSet 上的?pod-template-hash?標(biāo)簽一致。

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

8.要查看每個(gè) Pod 自動(dòng)生成的標(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=75675f5897
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897

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

說明：

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

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

注意：

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

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

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

更新 Deployment

說明：

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

按照以下步驟更新 Deployment：

1.先來(lái)更新 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?表明 Deployment 的名稱，nginx?表明需要進(jìn)行更新的容器，而?nginx:1.16.1?則表示鏡像的新版本以及它的標(biāo)簽。

????????輸出類似于：

deployment.apps/nginx-deployment image updated

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

kubectl edit deployment/nginx-deployment

????????輸出類似于：

deployment.apps/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?來(lái)查看 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 個(gè)副本并將舊 ReplicaSet 縮容到 0 個(gè)副本完成了 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)僅顯示新的 Pod：
```
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
```
下次要更新這些 Pod 時(shí)，只需再次更新 Deployment Pod 模板即可。

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

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

例如，如果仔細(xì)查看上述 Deployment ，將看到它首先創(chuàng)建了一個(gè)新的 Pod，然后刪除舊的 Pod，并創(chuàng)建了新的 Pod。它不會(huì)殺死舊 Pod，直到有足夠數(shù)量的新 Pod 已經(jīng)出現(xiàn)。在足夠數(shù)量的舊 Pod 被殺死前并沒有創(chuàng)建新 Pod。它確保至少 3 個(gè) Pod 可用，同時(shí)最多總共 4 個(gè) Pod 可用。當(dāng) Deployment 設(shè)置為 4 個(gè)副本時(shí)，Pod 的個(gè)數(shù)會(huì)介于 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:  <none>
      Mounts:       <none>
    Volumes:        <none>
  Conditions:
    Type           Status  Reason
    ----           ------  ------
    Available      True    MinimumReplicasAvailable
    Progressing    True    NewReplicaSetAvailable
  OldReplicaSets:  <none>
  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 時(shí)，它創(chuàng)建了一個(gè) ReplicaSet（nginx-deployment-2035384211）并將其直接擴(kuò)容至 3 個(gè)副本。更新 Deployment 時(shí)，它創(chuàng)建了一個(gè)新的 ReplicaSet （nginx-deployment-1564180365），并將其擴(kuò)容為 1，等待其就緒；然后將舊 ReplicaSet 縮容到 2，將新的 ReplicaSet 擴(kuò)容到 2 以便至少有 3 個(gè) Pod 可用且最多創(chuàng)建 4 個(gè) Pod。然后，它使用相同的滾動(dòng)更新策略繼續(xù)對(duì)新的 ReplicaSet 擴(kuò)容并對(duì)舊的 ReplicaSet 縮容。最后，你將有 3 個(gè)可用的副本在新的 ReplicaSet 中，舊 ReplicaSet 將縮容到 0。

說明：

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

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

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

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

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

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

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

說明：

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

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

回滾 Deployment

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

說明：

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

假設(shè)你在更新 Deployment 時(shí)犯了一個(gè)拼寫錯(cuò)誤，將鏡像名稱命名設(shè)置為?nginx:1.161?而不是?nginx:1.16.1：
```
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
輸出類似于：
```
deployment.apps/nginx-deployment image updated
```

此上線進(jìn)程會(huì)出現(xiàn)停滯。你可以通過檢查上線狀態(tài)來(lái)驗(yàn)證：
```
kubectl rollout status deployment/nginx-deployment
```
輸出類似于：
```
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
```

按 Ctrl-C 停止上述上線狀態(tài)觀測(cè)。有關(guān)上線停滯的詳細(xì)信息，參考這里。

你可以看到舊的副本有兩個(gè)（nginx-deployment-1564180365?和?nginx-deployment-2035384211），新的副本有 1 個(gè)（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，你會(huì)注意到新 ReplicaSet 所創(chuàng)建的 1 個(gè) 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 控制器自動(dòng)停止有問題的上線過程，并停止對(duì)新的 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.161
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
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 上線歷史

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

????????首先，檢查 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ù)制過來(lái)的。復(fù)制動(dòng)作發(fā)生在修訂版本創(chuàng)建時(shí)。你可以通過以下方式設(shè)置?CHANGE-CAUSE?消息：

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

2.要查看修訂歷史的詳細(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:      <none>
  No volumes.

回滾到之前的修訂版本

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

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

kubectl rollout undo deployment/nginx-deployment

????????輸出類似于：

deployment.apps/nginx-deployment rolled back

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

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

????????輸出類似于：

deployment.apps/nginx-deployment rolled back

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

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

2.檢查回滾是否成功以及 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:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
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è)集群?jiǎn)⒂昧薖od 的水平自動(dòng)縮放，你可以為 Deployment 設(shè)置自動(dòng)縮放器，并基于現(xiàn)有 Pod 的 CPU 利用率選擇要運(yùn)行的 Pod 個(gè)數(shù)下限和上限。

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

輸出類似于：

deployment.apps/nginx-deployment scaled

比例縮放

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

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

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

kubectl get deploy

輸出類似于：

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

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

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

輸出類似于：

deployment.apps/nginx-deployment image updated

鏡像更新使用 ReplicaSet?nginx-deployment-1989198191?啟動(dòng)新的上線過程，但由于上面提到的?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ò)縮請(qǐng)求。自動(dòng)縮放器將 Deployment 副本增加到 15。 Deployment 控制器需要決定在何處添加 5 個(gè)新副本。如果未使用比例縮放，所有 5 個(gè)副本都將添加到新的 ReplicaSet 中。使用比例縮放時(shí)，可以將額外的副本分布到所有 ReplicaSet。較大比例的副本會(huì)被添加到擁有最多副本的 ReplicaSet，而較低比例的副本會(huì)進(jìn)入到副本較少的 ReplicaSet。所有剩下的副本都會(huì)添加到副本最多的 ReplicaSet。具有零副本的 ReplicaSets 不會(huì)被擴(kuò)容。

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

kubectl get deploy

輸出類似于：

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

上線狀態(tài)確認(rèn)了副本是如何被添加到每個(gè) 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 的上線過程

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

例如，對(duì)于一個(gè)剛剛創(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

接下來(lái)更新 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   <none>

獲取上線狀態(tài)驗(yàn)證現(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 上線被暫停期間不會(huì)產(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 的生命周期中會(huì)有許多狀態(tài)。上線新的 ReplicaSet 期間可能處于?Progressing（進(jìn)行中），可能是?Complete（已完成），也可能是?Failed（失?。┮灾劣跓o(wú)法繼續(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) 縮容
新的 Pod 已經(jīng)就緒或者可用（就緒至少持續(xù)了?MinReadySeconds?秒）。

當(dāng)上線過程進(jìn)入“Progressing”狀態(tài)時(shí)，Deployment 控制器會(huì)向 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 具有以下特征時(shí)，Kubernetes 將其標(biāo)記為完成（Complete）;

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

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

type: Progressing
status: "True"
reason: NewReplicaSetAvailable

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

你可以使用?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 可能會(huì)在嘗試部署其最新的 ReplicaSet 受挫，一直處于未完成狀態(tài)。造成此情況一些可能因素如下：

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

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

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

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

輸出類似于：

deployment.apps/nginx-deployment patched

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

type: Progressing
status: "False"
reason: ProgressDeadlineExceeded

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

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

說明：

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

說明：

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

Deployment 可能會(huì)出現(xiàn)瞬時(shí)性的錯(cuò)誤，可能因?yàn)樵O(shè)置的超時(shí)時(shí)間過短，也可能因?yàn)槠渌烧J(rèn)為是臨時(shí)性的問題。例如，假定所遇到的問題是配額不足。如果描述 Deployment，你將會(huì)注意到以下部分：

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)的控制器，或者直接在命名空間中增加配額來(lái)解決配額不足的問題。如果配額條件滿足，Deployment 控制器完成了 Deployment 上線操作， Deployment 狀態(tài)會(huì)更新為成功狀況（Status=True?和?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)度，最小所需新副本處于可用。請(qǐng)參閱對(duì)應(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ā)生了錯(cuò)誤）：

echo $?

對(duì)失敗 Deployment 的操作

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

清理策略

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

說明：

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

金絲雀部署

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

編寫 Deployment 規(guī)約

同其他 Kubernetes 配置一樣， Deployment 需要?.apiVersion，.kind?和?.metadata?字段。有關(guān)配置文件的其他信息，請(qǐng)參考部署 Deployment、配置容器和使用 kubectl 管理資源等相關(guān)文檔。

當(dāng)控制面為 Deployment 創(chuàng)建新的 Pod 時(shí)，Deployment 的?.metadata.name?是命名這些 Pod 的部分基礎(chǔ)。 Deployment 的名稱必須是一個(gè)合法的?DNS 子域值，但這會(huì)對(duì) Pod 的主機(jī)名產(chǎn)生意外的結(jié)果。為獲得最佳兼容性，名稱應(yīng)遵循更嚴(yán)格的?DNS 標(biāo)簽規(guī)則。

Deployment 還需要?.spec?部分。

Pod 模板

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

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

除了 Pod 的必填字段外，Deployment 中的 Pod 模板必須指定適當(dāng)?shù)臉?biāo)簽和適當(dāng)?shù)闹匦聠?dòng)策略。對(duì)于標(biāo)簽，請(qǐng)確保不要與其他控制器重疊。請(qǐng)參考選擇算符。

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

副本

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

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

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

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

選擇算符

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

.spec.selector?必須匹配?.spec.template.metadata.labels，否則請(qǐng)求會(huì)被 API 拒絕。

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

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

說明：

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

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

策略

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

重新創(chuàng)建 Deployment

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

說明：

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

滾動(dòng)更新 Deployment

Deployment 會(huì)在?.spec.strategy.type==RollingUpdate時(shí)，采取滾動(dòng)更新的方式更新 Pod。你可以指定?maxUnavailable?和?maxSurge?來(lái)控制滾動(dòng)更新過程。

最大不可用

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

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

最大峰值

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

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

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

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

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

最短就緒時(shí)間

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

修訂歷史限制

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

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

更具體地說，將此字段設(shè)置為 0 意味著將清理所有具有 0 個(gè)副本的舊 ReplicaSet。在這種情況下，無(wú)法撤消新的 Deployment 上線，因?yàn)樗男抻啔v史被清除了。

paused（暫停的）

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

到了這里，關(guān)于【云原生】Kubernetes中deployment是什么？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！

国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

Toy模板網(wǎng)

【云原生】Kubernetes中deployment是什么？

Deployments

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

更新 Deployment

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

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

回滾 Deployment

檢查 Deployment 上線歷史

回滾到之前的修訂版本

縮放 Deployment

比例縮放

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

Deployment 狀態(tài)

進(jìn)行中的 Deployment

完成的 Deployment

失敗的 Deployment

對(duì)失敗 Deployment 的操作

清理策略

金絲雀部署

編寫 Deployment 規(guī)約

Pod 模板

副本

選擇算符

策略

重新創(chuàng)建 Deployment

滾動(dòng)更新 Deployment

最大不可用

最大峰值

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

最短就緒時(shí)間

修訂歷史限制

paused（暫停的）

覺得文章有用就打賞一下文章作者

支付寶掃一掃打賞

微信掃一掃打賞

支付寶掃一掃領(lǐng)取紅包，優(yōu)惠每天領(lǐng)

二維碼1

二維碼2

【云原生】Kubernetes中deployment是什么？

Deployments

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

更新 Deployment

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

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

回滾 Deployment

檢查 Deployment 上線歷史

回滾到之前的修訂版本

縮放 Deployment

比例縮放

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

Deployment 狀態(tài)

進(jìn)行中的 Deployment

完成的 Deployment

失敗的 Deployment

對(duì)失敗 Deployment 的操作

清理策略

金絲雀部署

編寫 Deployment 規(guī)約

Pod 模板

副本

選擇算符

策略

重新創(chuàng)建 Deployment

滾動(dòng)更新 Deployment

最大不可用

最大峰值

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

最短就緒時(shí)間

修訂歷史限制

paused（暫停的）

相關(guān)文章

覺得文章有用就打賞一下文章作者

支付寶掃一掃打賞

微信掃一掃打賞

支付寶掃一掃領(lǐng)取紅包，優(yōu)惠每天領(lǐng)

二維碼1

二維碼2

【云原生】Kubernetes中deployment是什么？

支付寶掃一掃領(lǐng)取紅包，優(yōu)惠每天領(lǐng)