Kubernetes 中如何做到 AB 分流

[idblife]

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

[minmini]

service mesh?

[armyHcz]

这不就是 service 的流量分配吗,类似 nginx 的负载均衡

[idblife]

@armyHcz
service 层面的负载均衡做不到 AB 两组网络流量隔离吧

[idblife]

@minmini
istio 可以做到，但是性能垃圾

[helone]

istio

[hwdef]

平常用 service ，特定时段用 networkpolicy?

[idblife]

@helone
性能不行啊

[rushssss]

只用原生 service 实现的话，可以考虑 A 、B 两组服务打上两组标签，如 service=backend,group=a; service=backend,group=b


建立一个 svc ，平时 selecor 只指定 service=backend 就行，这样 AB 两组都会被选择到

需要的时候增加 selector 的条件，即可实现流量到指定的 group

[pigmen]

@idblife #7 哪里来的结论，istio （背后主要是 envoy ）性能不行？

[zhanggg]

ingress + service selector + networkpolicy 组合试试

[FullBridgeRect]

@pigmen 可能想表达 iptables ？用过是有明显损耗，但不至于不行吧

[NathanInMac]

就楼主说的这点需求 nginx 也能做到

[idblife]

@pigmen
实战经验

[idblife]

@FullBridgeRect
@pigmen
istio 你们上过生产没？

[idblife]

@NathanInMac
求 nginx 指教

[binfengxy]

性能垃圾? 性能不是现在很多服务最后才考虑的事情么？ XD

[idblife]

@rushssss
这个思路不错，不过我们有几百个服务，操作起来比较繁琐，但是值得试试，多谢

[idblife]

@binfengxy
我们是实际用过 istio 的。。。

[binfengxy]

关键是需求怎么定吧？感觉这个比较难根据实际弄清楚

下面是我当时做灰度发布时候定的初始目标，然后 pipeline 按这个要求去改.

发出来大家讨论一下，希望多多给建议，谢谢！

需要达成的目标

1. 可以手动指定某个老版本和最新版本同时发布在生产环境中；
2. 实现发布新版本时，让测试人员对新版本进行线上测试，普通用户依旧访问老版本；
3. 可以灵活控制新老版本的访问流量比例及运行服务器副本（ pod ）数量；
4. 保证同一个用户持续稳定访问一个版本，而不是首次请求新版本，后面可能请求老版本导致 404 等错误；
5. 在一个项目中，需要在部署环境中存在 2 个不同版本的发布；
6. 1 个版本为当前提交并打 tag 的 image 版本，另一个版本为指定的 tag 且发布成功的 image 版本（若不指定则默认为上个 tag 对应的 image 版本）；
7. 确保当前版本号和指定的版本号以变量的方式注入到对应的发布版本 image 中；

[Hanggi]

istio 性能垃圾？头一回听。

我们这边生产环境，不算 replica 几十个服务统一 istio 管理流量。

服务底层都是 envoy 做转发，怎么会有性能问题，还是再看看是不是你配置有问题。

Istio 是正解。

[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 到需求.
发布的话, 探针停一半不就可以了

[calmzhu]

是指灰度发布这种效果吗? https://help.aliyun.com/document_detail/200941.html

[raptor]

搭车问一下，consul 比 istio 如何？

[tanxnative]

10%的性能损失,带来的语言无关特性
其实你使用其他框架也会有性能损失

[idblife]

@tanxnative
如果用 k8s 里 service 标签来实现呢？

[idblife]

@calmzhu
需要考虑到比如 100 个服务发布新版本，这一百个服务的旧版本之间互相调用，不能调用到新版本。

[morphyhu]

talk is cheap,show me the data.
"@idblife
istio 可以做到，但是性能垃圾"

[zmal]

性能损耗是必然的啊。真要说起来，容器化虚拟化技术本来就都有性能损耗。

[idblife]

@morphyhu
响应时间增加 10%
istio ingress gateway 在不同 worknode 上响应时间相差 20%

[idblife]

@zmal
性能损耗也得看 roi
istio 不值

[tanxnative]

我猜你服务没有治理, 有很多同步的调用, 还不止一跳

[idblife]

@tanxnative
进行过指定接口的测试，确保调用链时合理的。