GSP053

總覽

開發運作的做法，經常是運用多種部署來管理應用程式部署情境，例如「持續部署」、「藍綠部署」和「初期測試部署」等。本研究室提供資源調度和容器管理方法，方便您演練採用多種異質部署的常見情境。

目標

在本研究室中，您將瞭解如何執行下列工作：

• 實際練習使用 kubectl 工具
• 建立 Deployment yaml 檔案
• 發布、更新 Deployment 並調度資源
• 更新 Deployment 並瞭解這些物件的樣式

事前準備

為了達到最大學習效益，進行本研究室課程前，建議先達成下列條件：

• 完成以下 Google Cloud Skills Boost 研究室：
  • Docker 簡介
  • Hello 節點 Kubernetes
• 具備 Linux 系統管理技能。
• 瞭解開發運作理論：持續部署概念。

部署簡介

異質部署通常需要連接至少兩個不同的基礎架構環境或區域，以滿足特定技術或作業需求。視部署特點而定，異質部署有「混合」、「多雲端」或「公開/私人」三種類型。

本研究室說明的異質部署包含在單一雲端環境中橫跨多個區域的部署、多重公有雲環境 (「多雲端」) 的部署，或結合地端部署與公有雲環境 (「混合」或「公開/私人」) 的部署。

限定在單一環境或區域進行部署可能會發生多種業務和技術問題：

• 資源不敷所需：在任何單一環境中，特別是在地端部署環境，您的運算、網路和儲存資源可能無法滿足實際運作所需。
• 地理範圍過於侷限：使用單一環境部署，人員即使彼此相距遙遠也必須存取同一個部署環境，他們的流量可能因此繞過大半個地球才能傳輸到中央位置。
• 可用性受到牽制：網路規模的流量模式讓應用程式難以維持容錯能力和彈性。
• 無法自由選擇廠商：廠商層級的平台和基礎架構抽象化，讓您無法遷移應用程式。
• 資源缺乏彈性：資源可能受限於一組特定的運算、儲存或網路服務。

異質部署有助於解決這些問題，但必須使用程式輔助的確定性程序來建立架構。一次性或臨時部署程序會產生脆弱且無法容錯的部署或程序。臨時程序可能遺失資料或降低流量。良好的部署程序必須可重複執行，並使用經過驗證的方法來管理佈建、設定和維護。

異質部署的三種常見情境為多雲端部署、前置地端部署資料，以及持續整合/持續推送軟體更新 (CI/CD) 程序。

您將藉由下列練習，瞭解異質部署的一些常見用途，以及如何運用 Kubernetes 和其他基礎架構資源建立架構良好的方法以達成目的。

設定和需求

點選「Start Lab」按鈕前的須知事項

請詳閱以下操作說明。研究室活動會計時，而且中途無法暫停。點選「Start Lab」 後就會開始計時，讓您瞭解有多少時間可以使用 Google Cloud 資源。

您將在真正的雲端環境中完成實作研究室活動，而不是在模擬或示範環境。為達此目的，我們會提供新的暫時憑證，讓您用來在研究室活動期間登入及存取 Google Cloud。

如要完成這個研究室活動，請先確認：

• 您可以使用標準的網際網路瀏覽器 (Chrome 瀏覽器為佳)。

注意：請使用無痕模式或私密瀏覽視窗執行此研究室。這可以防止個人帳戶和學生帳戶之間的衝突，避免個人帳戶產生額外費用。

• 是時候完成研究室活動了！別忘了，活動一開始將無法暫停。

注意：如果您擁有個人 Google Cloud 帳戶或專案，請勿用於本研究室，以免產生額外費用。

如何開始研究室及登入 Google Cloud 控制台

