管理應用程式生命週期

使用 Kubernetes 的原生與第三方工具，為應用程式執行滾動更新與回滾操作，同時確保用戶無需經歷服務中斷。

更新策略

若要更新應用程式，可以從各種策略中進行選擇，例如下列策略。在進行更複雜的 Canary 部署之前，您可以從漸進式部署或即時切換開始。

漸進式部署: 您可以使用 Kubernetes 原生功能來建立 v2 部署，並逐步取代先前的 v1 部署。此方法要求應用程式具備向後相容性，以確保使用 v2 版本應用程式的使用者不會遇到任何破壞性變更。如需相關資訊，請參閱管理漸進式部署以更新應用程式。
即時切換: 即時切換也稱為藍綠部署，需要將運算資源加倍，才能同時執行應用程式的兩個版本。使用此方式，您可以近乎即時地將使用者切換至較新的版本。請務必使用服務標籤選擇器（例如 version: green 和 version: blue ），以確保請求能傳送至正確的應用程式版本。您可以建立新的 version: green 部署，並等待它就緒，然後刪除 version: blue 部署。或者，您可以執行滾動更新，但需將 maxUnavailable 參數設定為 0%，並將 maxSurge 參數設定為 100%。
Canary 或 A/B 部署: Canary 部署是更複雜的更新策略，是指您挑選一定比例（例如 5%）的使用者並將他們傳送至新的應用程式版本。您可以在記載及監視工具中收集下列作業的度量值：如何執行新的應用程式版本，執行 A/B 測試，然後將更新項目推出給更多使用者。與所有部署一樣，標示應用程式（例如，version: stable 和 version: canary）至關重要。若要管理 Canary 部署，您可以安裝受管理的 Istio 附加服務網，為您的叢集設定 Monitoring，然後依照這篇部落格文章的說明，使用 Istio 服務網進行 A/B 測試。

調整應用程式

透過 Kubernetes，您可以啟用水平 Pod 自動擴展功能，系統將根據 CPU 使用率自動增加或減少應用程式的執行個體數量。

想要調整工作者節點而非 Pod？請查看叢集 Autoscaler。

開始之前：

請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。
請確認您已被指派一個服務存取角色，該角色會授予相應的「Kubernetes」RBAC 角色，以便您能在該命名空間中管理 Kubernetes 資源。

要擴展您的應用程式：

從 CLI 將您的應用程式部署至叢集。若為更複雜的部署，您可能需要建立配置檔。
```
kubectl create deployment <app_name> --image=<image>
```
針對在部署中執行的容器 (例如 100m)，設定 CPU 資源限制 (以 millicore 為單位)。您也可以設定記憶體限制，但水平 Pod Autoscaler 只會考量用於調整的 CPU 資源限制。如需相關資訊，請參閱 kubectl set resources 文件。
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

建立 Horizontal Pod Autoscaler，並定義您的原則。如需相關資訊，請參閱 kubectl autoscale 說明文件。

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

了解您的命令選項
選項	說明
`--cpu-percent`	Horizontal Pod Autoscaler 所維護的平均 CPU 使用率（以百分比為指定單位）。
`--min`	用來維護指定 CPU 使用率百分比之已部署的 Pod 數目下限。
`--max`	用來維護指定 CPU 使用率百分比之已部署的 Pod 數目上限。

管理漸進式部署以更新應用程式

您可以使用 Pod 範本（例如部署），以工作負載的自動化及受管理方式來管理應用程式變更的推出。如果推出不是根據計劃進行，您可以將部署回復為前一個修訂。

想要在漸進式更新期間防止運作中斷時間嗎？請務必在您的部署中指定就緒探測，以讓推出可在最近更新的 Pod 就緒之後繼續進行至下一個應用程式 Pod。

開始之前：

請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。
建立部署。
請確保您擁有一個服務存取角色，該角色會授予相應的「Kubernetes」RBAC 角色，以便您能在該命名空間中管理 Kubernetes 資源。

若要管理應用程式的漸進式更新，請執行下列動作：

若要確定只有在容器正在執行且已準備好處理要求時，才將部署標示為就緒，請新增存活性及就緒探測至部署。
更新部署以包括漸進式更新策略，該策略在更新期間指定突波上限及無法使用的 Pod 或 Pod 百分比。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

依預設，部署會等到將 Pod 標示為 ready，再繼續推出。如果您注意到即使最新 Pod 中的應用程式尚未就緒，部署還是繼續建立 Pod，則請使用此欄位來減緩部署推出的速度。例如，如果您指定 5，則部署會在 Pod ready 之後先等待 5 秒，再建立下一個 Pod。

