在 Ali Kubernetes 系統中，咱們這樣實踐混沌工程

做者| 阿里雲智能事業羣高級測試開發工程師 智妍

在傳統的軟件測試中，咱們一般經過一個給定的條件來判斷系統的反饋，經過斷言來判斷是否符合預期，測試條件和結果一般比較明確和固定。而混沌工程，是經過注入一些「不肯定」因素，象放進了一羣淘氣的猴子，在系統資源、可用性、安全性、延遲、壓力等方面進行搗亂，而此過程當中，要求系統能夠毫無影響的提供服務，用戶無感知。


這其實對系統的自愈能力，健壯性都有很高的要求。故障注入通常是指比較受控的一些實驗條件，經過注入一些相對極端的異常場景，爲系統提供可靠性測試的過程。 總體來講，混沌是一種故障注入規則，強調了一些不肯定性、隨機性，比較常見的"猴子"有 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、內核、網絡、誤配置等災難場景。同時因爲其支撐業務生態的複雜性，全鏈路綜合異常流也須要特殊的驗證。


爲更系統的進行演練，在過程當中主要進行了如下幾部分工做：

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 相關的故障，又能夠注入一些通用故障，同時又能夠相對自由的擴展故障集合的目的。


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

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

通用故障小程序

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

Kubernetes 套件小程序

這一部分主要實現了一些通用的 Kubernetes 命令，經過指定這些命令和入參，咱們能夠執行好比 create delete apply patch 這些操做，來間接的達到注入一些 Kubernetes 相關故障的目的。
實現原理以下：




要點說明以下：

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

舉個例子，上文中 master 組件故障的場景中，咱們就能夠利用以上的兩類小程序來完成故障注入的操做:

開源工具小程序

目前咱們和集團安全生產的 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筱姜
原文連接