3. Serverless 控制面概念：Knative Serving 与 Eventing 控制面架构、与 Istio 的集成点
在 Serverless 架构中，控制面是管理函数/服务生命周期、流量路由、事件分发和自动伸缩的核心大脑。Knative 作为 Kubernetes 原生的 Serverless 框架，其控制面由 Serving 和 Eventing 两个子系统构成。Istio 在其中扮演了统一的南北向与东西向流量安关的角色。本章将深入剖析这两个控制面的架构组件，并明确它们与 Istio 的集成边界。
3.1 Knative Serving 控制面架构
Knative Serving 控制面负责管理 Serverless 工作负载的版本化部署、流量路由和自动缩零（Scale-to-Zero）。其核心组件均以 Kubernetes CRD 和控制器形式运行。
核心概念： Knative Serving 控制面不直接管理 Pod，而是通过
Revision（不可变快照）和 Configuration（期望状态）来驱动 Deployment 的创建与更新。
3.1.1 控制面核心组件
| 组件（CRD / Controller） | 职责 | 与 Istio 的交互点 |
|---|---|---|
| Service (ksvc) | 用户入口，管理 Route 与 Configuration 的生命周期 | 自动创建 Istio VirtualService 和 Gateway |
| Route | 定义流量在多个 Revision 之间的分配规则（百分比、标签） | 更新 Istio VirtualService 的 HTTPRoute 规则 |
| Configuration | 维护期望的 Revision 模板（镜像、环境变量、资源限制） | 无直接交互，但 Revision 创建后触发 Istio 注入 |
| Revision | 不可变的部署快照，对应一个 Deployment 和 KPA（Pod 自动伸缩） | Pod 注入 Istio Sidecar（Envoy），受 PeerAuthentication 约束 |
| Activator | 处理缩零后的冷启动请求，缓冲流量并唤醒 Revision | 作为 Istio 网格内的一个特殊 Service，接收并转发请求 |
| Queue-Proxy | 每个 Revision Pod 内的伴生容器，负责并发控制与负载上报 | 与 Envoy Sidecar 协作，实现请求排队与指标采集 |
3.1.2 Serving 控制面与 Istio 的集成点
Knative Serving 通过 net-istio 插件与 Istio 深度集成。该插件是一个 Knative 网络层实现，负责将 Knative 的 Route 和 Service 资源翻译为 Istio 的流量管理配置。
- Gateway 管理： Knative 控制面自动创建
knative-local-gateway（集群内部）和knative-ingress-gateway（外部）两个 Istio Gateway，用于区分内部流量与外部流量。 - VirtualService 动态更新： 当 Route 的流量比例变更或新 Revision 上线时，Knative 控制面会立即更新对应的 Istio VirtualService，实现灰度发布和蓝绿部署。
- mTLS 自动适配： Knative 控制面会读取 Istio 的
PeerAuthentication策略，并自动调整 Activator 与 Revision 之间的通信模式（STRICT / PERMISSIVE）。
3.2 Knative Eventing 控制面架构
Knative Eventing 控制面负责事件的生产、路由、过滤和交付。它通过一组 Broker 和 Trigger 资源，将事件从 Source 传递到对应的 Service 或 Function。与 Serving 不同，Eventing 控制面更关注事件流拓扑而非流量比例。
3.2.1 控制面核心组件
| 组件（CRD / Controller） | 职责 | 与 Istio 的交互点 |
|---|---|---|
| Broker | 事件网格的入口，负责接收事件并路由到对应的 Trigger | Broker Pod 注入 Envoy，接收来自 Istio 网格内的事件流量 |
| Trigger | 定义事件过滤规则（类型、来源、属性）和交付目标（Subscriber） | 无直接 Istio 资源操作，但 Subscriber 通常是 Knative Service 或 k8s Service |
| Channel | 事件缓冲与持久化层（如 InMemoryChannel、KafkaChannel） | Channel Pod 注入 Envoy，实现跨集群事件传输的 mTLS 加密 |
| Subscription | 将 Channel 与 Subscriber 绑定，定义事件交付链路 | 依赖 Istio 的 ServiceEntry 实现跨命名空间或跨集群事件路由 |
| Source | 事件生产者（ApiServerSource、PingSource、KafkaSource 等） | Source Pod 注入 Envoy，通过 Istio 的 Egress Gateway 访问外部事件源 |
| Eventing Controller | 协调所有 Eventing CRD 的状态，管理事件通道的后端资源 | 通过 Kubernetes API 读取 Istio 配置，但不直接修改 VirtualService |
3.2.2 Eventing 控制面与 Istio 的集成点
Eventing 与 Istio 的集成相对 Serving 更为间接，主要集中在数据面的安全通信和跨网络事件路由上。
- Broker 的 Envoy 注入： Broker 的 Pod 默认开启 Istio Sidecar 注入，确保所有进入 Broker 的事件流量都经过 mTLS 加密和身份验证。
- 跨命名空间事件路由： 当 Trigger 的 Subscriber 位于不同命名空间时，Eventing 控制面依赖 Istio 的
ServiceEntry和VirtualService来打通网络路径。 - 事件源的外部访问： 对于 KafkaSource 或 GCP PubSub Source 等外部事件源，Eventing 控制面通过 Istio 的
Egress Gateway实现可控的外部访问，并应用出口流量策略。
安全集成要点： 在 Eventing 场景下，Istio 的
AuthorizationPolicy 可以精确控制哪些 Source 可以发送事件到哪个 Broker，以及哪些 Trigger 可以订阅哪些事件类型。这是实现事件网格零信任安全的基础。
3.3 Serving 与 Eventing 控制面集成对比
下表从控制面职责、Istio 资源操作方式、安全策略作用域三个维度对比两个子系统的集成差异：
| 对比维度 | Knative Serving | Knative Eventing |
|---|---|---|
| 控制面核心 CRD | Service, Route, Configuration, Revision | Broker, Trigger, Channel, Subscription, Source |
| Istio 资源操作 | 自动创建/更新 VirtualService 和 Gateway | 不直接操作 Istio CRD，依赖 Sidecar 注入和 ServiceEntry |
| 流量模型 | 请求-响应（同步），支持百分比灰度 | 事件驱动（异步），支持过滤和扇出 |
| 安全策略作用域 | Revision 级别的 mTLS 和访问控制 | Broker/Channel 级别的事件源身份验证和授权 |
| 冷启动影响 | Activator 缓冲请求，Istio 路由需等待 Revision 就绪 | Broker 常驻，无冷启动，事件持久化在 Channel 中 |
| 跨集群支持 | 通过 Istio Multi-Cluster Gateway 实现 | 通过 Channel 的跨集群实现（如 KafkaChannel） |
常见误区： 不要将 Serving 的流量管理策略（如 VirtualService 权重）直接套用到 Eventing 的 Trigger 过滤规则上。Serving 控制面操作的是 网络层 的流量分发，而 Eventing 控制面操作的是 应用层 的事件路由。两者的安全策略配置入口完全不同。
3.4 集成架构最佳实践
在生产环境中配置 Istio 安全策略时，需要同时考虑 Serving 和 Eventing 两个控制面的特性：
- 统一命名空间策略： 将 Serving 和 Eventing 的资源部署在启用了 Istio 注入的命名空间中，确保所有控制面组件和数据面 Pod 都处于网格内。
- 分离 Gateway 职责： 使用
knative-local-gateway处理集群内部事件流量，使用knative-ingress-gateway处理外部 API 请求，避免事件流量与用户请求流量混合。 - 精细化 AuthorizationPolicy： 为 Broker 和 Knative Service 分别定义授权策略。例如，只允许特定 Source 的 ServiceAccount 向 Broker 发送事件，只允许特定 Trigger 的 Subscriber 接收事件。
- 监控集成点： 重点监控 Istio 的
VirtualService更新频率（Serving 场景）和ServiceEntry的创建情况（Eventing 场景），这些是控制面与 Istio 交互最频繁的边界。