Kubernetes 中如何做到 AB 分流

[idblife]

就是把所有的服务分成 AB 两组，
平常流量随机进入 AB ，A 组服务也能调用 B 组服务。
在发布的特定时间段，AB 互相隔绝，做到先发布 A 组再发布 B 组。

[idblife]

@Hanggi
才几十个服务？
你们对比过 istio 会导致性能损耗多少不？

[strawberryBug]

没懂你说的 istio 导致的性能损耗是指什么？ envoy 转发带来的请求响应时长增加吗？

[eudore]

istio 性能垃圾+1

[Hanggi]

@idblife 你这人真有意思啊，才几十个服务，replica 都算上不就几百个了吗？

你在这里喊 Istio 性能垃圾，你把你的 Benchmark 发出来，内部运转的 profile 结果打出来给大家瞧瞧呗？

怎么，还等别人给你分析你的集群里的 Istio 为啥性能很垃圾吗？

[gengchun]

istio 本身我不是太喜欢。推广做得确实是比较优秀的。

不过运维大点规模服务的系统，一年至少化掉几百万小一千万吧，都是厂商求着给你做的。就这连优化 istio 也做不到的话，做 AB 分发这种基础需求还需要在 v 站上讨论，未免太不靠谱了。

这种基本上都要基于特定的版本和生态环境讨论。真的生产上组件和版本的选取也不是想怎么来都行的。厂商一般都是谈生意的时候，顺便帮你整个方案。谁没事会在 v 站上讨论这些？

OP 给的信息也过少。不会是哪个集成商在 v 站这里薅出一个方案文档？感觉可能是甲方上过一个 istio 失败了。所以这次不能用 istio 了。

就算在这里拿了个方案，感觉让 OP 实施，失败的概率还是过高。

[idblife]

@Hanggi
不知道你哪里来的自信，几十个服务 几百个 replica 听起来不小了，但是你做过 benchmark 吗？
我们是十几个集群，每个集群几百个服务，几千个 replica ，istio 带来的性能损耗在 10%左右，这还是我们调优后的性能。

[idblife]

@gengchun
厂商当然求着做，但是我们是自建的，只能自己摸索了

[idblife]

@strawberryBug
响应时间增加
各节点作为 upstream 响应时间差异大

[gengchun]

@idblife istio 大部分在 L7 算简单的，linkerd 估计更找不到方案，不然就是让开发在框架上做，还有就是 k8s 的网络插件上做。都是比优化 istio 更复杂，而且用的人更少，istio10% 看具体需求。我觉得还能再争取一下，但要再省，也就这三条路了。你确定真的需要，我只是假设从 8% 降到 1% 吗？追求这指标的成本是指数级增长的。

[Hanggi]

@idblife

听你这么一说更不觉得是 Istio 的性能问题了，是你们服务架构设计本身就有问题。

你标题问的就是怎么做 AB 分流，主流答案就是 Service Mesh 。

你觉得 Istio 性能有问题是你们本身设计有问题，不知道你哪儿来的自信说 Istio 垃圾。
（你起码把你的服务场景、workload 、具体响应时间长的原因说出来，证明是 Istio 或者 Envoy 本身有什么，那还听得过去。就一句 Istio 垃圾，怎么听都觉得你的机会来了啊，是不是摩拳擦掌要做个性能爆炸的 Service Mesh 服务呢？不是的话就好好设计一下你们的服务架构。）

[idblife]

@Hanggi
嗯，我说 istio 导致服务响应时间增加 10%以上所以 istio 垃圾，你一听就知道我的服务架构设计垃圾。
我想问一下，你的服务做过 istio 的性能测试吗？

[idblife]

@gengchun
我个人觉得够呛能降到 10%以内，
所以在想其他办法，
看看能不能从 k8s 原生 service 层或者 ingress 上来做

[BraveRBT]

可以在 k8s 里装个 APISIX,作为 ingress-controller.
这样做策略路由和标签路由就都没问题了,流量也不需要到 SVC 可以直接到 POD.

[idblife]

@BraveRBT
嗯，也在看这种方案，多谢

[pepesii]

抱着学习的态度，如果最后解决了也分享下过程和方案吧 :)

就单纯的流量隔离的话，我感觉就 networkpolicy 就可以了呀；

[idblife]

@pepesii
嗯
最终方案会更新下

[gengchun]

@idblife istio 或者说 service mesh 的核心，其实是一堆 CRD ，算是定义流量怎么走的一个标准——telemetry 这些暂时不讨论——相当于 nginx.conf 语法的东西。

原生 service 功能太少，ingress 功能多一些，但是肯定有 api 的。api 你过一次，无论是 nginx 还是 envoy 都意味着延迟增加。

简单的说，一切都是砍需求。当然，要流量分发，不太可能砍到连 envoyproxy 都不要了，至少目前为止，网络插件还没有普及。但是还是可能减少流量通过 envoyproxy 这种的次数。需求砍到一定程度，istio 去掉你觉得不必要的功能，也就差不多了。

[anubu]

8 楼的方法应该能解决问题，也很直观。大规模使用的话，可以封装一下。

没有 istio 使用经验，不过就接触到新闻和信息，istio 的确性能不太好，并且持续很久了。

[pipixia]

Istio 边车那套真不喜欢

[calmzhu]

没 Get 到需求.
发布的话, 探针停一半不就可以了