使用 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 集羣部署文檔


https://hk.wxwenku.com/d/201266297