GSP053
總覽
開發運作做法經常使用多個 Deployment 來管理應用程式部署情境,例如「持續部署」、「藍綠部署」和「初期測試部署」等。這個研究室說明如何管理容器及調度相關資源,協助您處理有異質 Deployment 的情況 (這種情況相當常見)。
目標
在這個研究室,您會瞭解如何執行下列工作:
使用 kubectl
工具
建立 Deployment 的 yaml
檔案
發布、更新 Deployment 並調度資源
更新 Deployment 並瞭解這些物件的樣式
事前準備
為最大化學習效益,進行本研究室課程前,建議先達成下列條件:
完成以下 Google Cloud Skills Boost 研究室:
具備 Linux 系統管理技能。
瞭解開發運作理論和持續部署的概念。
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 控制台
按一下「Start Lab」(開始研究室) 按鈕。如果研究室會產生費用,畫面中會出現選擇付款方式的彈出式視窗。左側的「Lab Details」 窗格會顯示下列項目:
「Open Google Cloud console」 按鈕
剩餘時間
必須在這個研究室中使用的暫時憑證
完成這個實驗室所需的其他資訊 (如有)
點選「Open Google Cloud console」 ;如果使用 Chrome 瀏覽器,也能按一下滑鼠右鍵,然後選取「在無痕式視窗中開啟連結」 。
接著,實驗室會啟動相關資源並開啟另一個分頁,當中顯示「登入」 頁面。
提示 :您可以在不同的視窗中並排開啟分頁。
注意 :如果頁面中顯示「選擇帳戶」 對話方塊,請點選「使用其他帳戶」 。
如有必要,請將下方的 Username 貼到「登入」 對話方塊。
{{{user_0.username | "Username"}}}
您也可以在「Lab Details」 窗格找到 Username 。
點選「下一步」 。
複製下方的 Password ,並貼到「歡迎使用」 對話方塊。
{{{user_0.password | "Password"}}}
您也可以在「Lab Details」 窗格找到 Password 。
點選「下一步」 。
重要事項 :請務必使用實驗室提供的憑證,而非自己的 Google Cloud 帳戶憑證。
注意 :如果使用自己的 Google Cloud 帳戶來進行這個實驗室,可能會產生額外費用。
按過後續的所有頁面:
接受條款及細則。
由於這是臨時帳戶,請勿新增救援選項或雙重驗證機制。
請勿申請免費試用。
Google Cloud 控制台稍後會在這個分頁開啟。
注意 :如要查看列出 Google Cloud 產品和服務的選單,請點選左上角的「導覽選單」 。
啟動 Cloud Shell
Cloud Shell 是搭載多項開發工具的虛擬機器,提供永久的 5 GB 主目錄,而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權,方便您使用 Google Cloud 資源。
點按 Google Cloud 控制台上方的「啟用 Cloud Shell」 圖示 。
連線完成即代表已通過驗證,且專案已設為您的 PROJECT_ID 。輸出內容中有一行宣告本工作階段 PROJECT_ID 的文字:
您在本工作階段中的 Cloud Platform 專案會設為「YOUR_PROJECT_ID」
gcloud
是 Google Cloud 的指令列工具,已預先安裝於 Cloud Shell,並支援 Tab 鍵自動完成功能。
(選用) 您可以執行下列指令來列出使用中的帳戶:
gcloud auth list
點按「授權」 。
輸出畫面應如下所示:
輸出內容:
ACTIVE: *
ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net
To set the active account, run:
$ gcloud config set account `ACCOUNT`
(選用) 您可以使用下列指令來列出專案 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 }}}
取得本研究室的程式碼範例
取得建立及執行容器和部署的程式碼範例:
gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetescd orchestrate-with-kubernetes/kubernetes
建立含 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 物件。
kubectl
中的 explain
指令可說明 Deployment 物件:
kubectl explain deployment
您還可以使用 --recursive
選項查看所有欄位:
kubectl explain deployment --recursive
進行研究室課程期間,您可以使用 explain 指令來瞭解 Deployment 物件結構,以及個別欄位的作用:
kubectl explain deployment.metadata.name
工作 2:建立 Deployment
更新 deployments/auth.yaml
設定檔:
vi deployments/auth.yaml
啟動編輯器:
i
在 Deployment 的容器區段中,將 image
變更如下:
...
containers:
- name: auth
image: "kelseyhightower/auth:1.0.0"
...
儲存 auth.yaml
檔案:按下 <Esc>
鍵,然後輸入:
:wq
按下 <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 數量。
開始使用 kubectl create
建立 Deployment 物件:
kubectl create -f deployments/auth.yaml
建立 Deployment 後,您可以使用下列程式碼確認已建立該物件:
kubectl get deployments
建立 Deployment 之後,Kubernetes 會建立該 Deployment 的 ReplicaSet
。您可以使用下列程式碼,確認已建立該 Deployment 的 ReplicaSet
:
kubectl get replicasets
ReplicaSet
的名稱應該會是 auth-xxxxxxx
檢查已建立為 Deployment 一部分的 Pod。Kubernetes 會在建立 ReplicaSet
時一併建立一個 Pod:
kubectl get pods
接著來建立 Auth Deployment 的 Service。您已看過 Service 資訊清單檔案,因此這邊不會進一步說明。
使用 kubectl create
指令建立 Auth Service:
kubectl create -f services/auth.yaml
接著,請使用相同指令來建立並公開 hello
Deployment:
kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml
再次使用同樣的指令,建立並公開 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
。
與前端互動,擷取前端的外部 IP 並執行 curl 指令:
kubectl get services frontend
注意: 「External-IP」欄位可能需要幾秒鐘才會填入 Service 的外部 IP 位址。這是正常現象。只要每隔幾秒重新執行上述指令,直到該欄位填入位址即可。
curl -ks https://<EXTERNAL-IP>
然後您會收到 hello 回應。
您也可以使用 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
欄位即可。
再次使用 kubectl explain
指令,查看這個欄位的說明:
kubectl explain deployment.spec.replicas
建議使用 kubectl scale
指令,這可能是更新「replicas」欄位最輕鬆的方式:
kubectl scale deployment hello --replicas=5
注意: 系統可能需要幾分鐘時間才能啟動所有新 Pod。
Deployment 更新之後,Kubernetes 會自動更新相關聯的 ReplicaSet
並啟動新的 Pod,讓 Pod 總數等於 5。
確認現在有 5 個 hello
Pod 執行中:
kubectl get pods | grep hello- | wc -l
現在縮減應用程式資源:
kubectl scale deployment hello --replicas=3
請再次確認 Pod 數量正確無誤:
kubectl get pods | grep hello- | wc -l
您已瞭解 Kubernetes 的 Deployment,以及如何管理 Pod 群組並調度相關資源。
工作 3:滾動式更新
Deployment 能透過滾動式更新機制,將映像檔更新至新版本。Deployment 更新為新版本之後,會建立新的 ReplicaSet
,並慢慢增加新 ReplicaSet
中的備用資源數量,同時減少舊 ReplicaSet
的備用資源數量。
觸發滾動式更新程序
如要更新 Deployment,請執行下列指令:
kubectl edit deployment hello
在 Deployment 的容器區段中,將 image
變更如下:
...
containers:
image: kelseyhightower/hello:2.0.0
...
依序點選「儲存」 和「退出」 。
更新後的 Deployment 會儲存於叢集,Kubernetes 則會開始進行滾動式更新。
查看 Kubernetes 建立的新 ReplicaSet
:
kubectl get replicaset
您也會在推出記錄中看到新項目:
kubectl rollout history deployment/hello
暫停滾動式更新程序
如果在推出期間偵測到問題,請暫停程序來停止更新。
請執行下列指令,暫停推出作業:
kubectl rollout pause deployment/hello
確認推出更新的目前狀態:
kubectl rollout status deployment/hello
您也可以直接從 Pod 確認目前狀態:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
繼續滾動式更新程序
暫停推出作業,代表當下某些 Pod 為新版本,其他 Pod 仍為舊版本。
您可以使用 resume
指令繼續推出:
kubectl rollout resume deployment/hello
推出完畢後,您應該會在執行 status
指令時看到下列內容:
kubectl rollout status deployment/hello
輸出內容:
deployment "hello" successfully rolled out
復原更新內容
假設您在新版本偵測到錯誤,由於新版本出現問題,因此使用者連上新 Pod 時都會遇到這些問題。
您想復原至先前的版本進行調查,然後發布妥善修正的版本。
在這種情況下,請使用 rollout
指令復原至先前的版本:
kubectl rollout undo deployment/hello
確認復原記錄:
kubectl rollout history deployment/hello
最後,確認所有 Pod 都已復原至先前版本:
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
太棒了!您已瞭解如何為 Kubernetes Deployment 進行滾動式更新,以及如何不停機即更新應用程式。
工作 4:初期測試部署
如果您想對實際工作環境中的部分使用者測試新的部署作業,可以採用初期測試部署。您可藉由這種做法對一小群使用者發布變更,以減少部署新版本的相關風險。
建立初期測試部署
初期測試部署包含獨立的新版本 Deployment,以及目標鎖定為正常、穩定部署和初期測試部署的 Service。
首先,為新版本建立新的初期測試部署:
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
...
現在,建立初期測試部署:
kubectl create -f deployments/hello-canary.yaml
建立初期測試部署後,您應該會有 hello
和 hello-canary
這兩個 Deployment。您可以使用 kubectl
指令來確認:
kubectl get deployments
hello
Service 中的 app:hello
選取器,會比對正式環境部署項目和 初期測試部署項目中的 Pod。不過,初期測試部署項目的 Pod 數量較少,因此會看見的使用者人數較少。
確認初期測試部署
您可以執行下列要求,確認系統提供的 hello
版本:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
執行這項要求數次,您就會看到部分要求由 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 則不相符,因為彼此使用的版本不同。
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
建立綠色 Deployment:
kubectl create -f deployments/hello-green.yaml
建立並正常執行綠色 Deployment 後,請確認系統仍在使用目前的版本 1.0.0:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
現在,請更新 Service 以指向新版本:
kubectl apply -f services/hello-green.yaml
更新 Service 後,系統會立即使用「綠色」Deployment。現在可以確認是否系統一定會使用新版本:
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
藍綠復原
如果有需要,您可以用相同方式復原至舊版本。
只要在「藍色」Deployment 運作時,將 Service 更新回舊版本即可:
kubectl apply -f services/hello-blue.yaml
完成更新 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 2025 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標,其他公司和產品名稱則有可能是其關聯公司的商標。