Deployment 引入

前面我們學(xué)習(xí)了 RC 和 RS 兩種資源對(duì)象，它們的功能基本上是差不多的，唯一的區(qū)別就是 RS 支持集合的 selector。

另外，前面我們也了解了如何用 RC/RS 資源對(duì)象來控制 Pod 副本的數(shù)量，如何實(shí)現(xiàn)了滾動(dòng)升級(jí) Pod 的功能?，F(xiàn)在回過頭來看，似乎這些操作都比較完美了，但是在上一篇文章中最后也提到了：現(xiàn)在官方推薦我們使用 Deployment 這種控制器了，而不是前面所學(xué)的 RC 和 RS，大家知道原因嗎？

Deployment & RC 對(duì)比

沒有對(duì)比就沒有傷害，我們來看下它們之間有什么異同吧。首先 RC 是 Kubernetes 的一個(gè)核心概念，當(dāng)我們把應(yīng)用部署到集群之后，需要保證應(yīng)用能夠持續(xù)穩(wěn)定的運(yùn)行，RC 就是這個(gè)保證的關(guān)鍵，其主要功能如下：

• 維持 Pod 的數(shù)量：它會(huì)確保 Kubernetes 中有指定數(shù)量的 Pod 在運(yùn)行，如果少于指定數(shù)量的 Pod，RC 就會(huì)創(chuàng)建新的，反之這會(huì)刪除多余的，保證 Pod 的副本數(shù)量不變。
• 保證 Pod 健康：當(dāng) Pod 運(yùn)行出錯(cuò)了，無法提供正常服務(wù)時(shí)，RC 會(huì)殺死不健康的 Pod，然后重新創(chuàng)建新的。
• 可以彈性伸縮：在業(yè)務(wù)高峰或者低峰的時(shí)候，可以用過 RC 來動(dòng)態(tài)的調(diào)整 Pod 數(shù)量來提供資源的利用率，當(dāng)然我們也提到過如果使用 HPA 這種資源對(duì)象的話可以做到自動(dòng)伸縮。
• 滾動(dòng)升級(jí)：滾動(dòng)升級(jí)是一種平滑的升級(jí)方式，通過逐步替換的策略，保證整體系統(tǒng)的穩(wěn)定性，這個(gè)前面我們也已經(jīng)講過了。

Deployment 同樣也是 Kubernetes 系統(tǒng)的一個(gè)核心概念，主要職責(zé)和 RC 一樣，都是確保 Pod 的數(shù)量和健康，二者大部分功能都是完全一致的，我們可以看成是一個(gè)升級(jí)版的 RC 控制器，那 Deployment 除了和 RC 一樣的功能外，又具備有哪些其它新特性呢？

• 事件和狀態(tài)查看：可以查看 Deployment 的升級(jí)詳細(xì)進(jìn)度和狀態(tài)
• 回滾操作：當(dāng)升級(jí) Pod 的時(shí)候如果出現(xiàn)問題，可以使用回滾操作回滾到之前的任一版本
• 版本記錄：每一次對(duì) Deployment 的操作，都能夠保存下來，這也是保證可以回滾到任一版本的基礎(chǔ)

作為對(duì)比，我們知道 Deployment 作為新一代的 RC，不僅在功能上更為豐富了，同時(shí)我們也說過現(xiàn)在官方也都是推薦使用 Deployment 來管理 Pod 的，比如一些官方組件 kube-dns、kube-proxy 也都是使用的 Deployment 來管理的，所以當(dāng)大家在使用的使用也最好使用 Deployment 來管理 Pod。

Deployment 創(chuàng)建

其實(shí)一個(gè) Deployment 資源控制器擁有多個(gè) Replica Set，而一個(gè) Replica Set 擁有一個(gè)或多個(gè) Pod。一個(gè) Deployment 可以控制多個(gè) rs 主要是為了支持回滾機(jī)制。每當(dāng) Deployment 操作時(shí)，Kubernetes 會(huì)重新生成一個(gè) Replica Set 并保留，以后有需要的話就可以回滾至之前的狀態(tài)。

下面創(chuàng)建一個(gè) Deployment，它創(chuàng)建了一個(gè) Replica Set 來啟動(dòng) 3 個(gè) nginx pod，yaml 文件如下：

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

