摘要：故障注入為您的微服務(wù)注入故障以驗證集群性能由于導(dǎo)師和實驗室?guī)熜謧兊目蒲行枰?，本人專門以的模式設(shè)計了一個用于錯誤注入的微服務(wù)模塊。

“故障注入 Sidecar“——為您的微服務(wù)注入故障以驗證集群性能! 由于導(dǎo)師和實驗室?guī)熜謧兊目蒲行枰?，本人專門以 Sidecar
的模式設(shè)計了一個用于錯誤注入的微服務(wù)模塊。該模塊可以與任何微服務(wù)應(yīng)用共同部署運行，為其模擬cpu、內(nèi)存等錯誤。 本項目的 Github
地址: https://github.com/iscas-micr...
我的聯(lián)系方式: leontian1024@gmail.com || 或直接留言 歡迎您提出問題批評指點!

目前，本人正在中科院軟件所的微服務(wù)研究組從事部分研究工作。由于本人所在科研小組的研究內(nèi)容( 微服務(wù)自動擴縮容相關(guān) )，需要經(jīng)常使微服務(wù)應(yīng)用處于"高 CPU 利用率" 和 "高內(nèi)存使用"的狀態(tài)。因此，為了方便導(dǎo)師和實驗室的各位師兄進行實驗，本人特地開發(fā)了一個可以注入進 Pod 中的錯誤注入容器，來模擬上述的高負(fù)載狀態(tài)。

導(dǎo)師和師兄們使用后對我的工作給予了肯定，因此我準(zhǔn)備將開發(fā)過程和簡單使用方法寫成文章做個記錄( 也就是本文 )，一來方便自己日后工作學(xué)習(xí)，二來也方便有類似實驗需求的其他同仁們使用這個小項目，為大家的研究節(jié)省時間。更具體的安裝和使用方法，可以移步本項目 Github 的代碼倉庫，其中有非常詳細的說明。

什么是微服務(wù)中的"Sidecar 運行模式?"

上圖: 以 Sidecar 模式部署并運行的微服務(wù)單元

Sidecar 運行模式是最近兩年比較火的一種微服務(wù)部署和運行方法，它由目前流行的 ServiceMesh(服務(wù)網(wǎng)格) 架構(gòu)推廣而來。

具體而言，Sidecar 運行模式是一種"將不屬于業(yè)務(wù)應(yīng)用的功能以獨立的容器運行于業(yè)務(wù)容器旁邊"，在 K8s 中表現(xiàn)出的樣子就是將具有不同功能的模塊封裝成不同的鏡像，并以不同的容器運行在同一個 Pod 中。這種說法非常形象，因為 Sidecar 這個單詞的本意就是三輪摩托側(cè)面的"跨斗"，這里形容獨立于業(yè)務(wù)應(yīng)用但又與業(yè)務(wù)應(yīng)用部署在一起非常合適。

上圖: Sidecar ，中文意思為摩托車的跨斗，不由贊嘆命名的非常生動

本項目的錯誤注入模塊也采用了 Sidecar 這種設(shè)計思想，將用于模擬 CPU、內(nèi)存等故障的模塊獨立封裝成一個鏡像，并在 Pod 啟動時以 Sidecar 的形式運行在主業(yè)務(wù)容器旁邊。這樣，不用它時他就會安安靜靜地當(dāng)個美男子，完全不用擔(dān)心它會影響到正常業(yè)務(wù)的運行；一旦需要它模擬錯誤產(chǎn)生，由于與業(yè)務(wù)容器同處于一個 Pod 之中(而 K8s 又以 Pod 為基本單元)，因此他模擬出的錯誤亦被 K8s 集群視為業(yè)務(wù)應(yīng)用所在 Pod 產(chǎn)生而被監(jiān)測到。

上圖: Pod 中的每個容器都有自己的端口映射到外部主機，因此不會相互影響

本項目在設(shè)計之初是采用“在容器內(nèi)修改環(huán)境變量”的方式對容器注入故障的，但事實證明這種方法太low，而且非常麻煩。因此在后續(xù)設(shè)計和實現(xiàn)中采用了目前較為流行的通過 REST API 傳遞 POST 請求的方式使容器模擬錯誤，這樣就極大地方便了師兄們展開實驗，而且也可以模擬出“微服務(wù)間調(diào)用而產(chǎn)生錯誤”的場景( 上游服務(wù)調(diào)用錯誤注入的 API 而模擬下游服務(wù)產(chǎn)生錯誤 )。