1. 按一下「Start Lab」(開始研究室) 按鈕。如果研究室會產生費用，畫面中會出現選擇付款方式的彈出式視窗。左側的「Lab Details」(研究室詳細資料) 面板會顯示下列項目：

   • 「Open Google Console」(開啟 Google 控制台) 按鈕
   • 剩餘時間
   • 必須在這個研究室中使用的暫時憑證
   • 完成這個研究室所需的其他資訊 (如有)

2. 按一下「Open Google Console」(開啟 Google 控制台)。接著，研究室會啟動相關資源並開啟另一個分頁，當中會顯示「Sign in」(登入) 頁面。

   提示：您可以在不同的視窗中並排開啟分頁。

   注意事項：如果頁面中顯示了「Choose an account」(選擇帳戶) 對話方塊，請按一下「Use Another Account」(使用其他帳戶)。

3. 如有必要，請複製「Lab Details」(研究室詳細資料) 面板中的使用者名稱，然後貼到「Sign in」(登入) 對話方塊。按一下「Next」(下一步)。

4. 複製「Lab Details」(研究室詳細資料) 面板中的密碼，然後貼到「Welcome」(歡迎使用) 對話方塊。按一下「Next」(下一步)。

   重要注意事項：請務必使用左側面板中的憑證，而非 Google Cloud 技能重點加強的憑證。 注意事項：如果使用自己的 Google Cloud 帳戶來進行這個研究室，可能會產生額外費用。

5. 按過後續的所有頁面：

   • 接受條款及細則。
   • 由於這是臨時帳戶，請勿新增救援選項或雙重驗證機制。
   • 請勿申請免費試用。

Cloud 控制台稍後會在這個分頁中開啟。

注意事項：按一下畫面左上方的導覽選單，即可在選單中查看 Google Cloud 產品與服務的清單。

啟動 Cloud Shell

Cloud Shell 是搭載多項開發工具的虛擬機器，提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權，方便您使用 Google Cloud 資源。

1. 點按 Google Cloud 控制台上方的「啟用 Cloud Shell」圖示 。

連線完成即代表已通過驗證，且專案已設為您的 PROJECT_ID。輸出內容中有一行宣告本工作階段 PROJECT_ID 的文字：

您在本工作階段中的 Cloud Platform 專案會設為「YOUR_PROJECT_ID」

gcloud 是 Google Cloud 的指令列工具，已預先安裝於 Cloud Shell，並支援 Tab 鍵自動完成功能。

2. (選用) 您可以執行下列指令來列出使用中的帳戶：

gcloud auth list

3. 點按「授權」。

4. 輸出畫面應如下所示：

輸出內容：

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (選用) 您可以使用下列指令來列出專案 ID：

gcloud config list project

輸出內容：

[core] project = <project_ID>

輸出內容範例：

[core] project = qwiklabs-gcp-44776a13dea667a6 附註：如需有關 gcloud 的完整說明，請前往 Google Cloud 並參閱「gcloud CLI overview guide」(gcloud CLI 總覽指南)。

設定可用區

執行下列指令來設定您工作的 Google Cloud 可用區，並將所在可用區換成 ：

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

取得本研究室的程式碼範例

1. 取得建立及執行容器和部署的程式碼範例：

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetescd orchestrate-with-kubernetes/kubernetes

2. 建立含 3 個節點的叢集 (這需要幾分鐘的時間才能完成)：

gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

工作 1：瞭解 Deployment 物件

首先，請查看 Deployment 物件。

1. kubectl 中的 explain 指令可說明 Deployment 物件：

kubectl explain deployment

2. 您還可以使用 --recursive 選項查看所有欄位：

kubectl explain deployment --recursive

3. 進行研究室課程期間，您可以使用 explain 指令來瞭解 Deployment 物件結構，以及個別欄位的作用：

kubectl explain deployment.metadata.name

工作 2：建立 Deployment

1. 更新 deployments/auth.yaml 設定檔：

vi deployments/auth.yaml

2. 啟動編輯器：

i

