混沌測試

混沌測試基礎

混沌測試是一種可試驗的、基于系統的方法來處理大規模分布式系統中的混亂問題。通過不斷試驗，了解系統的實際能承受的韌性邊界并建立信心，通過不同的試驗方法和目的，觀察分布式系統的行為和反應。

在複雜的分布式系統中，無法阻止這些故障的發生，應該緻力于在這些異常行為被觸發之前，盡可能多地識别風險。然後，針對性地進行加強，防範，進而避免故障發生時所帶來的嚴重後果。

混沌測試正是這樣一套通過在生産分布式系統上進行實驗，主動找出系統中的脆弱環節的方法學。

ChaosBlade 

ChaosBlade 是阿裡巴巴開源的一款遵循混沌工程實驗原理，提供豐富故障場景實作，幫助分布式系統提升容錯性和可恢複性的混沌工程工具，可實作底層故障的注入，特點是操作簡潔、無侵入、擴充性強。

ChaosBlade 基于 Apache License v2.0 開源協定，目前有 chaosblade 和 chaosblade-exe-jvm 兩個倉庫。其中，Chaosblade 包含 CLI 和使用 Golang 實作的基礎資源、容器相關的混沌實驗實施執行子產品。chaosblade-exe-jvm 是對運作在 JVM 上的應用實施混沌實驗的執行器。

項目位址：https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97

系統架構

Component Architecture

• Cli 包含 create、destroy、status、prepare、revoke、version 6 個指令
• 相關混沌實驗資料使用 SQLite 存儲在本地（chaosblade 目錄下）
• Create 和 destroy 指令調用相關的混沌實驗執行器建立或者銷毀混沌實驗
• Prepare 和 revoke 指令調用混沌實驗準備執行器準備或者恢複實驗環境，比如挂載 jvm-sandbox
• 混沌實驗和混沌實驗環境準備記錄都可以通過 status 指令查詢

場景覆寫

從其cli工具的help中，可以看出ChaosBlade目前支援的一些能力。

cpu         Cpu experiment
  disk        Disk experiment
  docker      Execute a docker experiment
  dubbo       dubbo experiment
  jvm         method
  k8s         Kubernetes experiment
  mysql       mysql experiment
  network     Network experiment
  process     Process experiment
  servlet     java servlet experiment      

此工具目前的實踐場景如下：

1.自測階段的故障植入，在不需要變更真實邏輯的情況下，驗證自己的異常處理；

2.測試同學在測試階段，模拟底層依賴服務的故障場景，驗證系統可用程度，降級方案是否生效等；

3.業務故障演練時，在不需要變更真實邏輯的情況下，可以人為模拟特定場景的故障異常，驗證止損方案是否可是有效的，可落地的；

在分布式架構環境下，服務間的依賴日益複雜，可能沒有人能說清單個故障對整個系統的影響，建構一個高可用的分布式系統面臨着很大挑戰。在可控範圍或環境下，使用 ChaosBlade 工具，對系統注入各種故障，持續提升分布式系統的容錯和彈性能力，以建構高可用的分布式系統。

Chaos Mesh

Chaos Mesh 是PingCap團隊研發的一款用于測試kubernetes環境的工具。通過人為地在叢集中注入故障來檢測叢集對故障的處理以及恢複能力。混沌測試與針對某個應用測試的差別為：前者更傾向于在現有大規模叢集中進行測試，影響因素可能來自叢集中的方方面面；而後者更專注于對應用本身功能的測試。

Chaos Mesh 還支援許多其他的錯誤注入：

• pod-kill：模拟 Kubernetes Pod 被 kill。
• pod-failure：模拟 Kubernetes Pod 持續不可用，可以用來模拟節點當機不可用場景。
• network-delay：模拟網絡延遲。
• network-loss：模拟網絡丢包。
• network-duplication: 模拟網絡包重複。
• network-corrupt: 模拟網絡包損壞。
• network-partition：模拟網絡分區。
• I/O delay : 模拟檔案系統 I/O 延遲。
• I/O errno：模拟檔案系統 I/O 錯誤 。

Chaos Mesh 的目标是要做一個通用的混沌測試工具，是以需要遵循以下幾個原則。

易用性：

• 無特殊依賴，可以在 Kubernetes 叢集上面直接部署，包括 Minikube。
• 無需修改應用的部署邏輯，理想的情況是可以在生産環境上進行混沌實驗 。
• 易于編排實驗的錯誤注入行為，易于檢視實驗的狀态和結果，并能夠快速地對注入的故障進行復原。
• 隐藏底層的實作細節，使用者更聚焦于編排自己需要的實驗。

拓展性：

• 基于現有實作，易于擴充新的故障注入種類。
• 友善內建到其他測試架構中。

作為一個通用的工具，易用性是必不可少的，一個工具不管功能如何多，如何強大，如果不夠易用，那麼這個工具最終也會失去使用者，也就失去了工具的本身的價值。另一方面在保證易用的前提下，拓展性也是必不可少。如今的分布式系統越來越複雜，各種新的問題層出不窮，Chaos Mesh 的目标的是當有新的需求的時候，我們可以友善去在 Chaos Mesh 中實作，而不是重新再造個輪子。

總體來說，混沌測試更像是內建驗證的一部分，通過在現有運作環境中注入故障來發現系統或應用的相容性問題，故障恢複能力問題等。

原了解析

Chaos Mesh 的基本工作流原理是：

• Controller-manager
• 目前 controller-manager 可以分為兩部分，一部分 controllers 用于排程和管理 CRD 對象執行個體，另一部分為 admission-webhooks 動态的給 Pod 注入 sidecar 容器。
• Chaos-daemon
• Chaos-daemon 以 daemonset 的方式運作，并具有 Privileged 權限，Chaos-daemon 可以操作具體 Node 節點上網絡裝置以及 Cgroup 等。
• Sidecar
• Sidecar contianer 是一類特殊的容器，由 admission-webhooks 動态的注入到目标 Pod 中，目前在 Chaos Mesh 中實作了 chaosfs sidecar 容器，chaosfs 容器内會運作 fuse-daemon，用來劫持應用容器的 I/O 操作。

整體工作流如下：

1. 使用者通過 YAML 檔案或是 Kubernetes 用戶端往 Kubernetes API Server 建立或更新 Chaos 對象。
2. Chaos-mesh 通過 watch API Server 中的 Chaos 對象建立更新或删除事件，維護具體 Chaos 實驗的運作以及生命周期，在這個過程中 controller-manager、chaos-daemon 以及 sidecar 容器協同工作，共同提供錯誤注入的能力。
3. Admission-webhooks 是用來接收準入請求的 HTTP 回調服務，當收到 Pod 建立請求，會動态修改待建立的 Pod 對象，例如注入 sidecar 容器到 Pod 中。第 3 步也可以發生在第 2 步之前，在應用建立的時候運作。