2. 服务网格基础：Istio架构解析、数据平面与控制平面、Envoy代理原理
2.1 服务网格与Istio概述
服务网格（Service Mesh）是云原生架构中处理服务间通信的基础设施层，它将通信逻辑从业务代码中剥离，下沉为独立的代理层。Istio是目前最成熟的服务网格实现之一，其核心价值在于提供流量管理、安全策略和可观测性三大能力，且对应用透明。
关键认知：服务网格不是“服务发现”或“API网关”的替代品，而是对Kubernetes原生网络模型的增强。它通过Sidecar代理模式，在不修改业务容器代码的前提下，实现细粒度的流量控制与安全策略注入。
2.2 Istio整体架构：数据平面与控制平面
Istio架构严格遵循数据平面（Data Plane）与控制平面（Control Plane）分离的设计原则。数据平面由一组与业务容器同Pod运行的Envoy代理组成，负责实际流量转发与策略执行；控制平面则负责统一管理、下发配置与策略。
2.3 控制平面核心组件
控制平面由多个微服务组件构成，各自承担不同职责，通过统一的API向数据平面下发配置。
| 组件 | 核心职责 | 关键协议/接口 |
|---|---|---|
| Pilot | 服务发现、流量管理规则下发（VirtualService/DestinationRule） | xDS (CDS/EDS/LDS/RDS) |
| Citadel | 证书签发与管理、身份认证、mTLS密钥轮换 | SPIFFE、Kubernetes CSR |
| Galley | 配置验证、格式转换、配置分发状态管理 | MCP (Mesh Configuration Protocol) |
| Ingress/Egress Gateway | 南北向流量入口/出口管理，与数据平面Envoy共享同一二进制 | Gateway API、Istio Gateway |
实践要点：Pilot是控制平面与数据平面交互的枢纽。它监听Kubernetes Service/Endpoint变化，结合用户定义的流量规则，生成Envoy可理解的xDS配置。理解xDS协议是后续编写OPA策略的基础——因为OPA策略最终会通过Pilot的扩展机制注入到Envoy的配置中。
2.4 数据平面：Envoy代理原理
Envoy是Istio数据平面的默认代理，以Sidecar模式注入到每个业务Pod中。它拦截所有进出Pod的流量，并基于控制平面下发的动态配置执行路由、负载均衡、熔断、可观测性采集和策略执行。
2.4.1 Envoy核心架构
Envoy采用现代C++编写，基于事件驱动模型，具备高性能和低资源消耗的特点。其核心架构围绕Listener、Filter Chain、Cluster和Endpoint四个抽象构建。
2.4.2 Envoy关键机制
- Listener（监听器）：绑定端口（如15001、15006），接收入站/出站流量。每个Listener可挂载多个Filter Chain。
- Filter Chain（过滤器链）：流量处理的核心管道。支持L3/L4网络过滤器（如TCP Proxy）和L7 HTTP过滤器（如RBAC、JWT认证、OPA策略）。OPA策略引擎正是以HTTP Filter或Access Logger的形式插入Filter Chain。
- Cluster（集群）：定义一组提供相同服务的上游Endpoint集合，包含负载均衡策略、连接池、熔断设置。
- Endpoint（端点）：具体的后端服务实例（Pod IP:Port），由控制平面通过EDS动态发现。
- xDS协议：Envoy与控制平面通信的标准协议族，包括LDS（Listener发现）、RDS（路由发现）、CDS（集群发现）、EDS（端点发现）。
OPA集成关键点：Envoy的Filter Chain机制是OPA策略注入的入口。OPA作为External Authorization Filter（外部授权过滤器）运行，Envoy在转发请求前，会通过gRPC调用OPA的
Check接口，传入请求属性（源IP、路径、Header、JWT等），OPA返回ALLOW或DENY。这种架构保证了策略评估与流量转发解耦，且不侵入业务容器。
2.5 数据平面与控制平面的交互流程
理解两者如何协同工作，是掌握Istio流量管理的基础。以下是一个典型的请求处理流程：
- 配置下发：用户通过
kubectl apply创建VirtualService/DestinationRule等CRD资源。 - Galley验证：Galley监听CRD变更，验证配置合法性，转换为内部模型。
- Pilot生成xDS：Pilot结合服务注册信息与用户配置，生成Envoy可识别的xDS配置（LDS/RDS/CDS/EDS）。
- Envoy热更新：Envoy通过gRPC流式订阅xDS配置，无中断地更新Filter Chain和路由规则。
- 流量拦截：业务Pod A的Envoy通过iptables规则拦截出站流量，根据RDS匹配目标服务。
- 策略评估：Envoy在Filter Chain中调用OPA（或其他授权服务），检查请求是否满足访问控制策略。
- 转发：策略通过后，Envoy根据CDS/EDS选择目标Pod B的Endpoint，建立mTLS连接并转发请求。
性能指标参考：Envoy Sidecar引入的额外延迟通常在1-5ms（P99），CPU开销约为业务容器资源的5-10%。启用OPA策略评估后，额外延迟增加约0.5-2ms（取决于策略复杂度）。在生产环境中，建议为Sidecar设置独立的资源请求/限制（如100m CPU、128Mi内存）。