Istio_05_Istio架构
- Architecture
- Control Plane
- Pilot
- Citadel
- Galley
- Data Plane
- Sidecar
- Istio-proxy
- Pilot-agent
- Metadta Exchange
- Ambient
Architecture
如: Istio的架构(控制面、数据面)
- Gateway: Istio数据面的出/入口网关
- Gateway分为: Ingress-gateway、Egress-gateway
- 外部访问服务网格内的服务时均需通过Ingress-gateway(Egress-gateway同理)
- Gateway的Envoy与服务网格内的数据面代理相同, 都需从Pilot接受流量规则并执行
Control Plane
控制面(Control Plane): 统一服务发现和集中配置管理
- Istiod以单体应用方式实现, 但功能/维护以组件化方式进行
如: Istio控制面组件架构
Pilot
Pilot: Istio控制面的控制中枢
- 主要功能: 服务发现、配置管理、xDS Server
- Pilot也是Istiod的基础框架, 负责启动/协同其他功能组件
- Envoy均通过
gRPC
获取Pilot的配置资源, 并建立长连接获取
如: Pilot架构
- 平台适配器从运行平台提取数据并将其构造和转换成Istio服务模型
- Pilot同时支持以MCP从除Kubernetes以外平台服务端获取配置
- Pilot实现MCP客户端, 由第三方注册中心实现MCP服务器
- 聚合器将不同平台适配器提供的服务模型聚合, 以提供统一的索引接口
- Pilot通过聚合器可无需关注底层平台的差异(解耦)
- 也可通过ServiceEntry/WorkloadEntry扩展服务
- xDS生成器将各种规则转换成Envoy标准格式
- xDS Server通过
xDS
协议将配置发送给各Envoy- 通过订阅-发布模型实时、动态地推送xDS配置
- 服务网格的数据面代理收到相同的流量规则, 并执行相同的治理行为
- 本质: 通过
EDS
、CDS
和LDS
等接口向Enovy分发负载均衡和路由等配置信息
xDS Server: 基于xDS协议生成和分发配置
- 构成: xDS生成器、ADS服务器
- xDS(X Discovery Service): 数据源服务发现协议
- 本质:
LDS
、RDS
、CDS
、EDS
和SDS
等发现服务的总称
- 本质:
- ADS(Aggregated Discovery Service): 聚合发现服务
- 本质: 将xDS协议的更新指向相同的xDS Server(gRPC服务器)
- 功能: 避免配置更新过程中的流量丢失(xDS属于最终一致性协议)
xDS Server的配置分发模式: 主动、被动
- 主动分发: 根据订阅请求将配置下发到Sidecar(事件触发)
- 触发事件: 底层注册中心的服务或配置更新
- 主动分发需Sidecar提前与xDS Server建立连接
- 被动分发: 根据Sidecar请求响应配置
- 仅能响应指定请求资源类型的配置
如: xDS Server工作流程(省略平台模型的抽象中间组件)
- xDS Server以串行方式分发各xDS协议(
CDS -> EDS -> LDS -> RDS
) - Pilot通过各类事件通知xDS Server进行xDS推送(同时缓存xDS配置源)
ADS服务器原理: StoW
全量的ADS接口
- ADS服务器对数据的接收/发送使用独立的线程(生命周期同gRPC流)
- ADS服务器中由主线程处理器异步从队列中获取事件处理
如: ADS服务器工作流程
- 首次请求时会包含元数据信息以用于初始化
- 后续的xDS生成/分发都依赖于初始化的元数据
Pilot的核心优化设计:
- 三级缓存
- 构成: 平台资源缓存(资源)、Istio聚合层缓存(Istio API)、xDS配置缓存(分发)
- 功能: 以适量的内存换取Pilot的CPU利用率降低
- 去抖动分发
- 本质: 以最小静默时间和最大延迟时间参数控制分发频率
- 当时间超过最大延迟时间参数时, 会忽略最小静默时间参数
- 防过度分发
- 本质: Pilot等待ACK确定期间的所有xDS分发会合并发送
- 合并发送的数量取决于最近次分发和ACK响应的时间差值
Citadel
Citadel: Istio控制面的安全组件
- 主要功能: 自动生成、分发、轮换和撤销证书/密钥
- 证书种类: 双向TLS证书(CA: Citadel自签)、用户指定证书(RA: 机构签发)
- 会为每个负载都赋予个独立的身份, 基于该身份实现零信任安全的网络基础模型
如: Citadel原理
- Envoy启动时根据TLS配置, 向上游发起
SDS
请求以获取证书- 通过
SDS
接口以订阅方式获取证书, 且直接于内存中加载(便于重载)
- 通过
Pilot-agent
作为SDS
服务器处理请求(调用其他组件处理)- 向Citadel发送证书签发请求
CSR
Pilot-agent
同时负责证书的缓存和轮换(仅在Citadel自签时可用)
- 向Citadel发送证书签发请求
- Citadel认证请求, 并签发证书
- Citadel以gRPC方式接受
CSR
请求, 并进行同步处理 - 处理前以3种方式进行身份认证: X509证书、Kubernetes JWT、OIDC
- Citadel以gRPC方式接受
Galley
Galley: Istio控制面的配置管理组件
- 主要功能: 验证配置、监控配置、接受/提供配置
- 本质: 以
Webhook Server
作为Kubernetes准入控制器 - Galley监控配置对象发生变更时, 会通知Pilot解析并分发最新配置
如: Galley工作流程
- Galley启动时首先初始化MCP Sink
- 是否初始化取决于是否包含MCP源, 以监听MCP源获取配置并缓存
- MCP Sink: API配置获取和监听方式更新管理的MCP客户端
- 初始化校验服务器, 并将其注册到
HTTPS
多路服用其中- 校验服务器初始化时失败策略为
Ignore
(忽略配置错误) - 校验服务器最后与
HTTPS
同时启动以验证配置
- 校验服务器初始化时失败策略为
- 初始化并运行Webhook控制器(Istiod启动阶段)
- 通过监控CA文件的更新事件, 动态更新Webhook配置
Data Plane
数据面(Data Plane): 流量管理和数据上报
- 数据面代理统一的注入到管理服务的访问链路上
- 数据面代理通过控制面的
EDS
服务发现接口动态地更新负载均衡池 - 数据面代理通过
Iptables
规则实现流量拦截和管理, 且只能拦截TCP流量
Sidecar
Sidecar: Istio数据面的服务代理组件模式
- 构成: Pilot-agent守护进程、Envoy代理进程
- 本质: 与应用容器共享网络命名空间, 并通过
Iptables
拦截流量交由Envoy处理
如: Envoy管理流量的链路
- 流量拦截本质: Envoy在请求方和响应方分别建立Socket连接形成链路转发
- 可通过注解
sidecar.istio.io/interceptionMode
指定拦截模式- 流量拦截模式: Redirect(默认)、Tproxy
Redirect: Iptables
的REDIRECT目标拦截(路由转发)
- 缺陷: 丢失源客户端信息(未绑定源地址, 使用随机端口作为连接地址)
- Pod访问自身时需经历完整的Outbound+Inbound管理流程(Inbound流程与外部访问相同)
- Pod内部访问环回地址或本地网络设备
lo
和外部访问Envoy管理端口时, 将忽略Iptables
规则
如: Redirect模式的Inbound流量拦截流程
- Evnoy在Pod内部建立的Socket连接地址使用固定的
127.0.0.1
- 可在HTTP请求头中添加特定KV以保留源客户端信息
Tproxy: Iptables
的TPROXY目标拦截(报文转发)
- 缺陷: 复杂度较高, 仅实现L4源客户端信息保留
- Envoy需开启
IP_TRANSPARENT
(绑定连接不检查地址) - 拦截Outbound流量时需采用
DNAT
方式, 无法保留源地址
如: Tproxy模式的Inbound流量拦截流程
- 所有不可达的远程地址都有默认路由
Injector: Istio自动注入的Webhook组件
- 本质:
kube-apiserver
拦截Pod创建, 调用Webhook插入istio-init
和istio-proxy
容器 - 注入时会自动解析端口并配置就绪探针(服务需有对应的SVC, 否则检查始终失败)
- 也可通过
istioctl
命令行工具实现手动注入, 实现效果相同
如: Injector注入Sidecar容器流程
- Injector配置由
ConfigMap
保存, 并通过MutatingWebhookConfiguration
动态生效- 配置中包含注入模板和默认值, 每次注入时动态渲染
ConfigMap
名称: istio-sidecar-injector
istio-init
容器负责配置Pod的Iptables
规则, 以实现流量拦截istio-proxy
容器负责启动Pilot-agent进程, 以管理Envoy代理
Istio-proxy
Istio-proxy: 数据面代理容器
如: Istio-proxy的组成
Pilot-agent
Pilot-agent: 守护进程的方式维护Envoy
- 其他功能: 扩展功能、
SDS
证书管理、连接控制面 - pilot-agent和envoy进程之间使用
UDS
协议通信, 不受Iptables
规则管理 - 代理应用的健康检查(重写检查直接发送给Pilot-agent, 以绕过Envoy拦截)
如: Pilot-agent架构
- 根据启动参数和环境变量渲染Envoy的
Bootstrap
配置文件- 以
/var/lib/istio/envoy/envoy_bootstrap_tmpl.json
文件为启动模板 - 构建容器时复制模板并生成静态配置文件
/etc/istio/proxyenvoy-rev0.json
- xDS API调用需依赖于
Bootstrap
配置文件(获取相关配置信息)
- 以
- 监控Envoy运行情况
- 通过监控envoy进程的
Stdout
和Stderr
描述符获取状态 - 当envoy进程结束时, pilot-agent进程清理资源后也随之结束(实现Pod重启)
- 当envoy进程以优雅退出时, 将拒绝外部所有请求并等待内部所有请求处理结束
- 通过监控envoy进程的
xDS Proxy: Pilot-agent的xDS请求代理
- 下游ADS服务器(gRPC服务器)
- 接受Envoy的xDS请求并透明转发给上游处理模块
- 首次接受LDS请求时, 会主动发送NDS和PCDS请求
- 上游请求处理模块
- 从请求队列中依次取出xDS请求发送给Istiod
- 上游响应处理模块
- 接受Istiod返回的xDS响应, 并透明转发给下游ADS服务器
- NDS、PCDS和ECDS请求将单独拦截处理
如: xDS Proxy原理
- PCDS: 拦截
Proxy Config
并更新本地Trust Bundle
以触发SDS代理更新证书- Envoy加载
TLS Context
时, 会主动向Pilo-agent的SDS Server发送SDS请求 - 当提供自定义证书时, Envoy会直接向xDS Proxy发送SDS请求(透明转发)
- SDS Server请求并转发证书时, 会同时缓存和负责证书的轮转
- Envoy加载
- ECDS(Extension Config Discovery Service): Envoy原生支持的扩展配置发现服务
- xDS Proxy会拦截ECDS配置, 并交由ECDS处理器处理以重写ECDS配置
- Istio通过ECDS生成器和xDS Proxy协作, 实现对Wasm的远程获取
Metadta Exchange
Metadata Exchange(元数据交换): 补充元数据信息, 完善上报数据
- 本质: 数据面代理Envoy通过
metadata_exchange
Filter彼此交换元数据 - 数据面代理创建时自动创建个EnvoyFilter, 以插入L4和L7
Filter
实现元数据交换 - 交换信息存储与Envoy内存观测数据集合
Stats
中, 可被其他系统拉取并汇总(如: Prometheus)
如: L4的元数据交换
- 数据面代理创建时会自动获取自身元数据信息, 并将其写入Envoy的
bootstrap
配置中 - 元数据交换可实现L4/L7的请求数据完善, 两者的实现方式不同
- L4的TCP元数据交换基于
istio-peer-exchange
协议, 需双方启用mTLS
- L7的HTTP元数据交换基于请求头和响应头
- L4的TCP元数据交换基于
Ambient
Ambient: Istio数据面的节点代理模式
- 构成:
ztunnel
、waypoint
- 本质: 节点上多个服务共享
ztunnel
组件代理
如: Ambient代理模型
ztunnel
组件以Daemonset形式部署- 提供
mTLS
、可观测性、身份验证和L4授权等功能
- 提供
waypoint
组件以Deployment形式部署- 提供HTTP路由、负载均衡、熔断和重试等L7流量管理功能
如: Ambient拦截流量原理