在K8S上部署的微服務(wù)，經(jīng)常會依賴不受你控制的其他微服務(wù)。當(dāng)兩者之間的HTTP交互出現(xiàn)延遲或錯誤后，你的微服務(wù)能否按預(yù)期正常工作？應(yīng)該做一個故障注入實驗來檢驗一下。如果在K8S上使用了Istio，那么恭喜你，你已經(jīng)擁有了簡單易用的混沌工程開源工具。

官網(wǎng)

https://github.com/istio/istio

一句話介紹

雖然Istio主要作為K8S服務(wù)網(wǎng)格，用于連接、保護(hù)、控制和觀察服務(wù)，但在其流量管理功能中也支持故障注入。

關(guān)鍵特性

Istio 可以將HTTP延遲或 HTTP 錯誤注入任何虛擬服務(wù)之間的網(wǎng)絡(luò)流量中。 實驗以 Kubernetes manifest形式定義。可以使用現(xiàn)有的 Istio 功能（例如虛擬服務(wù)和路由規(guī)則）來選擇故障注入目標(biāo)。 還可以使用運行狀況檢查和 Envoy 統(tǒng)計數(shù)據(jù)來監(jiān)控故障注入對系統(tǒng)的影響。

故障注入實驗利用了 Istio 在網(wǎng)絡(luò)中的地位來執(zhí)行實驗，而無需添加任何額外的混沌工程工具或功能。

適用平臺

K8S

適用場景

如果已經(jīng)使用了 Istio，那么這可以直接用它在集群上運行混沌實驗，而無需部署或?qū)W習(xí)其他工具。 否則，僅僅為了這兩種故障注入功能就部署 Istio ，就不值了。

優(yōu)勢

故障注入功能原生內(nèi)置于 Istio 中。 無需額外設(shè)置。

實驗以簡單的 Kubernetes manifest形式表現(xiàn)。

劣勢

只有HTTP延遲或 HTTP 錯誤這兩種實驗類型。

如果沒有使用 Istio，僅僅為了這個故障注入功能而使用它就不值得了。

實驗無法在主機(jī)上安排和執(zhí)行，無法深入定制，也無法在 Istio 之外使用。

案例

我的好朋友，知乎用戶陳計節(jié)（https://www.zhihu.com/people/jijiechen）貢獻(xiàn)了以下案例。

“我們曾經(jīng)在一個頁面上發(fā)現(xiàn)，如果用戶點擊太快，當(dāng)某一兩個 API 還沒有加載完成的時候，用戶就已經(jīng)提交了表單。此時就有可能造成提交的數(shù)據(jù)不完整。復(fù)現(xiàn)這個問題時，我們把瀏覽器網(wǎng)速改為 3g 模式，就可以顯著提升復(fù)現(xiàn)率。之后確認(rèn)了問題，開發(fā)同學(xué)修復(fù)后，為了讓測試同學(xué)能夠復(fù)現(xiàn)并驗證修復(fù)的有效性，我們就提供了 一個 istio delay 規(guī)則，在服務(wù)端給特定 API 增加延時?！?/p>

開源許可證

Apache-2.0 license

Github點贊數(shù)

33.5k

最近發(fā)布日期與版本

2023.07: Istio 1.18.2

所屬項目

CNCF云原生計算基金會項目

參考資料

Istio故障注入官方文檔：https://istio.io/latest/docs/tasks/traffic-management/fault-injection/

Istio故障注入實例：https://istiobyexample.dev/fault-injection/

本文參考了Gremlin公司的文章Comparing Chaos Engineering tools https://www.gremlin.com/community/tutorials/chaos-engineering-tools-comparison/#istio

在K8S下檢驗微服務(wù)穩(wěn)定性，還有什么好用的開源工具？你還希望我聊有關(guān)混沌工程的其他什么新話題？歡迎在評論區(qū)留言。我會仔細(xì)閱讀每一條留言。期待聽到你的聲音。

如果覺得本文對你有幫助，歡迎點贊，并轉(zhuǎn)發(fā)給其他志同道合的小伙伴。

企業(yè)生意好，系統(tǒng)運行穩(wěn)。你所閱讀的文章，來自“吾真本說混沌工程”知乎專欄。