问题分析
service 前端有一个 gateway，后端有两个 pod，并且 service 的 DR 中的 LB 的 simple 配置的 round robin，手动用 curl 命令发送请求测试，结果并不是期望的那种消息在两个 pod 之间循环切换。而是看似随机选择转发。
分析
由于这个问题是我们系统测试同事报给我们的，开始以为环境不一样，他们的环境是类似真实环境，前端有多个 gateway，所以以为是前端的 gateway 负载均衡了这些消息到不同的 worker 上去了，导致的这个问题。于是让同事发送消息到特定的 gateway 上进行测试，结果一样，没有均衡。于是排除了这个原因，然后又咨询了一些朋友，说 RR 是连接跟踪的，所有对于长连接，它会始终转发的一个后端 pod，于是分析是不是由于长连接导致，因此让同事手动 curl 命令发送请求到特定的 gateway 上，测试结果是仍然还是不均衡。于是我在本地环境 (minikube)，手动 curl 命令测试，结果和同事的一样，看似随机的发到两个 pod 中。
通过查询资料和咨询专业的同事，最后发现，envoy 底层使用的是工作线程的方式转发请求的，默认开启 CPU 相同核数的工作线程，而对于每个工作线程来说，它是每个后端 pod 轮询的转发，而不保证多个工作线程的时候 是 round robin 的，也就是说在正常的环境上，基本上都不是期望的那种每条消息都在 pod 之间轮询，而是像测试的那样，看起来像是随机的。同时 envoy 提供参数–concurrency 去设置这个工作线程的数量。通过修改这个参数等于 1，然后进行前面的 curl 命令测试，得到的结果，就是我们所期待的一样，消息在两个 pod 之前轮询了。
具体的说明 可阅读 envoy FAQ 官方文档 Why doesn’t RR load balancing appear to be even?。
总结
学无止境；广交朋友。
参考
why istio Round robin load balance not work as expect
Why doesn’t RR load balancing appear to be even?