[[406687]]

Linkerd 2.10 中文手冊持續(xù)修正更新中：

• https://linkerd.hacker-linner.com

使用 Service Mesh Interface 的 Traffic Split API 很容易將故障注入應(yīng)用程序。TrafficSplit 允許您將一定比例的流量重定向到特定后端。這個后端是完全靈活的，可以返回任何你想要的響應(yīng)——500 秒、超時甚至瘋狂的有效載荷。

books demo 是展示這種行為的好方法。整體拓?fù)淙缦拢?/p>

在本指南中，您將把一些請求從 webapp 拆分到 books。大多數(shù)請求最終會到達(dá)正確的 books 目的地，但其中一些將被重定向到有問題的后端。此后端將為每個請求返回 500 秒并將錯誤注入 webapp 服務(wù)。不需要更改代碼，并且由于此方法是配置驅(qū)動(configuration driven)的， 因此可以將其添加到集成測試和 CI 管道中。如果你真的過著混沌工程(chaos engineering)的 lifestyle，甚至可以在生產(chǎn)中使用故障注入。

先決條件

要使用本指南，您需要在集群上安裝 Linkerd 及其 Viz 擴(kuò)展。

設(shè)置服務(wù)

首先，將 books 示例應(yīng)用程序添加到您的集群：

kubectl create ns booksapp && \ 
  linkerd inject https://run.linkerd.io/booksapp.yml | \ 
  kubectl -n booksapp apply -f - 

由于此清單在其他地方用作 demo，因此已配置錯誤率(error rate)。為了展示故障注入的工作原理，需要去除錯誤率，以便有一個可靠的基線(reliable baseline)。要將 bookapp 的成功率提高到 100%，請運(yùn)行：

kubectl -n booksapp patch deploy authors \ 
  --type='json' \ 
  -p='[{"op":"remove", "path":"/spec/template/spec/containers/0/env/2"}]' 

過了一會兒，統(tǒng)計(jì)數(shù)據(jù)會顯示 100% 的成功率。您可以通過運(yùn)行以下命令來驗(yàn)證這一點(diǎn)：

linkerd viz -n booksapp stat deploy 

輸出最終看起來有點(diǎn)像：

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 

創(chuàng)建有問題的后端

將錯誤注入到 booksapp 中需要一個配置為返回錯誤的服務(wù)。為此，您可以啟動 NGINX 并通過運(yùn)行將其配置為返回 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 的運(yùn)行，現(xiàn)在是時候在現(xiàn)有的后端(backend)、books 和 新創(chuàng)建的 error-injector 之間部分地分割流量了。這是通過向集群添加 TrafficSplit 配置來實(shí)現(xiàn)的：

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 

當(dāng) Linkerd 看到流向 Books 服務(wù)的流量時， 它會向原始服務(wù)發(fā)送 9⁄10 個請求，向錯誤注入器(error injector)發(fā)送 1⁄10 個請求。您可以通過運(yùn)行 stat 并顯式過濾來自 webapp 的請求來查看它的樣子：

linkerd viz -n booksapp routes deploy/webapp --to service/books 

與之前的 stat 命令只查看服務(wù)器收到的請求不同， 這個 routes 命令過濾到所有由 webapp 發(fā)出的 發(fā)往 books 服務(wù)本身的請求。輸出應(yīng)顯示 90% 的成功率：

ROUTE       SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99 
[DEFAULT]     books    90.08%   2.0rps           5ms          69ms          94ms 

在這種情況下，您正在查看 service 而不是 deployment。如果你運(yùn)行這個命令并查看 deploy/books，成功率仍然是 100%。這樣做的原因是 error-injector 是一個完全獨(dú)立的 deployment， 并且流量正在服務(wù)級別(service level)轉(zhuǎn)移。請求永遠(yuǎn)不會到達(dá) books pod，而是重新路由到錯誤注入器的 pod。

清理

要從集群中刪除本指南中的所有內(nèi)容，請運(yùn)行：

kubectl delete ns booksapp 

 【編輯推薦】