arrow_back

使用 Kubernetes Engine 管理部署

登录 加入
欢迎加入我们的社区，一起测试和分享您的知识！
done
学习 700 多个动手实验和课程并获得相关技能徽章

使用 Kubernetes Engine 管理部署

实验 1 小时 universal_currency_alt 5 积分 show_chart 中级
info 此实验可能会提供 AI 工具来支持您学习。
欢迎加入我们的社区，一起测试和分享您的知识！
done
学习 700 多个动手实验和课程并获得相关技能徽章

GSP053

Google Cloud 自修研究室標誌

總覽

開發運作做法經常使用多個 Deployment 來管理應用程式部署情境，例如「持續部署」、「藍綠部署」和「初期測試部署」等。這個研究室說明如何管理容器及調度相關資源，協助您處理有異質 Deployment 的情況 (這種情況相當常見)。

目標

在這個研究室，您會瞭解如何執行下列工作：

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

事前準備

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

Deployment 簡介

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

這個研究室說明下列異質 Deployment：在單一雲端環境橫跨多個區域、橫跨多個公有雲環境 (「多雲端」)，或是合併使用地端部署與公有雲環境 (「混合雲」或「公開對私人」)。

如果 Deployment 只在一個環境或區域內，可能會出現多種業務與技術問題：

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

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

異質 Deployment 的三種常見情境如下：

  • 多雲端 Deployment
  • 前置地端部署資料
  • 持續整合/持續推送軟體更新 (CI/CD) 程序

您會藉由下列練習體驗異質 Deployment 的幾個常見用途，以及採用 Kubernetes 和其他基礎架構資源且架構良好的做法，以便實作異質 Deployment。

設定和需求

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

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

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

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

  • 您可以使用標準的網際網路瀏覽器 (Chrome 瀏覽器為佳)。
注意：請使用無痕模式或私密瀏覽視窗執行此研究室。這可以防止個人帳戶和學生帳戶之間的衝突，避免個人帳戶產生額外費用。
  • 是時候完成研究室活動了！別忘了，活動一開始將無法暫停。
注意：如果您擁有個人 Google Cloud 帳戶或專案，請勿用於本研究室，以免產生額外費用。

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

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

    • 「Open Google Cloud console」按鈕
    • 剩餘時間
    • 必須在這個研究室中使用的暫時憑證
    • 完成這個實驗室所需的其他資訊 (如有)

  2. 點選「Open Google Cloud console」；如果使用 Chrome 瀏覽器，也能按一下滑鼠右鍵，然後選取「在無痕式視窗中開啟連結」。

    接著，實驗室會啟動相關資源並開啟另一個分頁，當中顯示「登入」頁面。

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

    注意：如果頁面中顯示「選擇帳戶」對話方塊，請點選「使用其他帳戶」。

  3. 如有必要，請將下方的 Username 貼到「登入」對話方塊。

    {{{user_0.username | "Username"}}}

    您也可以在「Lab Details」窗格找到 Username。

  4. 點選「下一步」。

  5. 複製下方的 Password，並貼到「歡迎使用」對話方塊。

    {{{user_0.password | "Password"}}}

    您也可以在「Lab Details」窗格找到 Password。

  6. 點選「下一步」。

    重要事項：請務必使用實驗室提供的憑證，而非自己的 Google Cloud 帳戶憑證。 注意：如果使用自己的 Google Cloud 帳戶來進行這個實驗室，可能會產生額外費用。

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

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

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

注意：如要查看列出 Google Cloud 產品和服務的選單，請點選左上角的「導覽選單」。「導覽選單」圖示

啟動 Cloud Shell

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

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

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

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

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

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

  1. 點按「授權」。

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

輸出內容：

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (選用) 您可以使用下列指令來列出專案 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
  1. 建立含 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
  1. 您還可以使用 --recursive 選項查看所有欄位：
kubectl explain deployment --recursive
  1. 進行研究室課程期間，您可以使用 explain 指令來瞭解 Deployment 物件結構，以及個別欄位的作用：
kubectl explain deployment.metadata.name

工作 2：建立 Deployment

  1. 更新 deployments/auth.yaml 設定檔：
vi deployments/auth.yaml
  1. 啟動編輯器：
i
  1. 在 Deployment 的容器區段中，將 image 變更如下：
... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...
  1. 儲存 auth.yaml 檔案：按下 <Esc> 鍵，然後輸入：
:wq
  1. 按下 <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 數量。

  1. 開始使用 kubectl create 建立 Deployment 物件：
kubectl create -f deployments/auth.yaml
  1. 建立 Deployment 後，您可以使用下列程式碼確認已建立該物件：
