目录一、架构核心控制平面与数据平面二、数据平面流量的执行者1. 核心组件Envoy Proxy2. 生命周期管理pilot-agent3. 流量拦截原理三、控制平面网格的大脑四、核心交互流程1. 完整集群启动流程2. 请求拦截与转发全链路一、架构核心控制平面与数据平面Istio 的架构设计精髓在于逻辑上的分离它将整个服务网格划分为两个核心部分控制平面 (Control Plane)负责全局的策略配置、安全认证和状态同步。它是网格的“大脑”。数据平面 (Data Plane)由一组智能代理Sidecar组成负责协调和控制微服务之间的所有网络通信。它是网格的“执行层”。这种分离设计使得 Istio 能够在不修改任何业务代码的情况下透明地接管微服务间的网络流量。二、数据平面流量的执行者数据平面由部署在每个业务 Pod 中的 Sidecar边车 容器组成它们与业务应用并肩运行。1. 核心组件Envoy Proxy角色高性能代理负责拦截所有入站Inbound和出站Outbound流量。能力在本地执行路由、负载均衡、限流、熔断、mTLS 加密等治理规则。特点业务应用完全感知不到它的存在依然以原本的方式通信。2. 生命周期管理pilot-agent角色Envoy 的“保姆”。能力负责为 Envoy 准备启动参数、管理进程生命周期启动、监控、异常重启负责下发配置、证书热加载以及监控 Envoy 的运行状态确保代理稳定运行。3. 流量拦截原理机制Pod 初始化时通过 Init 容器istio-init设置 iptables 规则。效果将业务容器的所有流量透明重定向到 Envoy 监听的端口默认 15001/15006实现无感接入。三、控制平面网格的大脑在 Istio 1.5 版本中控制平面整合为单一组件 Istiod内部包含三大核心模块模块核心职责关键能力Pilot流量与服务发现将高级路由规则A/B测试、金丝雀转换为 Envoy 配置通过 xDS API 实时下发。Citadel安全与证书管理自动颁发/轮换 TLS 证书实现服务间 mTLS 双向认证无需人工干预。Galley配置验证与分发拦截并校验 Istio 资源变更确保配置合法解耦底层平台如 K8s保证配置独立性。早期的 Mixer 组件负责策略和遥测因性能问题已被弃用相关功能已下沉到数据平面的 Envoy 过滤器中处理。Pilot流量管理的大脑Pilot 是 Istio 的流量管理中心负责将用户定义的高级路由规则转化为数据平面Envoy能够理解的配置并分发给它们。核心职责流量管理和服务发现。工作流程规则转换Pilot 接收用户通过 VirtualService、DestinationRule 等自定义资源CRD定义的高级路由规则例如 A/B 测试、金丝雀发布、故障注入等。服务发现它从底层平台如 Kubernetes获取服务实例列表Endpoints了解每个服务有哪些 Pod 实例在运行。配置下发Pilot 将转换后的路由规则和获取到的服务发现信息通过 xDS API一套标准的发现服务 API包括 LDS、RDS、CDS、EDS以 gRPC 长连接的方式实时推送给数据平面的每一个 Envoy 代理。热更新当路由规则或服务实例发生变化时Pilot 会增量地更新 Envoy 的配置实现无需重启服务的“热加载”。简单来说Pilot 告诉 Envoy “流量应该怎么走”以及“服务实例在哪里”。Citadel安全与证书的守护者Citadel 是 Istio 的安全核心负责为服务网格提供强大的身份认证和通信加密能力实现零信任安全模型。核心职责密钥和证书管理。工作流程充当根证书颁发机构 (CA)Citadel 内置了一个 CA负责生成和管理整个服务网格的根证书和私钥。自动颁发证书当一个新的服务Pod启动时其 Sidecar 中的 pilot-agent 会向 Citadel 发起证书签名请求CSR。Citadel 验证身份后会为其签发一个带有唯一身份标识的 TLS 证书和私钥。实现 mTLS服务间的通信通过 Envoy 代理进行。Envoy 使用 Citadel 颁发的证书来建立 mTLS双向 TLS 加密通道确保通信双方的身份都是可信的且数据在传输过程中是加密的。自动轮换Citadel 颁发的证书有效期较短并会自动进行轮换pilot-agent 负责监视证书变化并通知 Envoy 热加载整个过程对业务应用完全透明。简单来说Citadel 负责“证明你是谁”并“确保通信安全”。Galley配置的验证与分发中心Galley 的主要作用是作为用户配置与 Istio 其他组件之间的“守门员”和“中转站”旨在提升系统的健壮性和可移植性。核心职责配置验证、处理和分发。工作流程配置验证当用户通过 kubectl apply 创建或修改 Istio 的配置资源如 VirtualService时Galley 会通过 Kubernetes 的准入控制器Admission Webhook拦截这些请求。它会校验配置文件的语法和语义是否正确防止无效配置进入系统。平台解耦Galley 从 Kubernetes API Server 中获取经过验证的配置并将其抽象成一种与平台无关的内部表示。这样做的好处是Istio 的控制平面组件如 Pilot不再直接依赖 Kubernetes 的 API使得 Istio 理论上可以更容易地运行在其他平台上。配置分发Galley 将处理好的、平台无关的配置分发给 Pilot 等其他控制平面组件。简单来说Galley 负责“检查配置是否正确”并“安全地传递给其他组件”。四、核心交互流程1. 完整集群启动流程Istio 集群启动涉及控制平面组件IstiodPilot、Citadel、Galley、数据平面组件Envoy Proxy、pilot-agent以及 Kubernetes 平台机制的协同配合。下面从零开始完整描述一个服务网格集群的启动过程。阶段一Istiod 控制平面启动部署 IstiodIstiod 以 Deployment 形式部署在istio-system命名空间通常以多副本保证高可用。启动各子模块Pilot初始化服务发现与流量管理引擎准备接收 xDS 连接。Citadel加载或生成根证书作为集群的根 CA 就绪等待签发工作负载证书。Galley向 K8s API Server 注册 ValidatingWebhook拦截 Istio CRD 的创建/修改请求并进行校验。建立 Watch 监听Istiod 与 K8s API Server 建立长连接持续监控 Services、Endpoints、Pods、Nodes 及 Istio CRDVirtualService、DestinationRule 等的变更事件。服务就绪Istiod 各模块全部就绪等待数据平面 Sidecar 接入。阶段二业务 Pod 创建与 Sidecar 注入当用户在已开启自动注入的命名空间中创建业务 Pod 时Webhook 拦截K8s API Server 收到 Pod 创建请求后调用 Istio 注册的 Sidecar-Injector MutatingWebhook。修改 Pod Spec注入Injector 动态修改 Pod 的 YAML 描述注入两个关键元素istio-initInit 容器负责配置 iptables 规则。istio-proxySidecar 容器内部包含 pilot-agent Envoy。执行 Init 容器iptables 规则Pod 启动后istio-init容器率先执行写入 iptables 规则将所有进出业务容器的流量透明重定向到 Envoy 代理监听端口15001 入站 / 15006 出站。执行完成后 Init 容器退出。启动istio-proxy容器Init 容器执行完毕后主容器和 Sidecar 容器并行启动pilot-agent 启动pilot-agent 作为 Envoy 的保姆进程首先启动准备 Envoy 配置文件bootstrap 配置随后拉起 Envoy 进程。Envoy 启动Envoy 读取 pilot-agent 生成的 bootstrap 配置获知 Istiod 的地址。阶段三Sidecar 与控制平面建联连接 Pilot获取 xDS 配置Envoy 通过 gRPC 长连接向 Pilot 发起 xDS 订阅请求LDS / RDS / CDS / EDSPilot 将当前集群中所有服务实例的 Endpoints 和路由规则VirtualService、DestinationRule转换为 Envoy 可理解的配置并下发。连接 Citadel获取 mTLS 证书pilot-agent 代表 Envoy 向 Citadel 发起 CSR证书签名请求。Citadel 验证请求来源的身份后为该 Sidecar 签发带有 SPIFFE 身份标识如spiffe://cluster.local/ns/default/sa/my-service的 TLS 证书和私钥并下发。后续 pilot-agent 还会监控证书过期自动触发轮换并热加载。阶段四集群启动完成就绪状态Envoy 同时拿到最新路由配置 mTLS 证书后开启监听端口进入 Ready 状态。此时服务网格的控制平面和该 Pod 的数据平面已完整就绪可以承接业务流量。整个启动链路涉及文章中所有核心组件**IstiodPilot Citadel Galley**→Sidecar-Injector Webhook→Init 容器iptables→pilot-agent→Envoy Proxy。每个环节缺一不可共同完成从零到可服务的跨越。集群启动流程图数据平面业务 Pod控制平面istio-system 命名空间部署 Istiod DeploymentIstiod 启动Pilot初始化服务发现引擎Citadel加载根证书CA 就绪Galley注册 ValidatingWebhook建立 Watch 监听 K8s API ServerIstiod 全部就绪等待 Sidecar 接入用户创建 PodK8s API Server 接收请求Sidecar-Injector Webhook 拦截修改 Pod Spec注入 istio-init istio-proxyPod 启动Init 容器执行 iptables 规则istio-init 退出主容器与 Sidecar 并行启动pilot-agent 生成 bootstrap 配置并拉起 EnvoyEnvoy 向 Pilot 发起 xDS 订阅gRPC 长连接pilot-agent 向 Citadel 发起 CSR 证书请求Envoy 获取路由规则 EndpointsEnvoy 获取 mTLS 证书Sidecar 就绪可承接业务流量2. 请求拦截与转发全链路本部分聚焦一个真实的业务请求从发起到响应的完整路径展示数据平面 Envoy 如何透明地拦截、决策、安全转发和卸载流量。阶段一出站拦截与本地决策当服务 A发起对服务 B的 HTTP/gRPC 调用时iptables 透明拦截服务 A 进程发出的请求包首先被本 Pod 内 iptables 规则匹配重定向到 Envoy 的出站监听端口15006。对业务应用而言它认为自己直接连接了服务 B实际上流量已被旁路劫持。Envoy 出站处理链解析请求的目标地址Host:Port从本地 xDS 缓存中匹配对应的ListenerLDS和ClusterCDS。服务发现EDS从 Cluster 对应的 Endpoints 列表中依据负载均衡策略如 ROUND_ROBIN、LEAST_REQUEST选出一个具体的服务 B 的 Pod 实例。路由决策RDS根据 VirtualService 中定义的匹配规则Header、URI 前缀等决定是否执行流量切分、金丝雀路由、重试、超时、熔断等治理动作。安全握手根据 DestinationRule 中配置的 TLS 模式通常为 ISTIO_MUTUALEnvoy 使用自身持有的 mTLS 证书向目标 Envoy 发起双向 TLS 握手建立加密通道。阶段二转发到目标 Sidecar加密转发请求被封装在 mTLS 通道中通过网络发出目的地是服务 B 的 Pod IP Envoy 入站端口15006。目标 Envoy 入站处理服务 B 所在 Pod 的 iptables 规则将入站流量重定向到 Envoy 的入站监听端口15001。执行RBAC 鉴权AuthorizationPolicy、速率限制等入站策略。解密 mTLS 流量还原出原始请求。阶段三转发到业务容器与响应返回转发至应用Envoy 将解密后的请求转发给本 Pod 内服务 B 的业务容器端口如 8080。响应返回服务 B 处理完业务逻辑后返回响应响应沿原路服务 B Envoy → mTLS 加密 → 服务 A Envoy → 解密 → 服务 A 业务进程返回。遥测上报异步在整个过程中双方的 Envoy 自动记录请求延迟、状态码、错误率等指标对接到 Prometheus请求 Trace 信息上报到 Jaeger/Zipkin形成完整的分布式调用链。整个请求链路中iptables负责透明拦截Envoy作为策略执行点完成路由/安全/观测三大能力Pilot通过 xDS 持续提供配置保鲜Citadel保障通信的加密与身份认证。业务代码零侵入、零感知。请求拦截与转发流程图服务 B业务容器Envoy服务 BIstiodPilot CitadelEnvoy服务 A服务 A业务容器服务 B业务容器Envoy服务 BIstiodPilot CitadelEnvoy服务 A服务 A业务容器 前置Sidecar 已持有 mTLS 证书与 xDS 配置 1. 出站拦截2. 本地决策3. 入站处理与转发4. 响应返回5. 遥测上报异步HTTP/gRPC 请求流向服务 B匹配 Listener/Routes/Cluster服务发现选择目标 Endpoint流量治理重试/超时/熔断/灰度mTLS 加密通道建立加密请求目标 Pod IP:15001RBAC 鉴权 入站策略解密 mTLS 流量转发原始请求localhost:8080返回响应mTLS 加密响应解密后返回响应上报指标Prometheus/ TraceJaeger上报指标Prometheus/ TraceJaeger