Istio控制平面组件原理解析 朱经惠 2018.08.25 Service Mesh Meetup #3 深圳站关于我 • 朱经惠，ETC车宝平台工程师。 • 喜欢开源，个人开源项目”Jaeger PHP Client”。 • 喜欢研究源码，对NSQ，Jaeger，Istio（控制平面）等go语言开源项目进行 过研究。 • 除了代码还喜欢爬山和第二天睡醒后全身酸疼的感觉。目录Pil Envoy优雅关闭实现方式讨论：#3307 #2920Pilot-Discovery——配置中心（PD） uv1版本和v2版本之间的区别 u建立缓存配置 u触发配置生效方式v1版本和v2版本之间的区别 V1 HTTP1 REST JSON/YAML 弱类型 轮询 SDS/CDS/RDS/LDS 奠定控制平面基础 V2 HTTP2 GRPC Proto3 强类型 Push SDS/CDS/RDS/LDS/HDS/ADS/KDS secretName: istio.default证书过期 üroot-cert.pem 实际有效期1年，没有找到更新方式，手动更新？ ücert-chain.pem 和 key.pem 实际有效期90天，程序控制有效期45天 ü证书过期会被重新生成并挂载到/etc/certs ü触发envoy热启动ü方案一： • 把重新生成证书时间改为凌晨http://www.servicemesher.com

非侵入服务网格最早为2016年Linkerd。 • 2017年，Goole、IBM、Lyft发布Istio。Istio目前为服务网格的事实标准，并且是2019年Github增长最快的TOP 10开源 项目之一。目前最新为1.10版本。 Copyright © Huawei Technologies Co., Ltd. All rights reserved. Page 5 Envoy介绍 • Envoy采用C++实现， Iptables 规则 ./etc/istio/proxy/SDS 证书 获取 配置 文件 可以修改全局注入参数 作用于所有目标空间的 pod 证书更新 Envoy启动流程 Envoy控制面流量 Envoy数据面流量 ./etc/istio/proxy/XDS SDS xDS CSR Prometheus configmaps Copyright © Huawei Technologies GID=1337创建Envoy启动命令行与配置文件 • 可以通过自定义deployment内istio注解sidecar.istio.io/inject: “false”跳过自动注入过程，或修改部分启动参数。 • 2. 控制面通信 • Pilot-agent进程本身创建UDS接收Envoy连接，用于证书更新下发。并且与istiod建立证书更新通道。 • Envoy 通过pilot-agent转发机制与istiod建

PeaceIstio能做什么？ • 几乎全部功能都无需侵入 • 监控服务质量 • 控制服务间的访问路由 • 跟踪服务链路 • 应对服务故障 • 在服务间通信之间进行加密 • 访问控制和频率限制 • …Istio目前的突出问题 • API稳定性问题：流量管理也仅仅是v1alpha3，用alpha特性发布 1.0的情况似乎比较罕见。 • 发布进度和质量：大版本以月计算的发布延迟，据我所知的 Release撤回发生了两次。 Release撤回发生了两次。 • 世纪难题：多出一层Sidecar造成的延迟。 • Pilot的性能，近几个版本一直在出问题。 • Mixer按照我个人的看法，API较为混乱，重构风险比较大Istio还用不用？ • 你要的是不是API网关？ • Service Mesh为什么诞生的？ • Istio 为什么诞生的？ • 它能在我们的环境里运行么？ • 它能解决我们的问题么？ • 有条件的，慎重的用选定试用功能 • 性价比的灵魂拷问： 有完善的性能、功能测试方案。禁则 �������� ����� ����制定目标 • 集群环境申请：版本、开关、资源等。 • 功能性需求：本次试用中Istio需要提供的功能，再次强调：No Freestyle • 非功能需求：并发、成功率、响应时间等服务质量参数。 • 故障处理需求：故障预案。 • 影响范围分析。 • 选定测试版本：研读开放Issue以及Release Notes。测试方案部署 • Istio部署

多服务联动时问题难以察觉 Ø ... 服务间通信的复杂性： Ø 网络延迟 Ø 消息序列化 Ø 不可靠的网络 Ø 异步机制 Ø ... 开发难 排错难 测试难 运维难 Ø 服务变得非常多 Ø 版本变得非常复杂 Ø 上线十分痛苦 Ø 排查问题更难 Ø 解决手段更复杂 Ø 学的东西更多 Copyright © 2021 Cloud To Go 为什么我们需要服务网格 - 业务上k8s带来的问题 直到找到故障位置 1. 流量告警 / 发现页面报错 2. 看图 3. 直接找到故障位置 Copyright © 2021 Cloud To Go 应用场景 - 灰度版本迁移 传统的版本升级方式 使用solarmesh的版本升级方式 1. 打好部署包 2. 等到半夜 3. 部署一个机器 4. 使用模拟的测试数据测试 1. 打好部署包即可部署 2. 用真实的数据测试 3. 挑个良辰吉日分配流量，宣布更新 •Grafana，为SolarMesh提供流量的实时仪表盘 •SLO，为SolarMesh提供服务质量检测的能力 SolarMesh的特点 Copyright © 2021 Cloud To Go 控制端与业务端隔离 控制面与数据面隔离 solarmesh坏了，istio还在，业务不会中断 istiod坏了，envoy还在，业务也不会中断 Copyright © 2021 Cloud To Go 无需重启

