Litmus 實踐：讓群魔在混沌中亂舞，看 K8s 能撐到何時

對於雲服務而言，如果系統出現異常，將會帶來很大的損失。為了最大程度地降低損失，我們只能不斷探尋系統何時會出現異常，甚至縮小到某些特定參數變化是否會造成系統異常。然而隨着雲原生的發展，不斷推進着微服務的進一步解耦，海量的數據與用戶規模也帶來了基礎設施的大規模分布式演進，系統中的故障變得越來越難以預料。我們需要在系統中不斷進行實驗，主動找出系統的缺陷，這種方法被稱作混沌工程。畢竟實踐是檢驗真理的唯一標准，所以混沌工程可以幫助我們更加透徹地掌握系統的運行規律，提高系統的彈性能力。

Litmus 是一種開源的雲原生混沌工程工具集，專注於 Kubernetes 集群進行模擬故障測試，以幫助開發者和 SRE 發現集群及程序中的缺陷，從而提高系統的健壯性。

Litmus 架構

Litmus 的架構如圖所示：

Litmus 的組件可以划分為兩部分：

1. Portal
2. Agents

Portal 是一組 Litmus 組件，作為跨雲管理混沌實驗的控制平面 (WebUI) ，用於協調和觀察 Agent 上的混沌實驗工作流。

Agent 也是一組 Litmus 組件，包括運行在 K8s 集群上的混沌實驗工作流。

使用 Portal，用戶可以在 Agent 上創建和調度新的混沌實驗工作流，並從 Portal 上觀察結果。用戶還可以將更多的集群連接到 Portal，並將 Portal 作為跨雲混沌工程管理的單個門戶。

Portal 組件

• Litmus WebUI

  Litmus WebUI 提供了 Web 用戶界面，用戶可以在這里輕松構建和觀察混沌實驗工作流。Litmus WebUI 也充當了跨雲混沌實驗控制平面。

• Litmus Server

  Litmus Server 作為中間件，用於處理來自用戶界面的 API 請求，並將配置和處理結果詳情信息存儲到數據庫中。它還充當各個請求之間的通信接口，並將工作流程調度到 Agent。

• Litmus DB

  Litmus DB 作為混沌實驗工作流及其測試結果詳情的存儲系統。

Agent 組件

• Chaos Operator

  Chaos Operator 監視 ChaosEngine 並執行 CR 中提到的混沌實驗。Chaos Operator 是命名空間范圍的，默認情況下運行在 litmus 命名空間中。實驗完成后，Chaos Operator 會調用 chaos-exporter 將混沌實驗的指標導出到 Prometheus 數據庫中。

• CRDs

  Litmus 安裝過程中會生成以下幾個 CRD：

  chaosexperiments.litmuschaos.io
  chaosengines.litmuschaos.io
  chaosresults.litmuschaos.io
  

• Chaos Experiment

  Chaos Experiment（混沌實驗）是 LitmusChaos 體系結構中的基本單元，用戶可以從 Chaos Hub 上選擇現場的混沌實驗或者自己創建新的混沌實驗來構建所需的混沌實驗工作流。簡單來說就是定義一個該測試支持哪些操作、能傳入哪些參數、可對哪些類型的對象進行測試等 CRD 資源清單，通常分為三種類別：通用的測試（比如內存，磁盤，CPU等操作），應用的測試（比如針對 Nginx 來進行測試），平台測試（針對於某個雲平台的測試：AWS, Azure, GCP）。詳情可參考 Chaos Hub 的文檔。

• Chaos Engine

  ChaosEngine 將 Chaos Experiment 實現的功能具體實施到命名空間中的應用中。該 CR 由 Chaos Operator 監控。

• Chaos Results

  ChaosResult 保存了混沌實驗的結果，它會在實驗運行時創建或更新，包含了各種信息，包括 Chaos Engine 的配置、實驗狀態等。chaos-exporter 將會讀取結果並導出到 Prometheus 數據庫中。

• Chaos Probes

  Chaos Probes 是可插拔的指標探針，可以在任意混沌實驗的 ChaosEngine 中定義，實驗 Pod 會根據其定義的模式來執行相應的檢測，並將其是否成功作為決定實驗結果的必要條件（還包括了標准的“內置”檢測）。

• Chaos Exporter

  可以選擇將指標導出到 Prometheus 數據庫。Chaos Exporter 實現了 Prometheus metrics endpoint。

