管理應用程式生命週期

使用 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）至關重要。要管理金絲雀部署，您可以安裝託管 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。
推出變更。例如，建議您變更起始部署中所用的映像檔。
1. 取得部署名稱。
```
kubectl get deployments
```
2. 取得 Pod 名稱。
```
kubectl get pods
```
3. 取得在 Pod 中執行的容器的名稱。
```
kubectl describe pod <pod_name>
```
4. 設定部署要使用的新映像檔。
```
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>

回復變更。
1. 檢視部署的推出歷程，並識別前次部署的修訂號碼。
```
kubectl rollout history deployment/<deployment_name>
```
  **提示：**若要查看特定修訂的詳細資料，請包括修訂號碼。
```
kubectl rollout history deployment/<deployment_name> --revision=<number>
```
2. 回復至舊版，或指定修訂版。若要回復至舊版，請使用下列指令。
```
kubectl rollout undo deployment/<depoyment_name> --to-revision=<number>
```

設定持續整合與交付

使用 IBM Cloud 及其他開放程式碼工具，您可以設定持續整合及交付 (CI/CD)、版本控制、工具鏈等，以協助自動化應用程式開發及部署。

若要查看支援的整合清單，以及設定持續交付管線的步驟，請參閱設定持續整合及交付。

將部署複製到其他叢集

當您在叢集中使用 Git等版本控制系統、kustomize 等設定管理專案或 Razee等持續交付工具時，您可以在叢集之間快速部署應用程式設定檔。有時，您僅有少量在叢集裡測試過的部署，並且希望複製這些部署，然後在另一個叢集裡重新部署。

在開始之前，您需要兩個叢集以及兩個叢集中所有命名空間的 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

將叢集裡的配置檔複製到本端目錄。 --export 選項從設定檔中刪除特定於叢集的資訊。
```
kubectl get all -o yaml --export > 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
```