Linkerd 2.10(Step by Step)—混沌工程之注入故障

开发 前端
在本指南中,您将把一些请求从 webapp 拆分到 books。大多数请求最终会到达正确的 books 目的地,但其中一些将被重定向到有问题的后端。此后端将为每个请求返回 500 秒并将错误注入 webapp 服务。

[[406687]]

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 - 
  • 1.
  • 2.
  • 3.

由于此清单在其他地方用作 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"}]' 
  • 1.
  • 2.
  • 3.

过了一会儿,统计数据会显示 100% 的成功率。您可以通过运行以下命令来验证这一点:

linkerd viz -n booksapp stat deploy 
  • 1.

输出最终看起来有点像:

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 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.

创建有问题的后端

将错误注入到 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 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
  • 45.
  • 46.
  • 47.
  • 48.
  • 49.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
  • 57.
  • 58.
  • 59.

注入故障

随着 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 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.

当 Linkerd 看到流向 Books 服务的流量时, 它会向原始服务发送 9⁄10 个请求,向错误注入器(error injector)发送 1⁄10 个请求。您可以通过运行 stat 并显式过滤来自 webapp 的请求来查看它的样子:

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

与之前的 stat 命令只查看服务器收到的请求不同, 这个 routes 命令过滤到所有由 webapp 发出的 发往 books 服务本身的请求。输出应显示 90% 的成功率:

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

在这种情况下,您正在查看 service 而不是 deployment。如果你运行这个命令并查看 deploy/books,成功率仍然是 100%。这样做的原因是 error-injector 是一个完全独立的 deployment, 并且流量正在服务级别(service level)转移。请求永远不会到达 books pod,而是重新路由到错误注入器的 pod。

清理

要从集群中删除本指南中的所有内容,请运行:

kubectl delete ns booksapp 
  • 1.

 【编辑推荐】

 

责任编辑:姜华 来源: 黑客下午茶
相关推荐

2021-06-22 06:24:57

Linkerd Ingress 流量网络技术

2021-06-16 17:42:48

Linkerd 配置CPU

2021-06-17 06:20:43

Linkerd Kustomize网络技术

2021-06-17 14:29:39

Linkerd 分布式跟踪Linkerd 2.1

2021-06-22 06:41:38

Linkerd 安装多集群组件网络技术

2021-06-17 06:13:29

Linkerd Prometheus 网络技术

2021-06-15 05:45:56

Linkerd annotations网络技术

2021-06-15 05:52:33

Linkerd canary网络技术

2021-06-24 07:20:21

Linked GitOps Argo CD

2021-06-16 06:31:55

Linkerd 2.1Step by SteWebhook TLS

2011-04-19 14:02:09

SSAS

2010-09-08 09:41:03

私有云部署

2009-04-22 17:18:29

Vxworks驱动加载step by ste

2021-06-29 13:09:07

服务配置文件

2024-01-25 11:38:11

AI数据

2022-08-30 22:22:23

developerArchitectu

2023-01-06 13:48:21

自然语言推理算法

2023-05-15 09:43:49

模型数据

2010-04-06 15:09:16

无线路由器安全配置

2010-08-04 14:30:25

点赞
收藏

51CTO技术栈公众号