Istio 大咖说第 8 期

讲师简介

贾建云,小红书 Kubernetes 云原生工程师,负责小红书服务网格相关工作。主导设计了小红书服务网格落地方案,对于大规模服务网格落地、调优有丰富的经验。

话题介绍

  1. 小红书基于 Istio 的服务网格方案和架构设计
  2. 小红书对于 Pilot、Envoy 做的特性增强
  3. 小红书落地服务网格碰到的性能/Bug 问题

听众收获

了解小红书服务网格关于流量拦截、thrift 协议、懒加载等做的特性增强,同时了解在大规模落地服务网格过程中碰到的控制面性能问题,以及 ServiceEntry 场景下 pilot 存在的 Bug。

问答

  1. 我们在落地Istio 中碰到一个坑是 envoy 的 connection idleTime 和各种语言的 keepalive 时间不同,在大量使用长连接(http1.1)的情况下,可能会出现客户端用现有的长连接发起请求,但是服务端连接刚好超时回收了,导致会有部分请求 503(报错是 connection reset),在 Istio 社区也看到了这类的 issue,但是都没发现一个合适的解决方案。Istio 默认内置的重试条件中不包括 connection reset 这种情况,可能是害怕对非幂等请求的重试。不知道小红书内部有没有类似的问题?

    答:这个问题可以参考Envoy官网关于超时时间设置的最佳实践

  2. Envoy是否考虑降级,以应对envoy异常时跳过sidecar直接访问服务,不知道是否有类似经验?

    答:我们目前是通过监听实际端口来做流量拦截的,这样当出现问题之后我们会让sdk把流量切换到中央sidecar。这种流量回滚方式与我们的流量拦截方式强相关,同时也对sdk有一定入侵,可以看一下小红书关于流量拦截方案的介绍。

  3. xds 和 eds 分开会不会有数据不一致的问题?

    答:不会有问题

  4. 有没有使用webassembly开发扩展?

    答:小红书暂时没有使用wasm,扩展是直接开发envoy filter。

  5. 配置灰度下发解决思路是什么?

    答:跟我们sidecar灰度升级的思路比较一致,通过创建cluster/ns/service粒度的升级任务,由pilot决定配置要下发给哪些sidecar

  6. Envoy引入brpc是替换了Envoy哪些部分?

    答:不算事替换吧,是想做到自由切换线程模型,引入bthread。

  7. 虚机服务(通过域名+nginx+tomcat)如何解决服务网格的灰度上线?

    答:虚拟机跟pod应该是一样的,通过创建dr维护版本信息,然后配置流量配比。

  8. 手动维护服务依赖的话还算懒加载吗?

    答:严格意义上面不算了。但是本质上都是为了做服务可见性。

  9. 懒加载中hosts依赖的serviceEntry信息是不是依然要全局envoy下发?

    答:特定服务的所有实例/流控配置是全量的,这个跟pilot实现有关,目前社区的新版本已经在开发增量推送了,可以关注一下。

  10. 不拦截入流量的话要做 inbound 的策略怎么办?

    答:原生的方案inbound本身也没有什么流量治理的特性,就是流量转发,所以我们不担心不拦截inbound会有流量治理能力的缺失。主要是担心可观察性会有影响,目前期望通过SDK补齐丢失的指标。

  11. 对 Istio multi-tenancy有支持增强吗?

    答:小红书内部对多租户没有什么诉求,这个应该是公有云比较关心。

  12. Thrift Proxy 的路由变化后会导致重建 Listener,线上业务可以接受客户端存量链接在路由规则变化后被断开吗?

    答:目前业务方可以接受,我们是告知过这个事情的。另外就是社区已经有envoy thrift filter支持rds的pr,合并到主干之后我们会升级,届时就没有问题了。

  13. 调用的下游过多的情况下,端口的冲突怎么解决?

    答:端口不会冲突,一个Pod内部依赖的服务不会重复,每个服务都有唯一的端口。但是主机网络会存在端口冲突的情况,目前我们的方案就是让用户改为非主机网络。

  14. 懒加载中serviceEntry+sidecar中如何支持按照route等方式配置http路由信息,就像virtualserver中支持的httproute功能?

    答:使用serviceEntry+sidecar不影响vs等的使用。两个东西没有太大关系。

  15. 老师提到了小红书用到了开源项目 Aeraki 来管理 Thrift 协议,请问这部分后续的开源计划?

    答:后续会有团队小伙伴小红书分享关于aeraki做的扩展,但是应该不会合并到aeraki,内容偏小红书定制。

  16. 流量拦截中还是用到了iptables(tproxy)模式,性能上会不会依然受影响?

    答:会有影响的,但是用了tproxy模式会好一些。

  17. 有没有Envoy数据面性能的参考数据,总体上和业务容器的平均占比会是怎样的,cpu 和内存呢?

    答:按照我们内部一个业务的压测,单跳Envoy延迟增加2ms。Envoy大概占用0.5核,300m左右内存。后续我们会压测高QPS业务,届时我再补充数据。整体来看配置了懒加载envoy资源吃的不多。

  18. 灰度下发的方案,不同sidecar配置的diff是保存在那个地方?

    答:存储在mysql。

  19. Istio 通过 virtualservice 做灰度的话,基于流量比例的灰度无法做到 session sticky,这个有最佳实践吗?

    答:这个没有。目前小红书的灰度是通过注册中心来实现的。

  20. 性能测试数据如何?

    答:参考问题17。

  21. 为什么不用 service 而用 serviceentry 呀?小红书内部没有使用 k8s service 吗?

    答:小红书内部不用service,而且serviceentry可以支持虚机。

  22. 老师能否介绍下小红书的Service Mesh发展到现在的程度,大概是多少人的团队,做了多久?

    答:目前4个人,大概做了半年。

  23. Envoy延迟的长尾情况呢?

    答:还是比较明显的,这个跟Envoy线程模型有关吧。但是引入backuprequest会好很多,来自百度的内部实践。

  24. 大佬微信发下?

    答:请加入云原生社区 Istio SIG 交流,大佬在群里。

  25. 原生 Istio 自动注入会跳过主机模式host的pod?

    答:出于安全考虑 Istio一般也不敢直接在虚机上面拦,比较危险,最好还是不要用主机网络吧。非要用的话只能修改webhook吧。

  26. 大佬服务注册这边是什么方案注册的

    答:公司内部自研的注册中心,细节不太清楚,后续可能有同事分享小红书注册中心。

  27. 请问sidecar热升级前后,通过istioctl ps 查看proxy的版本有变化吗?

    答:不会有变化。版本号是我们自己在Envoy开发的api,跟istioctl ps哪个版本没关系。

results matching ""

    No results matching ""