V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
idblife
V2EX  ›  Kubernetes

Kubernetes 中如何做到 AB 分流

  •  
  •   idblife · 118 天前 · 2939 次点击
    这是一个创建于 118 天前的主题,其中的信息可能已经有所发展或是发生改变。
    就是把所有的服务分成 AB 两组,
    平常流量随机进入 AB ,A 组服务也能调用 B 组服务。
    在发布的特定时间段,AB 互相隔绝,做到先发布 A 组再发布 B 组。
    51 条回复    2022-04-21 12:45:02 +08:00
    minmini
        1
    minmini  
       118 天前
    service mesh?
    armyHcz
        2
    armyHcz  
       118 天前
    这不就是 service 的流量分配吗,类似 nginx 的负载均衡
    idblife
        3
    idblife  
    OP
       118 天前
    @armyHcz
    service 层面的负载均衡做不到 AB 两组网络流量隔离吧
    idblife
        4
    idblife  
    OP
       118 天前
    @minmini
    istio 可以做到,但是性能垃圾
    helone
        5
    helone  
       118 天前
    istio
    hwdef
        6
    hwdef  
       118 天前   ❤️ 1
    平常用 service ,特定时段用 networkpolicy?
    idblife
        7
    idblife  
    OP
       118 天前
    @helone
    性能不行啊
    rushssss
        8
    rushssss  
       118 天前   ❤️ 2
    只用原生 service 实现的话,可以考虑 A 、B 两组服务打上两组标签,如 service=backend,group=a; service=backend,group=b


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

    需要的时候增加 selector 的条件,即可实现流量到指定的 group
    pigmen
        9
    pigmen  
       118 天前
    @idblife #7 哪里来的结论,istio (背后主要是 envoy )性能不行?
    zhanggg
        10
    zhanggg  
       118 天前
    ingress + service selector + networkpolicy 组合试试
    FullBridgeRect
        11
    FullBridgeRect  
       118 天前
    @pigmen 可能想表达 iptables ?用过是有明显损耗,但不至于不行吧
    NathanInMac
        12
    NathanInMac  
       118 天前
    就楼主说的这点需求 nginx 也能做到
    idblife
        13
    idblife  
    OP
       118 天前 via iPhone
    @pigmen
    实战经验
    idblife
        14
    idblife  
    OP
       118 天前 via iPhone
    @FullBridgeRect
    @pigmen
    istio 你们上过生产没?
    idblife
        15
    idblife  
    OP
       118 天前 via iPhone
    @NathanInMac
    求 nginx 指教
    binfengxy
        16
    binfengxy  
       118 天前
    性能垃圾? 性能不是现在很多服务最后才考虑的事情么? XD
    idblife
        17
    idblife  
    OP
       118 天前 via iPhone
    @rushssss
    这个思路不错,不过我们有几百个服务,操作起来比较繁琐,但是值得试试,多谢
    idblife
        18
    idblife  
    OP
       118 天前 via iPhone
    @binfengxy
    我们是实际用过 istio 的。。。
    binfengxy
        19
    binfengxy  
       118 天前
    关键是需求怎么定吧?感觉这个比较难根据实际弄清楚

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

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

    需要达成的目标

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

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

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

    Istio 是正解。
    idblife
        21
    idblife  
    OP
       118 天前
    @Hanggi
    才几十个服务?
    你们对比过 istio 会导致性能损耗多少不?
    strawberryBug
        22
    strawberryBug  
       118 天前 via Android
    没懂你说的 istio 导致的性能损耗是指什么? envoy 转发带来的请求响应时长增加吗?
    eudore
        23
    eudore  
       118 天前
    istio 性能垃圾+1
    Hanggi
        24
    Hanggi  
       118 天前
    @idblife 你这人真有意思啊,才几十个服务,replica 都算上不就几百个了吗?

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

    怎么,还等别人给你分析你的集群里的 Istio 为啥性能很垃圾吗?
    gengchun
        25
    gengchun  
       118 天前
    istio 本身我不是太喜欢。推广做得确实是比较优秀的。

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

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

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

    就算在这里拿了个方案,感觉让 OP 实施,失败的概率还是过高。
    idblife
        26
    idblife  
    OP
       118 天前
    @Hanggi
    不知道你哪里来的自信,几十个服务 几百个 replica 听起来不小了,但是你做过 benchmark 吗?
    我们是十几个集群,每个集群几百个服务,几千个 replica ,istio 带来的性能损耗在 10%左右,这还是我们调优后的性能。
    idblife
        27
    idblife  
    OP
       118 天前
    @gengchun
    厂商当然求着做,但是我们是自建的,只能自己摸索了
    idblife
        28
    idblife  
    OP
       118 天前
    @strawberryBug
    响应时间增加
    各节点作为 upstream 响应时间差异大
    gengchun
        29
    gengchun  
       118 天前
    @idblife istio 大部分在 L7 算简单的,linkerd 估计更找不到方案,不然就是让开发在框架上做,还有就是 k8s 的网络插件上做。都是比优化 istio 更复杂,而且用的人更少,istio10% 看具体需求。我觉得还能再争取一下,但要再省,也就这三条路了。你确定真的需要,我只是假设从 8% 降到 1% 吗?追求这指标的成本是指数级增长的。
    Hanggi
        30
    Hanggi  
       118 天前
    @idblife

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

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

    你觉得 Istio 性能有问题是你们本身设计有问题,不知道你哪儿来的自信说 Istio 垃圾。
    (你起码把你的服务场景、workload 、具体响应时间长的原因说出来,证明是 Istio 或者 Envoy 本身有什么,那还听得过去。就一句 Istio 垃圾,怎么听都觉得你的机会来了啊,是不是摩拳擦掌要做个性能爆炸的 Service Mesh 服务呢?不是的话就好好设计一下你们的服务架构。)
    idblife
        31
    idblife  
    OP
       118 天前
    @Hanggi
    嗯,我说 istio 导致服务响应时间增加 10%以上所以 istio 垃圾,你一听就知道我的服务架构设计垃圾。
    我想问一下,你的服务做过 istio 的性能测试吗?
    idblife
        32
    idblife  
    OP
       118 天前
    @gengchun
    我个人觉得够呛能降到 10%以内,
    所以在想其他办法,
    看看能不能从 k8s 原生 service 层或者 ingress 上来做
    BraveRBT
        33
    BraveRBT  
       118 天前
    可以在 k8s 里装个 APISIX,作为 ingress-controller.
    这样做策略路由和标签路由就都没问题了,流量也不需要到 SVC 可以直接到 POD.
    idblife
        34
    idblife  
    OP
       118 天前 via iPhone
    @BraveRBT
    嗯,也在看这种方案,多谢
    pepesii
        35
    pepesii  
       118 天前
    抱着学习的态度,如果最后解决了也分享下过程和方案吧 :)

    就单纯的流量隔离的话,我感觉就 networkpolicy 就可以了呀;
    idblife
        36
    idblife  
    OP
       118 天前 via iPhone
    @pepesii

    最终方案会更新下
    gengchun
        37
    gengchun  
       118 天前
    @idblife istio 或者说 service mesh 的核心,其实是一堆 CRD ,算是定义流量怎么走的一个标准——telemetry 这些暂时不讨论——相当于 nginx.conf 语法的东西。

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

    简单的说,一切都是砍需求。当然,要流量分发,不太可能砍到连 envoyproxy 都不要了,至少目前为止,网络插件还没有普及。但是还是可能减少流量通过 envoyproxy 这种的次数。需求砍到一定程度,istio 去掉你觉得不必要的功能,也就差不多了。
    anubu
        38
    anubu  
       118 天前
    8 楼的方法应该能解决问题,也很直观。大规模使用的话,可以封装一下。

    没有 istio 使用经验,不过就接触到新闻和信息,istio 的确性能不太好,并且持续很久了。
    pipixia
        39
    pipixia  
       118 天前 via Android
    Istio 边车那套真不喜欢
    calmzhu
        40
    calmzhu  
       118 天前
    没 Get 到需求.
    发布的话, 探针停一半不就可以了
    calmzhu
        41
    calmzhu  
       118 天前
    是指灰度发布这种效果吗? https://help.aliyun.com/document_detail/200941.html
    raptor
        42
    raptor  
       117 天前
    搭车问一下,consul 比 istio 如何?
    tanxnative
        43
    tanxnative  
       117 天前
    10%的性能损失,带来的语言无关特性
    其实你使用其他框架也会有性能损失
    idblife
        44
    idblife  
    OP
       117 天前
    @tanxnative
    如果用 k8s 里 service 标签来实现呢?
    idblife
        45
    idblife  
    OP
       117 天前
    @calmzhu
    需要考虑到比如 100 个服务发布新版本,这一百个服务的旧版本之间互相调用,不能调用到新版本。
    morphyhu
        46
    morphyhu  
       117 天前
    talk is cheap,show me the data.
    "@idblife
    istio 可以做到,但是性能垃圾"
    zmal
        47
    zmal  
       117 天前
    性能损耗是必然的啊。真要说起来,容器化虚拟化技术本来就都有性能损耗。
    idblife
        48
    idblife  
    OP
       117 天前 via iPhone
    @morphyhu
    响应时间增加 10%
    istio ingress gateway 在不同 worknode 上响应时间相差 20%
    idblife
        49
    idblife  
    OP
       117 天前 via iPhone
    @zmal
    性能损耗也得看 roi
    istio 不值
    tanxnative
        50
    tanxnative  
       116 天前
    我猜你服务没有治理, 有很多同步的调用, 还不止一跳
    idblife
        51
    idblife  
    OP
       116 天前
    @tanxnative
    进行过指定接口的测试,确保调用链时合理的。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2836 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 13:48 · PVG 21:48 · LAX 06:48 · JFK 09:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.