3. 在 Deployment 的容器區段中，將 image 變更如下：

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. 儲存 auth.yaml 檔案：按下 <Esc> 鍵，然後輸入：

:wq

5. 按下 <Enter> 鍵。現在，我們來建立簡單的 Deployment。檢查 Deployment 設定檔：

cat deployments/auth.yaml

輸出內容：

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

請注意 Deployment 建立備用資源的方式，而且該物件使用的驗證容器版本為 1.0.0。

執行 kubectl create 指令來建立 Auth Deployment 時，會產生一個符合 Deployment 資訊清單資料的 Pod，這樣即可變更 replicas 欄位指定的數字來調整 Pod 數量。

6. 開始使用 kubectl create 建立 Deployment 物件：

kubectl create -f deployments/auth.yaml

7. 建立 Deployment 後，您可以使用下列程式碼確認已建立該物件：

kubectl get deployments

8. 建立 Deployment 後，Kubernetes 會建立該 Deployment 的 ReplicaSet。您可以使用下列程式碼，確認已建立該 ReplicaSet：

kubectl get replicasets

ReplicaSet 應會顯示像 auth-xxxxxxx 這樣的名稱

9. 檢查已建立為 Deployment 一部分的 Pod。Kubernetes 會在建立 ReplicaSet 時一併建立單一 Pod：

kubectl get pods

接著來建立 Auth Deployment 的 Service。您已看過 Service 資訊清單檔案，因此這邊不會進一步說明。

10. 使用 kubectl create 指令建立 Auth Service：

kubectl create -f services/auth.yaml

11. 現在使用相同指令來建立並發布 Hello Deployment：

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. 再次使用相同指令來建立並發布 Frontend Deployment：

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml 注意：您已為前端建立 ConfigMap。

13. 與前端互動，擷取前端的外部 IP 並執行 curl 指令：

kubectl get services frontend 注意：「External-IP」欄位可能需要幾秒鐘才會填入 Service 的外部 IP 位址。這是正常現象。只要每隔幾秒重新執行上述指令，直到該欄位填入位址即可。 curl -ks https://<EXTERNAL-IP>

然後您會收到 hello 回應。

14. 您也可以使用 kubectl 的輸出範本功能，將 curl 做為單行程式碼範本：

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

測試已完成的工作

請點選下方的「Check my progress」，確認您的研究室進度。如果您已成功建立 Kubernetes 叢集和 Auth、Hello、Frontend Deployment，就會看到評量分數。

建立 Kubernetes 叢集和 Auth、Hello、Frontend Deployment

調度 Deployment 資源

Deployment 建立完成後，您就能調度相關資源。做法是更新 spec.replicas 欄位。

1. 您可以再次使用 kubectl explain 指令查看這個欄位的說明：

kubectl explain deployment.spec.replicas

2. 建議使用 kubectl scale 指令，這可能是更新「replicas」欄位最輕鬆的方式：

kubectl scale deployment hello --replicas=5 注意：系統可能需要幾分鐘時間才能啟動所有新 Pod。

更新 Deployment 後，Kubernetes 會自動更新相關聯的 ReplicaSet 並啟動新 Pod，讓 Pod 總數等於 5。

3. 確認現在有 5 個 hello Pod 執行中：

kubectl get pods | grep hello- | wc -l

4. 現在縮減應用程式資源：

kubectl scale deployment hello --replicas=3

5. 請再次確認 Pod 數量正確無誤：

kubectl get pods | grep hello- | wc -l

您已瞭解 Kubernetes Deployment，以及如何管理 Pod 群組並調度資源。

工作 3：滾動式更新

Deployment 能透過滾動式更新機制，將映像檔更新至新版本。當 Deployment 更新至新版本後，會建立新 ReplicaSet 並緩慢增加其中的備用資源數量，同時減少舊 ReplicaSet 的備用資源。

觸發滾動式更新程序

1. 如要更新 Deployment，請執行下列指令：