此外，原本該項目的實現(xiàn)是單進程的，故每注入一個錯誤都要等待錯誤結(jié)束后才能獲得應(yīng)答并注入下一個錯誤，這十分不利于實驗的進行。因此在后面我們改為了多進程運行，即每當(dāng)一個錯誤產(chǎn)生時，程序都會建立一個子進程用于運行錯誤故障，而原來的進程則立刻產(chǎn)生注入是否成功的應(yīng)答并繼續(xù)監(jiān)聽相應(yīng)的服務(wù)端口，從而滿足應(yīng)答實時匯報和多種錯誤同時注入的功能需求。

上圖: 該程序的主要運行流程-以 “A 進程監(jiān)聽服務(wù)端口”的狀態(tài)為起點

本應(yīng)用以 Web 服務(wù)的方式運行，并封裝為鏡像保存于 DockerHub 上。因此使用之前需要先以容器的形式運行鏡像。以 docker 命令運行本應(yīng)用的參考命令如下所示：

# 使用 docker 命令簡單測試該應(yīng)用( 測試版本為 docker  18.03-ce )
docker run --rm -it -d --name fault-injection-server -p 5000:5000  xinyaotian/micro-fault-injection:1.0.0

待容器就緒后，訪問您啟動該容器的主機 IP 的 5000 號端口，如果出現(xiàn)了使用指引界面，就表明您的服務(wù)啟動成功，可以參考使用說明進行錯誤注入了。

上圖: 為了方便師兄們和大家的使用, 特地在服務(wù)首頁制作了簡易的使用方法指引, 為大家節(jié)省查 Github 文檔的時間

本項目主要支持四種故障類型: cpu、內(nèi)存、磁盤和網(wǎng)絡(luò)，均通過 POST 請求向 /fault-inject 搭配相應(yīng)參數(shù)進行注入。具體的注入方法如下所示( 注意更改 IP 和端口號 ):

1.注入 CPU 故障

# fault_type=cpu 指定錯誤故障類型(此處為 cpu 類型)
# thread_num=4 觸發(fā)該錯誤的線程數(shù)(此處為 4 個線程)
# duration=15 故障持續(xù)時間,單位為秒(此處為 15 秒)
curl -X POST -d "fault_type=cpu&thread_num=4&duration=15" http://localhost:5000/fault-inject

2. 注入內(nèi)存故障

# fault_type=mem 指定錯誤故障類型(此處為 mem 類型)
# mem_size=120M 指定內(nèi)存泄露的數(shù)值(此處為 120M ,注意 M 不能省略)
# thread_num=4 觸發(fā)該錯誤的線程數(shù)(此處為 4 個線程)
# duration=15 故障持續(xù)時間,單位為秒(此處為 15 秒)
curl -X POST -d "fault_type=mem&mem_size=120M&thread_num=4&duration=15" http://localhost:5000/fault-inject

3.注入磁盤故障

# fault_type=disk 指定錯誤故障類型(此處為 disk 類型)
# io_times=4 
# duration=15 故障持續(xù)時間,單位為秒(此處為 15 秒)
curl -X POST -d "fault_type=disk&io_times=4&duration=15" http://localhost:5000/fault-inject

4.注入網(wǎng)絡(luò)故障

# fault_type=net 指定錯誤故障類型(此處為 net 類型)
# net_port=100
curl -X POST -d "fault_type=net&net_port=100" http://localhost:5000/fault-inject

本項目的鏡像將作為原本微服務(wù)應(yīng)用的 Sidecar 獨立部署運行， 因此在 K8s 環(huán)境中其應(yīng)該與業(yè)務(wù)應(yīng)用部署于同一個 Pod 之中。

您可以利用 yaml 啟動一個多帶帶的 Pod 來初步體驗一下這個應(yīng)用。快讀啟動的 yaml 如下所示( Istio 同樣可以這樣寫, K8s 版本為 1.13.1, Istio 版本為 1.0.6 ):

---
# 為 fault injection 創(chuàng)建 service 分配端口 #
---
apiVersion: v1
kind: Service
metadata:
  name: single-fault-injection
  namespace: default
spec:
  selector:
    # deployment identifier
    # 這個標(biāo)簽要與 deployment 中相對應(yīng)
    app: fault-injection
  ports:
    - protocol: TCP
      port: 5000  # 容器內(nèi)端口為 5000
      nodePort: 30050  # 映射至主機的 30050 端口
  type: NodePort  # 映射方式為 NodePort
