istio 负载均衡功能验证

前提：
可参考官网文档进行前期工作：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 版本的实例上