使用 GCP Kubernetes Engine 來管理部署

2月 7 2020 GCP 1 小时讀完 (大概 7841 字)

概述

Dev Ops 實踐通常使用多重部署的方法來管理應用部署情境, 像是 “持續部署”, “Blue-Green 部署”, “Canary 部署”, 等等… 本教程主要提供擴充以及管理容器的方法, 所以你可以完成這些使用多重部署的通用情境。

你將會做什麼？

Kubectl 工具的練習
建立 deployment yaml 檔案
啟動, 更新, 以及擴充 deployments
更新 deployments 以及部署風格的練習

事先準備

在開始本教程之前, 你應該至少完成 Introduction to Docker 以及 Hello Node Kubernetes
Linux 系統管理技能
Dev Ops 理論：持續部署的概念

deployments 介紹

Heterogeneous deployments (多種類部署) 一般來說包含兩個或多個基礎設施或地區以解決特定技術或運作需求。 Heterogeneous deployments 又被稱為 “hybrid”, “multi-cloud”, 或 “public-private”, 取決於部署細節。
在本教程中, heterogeneous deployments 包含地區橫跨單一雲端環境, 多公開雲端環境 (multi-cloud), 或是內部部署以及公開雲端的結合 (hybrid 或 public-private)

單一環境或地區的部署可能會在業務邏輯上或技術上有一些問題

資源耗盡: 在單一環境中, 尤其是內部部署環境, 你可能沒有正式環境需要的計算, 網路, 或儲存資源
被限制的觸及地區: 單一環境的部署需要不同區域的人們存取不同區域的部署, 他們的流量可能會繞了世界一周之後才到達一個中間地區
被限制的可用性: 網路擴充流量模式對應用保持容錯以及適應, 會是一個挑戰
供應商鎖定: 供應商等級的平台以及基礎設施抽象將讓應用移植變得困難
不靈活的資源: 你的資源可能會被限制在一組特定的計算機, 儲存區, 或網路

Heterogeneous 可幫我們解決這些難題, 但他們必須被建構在可程式化以及確定性的程序以及步驟。一次性的或點對點的部署步驟會造成部署或程序脆弱, 以及容錯能力降低。點對點程序會丟失資料或丟棄流量。一個好的部署程序需要是可重複的, 使用已確認可用的方法來管理提供, 設定, 以及維護。

三個 heterogeneous 通用的情境, 分別是 multi-cloud deployments (多雲端部署), fronting on-premises data (前端導向內部資料), 以及 CI/CD (持續整合 / 持續部署) 程序

以下的練習會實作一些 heterogeneous deployments 通用使用情境, 以及透過良好架構的 Kubernetes 方法以及其他的基礎設施資源來達成

設定及要求

在你按下 Start Lab 按鈕之前

詳讀所有的教學。 Labs 是有時間限制的, 而且你不可以停止時間倒數。倒數計時器在你按下 Start Lab 按鈕後開始倒數, 上面顯示的時間為你還能使用 Cloud 資源的時間。

Qwiklabs 的手把手環境, 讓你可以在真實環境中來操作進行 Qwiklabs 上提供的課程, 而不是在一個模擬或是展示的環境。我們透過提供你一個全新的、暫時的帳號密碼, 在計時器歸零之前, 你可以用來登入並存取 Google Cloud Platform。

你需要什麼？

要完成這個 lab, 你需要:

一個一般的網路瀏覽器（推薦 Chrome）
完成這個 lab 的時間

備註： 如果你已經有你自己的個人 GCP 帳號或專案,請不要使用在這一個 lab

現在你已經開始你的 lab, 你將會登入 Google Cloud Shell 主控台, 然後開啟命令列工具

如何開始你的 lab, 然後登入 Console?

按下 Start Lab 按鈕。如果你需要付費, 會有一個彈出視窗來讓你選擇付費的方式。在左方你會看到一個面板, 上面有暫時的帳號密碼, 你必須使用這些帳號密碼在此次 lab

