多点生活在 Service Mesh 上的实践 Istio + MOSN 在 Dubbo 场景下的探索之路 陈鹏 多点生活 平台架构组研发工程师1/23 自我介绍 • 陈鹏、多点生活平台架构组研发工程师 • 开源项目与云原生爱好者 • 多年网上商城、支付系统相关开发经验 • 2019 年至今从事云原生和 Service Mesh 相关开发工作2/23 /01 /02 /03 为什么需要 Sink： • Source 是资源提供方（server），资源变化了推送给订阅者（Pilot），Istio 1.5 之前这个 角色就是 Galley 或者自定义 MCP Server； • Sink 资源的订阅者（client），在 Istio1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义 MCP Server 的资源；8/23 MCP mcpserver nsole） 获取一些资源（Kubernetes 中使用 Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP 推送，文件） 触发推送流程 推送流程 • 记录变化的资源类型 • 根据变化的资源类型整理本地数据 • 根据变化的资源类型判断需要下发的 xDS资源 • 构建 xDS 资源，下发到连接的 Sidecar10/23

原因为客户POD内部署两个对外服务端口，当客户端同时发起对不同服务的访问时，路由结果可能会落 到相同的POD内，第一个连接目标为9080，第二个连接目标为8080。由于目标服务端口不同，通过五元 组规则可知，src-ip:src-port可以相同。而由于目标POD内流量被自动DNAT拦截入15006端口，此时目标 dst-ip:dst-port被临时替换为envoy-ip:15006，此时将无法 ，导致第二个连接建立失败。 解决 方案 1、与客户沟通拆分两个微服务到不同的POD（符合微服务拆分原则） 2、如果无法拆分微服务，则需要解决源端口重用的问题，目前没有采用此种方法。 TCP五元组:(不能重复，否则conntrack无法区分) srcip:srcport,prot,dstip:dstport APP backend1 iptables inbound POD2 backend2 Ltd. All rights reserved. Page 28 Istio数据面发展趋势 • 现状问题： • 引入透明Sidecar模式，导致端到端时延增加、并随着集群规模增加导致系统资源消耗上升，对大规模 Istio集群的实际使用造成影响。 • 运维难度增加，透明代理模式无法针对不同业务本身的特点定制监控能力，同时只能从业务容器外面收 集应用的运行状态。 • 演进方式： •

下游客户端连接。在 Envoy 中,Listener 可以绑定到端口上直接对外服务，也可以不绑 定到端口上，而是接收其他 listener 转发的请求。 • Cluster：集群是指 Envoy 连接的一组上游主机，集群中的主机是对等的，对外提供相 同的服务，组成了一个可以提供负载均衡和高可用的服务集群。Envoy 通过负载均衡 策略决定将请求路由到哪个集群成员。 xDS 协议的主要概念： • Listener ndCluster、InboundCluster 等 概念。 为何按端口对 HTTP 的处理进行聚合，而不是为每一个服务创建一个 Listener？ • 降低 Listener 数量和配置大小，减少资源占用 • 兼容 headless 和虚机服务，避免 Listener 配置频繁更新 • 采用七层 header 进行路由，请求原始目的 IP 不应影响路由结果 入向请求配置 出向请求配置 0.0.0

力，避免批处理任务的压力影响到用户体验。 ● 将服务端划分为两个服务实例组，分别用于处理批处理任务和用户请 求。 ● 客户端发起请求时通过一个“batchjob” header标明请求的来源 ，batchjob=true表示该请求来自于批处理任务；batchjob=false表示该 请求来自于用户请求。 ● 运维人员设置请求路由规则，将不同来源的请求路由到不同的服务实例 组进行处理。 #IstioCon Aeraki