• Subscriber

  Subscriber 用來和 Litmus Server 交互，獲取混沌實驗工作流的詳細結果，並發送回 Agent 端。

准備 KubeSphere 應用模板

KubeSphere 集成了 OpenPitrix 來提供應用程序全生命周期管理，OpenPitrix 是一個多雲應用管理平台，KubeSphere 利用它實現了應用商店和應用模板，以可視化的方式部署並管理應用。對於應用商店中不存在的應用，用戶可以將 Helm Chart 交付至 KubeSphere 的公共倉庫，或者導入私有應用倉庫來提供應用模板。

本教程將使用 KubeSphere 的應用模板來部署 Litmus。

要想從應用模板部署應用，需要創建一個企業空間、一個項目和兩個用戶帳戶（ws-admin 和 project-regular）。ws-admin 必須被授予企業空間中的 workspace-admin 角色， project-regular 必須被授予項目中的 operator 角色。在創建之前，我們先來回顧一下 KubeSphere 的多租戶架構。

多租戶架構

KubeSphere 的多租戶系統分三個層級，即集群、企業空間和項目。KubeSphere 中的項目等同於 Kubernetes 的命名空間。

您需要創建一個新的企業空間進行操作，而不是使用系統企業空間，系統企業空間中運行着系統資源，絕大部分僅供查看。出於安全考慮，強烈建議給不同的租戶授予不同的權限在企業空間中進行協作。

您可以在一個 KubeSphere 集群中創建多個企業空間，每個企業空間下可以創建多個項目。KubeSphere 為每個級別默認設有多個內置角色。此外，您還可以創建擁有自定義權限的角色。KubeSphere 多層次結構適用於具有不同團隊或組織以及每個團隊中需要不同角色的企業用戶。

創建帳戶

安裝 KubeSphere 之后，您需要向平台添加具有不同角色的用戶，以便他們可以針對自己授權的資源在不同的層級進行工作。一開始，系統默認只有一個帳戶 admin，具有 platform-admin 角色。在本步驟中，您將創建一個帳戶 user-manager，然后使用 user-manager 創建新帳戶。

1. 以 admin 身份使用默認帳戶和密碼 (admin/P@88w0rd) 登錄 Web 控制台。

出於安全考慮，強烈建議您在首次登錄控制台時更改密碼。若要更改密碼，在右上角的下拉菜單中選擇個人設置，在密碼設置中設置新密碼，您也可以在個人設置中修改控制台語言。

2. 登錄控制台后，點擊左上角的平台管理，然后選擇訪問控制。

   

   在帳戶角色中，有如下所示四個可用的內置角色。接下來要創建的第一個帳戶將被分配 users-manager 角色。

   內置角色	描述
   workspaces-manager	企業空間管理員，管理平台所有企業空間。
   users-manager	用戶管理員，管理平台所有用戶。
   platform-regular	平台普通用戶，在被邀請加入企業空間或集群之前沒有任何資源操作權限。
   platform-admin	平台管理員，可以管理平台內的所有資源。

3. 在帳戶管理中，點擊創建。在彈出窗口中，提供所有必要信息（帶有*標記），然后在角色字段選擇 users-manager。請參考下圖示例。

   

   完成后，點擊確定。新創建的帳戶將顯示在帳戶管理中的帳戶列表中。

4. 切換帳戶使用 user-manager 重新登錄，創建如下三個新賬戶。

   帳戶	角色	描述
   ws-manager	workspaces-manager	創建和管理所有企業空間。
   ws-admin	platform-regular	管理指定企業空間中的所有資源（此帳戶用於邀請成員 project-regular 加入該企業空間）。
   project-regular	platform-regular	該帳戶將用於在指定項目中創建工作負載、流水線和其他資源。

5. 查看創建的三個帳戶。

   

創建企業空間

在本步驟中，您需要使用上一個步驟中創建的帳戶 ws-manager 創建一個企業空間。作為管理項目、創建工作負載和組織成員的基本邏輯單元，企業空間是 KubeSphere 多租戶系統的基礎。

1. 以 ws-manager 身份登錄 KubeSphere，它具有管理平台上所有企業空間的權限。點擊左上角的平台管理，選擇訪問控制。在企業空間中，可以看到僅列出了一個默認企業空間 system-workspace，即系統企業空間，其中運行着與系統相關的組件和服務，您無法刪除該企業空間。

   