複製 username, 然後點擊 Open Google Console。 Lab 會開啟另外一個視窗, 顯示選擇帳號的頁面

tip: 開啟一個全新的視窗,然後跟原本的頁面並排

在選擇帳號頁面, 點擊 Use Another Account

登入頁面開啟, 貼上之前複製的 username 以及 password, 然後貼上

重要： 必須使用之前於 Connection Details 面板 取得的帳號密碼,不要使用你自己的 Qwiklabs 帳號密碼。如果你有自己的 GCP 帳號, 請不要用在這裡（避免產生費用）

點擊並通過接下來的頁面:
- 接受 terms 以及 conditions
- 不要增加 recovery optoins 或 two factor authentication (因為這只是一個臨時帳號)
- 不要註冊免費體驗

稍待一些時候, GCP 控制台將會在這個視窗開啟。

注意： 按下左上方位於 Google Cloud Platform 隔壁的 Navigation menu, 你可以瀏覽選單, 裡面有一系列的 GCP 產品以及服務

啟動 Google Cloud Shell

Google Cloud Shell 是載有開發工具的虛擬機器。它提供了5GB的 home 資料夾, 並且運行在 Google Cloud 上。 Google Cloud Shell 讓你可以利用 command-line 存取 GCP 資源

在 GCP 控制台, 右上的工具列,點擊 Open Cloud Shell 按鈕

在打開的對話框裡, 按下 START CLOUD SHELL:

你可以立即按下 START CLOUD SHELL 當對話視窗打開。

連結並提供環境會需要一點時間。當你連結成功, 這代表你已成功獲得授權, 且此專案已被設為你的專案ID, 例如：

gcloud 是 Google Cloud Platform 的 command-line 工具, 他已事先被安裝在 Cloud Shell 並且支援自動補齊

使用這個 command, 你可以列出有效帳戶名稱:

gcloud auth list

輸出:

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

範例輸出:

Credentialed accounts:
 - google1623327_student@qwiklabs.net

你可以使用以下 command 來列出專案 ID

gcloud config list project

輸出：

[core]
project = <project_ID>

範例輸出：

[core]
project = qwiklabs-gcp-44776a13dea667a6

gcloud 的完整文件可以參閱 Google Cloud gcloud Overview

設定 zone

執行以下指令來設定你的 GCP zone, 將 local zone us-central1-a 替換掉

gcloud config set compute/zone us-central1-a

取得本教程範例程式碼

取得建立, 運行容器以及 deployments 的範例程式碼

git clone https://github.com/googlecodelabs/orchestrate-with-kubernetes.git
cd orchestrate-with-kubernetes/kubernetes

建立一個含有 5 台 n1-standard-1 node 的叢集 (會需要幾分鐘時間完成)

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

理解 deployment 物件

讓我們從 Deployments 開始。首先檢視一下 Deployment 物件。 kubectl 的 explain 指令可以告訴我們有關 Deployment 物件的資訊

kubectl explain deployment

我們可以使用 --resursive 選項來檢視所有的欄位

kubectl explain deployment --recursive

在你進行本教程的過程中, 你可以使用 explain 來更了解 Deployment 物件的結構, 以及每個欄位做什麼事

kubectl explain deployment.metadata.name

建立 deployment

更新 deployments/auth.yaml cs 檔案：

vim deployments/auth.yaml

開始編輯模式

將 container 區塊內的 image 變更如下：

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

儲存 auth.yaml 檔案, 按下 <Esc>, 然後：

:wq

現在讓我們來建立一個簡單的 deployment 。檢視 deployment 設定檔

cat deployments/auth.yaml

(輸出)

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  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 是如何建立一個 replica 且使用 auth container 的 version 1.0.0

當你執行 kubectl create 指令來建立 auth deployment 時, 一個符合 Deployment 設定檔的 pod 將會被建立。這表示說, 我們可以藉由變更 replica 欄位的數量擴縮 Pods 的數量

