熔断
本任务展示如何为连接、请求以及异常检测配置熔断。
熔断,是创建弹性微服务应用程序的重要模式。熔断能够使您的应用程序具备应对来自故障、潜在峰值和其他 未知网络因素影响的能力。
这个任务中,你将配置熔断规则,然后通过有意的使熔断器“跳闸”来测试配置。
开始之前
跟随安装指南安装 Istio。
启动 httpbin 样例程序。
如果您启用了 sidecar 自动注入,通过以下命令部署
httpbin服务:$ kubectl apply -f @samples/httpbin/httpbin.yaml@
否则,您必须在部署
httpbin应用程序前进行手动注入,部署命令如下:$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@)
应用程序 httpbin 作为此任务的后端服务。
配置熔断器
创建一个目标规则,在调用
httpbin服务时应用熔断设置:如果您的 Istio 启用了双向 TLS 身份验证,则必须在应用目标规则之前将 TLS 流量策略
mode:ISTIO_MUTUAL添加到DestinationRule。否则请求将产生 503 错误,如这里所述。$ kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: httpbinspec:host: httpbintrafficPolicy:connectionPool:tcp:maxConnections: 1http:http1MaxPendingRequests: 1maxRequestsPerConnection: 1outlierDetection:consecutiveErrors: 1interval: 1sbaseEjectionTime: 3mmaxEjectionPercent: 100EOF
验证目标规则是否已正确创建:
$ kubectl get destinationrule httpbin -o yamlapiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: httpbin...spec:host: httpbintrafficPolicy:connectionPool:http:http1MaxPendingRequests: 1maxRequestsPerConnection: 1tcp:maxConnections: 1outlierDetection:baseEjectionTime: 180.000sconsecutiveErrors: 1interval: 1.000smaxEjectionPercent: 100
增加一个客户
创建客户端程序以发送流量到 httpbin 服务。这是一个名为 Fortio 的负载测试客户的,其可以控制连接数、并发数及发送 HTTP 请求的延迟。通过 Fortio 能够有效的触发前面 在 DestinationRule 中设置的熔断策略。
向客户端注入 Istio Sidecar 代理,以便 Istio 对其网络交互进行管理:
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/sample-client/fortio-deploy.yaml@)
登入客户端 Pod 并使用 Fortio 工具调用
httpbin服务。-curl参数表明发送一次调用:$ FORTIO_POD=$(kubectl get pod | grep fortio | awk '{ print $1 }')$ kubectl exec -it $FORTIO_POD -c fortio /usr/bin/fortio -- load -curl http://httpbin:8000/getHTTP/1.1 200 OKserver: envoydate: Tue, 16 Jan 2018 23:47:00 GMTcontent-type: application/jsonaccess-control-allow-origin: *access-control-allow-credentials: truecontent-length: 445x-envoy-upstream-service-time: 36{"args": {},"headers": {"Content-Length": "0","Host": "httpbin:8000","User-Agent": "istio/fortio-0.6.2","X-B3-Sampled": "1","X-B3-Spanid": "824fbd828d809bf4","X-B3-Traceid": "824fbd828d809bf4","X-Ot-Span-Context": "824fbd828d809bf4;824fbd828d809bf4;0000000000000000","X-Request-Id": "1ad2de20-806e-9622-949a-bd1d9735a3f4"},"origin": "127.0.0.1","url": "http://httpbin:8000/get"}
可以看到调用后端服务的请求已经成功!接下来,可以测试熔断。
触发熔断器
在 DestinationRule 配置中,您定义了 maxConnections: 1 和 http1MaxPendingRequests: 1。 这些规则意味着,如果并发的连接和请求数超过一个,在 istio-proxy 进行进一步的请求和连接时,后续请求或 连接将被阻止。
发送并发数为 2 的连接(
-c 2),请求 20 次(-n 20):$ kubectl exec -it $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/getFortio 0.6.2 running at 0 queries per second, 2->2 procs, for 5s: http://httpbin:8000/getStarting at max qps with 2 thread(s) [gomax 2] for exactly 20 calls (10 per thread + 0)23:51:10 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)Ended after 106.474079ms : 20 calls. qps=187.84Aggregated Function Time : count 20 avg 0.010215375 +/- 0.003604 min 0.005172024 max 0.019434859 sum 0.204307492# range, mid point, percentile, count>= 0.00517202 <= 0.006 , 0.00558601 , 5.00, 1> 0.006 <= 0.007 , 0.0065 , 20.00, 3> 0.007 <= 0.008 , 0.0075 , 30.00, 2> 0.008 <= 0.009 , 0.0085 , 40.00, 2> 0.009 <= 0.01 , 0.0095 , 60.00, 4> 0.01 <= 0.011 , 0.0105 , 70.00, 2> 0.011 <= 0.012 , 0.0115 , 75.00, 1> 0.012 <= 0.014 , 0.013 , 90.00, 3> 0.016 <= 0.018 , 0.017 , 95.00, 1> 0.018 <= 0.0194349 , 0.0187174 , 100.00, 1# target 50% 0.0095# target 75% 0.012# target 99% 0.0191479# target 99.9% 0.0194062Code 200 : 19 (95.0 %)Code 503 : 1 (5.0 %)Response Header Sizes : count 20 avg 218.85 +/- 50.21 min 0 max 231 sum 4377Response Body/Total Sizes : count 20 avg 652.45 +/- 99.9 min 217 max 676 sum 13049All done 20 calls (plus 0 warmup) 10.215 ms avg, 187.8 qps
有趣的是,几乎所有的请求都完成了!
istio-proxy确实允许存在一些误差。Code 200 : 19 (95.0 %)Code 503 : 1 (5.0 %)
将并发连接数提高到 3 个:
$ kubectl exec -it $FORTIO_POD -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://httpbin:8000/getFortio 0.6.2 running at 0 queries per second, 2->2 procs, for 5s: http://httpbin:8000/getStarting at max qps with 3 thread(s) [gomax 2] for exactly 30 calls (10 per thread + 0)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)Ended after 71.05365ms : 30 calls. qps=422.22Aggregated Function Time : count 30 avg 0.0053360199 +/- 0.004219 min 0.000487853 max 0.018906468 sum 0.160080597# range, mid point, percentile, count>= 0.000487853 <= 0.001 , 0.000743926 , 10.00, 3> 0.001 <= 0.002 , 0.0015 , 30.00, 6> 0.002 <= 0.003 , 0.0025 , 33.33, 1> 0.003 <= 0.004 , 0.0035 , 40.00, 2> 0.004 <= 0.005 , 0.0045 , 46.67, 2> 0.005 <= 0.006 , 0.0055 , 60.00, 4> 0.006 <= 0.007 , 0.0065 , 73.33, 4> 0.007 <= 0.008 , 0.0075 , 80.00, 2> 0.008 <= 0.009 , 0.0085 , 86.67, 2> 0.009 <= 0.01 , 0.0095 , 93.33, 2> 0.014 <= 0.016 , 0.015 , 96.67, 1> 0.018 <= 0.0189065 , 0.0184532 , 100.00, 1# target 50% 0.00525# target 75% 0.00725# target 99% 0.0186345# target 99.9% 0.0188793Code 200 : 19 (63.3 %)Code 503 : 11 (36.7 %)Response Header Sizes : count 30 avg 145.73333 +/- 110.9 min 0 max 231 sum 4372Response Body/Total Sizes : count 30 avg 507.13333 +/- 220.8 min 217 max 676 sum 15214All done 30 calls (plus 0 warmup) 5.336 ms avg, 422.2 qps
现在,您将开始看到预期的熔断行为,只有 63.3% 的请求成功,其余的均被熔断器拦截:
Code 200 : 19 (63.3 %)Code 503 : 11 (36.7 %)
查询
istio-proxy状态以了解更多熔断详情:$ kubectl exec $FORTIO_POD -c istio-proxy -- pilot-agent request GET stats | grep httpbin | grep pendingcluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_active: 0cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_failure_eject: 0cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_overflow: 12cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_total: 39
可以看到
upstream_rq_pending_overflow值12,这意味着,目前为止已有 12 个调用被标记为熔断。
清理
清理规则:
$ kubectl delete destinationrule httpbin
下线 httpbin 服务和客户端:
$ kubectl delete deploy httpbin fortio-deploy$ kubectl delete svc httpbin
相关内容
使用 Admiral 管理 Istio 多集群的配置和服务发现
为 Istio deployment(cluster)提供自动化 Istio 配置,并让其像单个网格一样工作。
把 Istio 入口网关配置为外部服务的代理。
将需要隔离的环境部署到单独的网格中,并通过网格联邦启用网格间通信。
管控出口流量的备选方案比较,包括性能因素。
使用 Istio 的出口流量管控来阻止相关出口流量攻击。
涉及出口流量攻击和出口流量管控要求。