將上面內(nèi)容保存為: nginx-deployment.yaml，執(zhí)行命令:

$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deploy" created

然后執(zhí)行一下命令查看剛剛創(chuàng)建的 Deployment:

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         0         0            0           1s

隔一會(huì)再次執(zhí)行上面命令：

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         3         3            3           4m

我們可以看到 Deployment 已經(jīng)創(chuàng)建了 1 個(gè) Replica Set 了，執(zhí)行下面的命令查看 rs 和 pod:

$ kubectl get rs
NAME                     DESIRED   CURRENT   READY     AGE
nginx-deploy-431080110   3         3         3         6m

$ kubectl get pod --show-labels
NAME                           READY     STATUS    RESTARTS   AGE       LABELS
nginx-deploy-431080110-53z8q   1/1       Running   0          7m        app=nginx,pod-template-hash=431080110
nginx-deploy-431080110-bhhq0   1/1       Running   0          7m        app=nginx,pod-template-hash=431080110
nginx-deploy-431080110-sr44p   1/1       Running   0          7m        app=nginx,pod-template-hash=431080110

上面的 Deployment 的 yaml 文件中的 replicas:3 將會(huì)保證我們始終有 3 個(gè) POD 在運(yùn)行。

由于 Deployment 和 RC 的功能大部分都一樣的，我們上節(jié)課已經(jīng)和大家演示了大部分功能了，我們這里重點(diǎn)給大家演示下 Deployment 的滾動(dòng)升級(jí)和回滾功能。

Deployment 滾動(dòng)升級(jí)

現(xiàn)在我們將剛剛保存的 yaml 文件中的 nginx 鏡像修改為 nginx:1.12.1，然后在 spec 下面添加滾動(dòng)升級(jí)策略：

minReadySeconds: 5
strategy:
  # indicate which strategy we want for rolling update
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds:

  • Kubernetes 在等待設(shè)置的時(shí)間后才進(jìn)行升級(jí)
  • 如果沒有設(shè)置該值，Kubernetes 會(huì)假設(shè)該容器啟動(dòng)起來后就提供服務(wù)了
  • 如果沒有設(shè)置該值，在某些極端情況下可能會(huì)造成服務(wù)不正常運(yùn)行

• maxSurge:

  • 升級(jí)過程中最多可以比原先設(shè)置多出的 POD 數(shù)量
  • 例如：maxSurage=1，replicas=5,則表示 Kubernetes 會(huì)先啟動(dòng) 1 一個(gè)新的 Pod 后才刪掉一個(gè)舊的 POD，整個(gè)升級(jí)過程中最多會(huì)有 5+1 個(gè) POD。

• maxUnavaible:

  • 升級(jí)過程中最多有多少個(gè) POD 處于無法提供服務(wù)的狀態(tài)
  • 當(dāng) maxSurge 不為 0 時(shí)，該值也不能為 0
  • 例如：maxUnavaible=1，則表示 Kubernetes 整個(gè)升級(jí)過程中最多會(huì)有 1 個(gè) POD 處于無法服務(wù)的狀態(tài)。

然后執(zhí)行命令：

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured

然后我們可以使用 rollout 命令查看狀態(tài)：

$ kubectl rollout status deployment/nginx-deploy
Waiting for rollout to finish: 1 out of 3 new replicas have been updated..
deployment "nginx-deploy" successfully rolled out

升級(jí)結(jié)束后，繼續(xù)查看 rs 的狀態(tài)：

$ kubectl get rs
NAME                      DESIRED   CURRENT   READY     AGE
nginx-deploy-2078889897   0         0         0         47m
nginx-deploy-3297445372   3         3         3         42m
nginx-deploy-431080110    0         0         0         1h

根據(jù) AGE 我們可以看到離我們最近的當(dāng)前狀態(tài)是：3，和我們的 yaml 文件是一致的，證明升級(jí)成功了。用 describe 命令可以查看升級(jí)的全部信息：

Name:     nginx-deploy
Namespace:    default
CreationTimestamp:  Wed, 18 Oct 2017 16:58:52 +0800
Labels:     k8s-app=nginx-demo
Annotations:    deployment.kubernetes.io/revision=3
      kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa...
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.12.1
    Port:   80/TCP
    Environment:  <none>
    Mounts:   <none>
  Volumes:    <none>
