• istio-init容器添加用于配置容器网络内iptables规则 • istio-proxy容器启动pilot-agent进程，使用UID=1337 GID=1337创建Envoy启动命令行与配置文件 • 可以通过自定义deployment内istio注解sidecar.istio.io/inject: “false”跳过自动注入过程，或修改部分启动参数。 • 2. 控制面通信 • P 过 滤 路 由 处 理 上 游 连 接 池 • 分为Envoy主线程及worker线程： • 主线程： • 负责初始化Envoy并读取解析配置文件 • 启动gRPC监听器，并启动xDS变化监听 • 启动日志写入线程，每个目标日志文件有独立线程负责输出 • 启动concurrency数目的工作线程 • 启动看门狗线程监控各个工作线程是否定期touch，否则SIGABRT杀掉线程 目标主机列表变化 • 2. 监控到目标主机健康状态变化时，需要通知到工作线程内主机可用状态。 • 3. 当收到节点变化EDS消息时，需要通知到工作线程内新上线、下线主机。 • 4. Envoy使用前面提到的TLS方式实现集群状态更新，集群管理器保存一个TLS slot ，类型为ThreadLocalClusterManagerImpl。 当节点变化、DNS解析更新、健康状态变化时，将调用集群

MCP MCP（Mesh Configuration Protocol）提供了一套用于订阅、推送的 API。 分为 Source 和 Sink： • Source 是资源提供方（server），资源变化了推送给订阅者（Pilot），Istio 1.5 之前这个 角色就是 Galley 或者自定义 MCP Server； • Sink 资源的订阅者（client），在 Istio1.5 之前这个角色就是 获取一些资源（Kubernetes 中使用 Informer 机制获取 Node、Endpoint、 Service、Pod 变化） • 根据用户的配置（CR、MCP 推送，文件） 触发推送流程 推送流程 • 记录变化的资源类型 • 根据变化的资源类型整理本地数据 • 根据变化的资源类型判断需要下发的 xDS资源 • 构建 xDS 资源，下发到连接的 Sidecar10/23 xDS Sidecar Sidecar 通过动态获取服务信息，对服务的发现 API 被称为 xDS。 • 协议部分（ADS、控制发送的顺序以及返回的确认数据） • 数据部分（CDS、EDS、LDS、RDS、SDS）11/23 资源变化 资源名称 CDS EDS LDS RDS Virtualservices ✔ Gateways Serviceentries Destinationrules Envoyfilters

的价值和问题13/25 灰度发布 Istio 的价值和问题14/25 性能损耗 Istio 的价值和问题 每 pod 多占用内存 20 MB -8 毫秒 测试 API 平均响应时 间变化量 吞吐量提升 5 %15/25 Pilot、Mixer 性能瓶颈 Istio 的价值和问题16/25 总结 Istio 的价值和问题 • 已经可以稳定用在生产环境 • 工程架构收益

应控制在k级别，达到 10k 量级后响应可能会出现超 时导致配置读写状态异常，进而影响整个系统稳定性 实践总结 • Istio配置管理有局限性： • Endpoint的配置管理有防抖动处理，即使集群中的部署变化再快， 也不会阻塞Istio • Istio其他配置管理没有防抖动处理（ VirtualService/DestinationRule等），如果用程序自动化注入这些 配置要注意在客户端实现限流