Istio如何注入延迟并测试应用程序的弹性。
kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
为了测试微服务应用程序 Bookinfo 的弹性,我们将为用户 jason 在 reviews:v2 和 ratings 服务之间注入一个 7 秒的延迟。由于 reviews:v2 服务对其 ratings 服务的调用具有 10 秒的硬编码连接超时,比我们设置的 7s 延迟要大,因此我们期望端到端流程是正常的。
创建故障注入规则以延迟来自用户 jason(测试用户)的流量
kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
YAML具体内容如下:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- match:
- headers:
end-user:
exact: jason
fault:
delay:
percentage:
value: 100.0
fixedDelay: 7s
route:
- destination:
host: ratings
subset: v1
- route:
- destination:
host: ratings
subset: v1
确认已创建规则:
kubectl get virtualservice ratings -o yaml
Error fetching product reviews!
Sorry, product reviews are currently unavailable for this book.
你发现了一个 bug。在微服务中有硬编码超时,导致 reviews 服务失败。在 productpage 和 reviews 服务之间超时时间是 6s(编码 3s + 1 次重试总共 6s),reviews 和 ratings 服务之间的硬编码连接超时为 10s 。由于我们引入的延时,/productpage 提前超时并引发错误。
这些类型的错误可能发生在典型的企业应用程序中,其中不同的团队独立地开发不同的微服务。Istio 的故障注入规则可帮助您识别此类异常,而不会影响最终用户。如本次案例,仅会限制用户 jason 的失败影响,不会影响任何其他用户身份登录。
reviews 服务的 v3 版已经修复该问题,因此我们可以通过将所有流量迁移到 reviews:v3 来解决问题。
测试微服务弹性的另一种方法是引入 HTTP abort 故障。在这个任务中,在 ratings 微服务中引入 HTTP abort ,测试用户为 jason 。
为用户 jason 创建故障注入规则发送 HTTP abort
kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml
YAML具体内容如下:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- match:
- headers:
end-user:
exact: jason
fault:
abort:
percentage:
value: 100.0
httpStatus: 500
route:
- destination:
host: ratings
subset: v1
- route:
- destination:
host: ratings
subset: v1
确认已创建规则
kubectl get virtualservice ratings -o yaml
如果规则成功传播到所有的 pod,您应该能立即看到页面加载并看到 Ratings service is currently unavailable 消息。如果您注销用户 jason 或在匿名窗口(或其他浏览器)中打开 Bookinfo 应用程序, 您将看到 /productpage 为除 jason 以外用户调用了 reviews:v1(它根本不调用 ratings)。 因此,您不会看到任何错误消息。