在 Ali Kubernetes 系統中,我們這樣實踐混沌工程

許此一生發表於2019-03-20

作者| 阿里雲智慧事業群高階測試開發工程師 智妍


在傳統的軟體測試中,我們通常通過一個給定的條件來判斷系統的反饋,通過斷言來判斷是否符合預期,測試條件和結果通常比較明確和固定。而混沌工程,是通過注入一些“不確定”因素,象放進了一群淘氣的猴子,在系統資源、可用性、安全性、延遲、壓力等方面進行搗亂,而此過程中,要求系統可以毫無影響的提供服務,使用者無感知。


這其實對系統的自愈能力,健壯性都有很高的要求。故障注入一般是指比較受控的一些實驗條件,通過注入一些相對極端的異常場景,為系統提供可靠性測試的過程。 整體來說,混沌是一種故障注入規則,強調了一些不確定性、隨機性,比較常見的"猴子"有 Netflix 的"猴子軍團",可以用來隨機關閉系統例項,注入延時,回收資源,檢查安全漏洞等等。

開源工具介紹

除了一般系統的 monkey,基於 Kubernetes 已經有一些"猴子"工具可以測試系統的健壯性。接下來,介紹一下比較常見的三種 Kubernetes monkey:

kube-monkey

github.com/asobti/kube…

  • 執行方式:kube-monkey 通過 label 設定受害者 pod,建立了一個單獨的 kube-monkey pod 對受害者 pod 施加影響;
  • 注入型別:目前支援的故障注入型別僅有殺容器;
  • 配置項:可以通過配置檔案設定執行週期和頻率,在一定時間內隨機的殺死打標範圍內的 pod。

powerfulseal

github.com/bloomberg/p…

  • 注入型別:powerfulseal 的故障注入型別包括殺 pod 和啟停 node。
  • 執行方式:包括互動模式,自動模式、打標模式和示例模式。互動模式通過介面互動查詢node/namespace/pod,啟停 node 或殺死 pod 操作;自動模式通過讀取配置檔案確定注入範圍,注入頻率;打標模式通過給 pod 打標確定注入的靶向 pod 及注入頻率;示例模式可以反映根據使用資源情況進行故障注入的過程。

Chaos Toolkit-kubernetes

https://github.com/chaostoolkit/chaostoolkit-kubernetes
/>
是 chaos 工具包中的一個,通過 chaos run experiment.json 設定 json 檔案來指定 namespace,正則匹配名字等等來隨機殺一個 pod。


以上三種"猴子",主要是基於殺 pod 場景來注入故障,雖然是最有力的場面但是比較有侷限性,對於商業化系統面臨的複雜場景,是值得參考但是不夠的。

結合 Ali Kubernetes 故障場景分析


Ali Kubernetes 作為一個管理大規模叢集的商業排程系統,需要應對的不僅包括一些基本的 Kubernetes 中 pod 誤刪誤停的故障現象,也包含一些底層 OS、核心、網路、誤配置等災難場景。同時由於其支撐業務生態的複雜性,全鏈路綜合異常流也需要特殊的驗證。


為更系統的進行演練,在過程中主要進行了以下幾部分工作:



1


FMEA 分析就是失效模式和效果分析,旨在對系統範圍內潛在的失效模式加以分析,以便按照嚴重程度加以分類,或者確定失效對於該系統的影響。
從故障場景上,分析得出較為符合 Ali Kubernetes 的三大類場景:

  • 通用故障場景:包括網路相關故障(網路 iohang ,斷網,網路延遲等),宿主機相關故障(機器重啟,機器 load 高等)
  • Ali Kubernetes 業務場景故障:包括 Kubernetes 相關的故障(pod 刪除,pod patch等),pod 遷移,混部、etcd 等業務相關場景;
  • chaos 故障:較為隨機的故障注入,可以為以上任何故障的組合


從影響面上,需要 case by case 確定影響範圍為無任何影響,僅影響部分功能,影響核心功能等等;從驗證恢復手段上,也可以分為自動恢復、手動恢復,同時需要關注監控情況及恢復時間。


在分析過程中,我們發現,已有的開源工具無法完全滿足 Ali Kubernetes 的故障場景。下面舉 2 個典型故障場景:

pod 被誤刪

這個場景並不是簡單的 pod 隨機刪除,而是在 kubelet 連錯 apiserver 配置等異常情況下,重啟 ali-kubelet 後,al 自行判斷了容器在當前叢集內不存在,自己做了刪除操作。
要引入這個故障需要修改 kubelet 元件的配置,重啟 kubelet,才算是真正引入了故障,而當前的無論是 kube-monkey 還是 powerfulseal 場景都無法滿足。