spec.progressDeadlineSeconds

設定將部署視為失敗之前的逾時（以秒為單位）。舉例來說，若未設定超時，當您的新應用程式版本出現錯誤並立即當機時，由於該 Pod 永遠無法進入「ready」狀態，因此部署將無法繼續。如果您將此逾時設為 600 秒，則推出的任何階段無法進行 10 分鐘時，會將部署標示為失敗，並停止推出。

spec.strategy.type

指定 RollingUpdate 策略類型。

spec.strategy.rollingUpdate.maxUnavailable

設定更新期間可能無法使用的 Pod 數目上限，以數字 (2) 或百分比 (50%) 表示。一般而言，請使用百分比，這樣，稍後變更抄本數目時，就不需要記得在這裡更新此數字，除非您要將推出限制為僅容許一次關閉一個 Pod。若您希望容量永遠不低於 100%，請將此值設定為「0%」，並指定「spec.strategy.type.rollingUpdate.maxSurge」參數。

spec.strategy.rollingUpdate.maxSurge

將應用期間部署可以使用的額外資源數設定為數字 (2) 或百分比 (50%)。例如，如果部署指定了 10 個抄本，並且您將 maxSurge 設定為 2，則在應用期間會建立 2 個新抄本。您現在會有 12 個抄本（10 個現有抄本，2 個新抄本）。在 2 個新抄本就緒後，部署會將舊抄本縮減為 8 個，以符合指定的 10 個抄本的設定。此處理程序會繼續進行，直到推出完成為止，而且 10 個抄本全部都會執行新版本。

如果您要執行藍綠即時交換器樣式更新，請將 maxSurge 設為 100%。部署會建立所有新的必要抄本，然後將舊版本抄本縮減至 0。

推出變更。例如，建議您變更起始部署中所用的映像檔。

取得部署名稱。

    kubectl get deployments
    ```
2. 取得 Pod 名稱。

```sh {: pre}
    kubectl get pods
    ```
3. 取得在 Pod 中執行的容器的名稱。

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. 設定部署要使用的新映像檔。

```sh {: pre}
    kubectl set image deployment/<deployment_name> <container_name>=<image_name>
    ```
當您執行這些指令時，會立即套用變更，並記載推出歷程。

檢查部署的狀態。

kubectl rollout status deployments/<deployment_name>

如果您注意到某事項的狀態需要您花時間跟進，則可以使用下列指令來暫停及繼續推出。

kubectl rollout pause deployment <deployment_name>

kubectl rollout resume deployment <deployment_name>

回復變更。

檢視部署的推出歷程，並識別前次部署的修訂號碼。

    kubectl rollout history deployment/<deployment_name>
    ```
    若要查看特定修訂的詳細資料，請包括修訂號碼。
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. 回復至舊版，或指定修訂版。 若要回復至舊版，請使用下列指令。

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

設定持續整合與交付

透過 IBM Cloud 及其他開源工具，您可建立持續整合與交付（CI/CD）、版本控制、工具鏈等系統，協助自動化應用程式開發與部署流程。

若要查看支援的整合清單和設定持續遞送管道的步驟，請檢閱 IBM Cloud 主控台中的可用整合和相關群集文件。

將部署複製到其他叢集

當您在叢集中使用版本控制系統（例如 Git ）、配置管理專案或持續交付工具時，即可快速將應用程式配置檔案從一個叢集部署到另一個叢集。有時，您僅有少量在叢集裡測試過的部署，並且希望複製這些部署，然後在另一個叢集裡重新部署。

開始之前，您需要兩個叢集，並針對兩個叢集中的所有命名空間擁有「Manager」服務存取角色，以便將一個叢集中的所有資源複製並部署到另一個叢集。

請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

列出叢集裡的所有配置檔，並驗證是否要複製這些配置。

kubectl get all

輸出範例

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d
NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d
NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

將叢集裡的配置檔複製到本端目錄。接著，在將檔案套用至另一個叢集之前，請手動從匯出的 YAML 檔案中移除叢集專屬欄位，例如 resourceVersion、uid、creationTimestamp 以及 status。
```
kubectl get all -o yaml > myconfigs.yaml
```
請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。
可選：若您的叢集使用了多個命名空間，請在標準叢集中建立相同的命名空間，並將映像檔拉取密鑰複製到每個命名空間中。

將複製的配置檔部署到叢集。如果某個設定檔中含有無法套用的特定資訊，您可能需要更新該設定檔，然後重新套用。

kubectl apply -f myconfigs.yaml

輸出範例

pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created

驗證配置檔是否已套用。
```
kubectl get all
```