使用 kubectl create 來建立 deployment 物件

kubectl create -f deployments/auth.yaml

一旦你已經建立 Depolyment, 你可以確認看看它是否有被建立

kubectl get deployments

一旦 deployment 被建立了, Kubernetes 會建立一個相對應的 ReplicaSet 。我們可以確認對應該 Deployment 的 ReplicaSet 是否有被建立

kubectl get replicasets

我們應會看到一個名為 auth-xxxxxx 的 ReplicaSet

最後, 我們可以檢視 Pods, 它是 Deployment 的一部分。當 ReplicaSet 被建立, Kubernetes 會建立一個 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

注意: 你為 frontend 建立了一個 ConfigMap

取得 frontend 的外部 IP 然後使用 curl 與它互動

kubectl get services frontend
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 deployments, 你將獲得一個評價分數。

擴縮 Deployment

現在我們已建立一個 Deployment, 我們可以擴縮它。可以藉由更新 spec.replicas 欄位來達成。你可以再次使用 Kubectl explain 指令來檢視這個欄位的解釋

kubectl explain deployment.spec.replicas

更新 replicas 欄位最簡單的方法就是使用 kubectl scale 指令

kubectl scale deployment hello --replicas=5

注意: 要讓全部的 pods 都啟動且運行約需要幾分鐘
Deployment 建立後, Kubernetes 會自動地更新相對應的 ReplicaSet 以及啟動新的 Pods, 讓 Pods 的總數量等於 5

確認是否有 5 個 hello Pods 運行中：

kubectl get pods | grep hello- | wc -l

現在擴縮回原本的數量

kubectl scale deployment hello --replicas=3

再一次, 確認 Pods 的數量是正確的

kubectl get pods | grep hello- | wc -l

你已經學習了 Kubernetes deployments 以及如何管理 & 擴縮 Pods 群組

rolling update (滾動升級)

Deployments 支援透過滾動升級的機制進行鏡像升級。當 Deployment 被更新成新的版本, 它會建立一個新的 ReplicaSet, 並且慢慢的增加新版的 replicas 的數量, 同時, 也慢慢地減少舊版的 replicas 數量

觸發滾動升級

執行以下指令來更新 Deployment:

kubectl edit deployment hello

將 containers 區塊內的 image 變更如下：

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

儲存並離開
一但你成功的儲存編輯器, 更新的 Deployment 會被儲存到你的叢集, 然後 Kubernetes 將會開始滾動升級。
檢視 Kubernetes 新建立的 ReplicaSet

kubectl get replicaset

同時你也可以檢視 rollout 的紀錄

kubectl rollout history deployment/hello

暫停滾動升級

如果在滾動升級的過程中, 你發現一些問題, 你可以停止升級

kubectl rollout pause deployment/hello

確認目前的滾動狀態

kubectl rollout status deployment/hello

你也可以直接透過 Pods 資訊來確認

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

繼續滾動升級

滾動升級被中斷了, 這表示有一些 Pods 正運行著新版本而有些 Pods 運行舊版本。我們可以使用以下的 resume 指令來繼續未完成的滾動

kubectl rollout resume deployment/hello

當滾動完成了, 你執行 status 指令時, 應會看到輸出如下：

kubectl rollout status deployment/hello

(輸出)

deployment "hello" successfully rolled out

回滾

假設我們在新版本發現了一個 bug 。因為新版本有問題, 任何存取新的 Pods 資源的使用者都會遇到這個問題
你會想要回滾之前的版本, 所以你可以看看出了什麼問題, 待修復後再發布一個新的版本
使用 rollout 指令來回滾到之前的版本

kubectl rollout undo deployment/hello

確認回滾歷史

kubectl rollout history deployment/hello

最後, 確認所有的 Pods 都有回滾到之前的版本

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

帥氣！你已經學會 Kubernetes 的滾動升級, 以及如何 0 downtime 的更新你的應用

