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.
【编辑推荐】