kubectl edit deployment hello

2. 在 Deployment 的容器區段中，將 image 變更如下：

... containers: image: kelseyhightower/hello:2.0.0 ...

3. 儲存並結束。

儲存變更並結束編輯器後，更新的 Deployment 將儲存至叢集，Kubernetes 則會開始進行滾動式更新。

4. 查看 Kubernetes 建立的新 ReplicaSet：

kubectl get replicaset

5. 您也會在推出記錄中看到新項目：

kubectl rollout history deployment/hello

暫停滾動式更新程序

如果您在推出期間偵測到問題，請暫停程序來停止更新。

1. 立即來試試看：

kubectl rollout pause deployment/hello

2. 確認推出更新的目前狀態：

kubectl rollout status deployment/hello

3. 您也可以直接從 Pod 確認目前狀態：

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

繼續滾動式更新程序

暫停推出作業，代表當下某些 Pod 為新版本，其他 Pod 仍為舊版本。

1. 您可以使用 resume 指令繼續推出：

kubectl rollout resume deployment/hello

2. 推出完畢後，您應該會在執行 status 指令時看到下列內容：

kubectl rollout status deployment/hello

輸出內容：

deployment "hello" successfully rolled out

復原更新

假設您在新版本中偵測到錯誤，由於新版本出現問題，因此使用者連上新 Pod 時都會遇到這些問題。

您想復原至先前的版本進行調查，然後發布妥善修正的版本。

1. 在這種情況下，請使用 rollout 指令復原至先前的版本：

kubectl rollout undo deployment/hello

2. 確認復原記錄：

kubectl rollout history deployment/hello

3. 最後，確認所有 Pod 都已復原至先前版本：

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

太好了！您已瞭解如何為 Kubernetes Deployment 進行滾動式更新，以及如何在不停機的狀態下更新應用程式。

工作 4：初期測試部署

如果您想對實際工作環境中的部分使用者測試新的部署作業，可以採用初期測試部署。您可藉由這種做法對一小群使用者發布變更，以減少部署新版本的相關風險。

建立初期測試部署

初期測試部署包含獨立的新版本 Deployment，以及目標鎖定為正常、穩定部署和初期測試部署的 Service。

1. 首先，為新版本建立新的初期測試部署：

cat deployments/hello-canary.yaml

輸出內容：

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. 現在，建立初期測試部署：

kubectl create -f deployments/hello-canary.yaml

3. 建立初期測試部署後，您應該會有 hello 和 hello-canary 這兩個 Deployment。您可以使用 kubectl 指令來確認：

kubectl get deployments

hello Service 使用的 app:hello 選取器，將同時比對實際工作環境部署和初期測試部署中的 Pod。然而，由於初期測試部署的 Pod 數量較少，因此只會對少數使用者顯示。

確認初期測試部署

1. 您可以執行下列要求，確認系統提供的 hello 版本：

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. 執行這項要求數次，您就會看到部分要求由 hello 1.0.0 處理，一小部分 (1/4 = 25%) 要求則由 hello 2.0.0 處理。

測試已完成的工作

請點選下方的「Check my progress」，確認您的研究室進度。如果您已成功建立初期測試部署，就會看到評量分數。

初期測試部署

實際工作環境中的初期測試部署：工作階段相依性

在本研究室中，每個傳送至 Nginx Service 的要求都有機會由初期測試部署處理。不過，如果不想讓初期測試部署處理某個使用者的要求，該怎麼做？上述情況可能是，您變更了應用程式的使用者介面，且不想讓使用者因此感到困惑。在這種情形下，您會希望使用者「固定」使用某個部署就好。

要達到這個目標，您可以建立附有工作階段相依性的 Service，這樣特定使用者便會一直由同一個版本提供服務。以下示例中的 Service 與先前相同，但新增了一個 sessionAffinity 欄位，並且值設為 ClientIP。這樣一來，IP 位址相同的用戶端要求都會傳送至同一個 hello 應用程式版本。

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

