使用 Litmus 進行混沌工程：一個 CNCF 孵化計畫

問題陳述: 確保基於微服務的電子商務平台的韌性。

系統韌性是電子商務平台在擴展操作期間的一項關鍵要求，以保持服務運行並為用戶提供卓越的性能。我們開發了一個微服務架構的平台，當面對大量流量事件時，經常會遇到偶發的系統故障。服務可用性下降及其對收入的影響主要是由於Kubernetes pod崩潰，以及在高峰購物季節期間發生的資源耗盡和網絡中斷。

該組織計劃利用CNCF孵化的項目Litmus來進行平台的評估和韌性增強。當我們使用Litmus進行模擬故障測試時，我們的系統弱點變得更加明顯，這使我們能夠觸發現實世界的故障情況，如pod終止事件、網絡延遲和資源使用限制。這些實驗使我們能夠驗證可擴展性自動化系統，同時測試災難恢復程序，並最大化Kubernetes設置以實現系統的總體可靠性。

該系統為承受故障情況和安全地分配繁忙流量期間提供了堅實的基礎，而不會降低用戶體驗質量。主動應用於我們基礎設施的混沌工程能夠提高風險降低和增加可觀察性，使我們能夠開發自動化恢復方法，增強我們平台對於各種運營條件的電子商務韌性。

設置混沌實驗環境

在您的Kubernetes集群中安裝LitmusChaos:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

驗證安裝:

kubectl get pods -n litmus

注意：確保您的集群已準備好進行混沌實驗。

定義混沌實驗

創建一個 ChaosExperiment YAML 文件以模擬 Pod 刪除場景。

範例 (pod-delete.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

安裝 ChaosOperator 並配置服務帳戶

部署 ChaosOperator 以管理實驗：

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

注意：創建一個 ServiceAccount 來授予必要的權限。

向目標應用注入混沌

為混沌標記應用程式命名空間：

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

部署 ChaosEngine 以觸發實驗：

範例 (chaosengine.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

應用 ChaosEngine:

kubectl apply -f chaosengine.yaml

監控實驗

查看進度：

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

檢查混沌 Pod 的狀態：

kubectl get pods -n <target-namespace>

分析結果

實驗後，檢查日誌和指標以確定應用程式是否自動恢復或在壓力下失敗。

以下是一些需要監控的指標：

• 應用程式響應時間
• 實驗期間和之後的錯誤率
• Pod 恢復所需的時間

解決方案

已識別根本原因：在高流量期間，由於部署中的副本數量不足和不當的資源限制，導致 Pod 失敗。

已應用修復措施：

• 增加部署中的副本數量以應對更高的流量
• 在 pod 規格中配置了適當的 CPU 和內存資源請求和限制
• 實施了水平 Pod 自動擴展器 (HPA) 來動態處理流量峰值

結論

通過使用 LitmusChaos 模擬 pod 失敗，我們發現了電子商務平台的 Kubernetes 部署中的關鍵弱點。混沌實驗表明，通過調整擴展和資源分配，可以顯著提高韌性。混沌工程使得系統主動強化，從而提高了系統正常運行時間和客戶滿意度。