master 元件斷網

有的人可能會說,直接指定 master 元件的機器引入斷網操作,是不是就可以了呢?然鵝現實是比較骨感的,我們也許只知道這個 master 所在叢集的 kubeconfig,元件的機器其實也可以隨著每次升級變動的。在僅僅已知 kubeconfig 的情況下我們只能先查一下 master 元件的機器資訊,再在機器上引入斷網的操作,才算是一個整體的故障引入。而目前所有的開源工具也沒有此類稍微複雜一些的場景,只是通過指定 pod namespace 來隨機的刪除一些 pod。
所以綜上所述,其實我們需要對此進行擴充套件開發,除了簡單的殺 pod,我們亟需一套可以自由開發的小程式,把這個步驟拼接起來,進行更為複雜的故障注入。


套件實現


為了滿足此類複雜的故障注入,我們使用了目前集團內正在開發的一套故障注入系統 monkeyking,並在它的基礎上擴充套件了一些 kubernetes 相關的套件,來達到既可以注入 kubernetes 相關的故障,又可以注入一些通用故障,同時又可以相對自由的擴充套件故障集合的目的。


這個故障注入的演練流程如下圖所示:



2


它的每一個步驟都可以是我們自由擴充套件的一個或者多個小程式,各個小程式之間的執行順序也可以自由的定義。考慮到 Ali Kubernetes 的場景,我們在其中擴充套件了四大類小程式套件。

通用故障小程式

在這一部分主要實現了一些比較通用的 os 故障,網路故障,比如最基本的指定一個宿主機斷網,指定宿主機重啟這類。

Kubernetes 套件小程式

這一部分主要實現了一些通用的 Kubernetes 命令,通過指定這些命令和入參,我們可以執行比如 create delete apply patch 這些操作,來間接的達到注入一些 Kubernetes 相關故障的目的。
實現原理如下:




要點說明如下:

  • 下載叢集證書的地址及證書的 md5 碼都作為小程式的輸入,在執行實際的 kubectl 生效命令前進行下載校驗;
  • 底層 toolkit 中已經加入了 kubectl 命令列工具,無需自己找環境進行配置和下載;
  • 目前已經支援了 apply,create,delete,patch,get 操作,支援指定 label,namespace,-o json 的操作


舉個例子,上文中 master 元件故障的場景中,我們就可以利用以上的兩類小程式來完成故障注入的操作:

3

開源工具小程式

目前我們和集團安全生產的 MonkeyKing 團隊合作,聯合在故障注入平臺 monkeyking 中整合了開源工具 kube-monkey,實現過程藉助了上文的 kubernetes 套件執行,可以通過打標的方式標記受害者,讓 kube-monkey 隨機的殺受害者 pod。步驟如下:

環境準備

  • 鎖演練環境
  • 在當前叢集中初始化kube-monkey: 使用kubernetes套件的apply功能提交km-config.yaml檔案,部署 kube-monkey deployment

**

給應用標記受害者 label

  • 使用 Kubernetes 套件的 patch 功能,標記受害者

**

驗證步驟

  • 自定義元件校驗應用服務是否可用

**

故障恢復

  • 使用 Kubernetes 套件的 patch 功能,給受害者去標
  • 使用 Kubernetes 套件的 delete 功能,刪除 kube-monkey deployment
  • 解鎖演練環境


其他業務相關小程式

這一部分比較自由,主要根據 Ali Kubernetes 的業務需求,接入了一些常用的小程式。


比如故障演練過程中,環境需要獨佔,不允許其他測試執行,在這裡實現了一個小程式用來對環境進行加解鎖操作;比如校驗階段需要驗證服務是否可用,這裡實現了一個通過 curl 命令校驗返回值的方式驗證服務是否可用的小程式;比如故障注入過程可能影響vip掛載,這裡也實現了一個呼叫 vip 服務校驗 vip 下 ip 數量及是否可用的小程式。


總結


在 Ali Kubernetes 中,我們將故障以場景化的方式進行沉澱,將底層 os,核心、網路、誤配置等故障聯合 Kubernetes 相關故障,引入混沌工程的理念進行注入,有效的發現了很多系統穩定性問題,驅動開發人員更多關注系統健壯性。


後續我們會在 Ali Kubernetes 演進過程中持續發力,基於架構和業務場景輸入更多 Kubernetes 相關的故障場景,為系統的高可用保駕護航。

作者: jessie筱姜
原文連結


相關文章