1、Higress 核心组件和原理
Higress 是基于 Envoy 和 Istio 进行二次定制化开发构建和功能增强，同时利用 Envoy 和 Istio 一些插件机制，实现了一个轻量级的网关服务。其包括 3 个核心组件：Higress Controller（控制器）、Higress Gateway（网关）和 Higress Console（控制台）
其核心工作流程如下图：
1）、Higress Controller
Higress Controller（控制器） 是 Higress 的核心组件，其功能主要是实现 Higress 网关的服务发现、动态配置管理，以及动态下发配置给数据面。Higress Controller 内部包含两个子组件：Discovery 和 Higress Core
1）Discovery 组件
Discovery 组件（Istio Pilot-Discovery）是 Istio 的核心组件，负责服务发现、配置管理、证书签发、控制面和数据面之间的通讯和配置下发等。 Discovery 将 Kubernetes Service、Gateway API 配置等转换成 Istio 配置，然后将所有 Istio 配置合并转成符合 xDS 接口规范的数据结构，通过 GRPC 下发到数据面的 Envoy。其工作原理如下图：
Discovery 组件（Istio Pilot-Discovery）是 Istio 的核心组件。Discovery 可以作为 MCP Client，任何实现了 MCP 协议的 Server 都可以通过 MCP 协议向 Discovery 下发配置信息，从而消除了 Istio 和 Kubernetes 之间的耦合，同时使 Istio 的配置信息处理更加灵活和可扩展。 同时 MCP 是一种基于 xDS 协议的配置管理协议（详细可以看下 MCP over XDSv3 设计文档）
在 Higress 中 Discovery 的核心作用是作为 MCP Client，Higress Core 作为 MCP Server 通过 MCP 协议向 Discovery 下发配置信息。然后 Discovery 将由 Higress Core 下发的所有 Istio 配置合并转成符合 xDS 接口规范的数据结构，通过 GRPC 下发到数据面的 Envoy
2）Higress Core 组件
Higress Core 核心逻辑如下图：
Higress Core 中核心子组件为 Ingress Config，Ingress Config 包含 6 个控制器，各自负责不同的功能：
- Ingress Controller：监听 Ingress 资源，将 Ingress 转换为 Istio 的 Gateway、VirtualService、DestinationRule 等资源
- Gateway Controller：监听 Gateway API 资源，将 Gateway API 资源转换为 Istio 的 Gateway、VirtualService、DestinationRule 等资源（Gateway API 配置包括：
GatewayClass、Gateway、HttpRoute、TCPRoute、GRPCRoute等，可以参考 Gateway API 官方文档 了解更多配置信息） - McpBridge Controller：根据 Higress McpBridge 的配置，将来自 Nacos、Eureka、Consul、Zookeeper 等外部注册中心或 DNS 的服务信息转换成 Istio ServiceEntry 和 WorkloadEntry 资源
- Http2Rpc Controller：监听 Higress Http2Rpc 资源，实现 HTTP 协议到 RPC 协议的转换。用户可以通过配置协议转换，将 RPC 服务以 HTTP 接口的形式暴露，从而使用 HTTP 请求调用 RPC 接口
- WasmPlugin Controller：监听 Higress WasmPlugin 资源，将 Higress WasmPlugin 转化为 Istio WasmPlugin。Higress WasmPlugin 在 Istio WasmPlugin 的基础上进行了扩展，支持全局、路由、域名、服务级别的配置
- ConfigmapMgr：监听 Higress 的全局配置
higress-configConfigMap，可以根据 tracing、gzip 等配置构造 EnvoyFilter
2）、Higress Gateway
Higress Gateway 内部包含两个子组件：Pilot Agent 和 Envoy。Pilot Agent 主要负责 Envoy 的启动和配置，同时代理 Envoy xDS 请求到 Discovery。 Envoy 作为数据面，负责接收控制面的配置下发，并代理请求到业务服务。 Pilot Agent 和 Envoy 之间通讯协议是使用 xDS 协议， 通过 Unix Domain Socket（UDS）进行通信。 Envoy 核心架构如下图：
参考：
推荐阅读：
2、Wasm 插件实现原理
Higress 的核心思路是基于 Wasm 插件机制进行扩展，提供了AI、认证、安全、流量控制等类型的 Wasm 插件（可以参考 Higress 插件文档 了解各个 Wasm 插件的使用方式）。这里详细来看下 Wasm 插件如何在 Higress 中使用、分发及最终在 Envoy 中加载的整个流程
1）、Wasm VM 和 Wasm 插件
Wasm 虚拟机（Wasm VM 或简称 VM）指的是加载 Wasm 程序的实例。 在 Envoy 中，VM 通常在每个线程中创建并相互隔离。因此 Wasm 程序将复制到 Envoy 所创建的线程里，并在这些虚拟机上加载并执行。 插件提供了一种灵活的方式来扩展和自定义 Envoy 的行为。Proxy-Wasm 规范允许在每个 VM 中配置多个插件。因此一个 VM 可以被多个插件共同使用。Envoy 中有三种类型插件: Http Filter、Network Filter 和 Wasm Service
Http Filter是一种处理 Http 协议的插件，例如操作 Http 请求头、正文等Network Filter是一种处理 Tcp 协议的插件，例如操作 Tcp 数据帧、连接建立等Wasm Service是在单例 VM 中运行的插件类型（即在 Envoy 主线程中只有一个实例）。它主要用于执行与Network Filter或Http Filter并行的一些额外工作，如聚合指标、日志等。这样的单例 VM 本身也被称为Wasm Service
2）、Envoy 使用 Wasm Http Filter 配置示例
static_resources:
# 监听器配置
listeners:
- name: listener_0
address:
socket_address:
protocol: TCP
address: 0.0.0.0
port_value: 10000 # 监听器端口
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager # HTTP连接管理器配置
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
scheme_header_transformation:
scheme_to_overwrite: https # 将scheme重写为https
stat_prefix: ingress_http # 统计信息前缀
# 将Envoy日志输出到标准输出
access_log:
- name: envoy.access_loggers.stdout
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
# 路由配置
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: [ "*" ] # 匹配所有域名
routes:
- match:
prefix: "/" # 匹配所有路径
route:
cluster: qwen # 路由到qwen集群
timeout: 300s # 设置超时时间为300秒
http_filters: # HTTP过滤器配置
- name: ai-proxy-wasm # 使用自定义Wasm插件
typed_config:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
value:
config:
name: ai-proxy-wasm
vm_config:
vm_id: "ai-proxy" # VM ID，可以为空
runtime: envoy.wasm.runtime.v8 # 使用V8运行时环境
code:
local:
filename: /etc/envoy/plugin.wasm # WASM文件路径
configuration: # WASM插件配置
"@type": "type.googleapis.com/google.protobuf.StringValue"
value: |
{
"provider": {
"type": "qwen",
"apiTokens": [
"fake_token"
],
"modelMapping": {
"gpt-3": "qwen-turbo",
"gpt-35-turbo": "qwen-plus",
"gpt-4-turbo": "qwen-max",
"*": "qwen-turbo"
}
}
}
- name: envoy.filters.http.router # HTTP路由过滤器，用于处理最终的路由决策
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
# 集群配置
clusters:
- name: qwen
connect_timeout: 30s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: qwen
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: dashscope.aliyuncs.com # 上游服务地址
port_value: 443 # 上游服务端口
transport_socket:
name: envoy.transport_sockets.tls # 使用TLS传输套接字
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
"sni": "dashscope.aliyuncs.com" # TLS中的服务器名称指示
以上配置中使用 ai-proxy Wasm 插件，该 Wasm 插件实现了基于 OpenAI API 契约的 AI 代理功能，该配置文件的主要作用是：
- 监听 HTTP 请求：Envoy 监听10000端口，接收所有传入的 HTTP 请求
- 路由请求：将所有请求路由到 qwen 集群
- 使用 Wasm 过滤器：
- 在请求处理过程中使用 ai-proxy-wasm 过滤器
- 该过滤器使用 V8 运行时环境加载
/etc/envoy/plugin.wasm文件 - 传递通义千问代理的配置参数，包括 API 令牌和模型映射
- 负载均衡：qwen 集群使用逻辑 DNS 解析和轮询负载均衡策略，将请求转发到 dashscope.aliyuncs.com 的443端口
这时 Envoy 会在每个工作线程中实例化一个 Wasm 虚拟机，该虚拟机将专门用于处理该线程上的 HTTP 请求和响应。每个虚拟机都会加载和执行 WebAssembly 代码，允许对 HTTP 流量进行自定义处理，如修改头信息、处理请求和响应体等
完全相同的 vm_config 配置（相同的 vm_id + runtime + Wasm 文件）的多个插件它们之间共享一个 Wasm VM，单个 Wasm VM 用于多个 Http Filter 或 Network Filter，可以提升内存/CPU 资源效率、降低启动延迟
更多 Envoy 中使用 Wasm 的配置示例可以看下 Wasm VM、插件和 Envoy 配置
3）、Higress Wasm 插件分发原理
OCI 分发流程如下：
- 当 Higress WasmPlugin 资源更新时，Higress Core 监听到这个变化，同时把 Higress WasmPlugin 转成 Istio WasmPlugin
- Higress Core 将转成 Istio WasmPlugin 通过 MCP Over Xds 推送给 Discovery
- Discovery 通过 Pilot Agent 的 ADS 连接，通过 LDS 协议下发给 Plot Agent
- Pilot Agent 将 LDS 响应直接代理转发给 Envoy
- Envoy 根据 Listener 里插件配置，通过 ECDS (Extension Config Discovery Service) 订阅插件配置
- Pilot Agent 代理 ECDS 协议请求到 Discovery，同时拦截 ECDS 协议响应
- Pilot Agent 根据 ECDS 响应里插件 OCI 配置，从 Registry Hub 下载镜像
- Pilot Agent 把镜像里插件 Wasm 文件解压到本地，同时修改 ECDS 响应里插件地址到本地 Wasm 文件路径，然后把 ECDS 协议响应返回给 Envoy
- Envoy 根据 ECDS 协议响应，加载本地 Wasm 文件
4）、Higress WasmPlugin CRD
1）配置字段
Higress WasmPlugin CRD 在 Istio WasmPlugin CRD 的基础上进行了扩展，新增 defaultConfig、defaultConfigDisable 和 matchRules 字段，用于配置插件的默认配置和路由级、域名级、服务级配置
Istio WasmPlugin CRD 配置：
| 字段名称 | 数据类型 | 填写要求 | 描述 |
|---|---|---|---|
pluginName | string | 选填 | 插件名称 |
phase | string | 选填 | 插件插入插件链中的位置，默认是 UNSPECIFIED_PHASE |
priority | int | 选填 | 插件执行优先级，默认为 0，在相同 phase 下，值越大越先处理请求，但越后处理响应 |
imagePullPolicy | string | 选填 | 插件镜像拉取策略，可选值有：UNSPECIFIED_POLICY（默认值）、IfNotPresent、Always |
imagePullSecret | string | 选填 | 用于拉取 OCI 镜像的凭据。与 WasmPlugin 在同一命名空间中的 Kubernetes Secret 的名称 |
url | string | 必填 | Wasm 文件或 OCI 容器的 URL，默认为 oci://，引用 OCI 镜像。同时支持 file://，用于容器本地的 Wasm 文件，以及 http[s]://，用于引用远程托管的 Wasm 文件 |
Higress WasmPlugin CRD 扩展的配置：
| 字段名称 | 数据类型 | 填写要求 | 描述 |
|---|---|---|---|
defaultConfig | object | 选填 | 插件默认配置，全局生效于没有匹配具体域名和路由配置的请求 |
defaultConfigDisable | bool | 选填 | 插件默认配置是否失效，默认值是 false |
matchRules | array of object | 选填 | 匹配域名或路由生效的配置 |
matchRules 中每一项的配置字段说明：
| 字段名称 | 数据类型 | 填写要求 | 配置示例 | 描述 |
|---|---|---|---|---|
ingress | []string | ingress、domain 和 service 中必填一项 | [“default/foo”, “default/bar”] | 匹配 ingress 资源对象，匹配格式为: 命名空间/ingress名称 |
domain | []string | ingress、domain 和 service 中必填一项 | [“example.com”, “*.test.com”] | 匹配域名，支持泛域名 |
service | []string | ingress、domain 和 service 中必填一项 | [“echo-server.higress-course.svc.cluster.local”] | 匹配服务名称 |
config | object | 选填 | - | 匹配后生效的插件配置 |
configDisable | bool | 选填 | false | 配置是否生效，默认设置为 false |
2）Wasm 插件的 phase 和 priority
Wasm 插件 phase 有4个值，分别为：
UNSPECIFIED_PHASE：在插件过滤器链的末端，在路由器之前插入插件，如果没有指定插件的phase，则默认设置为UNSPECIFIED_PHASEAUTHN：在 Istio 认证过滤器之前插入插件AUTHZ：在 Istio 授权过滤器之前且在 Istio 认证过滤器之后插入插件STATS：在 Istio 统计过滤器之前且在 Istio 授权过滤器之后插入插件
同时在相同 phase 情况下，priority 值越大，插件在插件链位置越靠前。 关于认证和授权相关内容可以参考 Istio 安全官方文档 。其插件链结构如下图：
3）配置示例
Higress 中使用 ai-proxy Wasm 插件示例：
apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
name: ai-proxy-1.0.0
namespace: higress-system
spec:
defaultConfigDisable: true
matchRules:
- config: # 代理通义千问，对应ingress为qwen
provider:
apiTokens:
- fake_token
modelMapping:
gpt-3: qwen-turbo
gpt-35-turbo: qwen-plus
gpt-4-*: qwen-max
'*': qwen-turbo
type: qwen
configDisable: false
ingress:
- qwen
- config: # 代理豆包，对应ingress为doubao
provider:
apiTokens:
- fake_token
modelMapping:
'*': fake_doubao_endpoint
type: doubao
configDisable: false
ingress:
- doubao
phase: UNSPECIFIED_PHASE
priority: 100
url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/ai-proxy:1.0.0
Higress Controller 控制面（Higress Core 组件）会把 Higress WasmPlugin 配置转换成 Istio WasmPlugin 配置，同时通过 MCP over Xds 同步到 Istio Discovery，然后下发到 Envoy。这里可以通过 Higress Controller Debug 接口查看转换后的 Istio WasmPlugin 配置：
kubectl exec <higress-controller-pod> -c higress-core -n higress-system -- curl http://127.0.0.1:8888/debug/configz
以下是 ai-proxy 插件转换成 Istio WasmPlugin 配置如下：
kind: WasmPlugin
apiVersion: extensions.istio.io/v1alpha1
metadata:
name: ai-proxy-1.0.0
namespace: higress-system
spec:
imagePullPolicy: Always
phase: UNSPECIFIED_PHASE
pluginConfig:
_rules_:
- _match_route_:
- qwen
provider:
apiTokens:
- fake_token
modelMapping:
gpt-3: qwen-turbo
gpt-35-turbo: qwen-plus
"gpt-4-*": qwen-max
"*": qwen-turbo
type: qwen
- _match_route_:
- doubao
provider:
apiTokens:
- fake_token
modelMapping:
"*": fake_doubao_endpoint
type: doubao
priority: 100
selector:
matchLabels:
higress: higress-system-higress-gateway
url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/ai-proxy:1.0.0
在 pluginConfig 中增加了 _rules_ 规则列表，每个规则可以指定匹配方式并填写对应生效的配置。一共有3种匹配方式，优先级由高到低依次为：
_match_route_：匹配 Ingress 名称生效，匹配格式为：Ingress 所在命名空间 + / + Ingress 名称（单个路由维度）_match_domain_：匹配域名生效，填写域名即可，支持通配符（路由对应的域名维度，可以对应多个路由）_match_service_：匹配服务生效，填写服务即可，支持通配符（转发的上游服务维度）
参考：
扫一扫
888
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