不能做什么 • Istio 能做什么 • 现阶段 Istio 有什么问题 • 那Istio还用不用 • 如何安全的试用 Istio目标听众 • 我 • 乙方 • 给大型企业开发某某管理系统 • 系统资源好像没缺过 • 手上有各个时代的应用 • 没有能力/不想维护Istio源码 • 业务负载不算大Istio不能做什么 • 提高代码质量 • 增强负载能力 • 改善交付流程 • 客户充满 Love • • 集群环境申请：版本、开关、资源等。 • 功能性需求：本次试用中Istio需要提供的功能，再次强调：No Freestyle • 非功能需求：并发、成功率、响应时间等服务质量参数。 • 故障处理需求：故障预案。 • 影响范围分析。 • 选定测试版本：研读开放Issue以及Release Notes。测试方案部署 • Istio部署 • 复查集群环境 • 调整资源参数 • 调整亲和性参数 • 根据功能需求，编写和部署 Istio相关功能YAML • 监控和告警部署 • 连接Alertmanager/… • 指标输出方案测试 • 根据性能和功能测试方案完成测试。 • 如果性能下滑，可以尝试扩张资源。 • 如果无法达成测试目标，建议取消——无侵入的好处就是可以撤 退。 • 评估关联服务的工作情况——尤其是重试、超时特性的应用切换演练 • 在测试版本和后备版本之间根据预案进行切换。 • 验证相关服务的工作状况。

Controller实现ServcieDiscovery 若干服务发现的接口定义 2. Controller List/Watch KubeAPIserver上service、 endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernetes Service Version Version Service Deployment Deployment Label selector Istio Istio几种重要资源对象 • 入口资源对象 • VirtualService • DestinationRule • 重要属性 • HTTPRoute • HTTPMatchRequest • TCPRoute • DestinationWeight

Controller实现ServcieDiscovery 若干服务发现的接口定义 2. Controller List/Watch KubeAPIserver上service、 endpoint等资源对象 3. DiscvoeryServer使用 ServcieDiscovery接口上的服务发 现方法和用户配置的规则构造xDS 4. Envoy从Discovery获取xDS，动态 更新 Kubernet Service Version Version Service Deployment Deployment Label selector Istio25 Istio几种重要资源对象 • 入口资源对象 – VirtualService – DestinationRule • 重要属性 • HTTPRoute • HTTPMatchRequest • TCPRoute • DestinationWeight26

nfig.json --type=kubernetes.io/dockerconfigjson 16 ��������� ������������� ASMFilter Deployment 资源对象 Controller (Watch & Reconcile) Istio EnvoyFilter CR wasm filter二进 制文件 服务网格ASM Pod K8s集群 Proxy Envoy配置 17 ASMFilterDeployment CR示例 ● 创建ASMFilterDeployment Custom Resource 18 生成的Istio Envoy Filter资源(1) apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: …. spec: configPatches: - match: …. patch: …. workloadSelector: labels: app: productpage version: v1 19 生成的Istio Envoy Filter资源(2) apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: …. spec: configPatches: -

吞吐量提升 5 %15/25 Pilot、Mixer 性能瓶颈 Istio 的价值和问题16/25 总结 Istio 的价值和问题 • 已经可以稳定用在生产环境 • 工程架构收益 >> 性能资源损耗 • 根据组织和业务情况推广或改造，新旧体系可并存 • 超大规模应用，几个架构问题有待社区或业界解决17/25 分享主题：字号 Knative 的实践和瓶颈 /03 酷家乐在使用 Knative 踩过的坑/问题 FAAS 实践进展 • 镜像源问题 • RevisionUnkown 状态(0.8版本) • Queue-proxy 内存增长(0.8版本) • Activator 重复创建并占用大量资源22/25 Knative 当前瓶颈 FAAS 实践进展 • 还未发布 Production-ready 版本 • Queue-proxy 过重 • 冷启动时间亟待优化 • 支持代码级更新？23/25

Istio Proxy: 劫持Pod的所有通信， 是Mesh的基础 • Pilot: 为Proxy提供动态配置管理 • Citadel: 自动维护mTLS密钥 • Mixer: 在k8s中部署了两组Mixer • Policy提供授权、Quota等能力 • Telemetry提供监控数据收集能力 基本原理 • Istio从架构上可以分为4个板块： • Istio Proxy: Mesh的基础