Istio_05_Istio架构

Istio_05_Istio架构

• Architecture
• • [Control Plane](#Control Plane)
  • • Pilot
    • Citadel
    • Galley
  • [Data Plane](#Data Plane)
  • • Sidecar
    • • Istio-proxy
      • • Pilot-agent
        • [Metadta Exchange](#Metadta Exchange)
    • Ambient

Architecture

如: Istio的架构(控制面、数据面)

1. Gateway : Istio数据面的出/入口网关
   • Gateway分为: Ingress-gateway、Egress-gateway
   • 外部访问服务网格内的服务时均需通过Ingress-gateway(Egress-gateway同理)
   • Gateway的Envoy与服务网格内的数据面代理相同, 都需从Pilot接受流量规则并执行

Control Plane

控制面 (Control Plane): 统一服务发现和集中配置管理

1. Istiod以单体应用方式实现, 但功能/维护以组件化方式进行

如: Istio控制面组件架构

Pilot

Pilot: Istio控制面的控制中枢

1. 主要功能: 服务发现、配置管理、xDS Server
2. Pilot也是Istiod的基础框架, 负责启动/协同其他功能组件
3. Envoy均通过gRPC获取Pilot的配置资源, 并建立长连接获取

如: Pilot架构

1. 平台适配器 从运行平台提取数据并将其构造和转换成Istio服务模型
   • Pilot同时支持以MCP从除Kubernetes以外平台服务端获取配置
   • Pilot实现MCP客户端, 由第三方注册中心实现MCP服务器
2. 聚合器 将不同平台适配器提供的服务模型聚合, 以提供统一的索引接口
   • Pilot通过聚合器可无需关注底层平台的差异(解耦)
   • 也可通过ServiceEntry/WorkloadEntry扩展服务
3. xDS生成器将各种规则转换成Envoy标准格式
4. xDS Server 通过xDS协议将配置发送给各Envoy
   • 通过订阅-发布模型实时、动态地推送xDS配置
   • 服务网格的数据面代理收到相同的流量规则, 并执行相同的治理行为
   • 本质: 通过EDS、CDS和LDS等接口向Enovy分发负载均衡和路由等配置信息

xDS Server: 基于xDS协议生成和分发配置

1. 构成: xDS生成器、ADS服务器
2. xDS (X Discovery Service ): 数据源服务发现协议
   • 本质: LDS、RDS、CDS、EDS和SDS等发现服务的总称
3. ADS (Aggregated Discovery Service ): 聚合发现服务
   • 本质: 将xDS协议的更新指向相同的xDS Server(gRPC服务器)
   • 功能: 避免配置更新过程中的流量丢失(xDS属于最终一致性协议)

xDS Server的配置分发模式: 主动、被动

1. 主动分发: 根据订阅请求将配置下发到Sidecar(事件触发)
   • 触发事件: 底层注册中心的服务或配置更新
   • 主动分发需Sidecar提前与xDS Server建立连接
2. 被动分发: 根据Sidecar请求响应配置
   • 仅能响应指定请求资源类型的配置

如: xDS Server工作流程(省略平台模型的抽象中间组件)

1. xDS Server以串行方式分发各xDS协议(CDS -> EDS -> LDS -> RDS)
2. Pilot通过各类事件通知xDS Server进行xDS推送(同时缓存xDS配置源)

ADS服务器原理: StoW全量的ADS接口

1. ADS服务器对数据的接收/发送使用独立的线程(生命周期同gRPC流)
2. ADS服务器中由主线程处理器异步从队列中获取事件处理

如: ADS服务器工作流程

1. 首次请求时会包含元数据信息以用于初始化
   • 后续的xDS生成/分发都依赖于初始化的元数据

Pilot的核心优化设计:

1. 三级缓存
   • 构成: 平台资源缓存(资源)、Istio聚合层缓存(Istio API)、xDS配置缓存(分发)
   • 功能: 以适量的内存换取Pilot的CPU利用率降低
2. 去抖动分发
   • 本质: 以最小静默时间 和最大延迟时间参数控制分发频率
   • 当时间超过最大延迟时间参数时, 会忽略最小静默时间参数
3. 防过度分发
   • 本质: Pilot等待ACK确定期间的所有xDS分发会合并发送
   • 合并发送的数量取决于最近次分发和ACK响应的时间差值

Citadel

Citadel: Istio控制面的安全组件

1. 主要功能: 自动生成、分发、轮换和撤销证书/密钥
2. 证书种类: 双向TLS证书(CA : Citadel自签)、用户指定证书(RA: 机构签发)
3. 会为每个负载都赋予个独立的身份, 基于该身份实现零信任安全的网络基础模型

如: Citadel原理

1. Envoy启动时根据TLS配置, 向上游发起SDS请求以获取证书
   • 通过SDS接口以订阅方式获取证书, 且直接于内存中加载(便于重载)
2. Pilot-agent作为SDS服务器处理请求(调用其他组件处理)
   • 向Citadel发送证书签发请求CSR
   • Pilot-agent同时负责证书的缓存和轮换(仅在Citadel自签时可用)
3. Citadel认证请求, 并签发证书
   • Citadel以gRPC方式接受CSR请求, 并进行同步处理
   • 处理前以3种方式进行身份认证: X509证书、Kubernetes JWT、OIDC

Galley

Galley: Istio控制面的配置管理组件

1. 主要功能: 验证配置、监控配置、接受/提供配置
2. 本质: 以Webhook Server作为Kubernetes准入控制器
3. Galley监控配置对象发生变更时, 会通知Pilot解析并分发最新配置

如: Galley工作流程

1. Galley启动时首先初始化MCP Sink
   • 是否初始化取决于是否包含MCP源, 以监听MCP源获取配置并缓存
   • MCP Sink: API配置获取和监听方式更新管理的MCP客户端
2. 初始化校验服务器, 并将其注册到HTTPS多路服用其中
   • 校验服务器初始化时失败策略为Ignore(忽略配置错误)
   • 校验服务器最后与HTTPS同时启动以验证配置
3. 初始化并运行Webhook控制器(Istiod启动阶段)
   • 通过监控CA文件的更新事件, 动态更新Webhook配置

Data Plane

数据面 (Data Plane): 流量管理和数据上报

1. 数据面代理统一的注入到管理服务的访问链路上
2. 数据面代理通过控制面的EDS服务发现接口动态地更新负载均衡池
3. 数据面代理通过Iptables规则实现流量拦截和管理, 且只能拦截TCP流量

Sidecar

Sidecar: Istio数据面的服务代理组件模式

1. 构成: Pilot-agent守护进程、Envoy代理进程
2. 本质: 与应用容器共享网络命名空间, 并通过Iptables拦截流量交由Envoy处理

如: Envoy管理流量的链路

1. 流量拦截本质: Envoy在请求方和响应方分别建立Socket连接形成链路转发
2. 可通过注解sidecar.istio.io/interceptionMode指定拦截模式
   • 流量拦截模式: Redirect(默认)、Tproxy

Redirect : Iptables的REDIRECT目标拦截(路由转发)

1. 缺陷: 丢失源客户端信息(未绑定源地址, 使用随机端口作为连接地址)
2. Pod访问自身时需经历完整的Outbound+Inbound管理流程(Inbound流程与外部访问相同)
3. Pod内部访问环回地址或本地网络设备lo和外部访问Envoy管理端口时, 将忽略Iptables规则

如: Redirect模式的Inbound流量拦截流程

1. Evnoy在Pod内部建立的Socket连接地址使用固定的127.0.0.1
2. 可在HTTP请求头中添加特定KV以保留源客户端信息

Tproxy : Iptables的TPROXY目标拦截(报文转发)

1. 缺陷: 复杂度较高, 仅实现L4源客户端信息保留
2. Envoy需开启IP_TRANSPARENT(绑定连接不检查地址)
3. 拦截Outbound流量时需采用DNAT方式, 无法保留源地址

如: Tproxy模式的Inbound流量拦截流程

1. 所有不可达的远程地址都有默认路由

Injector: Istio自动注入的Webhook组件

1. 本质: kube-apiserver拦截Pod创建, 调用Webhook插入istio-init和istio-proxy容器
2. 注入时会自动解析端口并配置就绪探针(服务需有对应的SVC, 否则检查始终失败)
3. 也可通过istioctl命令行工具实现手动注入, 实现效果相同

如: Injector注入Sidecar容器流程

1. Injector配置由ConfigMap保存, 并通过MutatingWebhookConfiguration动态生效
   • 配置中包含注入模板和默认值, 每次注入时动态渲染
   • ConfigMap名称: istio-sidecar-injector
2. istio-init容器负责配置Pod的Iptables规则, 以实现流量拦截
3. istio-proxy容器负责启动Pilot-agent进程, 以管理Envoy代理

Istio-proxy

Istio-proxy: 数据面代理容器

如: Istio-proxy的组成

Pilot-agent

Pilot-agent: 守护进程的方式维护Envoy

1. 其他功能: 扩展功能、SDS证书管理、连接控制面
2. pilot-agent和envoy进程之间使用UDS协议通信, 不受Iptables规则管理
3. 代理应用的健康检查(重写检查直接发送给Pilot-agent, 以绕过Envoy拦截)

如: Pilot-agent架构

1. 根据启动参数和环境变量渲染Envoy的Bootstrap配置文件
   • 以/var/lib/istio/envoy/envoy_bootstrap_tmpl.json文件为启动模板
   • 构建容器时复制模板并生成静态配置文件/etc/istio/proxyenvoy-rev0.json
   • xDS API调用需依赖于Bootstrap配置文件(获取相关配置信息)
2. 监控Envoy运行情况
   • 通过监控envoy进程的Stdout和Stderr描述符获取状态
   • 当envoy进程结束时, pilot-agent进程清理资源后也随之结束(实现Pod重启)
   • 当envoy进程以优雅退出时, 将拒绝外部所有请求并等待内部所有请求处理结束

xDS Proxy: Pilot-agent的xDS请求代理

1. 下游ADS服务器(gRPC服务器)
   • 接受Envoy的xDS请求并透明转发给上游处理模块
   • 首次接受LDS请求时, 会主动发送NDS和PCDS请求
2. 上游请求处理模块
   • 从请求队列中依次取出xDS请求发送给Istiod
3. 上游响应处理模块
   • 接受Istiod返回的xDS响应, 并透明转发给下游ADS服务器
   • NDS、PCDS和ECDS请求将单独拦截处理

如: xDS Proxy原理

1. PCDS : 拦截Proxy Config并更新本地Trust Bundle以触发SDS代理更新证书
   • Envoy加载TLS Context时, 会主动向Pilo-agent的SDS Server发送SDS请求
   • 当提供自定义证书时, Envoy会直接向xDS Proxy发送SDS请求(透明转发)
   • SDS Server请求并转发证书时, 会同时缓存和负责证书的轮转
2. ECDS (Extension Config Discovery Service ): Envoy原生支持的扩展配置发现服务
   • xDS Proxy会拦截ECDS配置, 并交由ECDS处理器处理以重写ECDS配置
   • Istio通过ECDS生成器和xDS Proxy协作, 实现对Wasm的远程获取

Metadta Exchange

Metadata Exchange(元数据交换): 补充元数据信息, 完善上报数据

1. 本质: 数据面代理Envoy通过metadata_exchangeFilter彼此交换元数据
2. 数据面代理创建时自动创建个EnvoyFilter, 以插入L4和L7Filter实现元数据交换
3. 交换信息存储与Envoy内存观测数据集合Stats中, 可被其他系统拉取并汇总(如: Prometheus)

如: L4的元数据交换

1. 数据面代理创建时会自动获取自身元数据信息, 并将其写入Envoy的bootstrap配置中
2. 元数据交换可实现L4/L7的请求数据完善, 两者的实现方式不同
   • L4的TCP元数据交换基于istio-peer-exchange协议, 需双方启用mTLS
   • L7的HTTP元数据交换基于请求头和响应头

Ambient

Ambient : Istio数据面的节点代理模式

1. 构成: ztunnel、waypoint
2. 本质: 节点上多个服务共享ztunnel组件代理

如: Ambient代理模型

1. ztunnel组件以Daemonset形式部署
   • 提供mTLS、可观测性、身份验证和L4授权等功能
2. waypoint组件以Deployment形式部署
   • 提供HTTP路由、负载均衡、熔断和重试等L7流量管理功能

如: Ambient拦截流量原理