使用 KubeSphere 輕鬆實現微服務灰度釋出與熔斷

2019-08-30 11:03:18


KubeSphere®️ 是在目前主流容器排程平臺 Kubernetes 之上構建的企業級分散式多租戶容器管理平臺,提供簡單易用的操作介面以及嚮導式操作方式,在降低使用者使用容器排程平臺學習成本的同時,極大減輕開發、測試、運維的日常工作的複雜度,旨在解決 Kubernetes 本身存在的儲存、網路、安全和易用性等痛點。

除此之外,平臺已經整合並優化了多個適用於容器場景的功能模組,以完整的解決方案幫助企業輕鬆應對敏捷開發與自動化運維、微服務治理、多租戶管理、工作負載和叢集管理、服務與網路管理、應用編排與管理、映象倉庫管理和儲存管理等業務場景。

KubeSphere 高階版還提供企業級容器應用管理服務,支援更強大的功能和靈活的配置,滿足企業複雜的業務需求。比如支援 Master 和 etcd 節點高可用、視覺化 CI/CD 流水線、多維度監控告警日誌、多租戶管理、LDAP 整合、新增支援 HPA (水平自動伸縮) 、容器健康檢查以及 Secrets、ConfigMaps 的配置管理等功能,新增微服務治理、灰度釋出、s2i、程式碼質量檢查等,後續還將提供和支援多叢集管理、大資料、人工智慧等更為複雜的業務場景。

KubeSphere 從專案初始階段就採用開源的方法來進行專案的良性發展,專案相關的原始碼和文件都在 GitHub 可見。

專案地址:https://github.com/kubesphere/kubesphere

KubeSphere 架構圖

本文將演示如何使用 KubeSphere 輕鬆實現微服務的灰度釋出與熔斷。

灰度釋出,是指在黑與白之間能夠平滑過渡的一種釋出方式。通俗來說,即讓產品的迭代能夠按照不同的灰度策略對新版本進行線上環境的測試,灰度釋出可以保證整體系統的穩定,在初始灰度的時候就可以對新版本進行測試、發現和調整問題。

KubeSphere 基於 Istio 提供了藍綠部署、金絲雀釋出、流量映象等三種灰度策略,無需修改應用的業務程式碼,即可實現灰度、流量治理、Tracing、流量監控、呼叫鏈等服務治理功能。本文使用 Istio 官方提供的 Bookinfo 微服務示例,基於 KubeSphere 快速建立一個微服務應用並對其中的服務元件進行灰度釋出與熔斷。

Bookinfo 微服務應用架構

開始之前,先簡單介紹一下 Bookinfo 示例微服務應用的架構,該應用分為四個單獨的微服務:

  • productpage :productpage 微服務會呼叫 details 和 reviews 兩個微服務,用來生成頁面。

  • details :這個微服務包含了書籍的資訊。

  • reviews :這個微服務包含了書籍相關的評論,它還會呼叫 ratings 微服務。

  • ratings :ratings 微服務中包含了由書籍評價組成的評級資訊。

reviews 微服務有 3 個版本:

  • v1 版本不會呼叫 ratings 服務,因此在介面不會顯示星形圖示。

  • v2 版本會呼叫 ratings 服務,並使用 1 到 5 個黑色星形圖示來顯示評分資訊。

  • v3 版本會呼叫 ratings 服務,並使用 1 到 5 個紅色星形圖示來顯示評分資訊。

