Istio 大咖说第 4 期

陈鹏,百度研发工程师,现就职于百度基础架构部云原生团队,主导和参与了服务网格在百度内部多个核心业务的大规模落地,对云原生、Service Mesh、Isito 等方向有深入的研究和实践经验。

Istio 大咖说第四期-陈鹏
Istio 大咖说第四期-陈鹏

分享大纲

  1. 百度服务治理现状 & Istio 落地挑战
  2. 深入解读如何让 Isito 在大规模生产环境落地
  3. 实践经验总结 & 思考

通过本次分享你将了解当前 Isito 落地的困境和解决思路。

Q&A

  1. 请问,Istio 组件,包括数据面和控制面发生故障时,有哪些快速 fallback 的方案,之前阅读了大佬的相关文章,这块好像没有细讲,谢谢!

    相对来说, 数据面 fallback 更重要一些,因为它直接接流量。最好是能结合流量劫持环节,让 sidecar 故障时,系统能自动感知到,流量自动 fallback 到直连模式,具体思路可以参考分享内容,其次 sidecar 的监控也是必要的,用来辅助感知和处理故障。控制面故障短时间内不会对流量转发造成影响,也可以通过部署多副本来应对故障。

  2. 有些服务 QoS 想设置 guaranteed,但是 istio 的 sidecar 不是 request 和 litmit 一样的。要 guaranteed 的话必须 sidecar 的 QoS 相关配置也要改。你们是怎么做的?如果改,建议设置为多少?感谢大佬!

    我们通常 sidecar 内存 limit 200M,cpu limit 是业务的 10% 到 20%,但我觉得这个没有通用的参考数据,需要结合业务场景压测拿到数据,更为科学。

  3. 你好。作为业务方的技术负责人,被中间件团队推动上 Istio,目前带来的收益主要是服务治理方向的。从业务迭代效率的角度看,上 Istio 的增量收益抵不上迁移成本的代价;另外还降低了业务方工作的技术含量。请问有没有实践中,业务方在 Mesh 化的过程中获得显著收益的例子?

    不能只关注 mesh 自身的能力,还要深入了解业务,最好是能挖掘业务最痛点的问题,比如原有框架治理能力比较弱,或者可视化能力弱,或者变更效率低等,业务最痛点的问题对于 mesh 来说可能是普通的能力,但却会给业务线带来很大的提升。

  4. 为什么没有采用 mcp over xds 的方案? 而是独立搭建了 API server 和 etcd?

    api server + etcd 可以比较容易的独立部署,能复用尽量复用。

  5. pilot 的多业务方案是怎么做的? 如果是多个 pilot 的话,那独立的 Kubernetes API server 和 etcd 也要多个么?

    我们目前的实践是 api server + etcd 是一套,pilot 根据业务线多套,当然 api server + etcd 也可以是多套,可以根据系统性能以及数据隔离等需求灵活部署。

  6. Envoy 的 brpc 改造方案,会考虑开源么? 怎么 follow 后续社区 Envoy 的最新代码呢

    brpc 本身也是开源的,Envoy 只是做了集成。社区版本更新很快,具体多久更新一次其实很难抉择,需要考虑架构升级成本,以及社区版本的成熟度,这块我也没有太好的建议。

  7. 内部的 mesh 方案,考虑通过百度云的方式对外输出么?

    一些高级策略能力会逐步输出到公有云产品。

  8. 随着 istio 新版本的不断发布,内部使用的版本是否跟进了开源新版本,跟进社区版本升级有什么经验分享?

    同上,社区版本更新很快,具体多久更新一次其实很难抉择,需要考虑架构升级成本,以及社区版本的成熟度,这块需要结合团队现实情况考虑升级时机。

  9. Envoy filter 管理麻烦的话,nshead、dubbo 等多协议支持是怎么实现的?在 pilot 中是如何管理的?

    我们内部是直接在 pilot 内部实现支持,类似于 http 的功能。

  10. 引入两个 sidecar 后问题定位的成本和难度会大福增加,这块有什么经验可以分享

    一方面 Envoy 自身提供了丰富的接口,可以暴露内部很多的状态,另一方面也需要和自有监控基础设施对接。

  11. Sidecar 带来的额外成本问题谁来买单?业务认可吗

    这个其实需要和业务团队明确,额外的资源成本是需要业务买单的,但对于内部业务,具体的成本可以比较低,业务普遍是能接受的。

  12. Sidecar 可以使用的的资源配额是怎么分配管理的,动态的还是静态的,有什么经验

    不同的业务场景可能不太一样,内存大概在几百 M,CPU 一般是是业务的 10% 到 20%,但最好是要根据业务场景进行压测,得到数据。

  13. Sidecar 的监控是怎么做的? 权限,成本方面可能都有一些疑问

    Envoy 本身会暴露自身指标,对接相关的监控即可。

  14. Naming 这个 agent 和框架非常不错,请问 Naming 可以支持负载均衡么, 也就是 PodX 访问 PodY 的时候,naming 不要返回 PodY 真实 IP,而是返回负载均衡的 VIP 给 PodX; 十分感谢 - Ken

    目前没有这么做,直接返回了 Envoy 的 loopback ip 来做流量劫持。

  15. 这种架构的话,PodX 主动出公网的逻辑是怎样的呢,也是通过 ip-masq 做 NAT 吗?

    目前主要做内网服务的 mesh,这块没有太多经验,十分抱歉~

  16. Naming agent 是部署在哪个容器?

    是一个主机部署一个的单机 agent,工作在主机网络上的。

  17. Pliot 在落地过程中部署模型,大规模 Envoy 注册后,是否存在一些性能瓶颈,有什么优化的经验?

    可以增加 pilot 的副本数,来应对大规模 Envoy 的链接,另外控制面处理逻辑也有很多可以优化的地方,来优化从 API server 拿到数据之后的计算过程,这部分需要对 pilot 代码有一定开发经验和熟悉程度。

  18. 虽然老师不一定有关注这一块,但也提个问题看看吧。 Envoy 流量劫持是在 userSpace 还要经 TCP 协议栈其实损耗非常大的,后续 Envoy 有考虑 byPass Kernel,直接传包给网卡驱动提速么(例如 DPDK、SPDK)

    这个一方面要考虑成本问题,比如内核和硬件是否满足,另一方面也要评估收益,比如流量劫持这一部分虽然优化了,但是缩减的耗时对于整个请求链路的占比是否足够明显。

  19. 流量都经过 sidecar 后,sidecar 在 trace 这方面是怎么考虑和设计的?

    Envoy 本身支持 trace 相关的功能,这块其实是需要业务 sdk 中来进行支持,必须要透传 trace 相关的信息。

  20. 对于 inbound 流量的限流是如何设计的呢?

    可以使用 EnvoyFilter CRD,给被调用方 inbound listener 插入 LocalRateLimiter 对应的 filter 来实现。

  21. 私有协议如果要变更的时候,是不是要级联更新?

    抱歉,这个问题没太看明白~

  22. 支持服务治理的配置灰度下发吗?可以简单说下实现方案吗

    内部其实是实现了,方案比较复杂,简单来说就是控制面自己控制 xds 下发,会先挑选部分实例生效,然后再给全部实例下发。

  23. 你们 内部对于 istio deployment 里的 version 字段在落地时有大规模使用吗?我们最近在基于 istio 做灰度发布,但是每次灰度都要给他一个版本号,导致完成之后 deployment 名称就从 v1 变成 v2 以此累加,这样还会导致 deployment 本身的回滚功能失效。

    我理解是不是只需要 v1 和 v2 就够了,先灰度给 v1,没问题的话 v2 也生效,这时候 v1 和 v2 策略就打平了。下次恢复依然还是这个流程,好像不需要一直叠加版本好吧,不确定我理解的对不对~

  24. Envoy 对于我司来说技术储备其实不是很够, 请问贵司刚上线的时候, Envoy 有没有遇到哪些问题。 特别是稳定性和故障方面。 如果能建议一下 Envoy 应该如何监控,那就 perfect.

    Envoy 本身比较复杂,上线初期一定会遇到问题,最好是能结合流量劫持方案,做到 Envoy 故障自动 fallback,思路可以参考分享内容。监控的话,Envoy 自身会暴露 stats 接口,比较容易接入监控系统。

  25. 对于 dubbo 的泛化调用,探针会实时检测调用关系的变化么?如果 sidecar 还没有被生成,这个时候流量请求阻塞怎么处理呢?一直等待还是直接拒绝?如果服务是新的请求呢?

    泛化调用这种比较灵活的方式,我们目前也没有很好的支持,一个思路是可以提前手动配置好调用关系。

  26. link 模型解决 xDS 问题,可以再详细介绍一下整个逻辑链路么?例如 consumer 和 provider 的 link 数据是怎么获得的

    目前内部大规模落地的方案中,是需要用户在产品上显示定义的。

  27. 2ms 的 Envoy 额外消耗,请问是怎么查看的呢?curl endpoint 跟 curl Envoy 做一次对比么

    官方的测试方法没有详细研究过,自己测试的话,可以用经过 Envoy 和 没经过 Envoy 的耗时 diff,也可以在程序里打点来看。

  28. Envoy 注入后业务 pod 会存在 2 个 container, 那么 Envoy 的配额是怎么限制的呢? 比如限制 4 核心可能就是 2 个容器(1 个 pod)里面的配额了;

    可以参见上面的回答

  29. 就是我们在落地的时候,会遇到部分服务有 sidecar,部分没有 (服务 A 会被其他 10 个服务调用),一般如何去判断配置设置在哪里,是在 outbound(其他 10 个服务部署 sidecar)处还是 inbound 处(服务 A 部署 sidecar)。这个有没有什么比较好的实践?

    这个需要结合流量劫持方案,做到有 sidecar 就过 sidecar,没有就走直连,具体思路可以参考分享内容。

  30. Envoy 如何实现长连接的动态开关的?

    这个问题比较好,我们是通过让 Envoy 重新生成一个 listener,更改了 listen 的地址,让调用 Enovy 的 SDK 感知到,并重新链接。

results matching ""

    No results matching ""