ReplicaSet 保證了 pod 的運行數，接下來該考慮管理了 ( ´ ▽ ` )ﾉ

上系統當然不是 deploy 完就沒事了，還要做維護啊～

Kubernetes 的 Deployment 就是用來管理服務的。
它的職責包含了部署一組 Pod 和定義該如何管理這些應用程式。

部署？那不就跟 ReplicaSet 重複了嗎？

不會的～
在 Kubernetes 的架構裡，ReplicaSet 是屬於 Deployment 的下層管理元件。

官方建議

當使用 Deployment 管理服務時，就不要再對 ReplicaSet 執行任何操作囉！

Deployment 和 ReplicaSet 的關係：

先檢視一下建立 Deployment 的 yaml file：

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

基本格式與 ReplicaSet 幾乎相同，參數設定中的 replicas 會自動去建立 ReplicaSet 物件，再由 ReplicaSet 根據設定數量去建立 Pod。

其他參數晚點再說，總之立刻來實作看看！

記得先開啟 minikube (先假設大家測試完都有好好關掉)

minikube start

建立 yaml 檔案，內容和上面的一模一樣就不另外寫了。
要注意的是 labels 的設定。
在 Kubernetes 中，標籤（labels）是用來識別元件的重要參數，由於 Deployment 和 ReplicaSet 都是使用 matchLabels 設定的條件去識別所屬 Pod，故在 Pod 的設定中（就是 template 底下的 label 設定），一定要確認有可以對應到的 label 喔！

官方建議

在 label 的使用上請特別注意，不要讓 Selector 或任何管理元件的設定重疊。
Kubernetes 並沒有禁止這樣的設定，但如果多個元件選擇到相同的 Pod，可能會發生衝突並出現例外行為。

另外：

Deployment 的 label selector 設定在建立後就不可更動了，請謹慎使用。

(至少目前的版本 apiVersion: apps/v1 是這樣)

執行看看：

# 使用 yaml file 建立元件
kubectl create -f <yaml file>

建立完成之後檢視元件內容：

# 取得 Deployment 清單
kubectl get deployments
kubectl get deployments -o wide

順利在 Cluster 中建立出三個 nginx pod 啦！
不止這樣，還自動建立出了對應的 ReplicaSet (rs)。

再來確認Deployment內容：

kubectl describe deployment <deployment-name>

怎麼好像比 yaml file 中多了不少設定值？！

既然是管理元件，當然少不了設定管理策略。
create 使用的 yaml file 是最簡易的版本，相關的策略設定 Kubernetes 就直接帶入預設值了。
Deployment 的管理策略，是從 StrategyType 參數設定的。

StrategyType

StrategyType 決定了服務更新的方式，即新版本的 Pod 如何替換舊版本。
Kubernetes 提供了兩種主要的更新策略：

RollingUpdate(預設)

RollingUpdate 會逐步替換舊的 Pod，並保證在更新過程中服務保持可用。
採用 RollingUpdate 策略時，每次只會替換一部分的 Pod，以確保有足夠的舊 Pod 繼續處理流量，直到所有新 Pod 都被成功啟動並替換掉舊的 Pod。

相關參數：

• minReadySeconds：預留給服務的啟動時間
  如果沒有設定，Kubernetes 會在 Pod 啟動後立刻執行替換。
  若是 Container 中有需要花時間預先執行的工作，又沒有設定 minReadySeconds，可能會對服務造成影響喔！
• maxSurge：定義最多可以有多少個額外的 Pod 運行，用以應對外部流量。
  可以設為數字（Pod 數量）或百分比（總副本數的百分比）。
• maxUnavailable：定義更新過程中最多有多少個不可用的 Pod。
  同maxSurge，可以設為數字（Pod 數量）或百分比（總副本數的百分比）。

• maxSurge 和 maxUnavailable 如果沒有特別設定，預設會是 25%。
• maxUnavailable 和 maxSurge 不可同時為零 

如果覺得文字說明有點難懂，上圖！
假設 replicas 設定為 4

根據預設：

• maxSurge: 25%：最多允許 4 × 25% = 1 個額外的 Pod 運行
• maxUnavailable: 25%：最多允許 4 × 25% = 1 個 Pod 在更新過程中處於不可用狀態
  
  
  以此類推，直到全部的 Pod 都替換成新的版本。
  這樣一來既可以將 Pod 更新又可以保證服務不中斷，就算只有一個 Pod 也一樣。

Recreate

Recreate 會先刪除所有舊版本的 Pod，然後再啟動新版本的 Pod。
在 Pod 被刪除和新 Pod 被啟動之間，服務會有一段時間不可用。

RollingUpdate

Kubernetes 中最常用的更新策略，適合大多數情境

• 平滑過渡：確保在更新過程中服務保持可用，不會中斷
• 滾動更新：逐步替換 Pod，減少風險

Recreate

適用於新舊版本會出現衝突、批次處理或是資源受限時使用（寧可暫停服務也無法加開資源的情況）

• 簡單直接：應用更新過程中沒有並行運行的舊版本 Pod，適合那些可以接受短暫中斷的應用
• 服務中斷：當新 Pod 啟動前，服務會出現短暫的不可用時段

Kubernetes 計算 Pod 可用數量時，並不會把替換時終止的 Pod 計算進去，但在回收之前，這些 Pod 都還是佔用資源的。
因此，在 RollingUpdate 策略下執行更新，會比運行時消耗更多的資源喔！

小結

Deployment 是用來管理服務的元件，負責確保所需數量的 Pod 在任何時間都正確運行。

觸發 Deployment 更新只有一個條件：Pod 有新的版本。
如果只是對服務做擴充，並不會觸發更新喔！