(Bookinfo 架構圖與示例說明參考自 https://istio.io/docs/examples/bookinfo/)

Step 1:部署 Bookinfo

1.1. KubeSphere 內建了 Bookinfo 示例應用,在專案中可一鍵部署 Bookinfo。

1.2. 確認應用狀態顯示 Ready,則說明 bookinfo 微服務建立成功。

Step 2:訪問 Bookinfo 應用

2.1. 點選 bookinfo 進入應用詳情頁,可以看到應用路由下自動生成的 hostname。

提示:本地需在  /etc/hosts 檔案中為 hostname 新增一條記錄:{$公網 IP} {$hostname},才可以訪問該示例應用。

2.2. 在應用路由下選擇 「點選訪問」,可以看到 bookinfo 的 details 頁面。

2.3. 點選 Normal user 訪問 productpage。注意此時 Book Reviews 部分的版本為 v1,只顯示了 Reviewer1 和 Reviewer2。

Step 3:新增灰度釋出

3.1. 回到 KubeSphere,選擇 「灰度釋出」,點選 「釋出灰度任務」。

3.2. 本文選擇 「金絲雀釋出」 作為灰度策略,點選 「釋出任務」。

3.3. 在彈窗中,填寫釋出任務名稱為 bookinfo-canary,點選 「下一步」。點選 reviews 一欄的 「選擇」,即選擇對應用元件 reviews 進行灰度釋出,點選 「下一步」。

3.4. 參考如下填寫灰度版本資訊,完成後點選 「下一步」。

  • 灰度版本號:v2;

  • 映象:istio/examples-bookinfo-reviews-v2:1.10.1 (將 v1 改為 v2)。

3.5. 金絲雀釋出允許按流量比例下發按請求內容下發等兩種釋出策略,來控制使用者對新老版本的請求規則。本示例選擇 按流量比例下發,流量比例選擇 v1 與 v2 各佔 50 %,點選 「建立」。

Step 4:驗證金絲雀釋出

再次訪問 Bookinfo 網站,重複重新整理瀏覽器後,可以看到 bookinfo 的 reviews 模組在 v1 和 v2 模組按 50% 概率隨機切換。

Step 5:檢視流量拓撲圖

開啟命令列視窗輸入以下命令,引入真實的訪問流量,模擬對 bookinfo 應用每 0.5 秒訪問一次。注意以下命令是模擬 Normal user 訪問,需要輸入完整的命令訪問到具體的服務在鏈路圖中才有流量資料。

$ watch -n 0.5 "curl http://productpage.demo-namespace.139.198.111.111.nip.io:31680/productpage?u=normal"

從流量治理的鏈路圖中,可以看到各個微服務之間的服務呼叫和依賴、健康狀況、效能等情況。

檢視 Tracing

如果在鏈路圖中發現了服務的流量監測異常,還可以在 Tracing 中追蹤一個端到端呼叫經過了哪些服務,以及各個服務花費的時間等詳細資訊,支援進一步檢視相關的 Header 資訊,每個呼叫鏈由多個 Span 組成。如下可以清晰的看到某個請求的所有階段和內部呼叫,以及每個階段所耗費的時間。

Step 6:設定熔斷規則

從上述的流量拓撲圖中可以看到,實際上一個微服務系統的各個服務之間在網路上可能存在大量的呼叫。在呼叫過程中,如果某個服務繁忙或者無法響應請求,可能會引發叢集的大規模級聯故障,從而造成整個系統不可用,引發服務雪崩效應。當下遊服務因訪問壓力過大而響應變慢或失敗,上游服務為了保護系統整體的可用性,可以暫時切斷對下游服務的呼叫,達到服務降級的效果,這種通過犧牲區域性保全整體的措施就叫做熔斷(Circuit Breaking)。

接下來將對 Bookinfo 其中的一個服務設定熔斷規則,並通過一個負載測試客戶端 (fortio) 來觸發熔斷機制。

點選 ratings,在右側展開 「流量治理」,開啟 「連線池管理」 和 「熔斷器」,參考如下設定。

  • 連線池管理:將 最大連線數最大等待請求數(等待列隊的長度) 都設定為 1,表示如果超過了一個連線同時發起請求,Istio 就會熔斷,阻止後續的請求或連線;

  • 熔斷器:參考如下設定,表示每 1 秒鐘掃描一次上游主機,連續失敗 5 次返回 5xx 錯誤碼的 100% 數量的主機 (Pod) 會被移出連線池 180 秒,引數釋義參考 熔斷器。

    • 連續錯誤響應(5xx)個數:5;

    • 檢查週期(單位: s):1;

    • 容器組隔離比例(單位: %):100;

    • 短隔離時間(s):180。

連線池引數說明:

  • 最大連線數:表示在任何給定時間內, Envoy 與上游叢集(比如這裡是 ratings 服務)建立的最大連線數,適用於 HTTP/1.1;

  • 每連線最大請求數:表示在任何給定時間內,上游叢集中所有主機(比如這裡是 ratings 服務)可以處理的最大請求數。對後端連線中最大的請求數量若設為 1 則會禁止 keep alive 特性;

  • 最大請求重試次數:在指定時間內對目標主機最大重試次數;

  • 連線超時時間:TCP 連線超時時間,最小值必須大於 1ms。最大連線數和連線超時時間是對 TCP 和 HTTP 都有效的通用連線設定;

  • 最大等待請求數 (等待列隊的長度):表示待處理請求佇列的長度,預設為 1024。如果該斷路器溢位,叢集的 upstream_rq_pending_overflow 計數器就會遞增。

Step 7:設定客戶端

由於我們已經在 reviews-v2 中 reviews 容器中注入了負載測試客戶端 (fortio),它可以控制連線數量、併發數以及傳送 HTTP 請求的延遲,能夠觸發在上一步中設定的熔斷策略。因此可以通過 reviews 容器來向後端服務傳送請求,觀察是否會觸發熔斷策略。

在右下角找到小錘子圖示開啟 Web kubectl (或直接 SSH 登入叢集任意節點)。執行以下命令登入客戶端 Pod (reviews-v2) 並使用 Fortio 工具來呼叫 ratings 服務,-curl 引數表明只調用一次,返回 200 OK 表示呼叫成功。

$ FORTIO_POD=$(kubectl get pod -n demo-namespace | grep reviews-v2 | awk '{print $1}')
$ kubectl exec -n demo-namespace -it $FORTIO_POD -c reviews /usr/bin/fortio -- load -curl http://ratings:9080/ratings/0HTTP/1.1 200 OK···

Step 8:觸發熔斷機制

8.1. 在 ratings 中設定了連線池管理的熔斷規則,最大連線數最大等待請求數(等待列隊的長度) 都設定為 1,接下來設定兩個併發連線(-c 2),傳送 20 請求(-n 20):

$ kubectl exec -n demo-namespace -it $FORTIO_POD -c reviews /usr/bin/fortio -- load -c 2 -qps 0 -n 20 -loglevel Warning http://ratings:9080/ratings/0
···Code 200 : 18 (90.0 %)Code 503 : 2 (10.0 %)···

8.2. 以上可以看到,幾乎所有請求都通過了,Istio-proxy 允許存在一些誤差。接下來把併發連線數量提高到 3:

$ kubectl exec -n demo-namespace -it $FORTIO_POD -c reviews /usr/bin/fortio -- load -c 3 -qps 0 -n 30 -loglevel Warning http://ratings:9080/ratings/0
···Code 200 : 22 (73.3 %)Code 503 : 8 (26.7 %)···

8.3. 檢視結果發現熔斷行為按照之前的設定規則生效了,此時僅 73.3 % 的請求允許通過,剩餘請求被斷路器攔截了。由於此時 503 的返回次數為 8,超過了預先設定的連續錯誤響應(5xx)個數 5,此時 ratings 的 Pod 將被 100% 地隔離 180 s,ratings 與 reviews-v2 之間也出現了灰色箭頭,表示服務間的呼叫已斷開,ratings 被完全隔離。

8.4. 可以給 reviews-v2 的部署 (Deployment) 新增如下一條 annotation,即可查詢 ratings 的 istio-proxy 的狀態。在 「工作負載」→ 「部署」列表中找到 reviews-v2,點選右側 ··· 選擇 「編輯配置檔案」,新增一條 sidecar.istio.io/statsInclusionPrefixes 的 annotation,完成後點選 「更新」。

···  annotations:    sidecar.istio.io/inject: 'true'    sidecar.istio.io/statsInclusionPrefixes: 'cluster.outbound,cluster_manager,listener_manager,http_mixer_filter,tcp_mixer_filter,server,cluster.xds-grpc'···

8.5. 查詢 istio-proxy 的狀態,獲取更多相關資訊。如下所示 upstream_rq_pending_overflow 的值是 10,說明有 10 次呼叫被熔斷。

$ kubectl exec -n demo-namespace -it $FORTIO_POD  -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep ratings | grep pending···cluster.outbound|9080|v1|ratings.demo-namespace.svc.cluster.local.upstream_rq_pending_overflow: 10cluster.outbound|9080|v1|ratings.demo-namespace.svc.cluster.local.upstream_rq_pending_total: 41···

Step 9:接管流量下線舊版本

中間順帶演示了熔斷,回到之前建立的灰度釋出。當新版本 v2 灰度釋出後,釋出者可以對線上的新版本進行測試和收集使用者反饋。如果測試後確定新版本沒有問題,希望將流量完全切換到新版本,則進入灰度釋出頁面進行流量接管。

9.1. 點選 「灰度釋出」,進入 bookinfo 的灰度釋出詳情頁,點選 ··· 選擇 「接管所有流量」,正常情況下所有流量將會指向 v2。

9.2. 再次開啟 bookinfo 頁面,多次重新整理後 reviews 模組也僅僅只顯示 v2 版本。

9.3. 當新版本 v2 上線接管所有流量後,並且測試和線上使用者反饋都確認無誤,即可下線舊版本,釋放資源 v1 的資源。下線應用元件的特定版本,會同時將關聯的工作負載和 istio 相關配置資源等全部刪除。

總結

本文先簡單介紹了微服務示例應用 Bookinfo 的架構,然後使用 KubeSphere 容器平臺通過 Step-by-Step Guide 說明了灰度釋出、流量治理與熔斷的操作。

微服務治理與監控是微服務管控中非常重要的一環,而 Service Mesh 作為下一代微服務技術的代名詞,KubeSphere 基於 Istio 提供了更簡單易用的 Service Mesh 視覺化與治理功能。KubeSphere 還在持續迭代和快速發展,歡迎大家在 GitHub 關注和下載試用。

參考

  1. KubeSphere GitHub:https://github.com/kubesphere/kubesphere

  2. 在 k8s 叢集部署 KubeSphere:https://mp.weixin.qq.com/s/FcCBXs-f_VsNPp9qdMDfNQ

  3. Bookinfo 微服務的灰度釋出示例:https://kubesphere.io/docs/advanced-v2.0/zh-CN/quick-start/bookinfo-canary/


你可能還喜歡

點選下方圖片即可閱讀

史上最全的生產環境下 Kubernetes 叢集部署文件


已同步到看一看
在看



熱點新聞