前言

本篇我們來講解什麼是部屬策略(Deployment Strategies)，並使用 Bookinfo Application 在 Kubernetes 實踐藍綠部屬 (Blue/Green Deployment)。

什麼是部署策略(Deployment Strategies)?

現今應用程式發展迅速，服務的更新也變得越來越頻繁，要如何在不影響用戶的前提下讓服務升級呢?這時就需要使用到部屬策略。部屬策略是指將新的應用程式部屬到正式環境時所採用的方式，目標是讓系統跟使用者的影響都降至最低，以下是常見的部署策略

重建(Recreate)

將 v1 版本下線後讓 v2 版本上線

滾動部署(Rolling-update)

v1 版本緩慢更新至 v2 版本

藍綠部署(Blue/Green Deployment)

先將 v2 版本部屬到正式環境，經過測試後再把流量從 v1 版本切換至 v2 版本

金絲雀部屬(Canary)

逐步將正式環境的流量從 v1 版本轉移到 v2 版本

A/B測試(A/B Testing)

使用特定帳號測試 v2版本，完成後再把流量從 v1 版本切換至 v2 版本

使用 Kubernetes 的原因之一在於它能輕鬆的實現部屬策略，如 Kubernetes Deployment 就有提供 Rolling-update 功能

藍綠部屬 (Blue/Green Deployment) 介紹

藍綠部屬的原理很簡單，需在正式環境中同時建立 v1 版本以及 v2 版本的應用程式，v1 版本負責當前的服務，v2 版本測試沒問題後，即可將 v1 的流量轉移至 v2，以此完成系統的升級。v2 版本上線後，若無異常情況，就可刪除 v1 版本，若發生異常，也可以將流量轉回 v1 版本，使服務不會中斷。

圖片取自 Six Strategies for Application Deployment

在 Kubernetes 實現藍綠部屬

那要如何在 Kubernetes 實現藍綠部屬呢，前一章 我們在 Kubernetes 建立了 Bookinfo Application， Reviews 元件同時部署了三個版本在環境中，如同藍綠部屬講到的第一步，需先在環境中部署不同版本的應用程式。

在完成不同版本的測試後，接著就要將流量切換至新版本，這個機制可以借助 Kubernetes Service 的 Label Selector 來完成，Label Selector 會根據設定的標籤來尋找到對應的 Pod，所以只要在 Pod 上設定不同版本號的 Label，要做流量切換時修改 Label Selector 的設定即可。

原先並沒有設置版本相關 Label，流量會在三個版本的 Pod 之間做負載平衡

在 Label Selector 設定 versions: v2 Label 後，即可將流量都移轉到 Reviews-v2 的 Pod 上

接下來透過實際操作，使用 Bookinfo Application 在 Kubernetes 實踐藍綠部屬吧!

1. 使用 kubectl apply -f <file> 部屬 Bookinfo Application

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.15/samples/bookinfo/platform/kube/bookinfo.yaml

2. 在 reviews Service 的 Label Selector 設定 version: v1 的 Label ，使流量轉移到 v1 版本

kubectl patch service reviews -p '{"spec":{"selector":{"app": "reviews","version": "v1"}}}'

3. 使用 kubectl describe svc <name>取得 Serice 詳細資訊

kubectl describe svc reviews

(輸出結果)

...
Selector:          app=reviews,version=v1
...

確認 Label 都已設置完成

4. 使用 kubectl port-forward 將流量轉入應用程式

kubectl port-forward svc/productpage 8080:9080

5. 在瀏覽器輸入網址連接至服務

# 在瀏覽器輸入
http://127.0.0.1:8080/productpage

此時可以觀察到 Reviews 都會使用 v1 版本的資料

當我們要升級 Reviews 元件版本，需先將 v2 版本部屬完成，並且經過完整測試，都準備好了之後，只需一行指令即可完成版本間的流量轉移。

6. 在 reviews Service 的 Label Selector 設定 version: v2 的 Label ，使流量轉移到 v2 版本

kubectl patch service reviews -p '{"spec":{"selector":{"app": "reviews","version": "v2"}}}'

7. 回到瀏覽器查看

# 在瀏覽器輸入
http://127.0.0.1:8080/productpage

此時可以觀察到 Reviews 已經升級為 v2 版本的資料，可以試著類推做 v3 的升級看看

總結

本篇講解了部屬策略並且在 Kubernetes 上實踐，下一篇將探討 Kubernetes 深入的原理，帶你了解為何 Kubernetes 會需要 Istio。

筆者也很想趕快進入到 Istio 環節，無奈要介紹的機制實在有點多 Orz