基于istio的service mesh落地实践

1. 信也基于istio的service mesh落地实践技术架构资深架构师徐玉强

2. 目录 CONTENTS 01 istio简介与信也服务治理背景 02 信也istio落地架构 03 信也istio使用场景 04 信也istio踩“坑”记 05 信也isito发展

3. 章节 P art 01 istio简介与信也服务治理背景

4. istio简介什么是Service Mesh？

5. istio简介什么是Service Mesh？

6. istio简介

7. 信也服务治理背景信也K8S CNI使用macVlan技术： • K8S跨主机、跨集群通信 • 容器与虚拟机通讯 • 静态IP管理

8. 信也服务治理背景 • • nginx配置reload，单点风险调用方式陈旧，分布式单体 • • • • 服务发现负载均衡金丝雀发布高级路由 • • • 安全故障注入监控增强 • • • 治理重点在JAVA，异构语言难统一框架繁多，运维压力大 SDK模式迭代升级推动困难，版本割裂严重

9. 章节 P art 02 信也istio落地架构

10. 部署架构 External control plane（since 1.11.X） • 将管理控制平面的网格所有者和在网格中部署和配置服务的网格用户之间的关注点分开 • 在单独的集群中运行的外部控制平面可以控制单个数据平面集群或多集群网格的多个集群

11. 部署架构信也istio部署架构（since 1.8.X） • • • 采用primary – remote模式一套istio管理多个K8S集群 remote istiod负责边车注入；primary istiod 维护边车信息

12. 服务信息导入 1. 发布阶段，用户在信也容器云平台执行实例流量拉入、拉出步骤 2. 拉入、拉出步骤调用控制面istio接口，执行CRD（SE、WE、VS、DR）更新操作 3. istio CRD写入istio集群的istio-config namespace 4. istio watch istio-config下CRD，组装ADS执行推送

13. 调用关系计算 • • • • istio默认为边车下发全量xDS ，每次xDS更新触发全量推送（EDS为增量推送）全量推送导致istiod CPU使用率、CPU load飙高 xDS推送失败率、延迟飙高(10S以上) 边车内存消耗大（300M以上）

14. 调用关系计算 Open Source K8S Service Discovery + Global Sidecar 信也科技 • 未使用K8S自身的服务发现机制 • 服务调用主要依赖Nginx转发 • 需要兼顾虚拟机服务通信与架构简洁

15. 调用关系计算 1. 控制面namespace配置默认Sidecar Scope 2. istiod仅推送istio-system namespace下的xDS 3. 初次域名访问passthrough 到nginx，产生调用metrics 4. prometheus收集到调用metrics 5. 信也实现调用关系controller 根据metrics计算Sidecar Scope 6. Sidecar Scope写入istiod 7. isitod根据sidecar按需下发xDS 8. 应用直连调用

16. Envoy Filter推送优化 • • EnvoyFilter的下发也会触发全量推送（sidecar scope）增加判断：EnvoyFilter + Workload Selector实现定向推送

17. 流量按需拦截-出口按需拦截出口流量 • • • Envoy默认拦截所有流量，MySQL、Redis作为TCP透传信也优先治理RPC流量，仅需拦截HTTP协议 MySQL、Redis无需经过边车，减少RT损耗 • • 数据面istio-sidecar-injector，修改iptables出口规则-q 控制面istio-system namespace，配置对应端口的ServiceEntry

18. 流量按需拦截-入口按需拦截入口流量 • • • • 安全扫描器进行TCP端口探测，尝试建立链接链接建立[1024-65535]，短时间构建大批HTTP攻击产生大量404等相关metrics Sidecar占用超过600M内存且不释放(pilot-agent+envoy) 发布时，POD打标，指定应用开启的端口

19. 章节 P art 03 信也istio使用场景

20. 环境隔离与mock • • • 同环境优先同环境实例不存在则fallback default环境 default环境可转发回来源环境

21. 环境隔离与mock

22. 同城双活路由支持控制面：添加outbound header 数据面：注入机房相关环境变量

23. istio熔断、限流熔断配置连接池限流配置

24. 自适应限流 • PID算法 • 中心控制器：规则配置、个性化参数

25. 监控能力增强访问日志 4XX、5XX大盘 • 业务逻辑无感知的404 Not Found报错告警 • 查询特定路径的srcIP、dstIP日志

26. 监控能力增强站点调用关系拓扑接口信息统计

27. 章节 P art 04 信也istio踩“坑”记

28. istio初始化优化 • • • • istiod启动时list watch到所有istio-config namespace下的CRD信息 istiod内部serviceEntryHandler方法会逐个处理加载好的ServiceEntry 每个ServiceEntry处理触发mayBeRefreshIndexs方法（耗时2-3S）处理完成后准备执行xDS推送，总耗时10min以上 • • • • 添加缓存层，周期(500ms)扫描缓存周期触达且缓存非空，批量执行edsUpdateByKeys mayBeRefreshIndexs仅执行一次处理完成后准备执行xDS推送，总耗时30S以内

29. Sidecar启动顺序 • • • • • K8S的POD可承载多个容器（init容器、应用容器） init容器优先执行（iptables规则写入）多容器启动顺序按照其声明顺序执行多容器启动过程是并行的（后启动的不会等待前启动的ready）边车未ready，应用即发送请求，失败！

30. HTTP1.0支持 Envoy HTTP connection manager delayed_close_timeout The default timeout is 1000 ms if this option is not specified. • • istio官方推荐修改nginx，升级为HTTP1.1 服务直接使用HTTP1.0请求的情况无法处理？支持了HTTP1.0 还是有问题！！！

31. Header大小写敏感 • • Envoy默认把HTTP Header转换为小写部分应用或框架内对Header处理大小写敏感 Inbound And Outbound

32. 重复Header处理-request • • • Spring MVC重复Content-Type情况下取第一个 Envoy把重复Content-Type使用逗号连接 Spring MVC不识别拼接后的Content-Type：415

33. 重复Header处理-response • • • 因为框架使用问题，reponse带有重复transfer_encodings边车无法处理社区讨论后认为需要业务层处理，否则503 bad gateway报错 Envoy 1.16.0 开关reject_unsupported_transfer_encodings=false已废弃仅出现一例业务改造

34. Passthrough内存增高 • • 边车对于走Passthrough的下游，超过5s未调用会清理下游主机、连接数据等清理过程中存在bug会导致内存泄漏

35. 偶发503问题 • • • 偶发 response code=503, response flag=UC UC：Upstream connection termination in addition to 503 response code 原因：同一个pod里的sidecar和upstream容器之间的链接被断开

36. 源IP地址保持 • • 安全策略控制，基于IP的黑白名单访问日志和监控统计获取真实的IP地址

37. Metrics精简 • • • • requests_total request_bytes response_bytes request_duration_milliseconds 占用大量的prometheus资源

38. 章节 P art 05 信也isito发展

39. 信也istio发展自适应熔断限流推广，拓展边车功能

40. 信也istio发展拥抱WASM，提升边车性能

41. 信也istio发展 • 升级API gateway，使用xDS协议管理，走向云原生 • 引入egress gateway，统一管理出口访问

42. 感谢聆听技术架构资深架构师徐玉强