kubectl get deployments
  1. 建立 Deployment 之後，Kubernetes 會建立該 Deployment 的 ReplicaSet。您可以使用下列程式碼，確認已建立該 Deployment 的 ReplicaSet：
kubectl get replicasets

ReplicaSet 的名稱應該會是 auth-xxxxxxx

  1. 檢查已建立為 Deployment 一部分的 Pod。Kubernetes 會在建立 ReplicaSet 時一併建立一個 Pod：
kubectl get pods

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

  1. 使用 kubectl create 指令建立 Auth Service：
kubectl create -f services/auth.yaml
  1. 接著，請使用相同指令來建立並公開 hello Deployment：
kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml
  1. 再次使用同樣的指令，建立並公開 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。
  1. 與前端互動，擷取前端的外部 IP 並執行 curl 指令：
kubectl get services frontend 注意：「External-IP」欄位可能需要幾秒鐘才會填入 Service 的外部 IP 位址。這是正常現象。只要每隔幾秒重新執行上述指令，直到該欄位填入位址即可。 curl -ks https://<EXTERNAL-IP>

然後您會收到 hello 回應。

  1. 您也可以使用 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
  1. 建議使用 kubectl scale 指令，這可能是更新「replicas」欄位最輕鬆的方式：
kubectl scale deployment hello --replicas=5 注意：系統可能需要幾分鐘時間才能啟動所有新 Pod。

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

  1. 確認現在有 5 個 hello Pod 執行中：
kubectl get pods | grep hello- | wc -l
  1. 現在縮減應用程式資源：
kubectl scale deployment hello --replicas=3
  1. 請再次確認 Pod 數量正確無誤：
kubectl get pods | grep hello- | wc -l

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

工作 3：滾動式更新

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

備用資源集之間的 Deployment 圖表

觸發滾動式更新程序

  1. 如要更新 Deployment，請執行下列指令：
kubectl edit deployment hello
  1. 在 Deployment 的容器區段中，將 image 變更如下：
... containers: image: kelseyhightower/hello:2.0.0 ...
  1. 依序點選「儲存」和「退出」。

更新後的 Deployment 會儲存於叢集，Kubernetes 則會開始進行滾動式更新。

  1. 查看 Kubernetes 建立的新 ReplicaSet：
kubectl get replicaset
  1. 您也會在推出記錄中看到新項目：
kubectl rollout history deployment/hello

暫停滾動式更新程序

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

  1. 請執行下列指令，暫停推出作業：
kubectl rollout pause deployment/hello
  1. 確認推出更新的目前狀態：
kubectl rollout status deployment/hello
  1. 您也可以直接從 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
  1. 推出完畢後，您應該會在執行 status 指令時看到下列內容：
kubectl rollout status deployment/hello

輸出內容：

deployment "hello" successfully rolled out

復原更新內容

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

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

  1. 在這種情況下，請使用 rollout 指令復原至先前的版本：
kubectl rollout undo deployment/hello
  1. 確認復原記錄：
kubectl rollout history deployment/hello
  1. 最後，確認所有 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 ...
  1. 現在，建立初期測試部署：
kubectl create -f deployments/hello-canary.yaml
  1. 建立初期測試部署後，您應該會有 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
  1. 執行這項要求數次，您就會看到部分要求由 hello 1.0.0 處理，一小部分 (1/4 = 25%) 要求則由 hello 2.0.0 處理。

測試已完成的工作

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

初期測試部署

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

在這個研究室，傳送至 Nginx Service 的各項要求都有機會由初期測試部署項目處理。不過，若想確保某使用者的要求不由初期測試部署處理，該怎麼做？其中一種情況可能是您變更了應用程式的 UI，而不想讓使用者感到困惑。在這種情形下，您會希望使用者「固定」使用某個部署就好。

要達到這個目標，您可以建立附有工作階段相依性的 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
  1. 建立並正常執行綠色 Deployment 後，請確認系統仍在使用目前的版本 1.0.0：
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
  1. 現在，請更新 Service 以指向新版本：
kubectl apply -f services/hello-green.yaml
  1. 更新 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
  1. 完成更新 Service，就代表您復原成功。請再次確認目前是否使用正確版本：
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

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

恭喜！

您已瞭解如何使用 kubectl 指令列工具執行更多工作，並在 YAML 檔案設置多種形式的 Deployment 設定，藉此啟動、更新 Deployment 並調度相關資源。有了這樣的練習基礎，您就能放心在實際的開發運作作業使用這些技巧。

後續行動/瞭解詳情

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期：2024 年 4 月 2 日

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

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

此内容目前不可用

一旦可用，我们会通过电子邮件告知您

太好了！

一旦可用，我们会通过电子邮件告知您