Skip to content
This repository has been archived by the owner on Jul 24, 2022. It is now read-only.

Latest commit

 

History

History
134 lines (72 loc) · 7.24 KB

ep08.md

File metadata and controls

134 lines (72 loc) · 7.24 KB
Raw

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哪个版本没关系。