Conditions:
  Type    Status  Reason
  ----    ------  ------
  Progressing   True  NewReplicaSetAvailable
  Available   True  MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet:  nginx-deploy-3297445372 (3/3 replicas created)
...

Deployment 回滾

我們已經(jīng)能夠滾動(dòng)平滑的升級(jí)我們的 Deployment 了，但是如果升級(jí)后的 POD 出了問題該怎么辦？我們能夠想到的最好最快的方式當(dāng)然是回退到上一次能夠提供正常工作的版本，Deployment 就為我們提供了回滾機(jī)制。

首先，查看 Deployment 的升級(jí)歷史：

$ kubectl rollout history deployment nginx-deploy
deployments "nginx-deploy"
REVISION  CHANGE-CAUSE
1   <none>
2   <none>
3   kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true

從上面的結(jié)果可以看出在執(zhí)行 Deployment 升級(jí)的時(shí)候最好帶上 record 參數(shù)，便于我們查看歷史版本信息。

默認(rèn)情況下，所有通過 kubectl xxxx --record 都會(huì)被 kubernetes 記錄到 etcd 進(jìn)行持久化，這無疑會(huì)占用資源，最重要的是，時(shí)間久了，當(dāng)你 kubectl get rs 時(shí)，會(huì)有成百上千的垃圾 RS 返回給你，那時(shí)你可能就眼花繚亂了。

如果是在生產(chǎn)，我們最好通過設(shè)置 Deployment 的.spec.revisionHistoryLimit 來限制最大保留的 revision number，比如 10 個(gè)版本，回滾的時(shí)候一般只會(huì)回滾到最近的幾個(gè)版本就足夠了。其實(shí) rollout history 中記錄的 revision 都和 ReplicaSets 一一對(duì)應(yīng)。如果手動(dòng) delete 某個(gè) ReplicaSet，對(duì)應(yīng)的 rollout history 就會(huì)被刪除，也就是還說你無法回滾到這個(gè) revison 了。

同樣我們可以使用下面的命令查看單個(gè) revison 的信息：

$ kubectl rollout history deployment nginx-deploy --revision=3
deployments "nginx-deploy" with revision #3
Pod Template:
  Labels: app=nginx
  pod-template-hash=3297445372
  Annotations:  kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true
  Containers:
   nginx:
    Image:  nginx:1.12.1
    Port: 80/TCP
    Environment:  <none>
    Mounts: <none>
  Volumes:  <none>

假如現(xiàn)在要直接回退到當(dāng)前版本的前一個(gè)版本：

$ kubectl rollout undo deployment nginx-deploy
deployment "nginx-deploy" rolled back

當(dāng)然也可以用 revision 回退到指定的版本：

$ kubectl rollout undo deployment nginx-deploy --to-revision=2
deployment "nginx-deploy" rolled back

Deployment 擴(kuò)容

也可以使用以下命令擴(kuò)容 Deployment：

$ kubectl scale deployment nginx-deploy --replicas 10
deployment "nginx-deployment" scaled

總結(jié)

最后我們總結(jié)下關(guān)于 Deployment 的一些特性和作用吧：

• 具備 RC 的功能：Deployment 具備 RC 的全部功能
• 事件和狀態(tài)查看：可以查看 Deployment 的升級(jí)詳細(xì)進(jìn)度和狀態(tài)，即可以隨時(shí)知道 Pod 的部署進(jìn)度
• 滾動(dòng)升級(jí)和回滾：可滾動(dòng)升級(jí) pod，但當(dāng)升級(jí) Pod 的時(shí)候如果出現(xiàn)問題，也可以使用回滾操作回滾到之前的任一版本
• 版本記錄：每一次對(duì) Deployment 的操作，都能夠保存下來，這也是保證可以回滾到任一版本的基礎(chǔ)

后續(xù)會(huì)給大家介紹另外一種更加高級(jí)且可自動(dòng)擴(kuò)縮容 Pod 的資源對(duì)象 HPA。

以上就是k8s 還有更高級(jí)的"對(duì)象"？它叫 Deployment的詳細(xì)內(nèi)容，更多關(guān)于k8s 對(duì)象Deployment的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！