idou老師教你學Istio 19 : Istio 流量治理功能原理與實戰

CCE_huawei發表於2019-02-15

一、負載均衡演算法原理與實戰


負載均衡演算法(load balancing algorithm),定義了幾種基本的流量分發方式,在Istio中一共有4種標準負載均衡演算法。


•Round_Robin: 輪詢演算法,顧名思義請求將會依次發給每一個例項,來共同分擔所有的請求。


•Random: 隨機演算法,將所有的請求隨機分發給健康的例項


•Least_Conn: 最小連線數,在所有健康的例項中任選兩個,將請求發給連線數較小的那一個例項。


接下來,我們將根據以上幾個演算法結合APM(應用效能管理)的監控拓撲圖來實戰下。


·實戰環境·


華為雲開啟了Istio服務網格的CCE叢集 


官方最佳時間Bookinfo應用,並且給Reviews配置了五個例項


開通APM測試服務(免費)


我們知道如果使用者不進行任何配置,負載均衡演算法預設是輪詢演算法,所以我們現將負載均衡演算法設為隨機(Random)。


步驟 1

在雲容器引擎介面點選應用管理,選擇流量治理。



步驟 2

右側出現拓撲圖,在上面的選項欄中選擇叢集,名稱空間,應用。然後點選我們想配置的元件,這裡是 reviews,右側則會

出現流量治理的介面。




步驟 3

在負載均衡演算法中,由Round_Robin 改為random。


步驟 4

在左側導航欄中選擇流量治理下面的流量監控,再選擇相應的叢集,名稱空間,應用。多訪問幾次,或者後臺寫指令碼一直

curl productpage,可以從拓撲圖中觀察資料。


步驟 5

當有流量時,滑鼠右鍵點選reviews元件,選擇展開選項這時我們可以看到所有例項的被分發情況。







其餘負載均衡演算法基本一樣,我們在步驟上不做贅述,直接展示結果。



輪詢演算法:






二、會話保持原理與實戰



會話保持(Session Affinity)是透過設定的某個指標來計算,將雜湊值相同的請求分發至某個固定的例項來處理。現在支援

基於HTTP頭部設定指標和Cookie鍵值設定指標。





我們當前還在輪詢演算法中,所以所有請求會均勻的分配給所有例項,設定會話保持基於HTTP請求頭部,並且設為Cookie。

我們後臺curl的請求cookie設為了一個固定值,理論上來講所有的請求都會分發至同一個pod。


我們依然採用流量監控,展開reviews元件來觀察分發情況。







根據圖中不難看出,所有的請求都分發至了第二個例項,因為cookie一致所以保持了這個會話連結。



三、故障注入原理與實戰



故障注入(Fault Injection)為開發和測試人員主動向系統中引入故障,來觀察系統在非正常狀態下的行為,是一種可靠性,

穩定性的驗證手段。Istio也支援了非侵入式的注入故障,分為時延故障和中斷故障。




故障注入的步驟大致相同在流量治理頁面的下方,選擇時延故障,並且輸入觸發百分比和延時時間。然後再開啟

productpage 手動重新整理幾次,能明顯感覺到延遲有了變化,當然也可以開啟F12除錯介面,觀察網路請求狀況,不難發現

productpage請求耗時都在2秒上下。





這時候我們開啟流量監控介面觀察下發現productpage與reviews受到了明顯的影響。紅色表示請求狀態極差,虛線表示是

由時延造成的。


接下來我們來測試並且使用中斷故障,我們對details配置中斷故障,中斷返回碼設為501。





配置完後,我們再去手動訪問幾次productpage來觀察下結果。


發現現在的右側details已經報了error





我們回到流量監控圖,可以看到元件之間的訪問情況。在給ratings配置了中斷故障後,原本呼叫ratings元件的reviews元件,

已經無法和ratings通訊了。



本文以華為雲istio服務結合APM服務為大家演示了流量治理中的主要功能。希望大家在今後的開發和測試中可以利用istio靈

活的非侵入的治理功能提高開發和測試的效率。


相關服務請訪問https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69908804/viewspace-2636113/,如需轉載,請註明出處,否則將追究法律責任。

相關文章