本文针对 Knative Serving 与 Istio Service Mesh 集成场景，提出一套完整的会话亲和性（Session Affinity）解决方案。该方案在保证会话保持能力的同时，通过 Sidecar 资源配置和 Passthrough 流程优化，显著降低 Istio Sidecar 的资源占用。

适用场景：

有状态服务需要会话保持

MCP Server 等长连接服务

多轮对话 AI 应用

需要客户端与特定后端 Pod 绑定的业务

一、问题背景

1.1 Istio Sidecar 资源占用问题

Istio 控制平面（istiod）默认将集群内所有服务发现信息下发至每个 Sidecar（Envoy），包括：

所有 Service 的 ClusterIP 和端口配置

所有 Endpoint（Pod IP）信息

VirtualService、DestinationRule 等路由规则

在 Knative 环境中，每个 Knative Service 会创建多个 Kubernetes Service（public、private 等），导致服务数量膨胀。同时，Knative 的自动伸缩特性使 Endpoint 频繁变化，进一步加剧配置下发压力。

典型表现：

Sidecar 内存占用达数十至数百 MB

配置下发延迟增加

istiod 和 Envoy 的 CPU 消耗上升

1.2 Passthrough 模式下会话保持失效

为降低资源占用，可启用 Passthrough 流程，使 Envoy 直接转发请求而不依赖 Endpoint 信息。但 Passthrough 模式下，Envoy 的 stateful_session filter 无法正常工作，原因如下：

stateful_session filter 解析 Cookie 后设置目标 Pod 地址

Passthrough 流程忽略 filter 设置的地址，直接使用原始目标 IP

会话亲和性失效

二、解决方案架构

2.1 核心思路

利用 Passthrough 模式支持 x-envoy-original-dst-host Header 的特性，通过 WASM 插件将 Cookie 中的会话信息转换为该 Header，实现会话保持。

2.2 组件职责

组件	职责
Sidecar 资源	限制 Envoy 配置下发范围，降低资源占用
EnvoyFilter (stateful_session)	首次请求时在响应中设置 Cookie，编码目标 Pod 地址
EnvoyFilter (use_http_header)	启用 PassthroughCluster 的 Header 路由能力
WASM Plugin	解析 Cookie 并设置 `x-envoy-original-dst-host` Header
ConfigMap (config-network)	关闭 mesh 兼容模式，启用 Passthrough 流程
ConfigMap (config-autoscaler)	确保请求始终经过 Activator

2.3 请求流程

首次请求：

请求到达 Activator 的 Envoy Sidecar

WASM Plugin 检测到无会话 Cookie，不做处理

stateful_session filter 通过负载均衡选择目标 Pod

响应中设置 Cookie，编码目标 Pod 地址

后续请求：

请求携带会话 Cookie 到达 Envoy

WASM Plugin 解析 Cookie，提取目标 Pod 地址

WASM Plugin 设置 x-envoy-original-dst-host Header

PassthroughCluster 读取 Header，将请求路由至指定 Pod

三、配置实施

3.1 前置条件

Kubernetes 集群已部署 Istio

已安装 Knative Serving

Activator 已启用 Istio Sidecar 注入

启用 Sidecar 注入：

3.2 创建 Placeholder Service

用于 Sidecar 资源的 egress 配置，确保基本网络通信。

3.3 配置 Sidecar 资源

限制 Activator Sidecar 的 egress 范围，仅保留必要的服务配置。

3.4 配置 EnvoyFilter

3.5 配置 WASM Plugin

3.6 修改 Knative ConfigMap

config-network：

config-autoscaler：

四、原理详解

4.1 Sidecar 资源优化原理

默认配置下，istiod 向每个 Sidecar 下发全量服务配置：

配置 Sidecar 资源后：

效果：

配置体积从 MB 级降至 KB 级

内存占用显著下降

配置下发延迟降低

4.2 Passthrough 流程原理

标准流程（需要 Endpoint 信息）：

Passthrough 流程（不需要 Endpoint 信息）：

4.3 会话保持实现原理

stateful_session filter 的 Cookie 编码：

Cookie 值包含目标 Pod 的地址信息，格式为 Base64 编码的地址字符串。

WASM Plugin 的作用：

PassthroughCluster 的 use_http_header 配置：

当 use_http_header: true 时，PassthroughCluster 优先使用 x-envoy-original-dst-host Header 中的地址作为目标，而非原始请求目标。

五、验证方法

5.1 检查 Sidecar 注入状态

预期输出包含 activator 和 istio-proxy 两个容器。

5.2 检查配置资源状态

5.3 验证会话亲和性

5.4 检查 Sidecar 配置体积

配置优化后，输出体积应显著减小。

六、注意事项

target-burst-capacity 设置：必须设置为 -1，确保所有请求经过 Activator，否则直接路由至 Pod 的请求无法获得会话保持能力。

Cookie 有效期：EnvoyFilter 中的 ttl 配置决定会话保持时长，根据业务需求调整。

WASM Plugin 镜像：确保集群可访问配置的镜像仓库地址。

Sidecar egress 配置：如需访问其他服务，需在 Sidecar 资源的 hosts 列表中添加。

故障恢复：当目标 Pod 不可用时，stateful_session filter 会自动选择新的 Pod 并更新 Cookie。

Knative Service 多版本管理指南

深度学习模型架构解析：以Encoder-Decoder为核心的分类体系