2. 點擊右側的創建，將新企業空間命名為 demo-workspace，並將用戶 ws-admin 設置為企業空間管理員，如下圖所示：

   

   完成后，點擊創建。

3. 登出控制台，然后以 ws-admin 身份重新登錄。在企業空間設置中，選擇企業成員，然后點擊邀請成員。

   

4. 邀請 project-regular 進入企業空間，授予其 workspace-viewer 角色。

   實際角色名稱的格式：<workspace name>-<role name>。例如，在名為 demo-workspace 的企業空間中，角色 viewer 的實際角色名稱為 demo-workspace-viewer。

   

5. 將 project-regular 添加到企業空間后，點擊確定。在企業成員中，您可以看到列出的兩名成員。

   帳戶	角色	描述
   ws-admin	workspace-admin	管理指定企業空間中的所有資源（在此示例中，此帳戶用於邀請新成員加入企業空間、創建項目）。
   project-regular	workspace-viewer	該帳戶將用於在指定項目中創建工作負載和其他資源。

創建項目

在此步驟中，您需要使用在上一步驟中創建的帳戶 ws-admin 來創建項目。KubeSphere 中的項目與 Kubernetes 中的命名空間相同，為資源提供了虛擬隔離。有關更多信息，請參見命名空間。

1. 以 ws-admin 身份登錄 KubeSphere，在項目管理中，點擊創建。

   

2. 輸入項目名稱（例如 litmus），然后點擊確定完成，您還可以為項目添加別名和描述。

   

3. 在項目管理中，點擊剛創建的項目查看其詳細信息。

   

4. 邀請 project-regular 至該項目，並授予該用戶 operator 角色。請參考下圖以了解具體步驟。

   

   具有 operator 角色的用戶是項目維護者，可以管理項目中除用戶和角色以外的資源。

添加應用倉庫

1. 以 ws-admin 用戶登錄 KubeSphere 的 Web 控制台。在您的企業空間中，進入應用管理下的應用倉庫頁面，並點擊添加倉庫。

   

2. 在彈出的對話框中，將應用倉庫名稱設置為 litmus，將應用倉庫的 URL 設置為 https://litmuschaos.github.io/litmus-helm/，點擊驗證對 URL 進行驗證，再點擊確定進入下一步。

   

3. 應用倉庫導入成功后會顯示在如下圖所示的列表中。

   

部署 Litmus 控制平面

導入 Litmus 的應用倉庫后，就可以通過應用模板來部署 Litmus 了。

1. 登出 KubeSphere 並以 project-regular 用戶重新登錄。在您的項目中，進入應用負載下的應用頁面，再點擊部署新應用。

   

2. 在彈出的對話框中選擇來自應用模板。

   

3. 在彈出的對話框中選擇來自應用模板。

   

   來自應用商店：選擇內置的應用和以 Helm Chart 形式單獨上傳的應用。

   來自應用模板：從私有應用倉庫和企業空間應用池選擇應用。

4. 從下拉列表中選擇之前添加的私有應用倉庫 litmus。

   

5. 選擇 litmus-2-0-0-beta 進行部署。

   

6. 您可以查看應用信息和配置文件，在版本下拉列表中選擇版本，然后點擊部署。

   

7. 設置應用名稱，確認應用版本和部署位置，點擊下一步。

   

8. 在應用配置頁面，您可以手動編輯清單文件或直接點擊部署。

   

9. 等待 Litmus 創建完成並開始運行。

   

訪問 Portal 服務

Portal 的 Service 名稱為 litmusportal-frontend-service。可以先到服務界面查看它的 NodePort：

用 ${Node IP}:${NODEPORT} 地址訪問 Portal：

默認的用戶名密碼：

Username: admin
Password: litmus

部署 Agent（可選）

Litmus 包含兩種類型的 Agent：

• Self Agent
• External Agent

默認情況下，安裝 Litmus 所在的集群會被自動注冊為 Self Agent，Portal 默認會在 Self Agent 中執行混沌實驗。

前面也說了，Portal 是一個跨雲混沌實驗控制平面，也就是說，用戶可以將多個部署在外部 K8s 集群中的 External Agent 連接到當前 Portal，以便將混沌實驗下發給 Agent，並在 Portal 中觀察結果。

關於 External Agent 的部署方式，可以參考 Litmus 的官方文檔。

創建混沌實驗

Portal 安裝完成后，可以通過 Portal 界面來創建混沌實驗，需要先創建一個用來測試的應用：

