前提:
可参考官网文档进行前期工作:https://istio.io/latest/zh/docs/setup/getting-started/
1) K8S 集群已经部署了 istio
2) 已部署了官网 bookinfo 相关服务 (本示例中将服务部署在了 wjx namespace 下)
3) 项目下服务已经注入了 sidecar
4)部署 sleep 服务,部署 yaml 文件 位于 istio-1.16.2/samples/sleep/sleep.yaml(sleep 服务用于网格服务间测试)
https://raw.githubusercontent.com/istio/istio/release-1.16/samples/sleep/sleep.yaml
负载均衡
操作前提:
确认服务正常运行,正常访问;
确认网格环境正常
reviews 服务,版本说明:
该服务有3个版本实例,不同版本返回值不同,根据返回值进行区分不同版本
测试客户端使用网格内 sleep 服务,测试时会进入 sleep 容器内部,模拟网格内请求
- v1 版本不会调用 ratings 服务
- v2 版本会调用 ratings 服务,并使用 1 到 5 个黑色星形图标来显示评分信息
- v3 版本会调用 ratings 服务,并使用 1 到 5 个红色星形图标来显示评分信息。
# 三个版本返回结果不同
# v1
{"id": "1","reviews": [{ "reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"},{ "reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]}
# v2
{"id": "1","reviews": [{ "reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!", "rating": {"stars": 5, "color": "black"}},{ "reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.", "rating": {"stars": 4, "color": "black"}}]}
# v3
{"id": "1","reviews": [{ "reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!", "rating": {"stars": 5, "color": "red"}},{ "reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.", "rating": {"stars": 4, "color": "red"}}]}
1. 随机算法
随机负载平衡器选择随机可用主机。如果未配置健康检查策略,随机负载平衡器的性能通常优于轮询。随机选择避免了主机失败后对主机的偏见。
# sleep 容器内访问 reviews,通过访问的返回结果可以直观的看出来返回实例是随机的
curl http://reviews:9080/reviews/1
随机算法,对应的资源配置内容如下
请求命令:
# 发送 999 个请求
for i in $(seq 999); do curl http://reviews:9080/reviews/1; echo -e;done > response-log
# 统计调用数
# v1 版本请求数(没有 black 和 red 结果)
grep -v "\"black\|\"red\"" response-log | wc -l
# v2 版本请求数
grep -o \"black\" response-log | wc -l |awk '{print $1/2 }'
# v3 版本请求数 (需要除2,返回结果中有两个 )
grep -o \"red\" response-log | wc -l |awk '{print $1/2 }'
请求结果统计,v1、v2、v3 版本的请求数据量分别为 342、340、317
相对来说,v3 版本处理请求数相对较少,可知请求响应是随机的实例是随机分配的
2. 轮询算法
# 发送 999 个请求
for i in $(seq 999); do curl http://reviews:9080/reviews/1; echo -e;done > response-log
# 统计调用数
# v1 版本请求数(没有 black 和 red 结果)
grep -v "\"black\|\"red\"" response-log | wc -l
# v2 版本请求数
grep -o \"black\" response-log | wc -l |awk '{print $1/2 }'
# v3 版本请求数 (需要除2,返回结果中有两个 )
grep -o \"red\" response-log | wc -l |awk '{print $1/2 }'
请求结果统计,v1、v2、v3 版本的请求数据量分别为 333、333、333
可知请求响应是按轮询分配各版本实例的
3. 会话保持(Hash 算法)
3.1 httpHeader
设置会话保持的 http headers key 为 aa,对应的资源配置内容如下:
请求命令
# 网格内测试(sleep 容器内)
curl -H "aa: aa" http://reviews:9080/reviews/1; echo -e
curl -H "aa: bb" http://reviews:9080/reviews/1; echo -e
可看到带有同样 key:value 值的请求会转发到同一实例上
“aa: aa” 请求发送到了 v2 版本实例上
“aa: bbbb” 请求发送到了 v3 版本实例上
3.2 httpCookie
设置会话保持的 http cookie key 为 cookie-test,对应的资源配置内容如下:
请求命令
curl -b "cookie-test=xxx" http://reviews:9080/reviews/1
curl -b "test=yyy" http://reviews:9080/reviews/1
请求传入 cookie-test=xxx 指定 cookie,请求每次都会分配到 v3 版本实例上
请求传入 test=yyy未指定 cookie,同一 cookie 请求没有会话保持
3.3 sourceIp
请求命令
curl http://reviews:9080/reviews/1; echo -e
sleep 容器内请求,请求会一直分配到 v1 版本实例上
更换请求源,进入 ratings 容器内请求 reviews 服务,如截图请求一直分配到了 v3 版本的实例上