前言

昨天的文章介紹了 Deployment 以及 ReplicaSet 的基本介紹後，接下來要介紹如何撰寫以及建立，廢話不多說馬上開始 Deployment 系列文的第二篇吧！

Deployment 結合 ReplicaSet 寫法

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  replica: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 60
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: helloworld
        image: w5151381guy/helloworld
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 8080

看到 Deployment 的設定是不是覺得跟之前文章提到的 Replication Controller 非常接近呢？其實 Deployment 只多了幾個在滾動更新的設定以及加上 ReplicaSet 的設定而已，這邊就稍微講一下這幾個設定值吧！

首先可以看到這次的 apiVersion 的值不是 v1 而是 apps/v1 了，由於 K8s 針對 Deployment、RollingUpdate、ReplicaSet 等等設立了新的 apiVersion 值，通常 apps/v1 都是用來設定跟應用程式有關的架設，所以在 Deployment 這邊記得要用 apps/v1 而不是 v1 喔！

在 spec 的地方有看到 strategy 這個新的設定值，這個主要是用來設定 Deployment 更新的策略，這裡的 strategy.type 有兩種設定：

• RollingUpdate

  預設值，先建立新的 ReplicaSet 並控制新內容的 Pod ，待新 Pod 也可以正常運作，才會通知 ReplicaSet 將現有的 Pod 移除，由於過程中會有新舊兩種 Pod 同時上線，因此會有一段時間是新舊內容會隨機出現的情形發生。

  這邊可以看到除了 type 之外還寫了 maxSurge 以及 maxUnavailable，這兩個設定值為滾動更新的過程中，接下來就來講一下這兩個設定主要的功能！

  • maxSurge：代表 ReplicaSet 可以產生比 Deployment 設定檔中的 replica 所設定數量還多幾個出來，多增加 Pod 的好處為在滾動更新的過程可以減少舊內容顯示在頁面上的機率。
  • maxUnavailable：代表在滾動更新的過程中，可以允許多少的 Pod 無法使用，假如 maxSurge 設定非 0 ，maxUnavailable 也要設定非 0。

• Recreate

  先通知當前 ReplicaSet 把砍掉舊有的 Pod 後再產生新的 ReplicaSet 並控制新內容的 Pod ，由於先砍掉 Pod 才建立新的 Pod ，所以中間會有一段伺服器無法連線的時間。

  也因為 Recreate 會砍掉重建，因此 Recreate 就無法像 RollingUpdate 設定 maxSurge 以及 maxUnavailable。

講完 Deployment 的更新流程設定後，接下來講 Deployment 完成更新後的設定，這邊有兩種設定： minReadySeconds 以及 revisionHistoryLimit。

• minReadySeconds

  minReadySeconds 代表當新的 Pod 建立好並且在運行的 container 並沒有 crash 的情況下，最少需要多久時間可以開始接受 Request ，預設為 0 秒代表當 Pod 一被建立起來就可以開始接受 Request ，假如今天 container 在剛運行的時候需要花時間做初始化，這時候就可以利用 minReadySeconds 讓此 Pod 不會馬上接受到 Request，這個為選填的設定。

• revisionHistoryLimit

  每次 Deployment 在進行更新的時候都會產生一個新的 ReplicaSet 用來進行版本控制，在 Deployment 中這個專有名詞叫 revision，所以這個設定就是要設定最多只會有多少個 revision，這個為選填的設定。

建立 Deployment

建立 Deployment 一樣也是用 apply 這個參數建立。

建立完後一樣可以下 get 參數來查看。

由於 Deployment 直接管理 ReplicaSet ，因此我們也可以查看 ReplicaSet 是否有被建立起來，這邊讀者可以看到每個 ReplicaSet 後方都有一小段 hash ，這邊是 Deployment 在建立 ReplicaSet 的時候加進去的，這樣之後就可以很方便地利用 ReplicaSet 進行 rollback 的動作。

由於 ReplicaSet 會直接管理 Pod 因此我們也可以查看 Pod 是否有正確的被建立到正確的數量。

一樣可以試試看刪除 Pod 看 ReplicaSet 是否有正確的重新建立一個新的 Pod 以符合我們設定好的數量。

建立好的 Deployment 一樣可以在瀏覽器測試 Hello World 是否有正確的顯示出來。

最後想要把整個 Pod 以及 ReplicaSet 刪除的話就直接把 Deployment 刪除即可。

小結

今天介紹了 Deployment 是如何撰寫以及建立，感覺上 Deployment 可以做到非常多事情了，但其實筆者一直沒有談到 Deployment 是如何更新旗下的 Pod。

接下來就是 Deployment 系列文的最後一篇了，如果對於文章有任何問題都歡迎留言給我，那我們就下篇文章見嘍～