$ kubectl create deployment nginx --image=nginx --replicas=2 --namespace=default

下面開始創建實驗。

1. 登錄 Portal

   

2. 進入 Workflows 頁面點擊【Schedule a workflow】

   

3. 選擇 Agent，比如 Self-Agent：

   

4. 選擇從 Chaos Hub 中添加混沌實驗：

   

5. 設置 Workflow 的名稱：

   

6. 點擊 【Add a new experiment】，向 Workflow 中添加混沌實驗：

   

7. 選擇實驗 pod-delete：

   

8. 立即開始調度：

   

9. 在 KubeSphere 中可以看到 Pod 被刪除重建了：

   

10. Portal 界面也可以看到實驗成功了：

    

    點擊具體的 Workflow 節點，可以看到詳細的日志：

    

11. 重復上面的步驟，創建混沌實驗 pod-cpu-hog：

    

    在 KubeSphere 中可以看到 Pod 的 CPU 使用率已經接近 1C：

    

12. 下面這個實驗用來模擬 Pod 網絡丟包，開始實驗前先把 Nginx 的副本數設為 1：

    

    

    現在只有一個 Pod，IP 為 10.233.71.170：

    

    下面重復上面的步驟，創建混沌實驗 pod-network-loss，並修改丟包率為 50%：

    

    在進入 KubeSphere 界面，在右下角的工具箱圖標上懸停，然后在彈出菜單中選擇 Kubectl。

    

    通過 ping Pod 的 IP 來測試丟包率，可以看到丟包率接近 50%，實驗成功：

    

以上所有實驗都是針對 Pod 進行的，除了 Pod 之外，還可以對 Node、K8s 組件等各種服務進行實驗，感興趣的讀者可以自行測試。

Workflow 詳解

所謂的 Workflow，實際上就是一個混沌實驗的工作流，雖然上一節的演示中每一個 Workflow 只有一個實驗，但實際上每個 Workflow 都可以設置多個實驗，並按照順序執行。

Workflow 是由 CRD 來實現的，可以在 KubeSphere Console 界面中查看該 CRD，這里可以看到之前創建的所有 Workflow：

以 pod-network-loss 為例，來看看有哪些參數：

Workflow 中的每一個實驗也是一個 CRD，CRD 名稱為 ChaosEngine。

解釋一下這里面各個環境變量的含義：

• appns: 要執行對象所在的命名空間。
• experiments：要執行測試的名稱(例如網絡延遲測試，Pod 刪除測試等),可用 kubectl get chaosexperiments -n test 進行查看支持的 experiments。
• chaosServiceAccount：要使用的 sa。
• jobCleanUpPolicy: 是否保留執行該次測試的 Job,字段可選為 delete/retain。
• annotationCheck: 是否進行注釋檢查,如果不進行檢查,則所有的 Pod 都被進行測試,字段可選為 true/false。
• engineState: 該次測試的狀態,可被設置為 active/stop。
• TOTAL_CHAOS_DURATION：混沌測試持續時間,默認 15s。
• CHAOS_INTERVAL：混沌測試時間間隔,默認 5s。
• FORCE：刪除pod是否使用 --force 選項。
• TARGET_CONTAINER: 刪除 Pod 里面的某個容器(默認刪除第一個)。
• PODS_AFFECTED_PERC：測試 Pod 占總數的百分比,默認是 0(相當於1個副本)。
• RAMP_TIME：在進行混沌測試前后需要等待的時間。
• SEQUENCE：測試執行策略,默認是並行 (parallel) 執行,可被設置為 serial/parallel。

其他各個實驗的詳細參數這里就不贅述了，感興趣的讀者可以自己查閱相關文檔。

總結

本文向大家介紹了混沌工程框架 Litmus 的架構以及在 KubeSphere 上的部署方法，通過一系列混沌實驗來驗證整個基礎設施和服務抵抗故障的能力。Litmus 是一個特別優秀的混沌工程框架，背后有強大的社區支持，它的實驗商店（即 Chaos Hub）中內置的實驗將會越來越多，你可以將這些混沌實驗一鍵部署到集群中制造混亂，通過可視化界面來直觀展示實驗結果，驗證集群的彈性能力。有了 Litmus 之后，我們不但可以直面故障，還可以主動出擊制造故障來找出系統的缺陷，避免黑天鵝事件的產生。

參考資料

• Getting Started with Litmus

本文由博客一文多發平台 OpenWrite 發布！