1. 启动阶段 • istiod拦截pod创建请求，识别为指定namepsace则根据configmap配置生成带有Envoy两个容器的创建POD请求，修改过的创建请求被 kubelet接收，并在节点创建POD。 • istio-init容器添加用于配置容器网络内iptables规则 • istio-proxy容器启动pilot-agent进程，使用UID=1337 GID=1337创建Envoy启动命令行与配置文件 收Envoy连接，用于证书更新下发。并且与istiod建立证书更新通道。 • Envoy 通过pilot-agent转发机制与istiod建立长连接，通过xDS协议接收系统下发的监听器、路由、集群节点等更新信息。 • 3. 数据面通信 • 客户端请求进入容器网络，并被iptables规则拦截，经过DNAT后进入Envoy virtualOutbound监听器 • virtualOutbou 监控到目标主机健康状态变化时，需要通知到工作线程内主机可用状态。 • 3. 当收到节点变化EDS消息时，需要通知到工作线程内新上线、下线主机。 • 4. Envoy使用前面提到的TLS方式实现集群状态更新，集群管理器保存一个TLS slot ，类型为ThreadLocalClusterManagerImpl。 当节点变化、DNS解析更新、健康状态变化时，将调用集群管理器的postThreadLocalClusterUpdate方法

调用oras API从注册库中动态拉取wasm filter; ○ 该asmwasm-controller使用HostPath方式挂载volume, 所以拉取的wasm filter会落 盘到对应的节点上; 15 创建私钥仓库登录Secret ● 获取私有仓库登录信息之后, 按照如下命令创建Secret ○ kubectl create secret generic asmwasm-cache 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: -

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 通过动态获取服务信息，对服务的发现 API 被称为 xDS。 • 协议部分（ADS、控制发送的顺序以及返回的确认数据） • 数据部分（CDS、EDS、LDS、RDS、SDS）11/23 资源变化 资源名称 CDS EDS LDS RDS Virtualservices ✔ Gateways Serviceentries Destinationrules Envoyfilters

to connect, manage, and secure microservices. Istio项目 微服务角度看Istio: 治理形态的演变 Node 1 svc1 自身业务 SDK Sidecar 服务治理 Node 2 svc 2 自身业务 SDK Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 应用侵入--； 治理位置--； } 微服务角度看Istio: 服务网格 服务网格控制面 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb.ns svcc.ns svcb svcd svce svce.ns svcd.ns svcd.ns Kube-proxy Kube-APIServer ServiceIp Backend Istio & Kubernetes：架构结合 Kube-APIServer Etcd istioctl / kubectl Pilot Envoy SVC Pod Node Envoy SVC Pod Node Envoy SVC Pod list/watch (Service, Endpoints, Pod) 用户 Istio & Kubernetes：统一服务发现

connect, manage, and secure microservices.4 Istio项目5 微服务角度看Istio: 治理形态的演变 Node 1 svc1 自身业务 SDK Sidecar 服务治理 Node 2 svc 2 自身业务 SDK Sidecar 服务治理 通信基础 服务发现 负载均衡 熔断容错 动态路由 … for (封装++) { 应用侵入--； 应用侵入--； 治理位置--； }6 微服务角度看Istio: 服务网格 服务网格控制面7 从基础设施(Kubernetes)看Istio: 服务访问 Node svca svcc svcb.n s svcc.ns svcb svcd svce svce.n s svcd.n s svcd.n s Kube-proxy Kube-APIServer ServiceIp Istio & Kubernetes：架构结合 Kube-APIServer Etcd istioctl / kubectl Pilot Envoy SVC Pod Node Envoy SVC Pod Node Envoy SVC Pod list/watch (Service, Endpoints, Pod) 用户13 Istio & Kubernetes：统一服务发现

运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 Ø 多数模块对单点异常，慢节点等异常缺乏容忍能力，推动每个模块独立修复，成本高，上线周期长。 Ø 因重试导致雪崩，底层RPC框架需要重复建设来定制动态熔断能力。 Ø 升级一级服务建设中，发现很多模块单点、多点故障不能容忍，能否低成本解决？ （百度APP100%核心模块，流量占比>79.5% ） #IstioCon 收益介绍 – 防雪崩&长尾 长尾优化： LocalityAware负载均衡策略 业务价值 LocalityAware负载均衡策略以下游节点的吞吐 除以延时作为分流权值，优化长尾平响问题。 Mesh价值 1. 优秀策略支持给业务方跨语言跨框架使用。 2. 支持LocalityAware Plus负载均衡策略，提 升单点容错能力。 业务价值

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

慢方法、异常调用以及异常报文 等信息 单次链路追踪 可细粒度排查应用单次链路调用 的包括日志、网络数据在内的所 有信息。 宏观下的监控需求 链路总体展示 展示整个服务调用过程中链路上 每一个节点的服务状况，包括延 时、吞吐量等基本信息。 服务器总体展示 展示当前所有服务器的运行状况， 包括CPU、内存、网络、I/O读写 等信息 业务总体展示 展示当前业务相关数据的 从宏观上快速定位问题，在微观上找到问题根因的

吞吐量提升 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

流量观测 超时重试 服务网格 流量安全 SolarMesh Copyright © 2021 Cloud To Go •轻量 核心组件少安装简单，轻量的架构赋予SolarMesh极低的资源占用以及极低的维护成本 •规范 标准的istio规范操作，实时反映真实集群状态，告别terminal。 •便捷 一键安装，UI操作，流量策略模板复用，批量设置 •多集群支持，零成本接入