Linkerd 2.10(Step by Step)—混沌工程之注入故障
Linkerd 2.10 中文手冊持續修正更新中：
- https://linkerd.hacker-linner.com
使用 Service Mesh Interface 的 Traffic Split API 很容易將故障注入應用程序。TrafficSplit 允許您將一定比例的流量重定向到特定后端。這個后端是完全靈活的，可以返回任何你想要的響應——500 秒、超時甚至瘋狂的有效載荷。
books demo 是展示這種行為的好方法。整體拓撲如下：
在本指南中，您將把一些請求從 webapp 拆分到 books。大多數請求最終會到達正確的 books 目的地，但其中一些將被重定向到有問題的后端。此后端將為每個請求返回 500 秒并將錯誤注入 webapp 服務。不需要更改代碼，并且由于此方法是配置驅動(configuration driven)的， 因此可以將其添加到集成測試和 CI 管道中。如果你真的過著混沌工程(chaos engineering)的 lifestyle，甚至可以在生產中使用故障注入。
先決條件
要使用本指南，您需要在集群上安裝 Linkerd 及其 Viz 擴展。
設置服務
首先，將 books 示例應用程序添加到您的集群：
- kubectl create ns booksapp && \
- linkerd inject https://run.linkerd.io/booksapp.yml | \
- kubectl -n booksapp apply -f -
由于此清單在其他地方用作 demo，因此已配置錯誤率(error rate)。為了展示故障注入的工作原理，需要去除錯誤率，以便有一個可靠的基線(reliable baseline)。要將 bookapp 的成功率提高到 100%，請運行：
- kubectl -n booksapp patch deploy authors \
- --type='json' \
- -p='[{"op":"remove", "path":"/spec/template/spec/containers/0/env/2"}]'
過了一會兒，統計數據會顯示 100% 的成功率。您可以通過運行以下命令來驗證這一點：
- linkerd viz -n booksapp stat deploy
輸出最終看起來有點像：
- NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN
- authors 1/1 100.00% 7.1rps 4ms 26ms 33ms 6
- books 1/1 100.00% 8.6rps 6ms 73ms 95ms 6
- traffic 1/1 - - - - - -
- webapp 3/3 100.00% 7.9rps 20ms 76ms 95ms 9
創建有問題的后端
將錯誤注入到 booksapp 中需要一個配置為返回錯誤的服務。為此，您可以啟動 NGINX 并通過運行將其配置為返回 500s：
- cat <<EOF | linkerd inject - | kubectl apply -f -
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: error-injector
- namespace: booksapp
- data:
- nginx.conf: |-
- events {}
- http {
- server {
- listen 8080;
- location / {
- return 500;
- }
- }
- }
- ---
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: error-injector
- namespace: booksapp
- labels:
- app: error-injector
- spec:
- selector:
- matchLabels:
- app: error-injector
- replicas: 1
- template:
- metadata:
- labels:
- app: error-injector
- spec:
- containers:
- - name: nginx
- image: nginx:alpine
- volumeMounts:
- - name: nginx-config
- mountPath: /etc/nginx/nginx.conf
- subPath: nginx.conf
- volumes:
- - name: nginx-config
- configMap:
- name: error-injector
- ---
- apiVersion: v1
- kind: Service
- metadata:
- name: error-injector
- namespace: booksapp
- spec:
- ports:
- - name: service
- port: 8080
- selector:
- app: error-injector
- EOF
注入故障
隨著 booksapp 和 NGINX 的運行，現在是時候在現有的后端(backend)、books 和 新創建的 error-injector 之間部分地分割流量了。這是通過向集群添加 TrafficSplit 配置來實現的：
- cat <<EOF | kubectl apply -f -
- apiVersion: split.smi-spec.io/v1alpha1
- kind: TrafficSplit
- metadata:
- name: error-split
- namespace: booksapp
- spec:
- service: books
- backends:
- - service: books
- weight: 900m
- - service: error-injector
- weight: 100m
- EOF
當 Linkerd 看到流向 Books 服務的流量時， 它會向原始服務發送 9⁄10 個請求，向錯誤注入器(error injector)發送 1⁄10 個請求。您可以通過運行 stat 并顯式過濾來自 webapp 的請求來查看它的樣子：
- linkerd viz -n booksapp routes deploy/webapp --to service/books
與之前的 stat 命令只查看服務器收到的請求不同， 這個 routes 命令過濾到所有由 webapp 發出的 發往 books 服務本身的請求。輸出應顯示 90% 的成功率：
- ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
- [DEFAULT] books 90.08% 2.0rps 5ms 69ms 94ms
在這種情況下，您正在查看 service 而不是 deployment。如果你運行這個命令并查看 deploy/books，成功率仍然是 100%。這樣做的原因是 error-injector 是一個完全獨立的 deployment， 并且流量正在服務級別(service level)轉移。請求永遠不會到達 books pod，而是重新路由到錯誤注入器的 pod。
清理
要從集群中刪除本指南中的所有內容，請運行：
- kubectl delete ns booksapp
【編輯推薦】