要設定環境來測試這個服務比較困難，因此您不需在這裡測試。但您可以考慮在實際工作環境中採用 sessionAffinity 進行初期測試部署。

工作 5：藍綠部署

滾動式更新能讓您逐步部署應用程式，同時盡量減少工作負擔、成效影響和停機時間，是相當理想的部署方式。但在某些情況下，完全部署新版本後，再修改負載平衡器來指向該版本卻較為有利。這種情況就適合採用藍綠部署。

為了施行這種部署方式，Kubernetes 會分別建立兩個 Deployment，其中一個為「藍色」的舊版本，另一個則為「綠色」的新版本。請將您現有的 hello Deployment 當做「藍色」版本，使用者會透過做為路由器的 Service 存取這類 Deployment。當「綠色」的新版本上線並運作時，更新 Service 即可切換成使用新版本。

注意：藍綠部署的一大缺點，是至少需要 2 倍叢集資源才能託管應用程式。因此請先確認叢集有足夠資源，再著手部署兩個應用程式版本。

Service

請更新現有的 hello Service，產生選取器 app:hello, version: 1.0.0。該選取器版本將與現有的「藍色」Deployment 相應，但與「綠色」Deployment 則不相符，因為彼此使用的版本不同。

• 首先，請更新 Service：

kubectl apply -f services/hello-blue.yaml 注意：請忽略「resource service/hello is missing」這行警示，因為系統會自動修補這部分。

使用藍綠部署更新

為了符合藍綠部署的作業需求，請為新版本新建「綠色」的 Deployment。綠色 Deployment 會更新版本標籤和映像檔路徑。

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. 建立綠色 Deployment：

kubectl create -f deployments/hello-green.yaml

2. 建立並正常執行綠色 Deployment 後，請確認系統仍在使用目前的版本 1.0.0：

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. 現在，請更新 Service 以指向新版本：

kubectl apply -f services/hello-green.yaml

4. 更新 Service 後，系統會立即使用「綠色」Deployment。現在可以確認是否系統一定會使用新版本：

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

藍綠復原

如果有需要，您可以用相同方式復原至舊版本。

1. 只要在「藍色」Deployment 運作時，將 Service 更新回舊版本即可：

kubectl apply -f services/hello-blue.yaml

2. 完成更新 Service，就代表您復原成功。請再次確認目前是否使用正確版本：

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

您做到了！您已瞭解什麼是藍綠部署，以及如何將更新部署到需要立刻切換版本的應用程式。

恭喜！

這個實作研究室使用 Kubernetes 管理部署，課程到此已結束。在本研究室中，您瞭解如何使用 kubectl 指令列工具執行更多工作，以及在 YAML 檔案中設定多種形式的部署來啟動、更新 Deployment 並調度資源。有了這個練習基礎，您就能輕鬆將這些技能應用在開發運作實務。

後續步驟/瞭解詳情

• 歡迎前往 Google Cloud 網站：

  • 進一步瞭解 Kubernetes 部署模式
  • 參閱 Google Cloud 說明文件的開發運作解決方案和指南。

• 在 Kubernetes 網站上與 Kubernetes 社群互動交流！

Google Cloud 教育訓練與認證

協助您瞭解如何充分運用 Google Cloud 的技術。我們的課程會介紹專業技能和最佳做法，讓您可以快速掌握要領並持續進修。我們提供從基本到進階等級的訓練課程，並有隨選、線上和虛擬課程等選項，方便您抽空參加。認證可協助您驗證及證明自己在 Google Cloud 技術方面的技能和專業知識。

使用手冊上次更新日期：2024 年 1 月 26 日

研究室上次測試日期：2023 年 8 月 14 日

Copyright 2024 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標，其他公司和產品名稱則有可能是其關聯公司的商標。