金絲雀部署 (Canary Deployments)

當你想要在正式環境只對一部分的使用者進行新版本的測試, 你可以使用金絲雀部署。金絲雀部署讓你可以只發布變更到一小部分的使用者, 降低新發布的風險

建立一個金絲雀部署 (canary deployment)

金絲雀部署包含分開的 deployment, 以及一個共同的 service, 這個 service 可以導向穩定, 一般的版本, 以及金絲雀版本

首先, 建立一個新的金絲雀 deployment

cat deployments/hello-canary.yaml

(輸出)

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

確認有更新到版本 1.0.0 (如果你的版本是指向其他的)
現在建立一個金絲雀 deployment

kubectl create -f deployments/hello-canary.yaml

金絲雀 deployment 被建立後, 你應會有兩個 deployments, hello 以及 hello-canary 。使用以下的 kubectl 指令來確認:

kubectl get deployments

在 hello service, selector 使用 app:hello selector, 這將會同時符合 prod deployment 以及 canary deployment 。然而, 因為 canary deployment 的 pods 數量較少, 所以它對使用者的可見度來說是相對低的。

確認 canary deployment

你可以發請求, 並經由以下指令來確認服務該請求的 hello 版本

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

執行這個指令多次, 你應會看到有一些請求是由 hello 1.0.0 所服務, 而有一小部分 (1/4 = 25%) 的請求是由 2.0.0 所服務

測試進度
點擊 Check my progress 來確認目前的進度。如果你已經建立金絲雀部署, 你將獲得一個評價分數。

在正式環境中的 Canary deployments - session affinity

在本教程中, 每個發往 Nginx 服務的請求都有機率由 canary deployment 所服務。但如果是你不想要某些使用者是由 canary deployment 來服務呢？一個使用情境是當你 canary deployment 的 UI 有變動, 而你不想要讓使用者覺得疑惑。在這個使用情境中, 你想要讓使用者們可以固定的被不同的 deployment 所服務, 不會一直切換來切換去的。

你可以建立一個賦有 session affinity 的 service 。這個方法會讓使用者總是被同一個版本的 deployment 服務。在以下的範例中, 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

Blue-green deployment

滾動升級是個理想的部署方式, 因為它讓我們可以用最小效能影響, downtime, 以及花費來部署應用。然而在某些情況中, 待新版本部署完成後, 修改平衡負載指向新版本, 這種方式會是比較有利的。在這樣的使用情境下, blue-green 部署會是我們需要的方式
Kubernetes 藉由建立兩個分開的 deployments 來達成這個目的; 一個舊的 “blue” 版本的 deployment 以及一個新的 “green” 版本的 deployment 。使用已存在的 hello 來作為 “blue” 版本。這個 deployment 將會透過一個角色為路由的 Service 來被存取。一旦新的 “green” 版本已成功啟動並且運行中, 你可以藉由更新這個 service 來切換使用新版本。

blue-green deployments 有一個主要的缺點, 那就是你必須在叢集中要有至少 2 組以上的資源來運行你的應用。在你同時部署兩個版本的應用到叢集之前, 務必確認你有足夠的資源。

The service (服務)

使用已存在的 hello service, 但是把它的 selector 更新成 app:hello, version: 1.0.0 。這個 selector 會符合 “blue” deployment, 但不會符合 “green” deployment 因為它使用不同的版本
首先更新服務：

kubectl apply -f services/hello-blue.yaml

更新使用 Blue-Green deployment

我們將建立一個新版本 “green” deployment 來支援 blue-green deployment 風格。這個 green deployment 更新了版本標籤以及鏡像路徑。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hello-green
spec:
  replicas: 3
  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

建立 green deployment

kubectl create -f deployments/hello-green.yaml

一但你已經建立好 green deployment, 並且它已經被正確啟動且運行, 確認目前是否還是使用 1.0.0 的版本

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

現在更新服務來指向新的 deployment 版本