Aeraki Dubbo Plugin 实现了控制面的管理，支持 下述能力： ○ 流量管理： ■ 七层（请求级别）负载均衡 ■ 地域感知负载均衡 ■ 熔断 ■ 基于版本的路由 ■ 基于 Method 的路由 ■ 基于 Header 的路由 ○ 可观测性：七层（请求级别）Metrics ○ 安全：基于 Interface/Method 的服务访问 控制 #IstioCon Aeraki 地域感知负载均衡(Dubbo) 场景：在开通地域感知负载均衡功能时，consumer 的请求将缺省被发送到本区域 的provider实例，当本地域无可用的provider实例，请求会被分发到其他区域。 实现原理：控制面根据 consumer 和 provider 的地域属性为provider实例配置 不同的LB优先级，优先级的判断顺序如下： 1. 最高：相同 region，相同zone 2. 其次：相同 region，不同zone 现阶段协议扩展方案面临的挑战： ● 在 Mesh 中支持一个七层协议的工作量较大： ○ 数据面：编写一个 Envoy filter 插件——流量管理（RDS、 负载均衡、熔断、流量镜像、故障注入等）、编解码 ○ 控制面：编写一个 Aeraki 插件——运维/流量管理策略 ● 非 HTTP 协议缺少 RDS 支持： ○ Listener 内嵌路由 ○ 修改内嵌路由后，Envoy 会重建 listener，导致业务出现短

need Hot-Upgrade for ServiceMesh Data-Plane • 只替换/重启Sidecar • 替换/重启过程中进/出不会出现请求失败，连接失败 • 易于运维，可以控制升级策略 理想的Sidecar升级 4 • 为什么需要服务网格数据面热升级 • 实现热升级 • 实践热升级 目录 Catalog 5 • Envoy热重启 • 以Epoch + 1的方式启动新实例，触发热重启 启动两个Sidecar，以进行Envoy热重启的排水流程两个实例并存的阶段 • 能够对整个热升级流程中的镜像替换进行控制 实现热升级 Implement Hot-Upgrade 7 • Sidecar生命周期管理能力 • 启动两个Sidecar，以进行Envoy热重启的排水流程两个实例并存的阶段 • 能够对整个热升级流程中的镜像替换进行控制 • 更强大的生命周期管理组件 • 对需要热升级的Pod注入两个Container，Sidecar 接管StatusPort监听（15021） 实现热升级 Implement Hot-Upgrade 9 实现热升级 Implement Hot-Upgrade 阿里云服务网格热升级完整流程 • 修改SidecarSet，指定新版本镜像 • SidecarSet将EmptyContainer替换为新Sidecar镜像，新Sidecar镜像启动 • 新Envoy进程与老Envoy交互，开始进行热重启流程 • 最大排水时间到达，SidecarSet

ent， fallback会使用原有治理策略。 #IstioCon 架构介绍 Ø Mesh控制中心： ü 运维中心：基于Mesh的统一运维操作中心。 ü 配置中心：维护模块上下游拓扑，管理路由配 置、通信策略。 ü 上线中心：管理Mesh组件版本，统一上线入口。 l 核心组件 Ø 控制面板：Istio-Pilot组件，路由管理、通信 策略等功能 Ø 数据面板：envoy组件，流量转发、负载均衡

Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 治理位置--； } 微服务角度看Istio: 服务网格 服务网格控制面 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb.ns svcc.ns svcb svcd svce svce.ns svcd exact: “group=dev” route: - destination: name: v1 - route: - destination: name: v2 灰度发布：灰度版本存在形式 kind: Deployment metadata: name: rating-v1 spec: replicas: 2 template: metadata: labels:

Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 治理位置--； }6 微服务角度看Istio: 服务网格 服务网格控制面7 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb.n s svcc.ns svcb svcd svce svce.n s svcd exact: “group=dev” route: - destination: name: v1 - route: - destination: name: v224 灰度发布：灰度版本存在形式 kind: Deployment metadata: name: rating-v1 spec: replicas: 2 template: metadata: labels:

可以无需关注分布式架构带来的通信相关问题，而专注于其业务价值。 流量控制：服务发现、请求路由、负载均衡、灰度发布、错误重试、 断路器、故障注入 可观察性：遥测数据、调用跟踪、服务拓扑 通信安全： 服务身份认证、访问鉴权、通信加密 Proxy Application Layer Service 1 Istio 流量管理 – 概览 • 控制面下发流量规则： Pilot • 数据面标准协议：xDS • 集群内Pod流量出入： Gateway（可选,在一个集中点对外部访问进行控制） • Service discovery • Load balancing • Time out • Retries • Circuit breaker • Routing • Auth • Telemetry collecting 外部流量出口 外部流量入口 Pilot 2 Istio 流量管理 – 控制面 两类数据： q 服务数据（Mesh com/istio-ecosystem/consul-mcp） v 通过CRD定义的服务数据 q 自定义流量规则（如何将请求路由到这些服务？） v 通过CRD定义的流量规则 服务数据 流量规则 3 Istio 流量管理 – 控制面 – 服务发现 • K8s Service ： Pilot 直接支持 • ServiceEntry： 手动添加 Service 到 Pilot 内部注册表中 • WorkloadEntry：单独添加