---
# 將該模塊作為一個獨立的 Pod 在 K8s 上進行部署 #
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: single-fault-injection
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        # svc identifier
        # 這個標(biāo)簽要與 service 中相對應(yīng)
        app: fault-injection
    spec:
      containers:
      # 錯誤注入模塊的 container
      - name: fault-injection-container
        image: xinyaotian/micro-fault-injection:1.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5000
        # 該容器的資源限制, 錯誤注入可使其達到峰值 #
        resources:
          limits:
            cpu: "0.4"
            memory: 128Mi

如果您希望以 Sidecar 的形式將本應(yīng)用部署在其他微服務(wù)的 Pod 之中同樣可行，這也是本項目的設(shè)計初衷。在 K8s 環(huán)境下部署和啟動的 yaml 如下所示意( Istio 同樣可以這樣寫, K8s 版本為 1.13.1, Istio 版本為 1.0.6 ):

---
# 為 fault injection 創(chuàng)建 service 分配端口 #
---
apiVersion: v1
kind: Service
metadata:
 name: your-microapp-with-faultinjection
 namespace: default
spec:
 selector:
 # deployment identifier
 # 這個標(biāo)簽要與 deployment 中相對應(yīng)
 app: sidecar-fault-injection
 ports:
    - protocol: TCP
 port: 5000
 nodePort: 30050
 type: NodePort
---
# 相應(yīng)的 deployment 配置( 與原應(yīng)用配置在一起 )
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: your-microapp-with-faultinjection
 namespace: default
spec:
 replicas: 1
 template:
 metadata:
 labels:
 # svc identifier
 # 這個標(biāo)簽要與 service 中相對應(yīng)
 app: sidecar-fault-injection
 spec:
 containers:
 # 你原來應(yīng)用的 container 信息
      - name: your-micro-app
 image: your-docker-name/project:1.0
 imagePullPolicy: IfNotPresent
 env:
        - name: PATH_VALUE
 value: "example"
 ports:
        - containerPort: 80
 # ------------------- #
 # Sidecar 錯誤注入模塊的 container
      - name: fault-injection-sidecar
 image: xinyaotian/micro-fault-injection:1.0.0
 imagePullPolicy: IfNotPresent
 ports:
        - containerPort: 5000
 # ------------------- #
---

在我自己的實驗集群上，利用 Istio 啟動該服務(wù)，并對其注入內(nèi)存故障后，可以在 Grafana 監(jiān)控面板上清晰地看到微服務(wù) Pod 的內(nèi)存忽高忽低，非常有趣。 錯誤注入的結(jié)果如下圖所示。

上圖: 注入內(nèi)存故障后, 我自己的 Istio 集群監(jiān)測微服務(wù)資源面板的可視化展現(xiàn)

項目到這里已經(jīng)滿足了實驗室內(nèi)師兄們絕大部分的科研需求。在之后的迭代中預(yù)計還會加入故障的產(chǎn)生速率( 例如 CPU 使用率會呈線性或指數(shù)上漲等 )，相應(yīng)的 API 也會采用向前兼容的形式進行擴充( 添加更多的可選參數(shù)，不填則設(shè)置為默認(rèn)值 )，以確保這個版本或之前版本使用者的代碼無需改變而可繼續(xù)使用后續(xù)版本。

此外，簡單的用戶控制面板也會在后續(xù)版本中開發(fā)。通過提供的用戶界面，使用者可以在界面上輸入?yún)?shù)并通過按鈕進行錯誤注入，而不再僅僅通過發(fā)送 POST 請求( 雖然底層原理還是本地請求 )。相信用戶界面會在匯報演示時為導(dǎo)師和師兄們帶來諸多便利。

本項目主要以 Sidecar 的方式開發(fā)了一個用于錯誤注入的實驗鏡像，并通過在 docker 和 k8s 上運行從而達到對微服務(wù)單元注入故障的目標(biāo)，為研究集群自動擴縮容、微服務(wù)自動擴縮容等課題提供了前提保障和研究條件。

感謝您的閱讀，如果您對這個項目有什么更好的建議，或指出哪里設(shè)計有問題，我都會非常歡迎，洗耳恭聽。非常希望于讀完本文的您進行交流，歡迎您在下方留言。

如果您的科研團隊也有類似需求，也非常歡迎與我們進行合作，并對針對本項目提出寶貴的改進意見。