kubectl apply -f services/hello-green.yaml

當 service 被更新後, “green” deployment 會立即地被使用。你可以確認新版本是否一直被使用著

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

Blue-Green 回滾

如果需要的話, 你也可以使用同樣的方式回滾到舊的版本。儘管 “blue” deployment 還在運行著, 可以直接更新 service 到舊的版本

kubectl apply -f services/hello-blue.yaml

一但你更新了服務, 回滾也就完成了。再一次, 確認看看目前使用中的是否是正確的版本

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

你做到了！你已經學到 blue-green deployment 以及如何立即全部一次切換的部署方法

恭喜

你已經完成本教程!

Q&A

以下的 deployment yaml 檔設定分別代表什麼意思？

deployment yaml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  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

Answer:

# apiVersion: 版本, 會隨著版本而變動, 可參考[文件](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#-strong-api-overview-strong-)
apiVersion: extensions/v1beta1
# 種類, 可參考[文件](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#-strong-api-overview-strong-)
kind: Deployment
# 該 Deployment 的 metadata
metadata:
  # 該 deployment 的 name
  name: auth
# 該 deployment 運行的規格
spec:
  # pod 數量
  replicas: 1
  # pod 樣板
  template:
    # pod 的 metadata
    metadata:
      # label, 可被 selector 挑選, 為 key/value pair
      labels:
        app: auth
        track: stable
    # pod 運行規格
    spec:
      # 定義容器
      containers:
          # 容器名稱
        - name: auth
          # 鏡像名稱
          image: "kelseyhightower/auth:1.0.0"
          # 定義 port
          ports:
              # port 名稱
            - name: http
              # port 號
              containerPort: 80
              # port 名稱
            - name: health
              # port 號
              containerPort: 81

以下的 Kubernetes yaml 設定檔的意思是？

yaml 檔

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth: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

Answer:

# api 版本
apiVersion: extensions/v1beta1
# 種類為 Deployment
kind: Deployment
# Deployment 的 metadata
metadata:
  # Deployment 的 name
  name: auth
# 該 Deployment 運行的規格
spec:
  # 該 Deployment 共會啟動幾個 Pod
  replicas: 1
  # 該 Pod 的詳細資料
  template:
    # 該 Pod 的 metadata
    metadata:
      # 該 Pod 的 label, 可透過 selector 被選取
      labels:
        # 自定義的 key/value pair
        app: auth
        track: stable
    # 該 Pod 的規格
    spec:
      # 容器規格
      containers:
          # 容器名稱
        - name: auth
          # 鏡像名稱
          image: "kelseyhightower/auth:2.0.0"
          # 該容器的 port 定義
          ports:
              # port 名稱
            - name: http
              # port 號
              containerPort: 80
              # port 名稱
            - name: health
              # port 號
              containerPort: 81
          # 容器的資源定義
          resources:
            # 限制
            limits:
              cpu: 0.2
              memory: "10Mi"
          # 存活探針
          livenessProbe:
            # 探測類型
            httpGet:
              # 探測路徑
              path: /healthz
              # 探測 port 號
              port: 81
              scheme: HTTP
            # 首次執行探針時需要延遲的時間, 以確保容器內各項工作都已準備就緒, 如果一啟動就探測的話很可能會直接失敗
            initialDelaySeconds: 5
            # 每隔 15 秒探測一次
            periodSeconds: 15
            # 探測時, 如果超過幾秒沒回覆視為失敗
            timeoutSeconds: 5
          # 就緒探針, 如果尚未就緒, service 不會將流量導向該容器
          readinessProbe:
            # 探測方式為 httpGet
            httpGet:
              # 探測 url
              path: /readiness
              # 探測 port 號
              port: 81
              # 使用 http 還是 https
              scheme: HTTP
            # 首次啟動 readinessProbe 時, 等待五秒
            initialDelaySeconds: 5
            # 若超過 1 秒沒有 response, 視為失敗
            timeoutSeconds: 1