2. Trigger 核心数据结构
Knative Eventing 的 Trigger CRD 是事件从 Broker 路由到特定订阅者的核心策略载体。理解 Trigger 的 Spec（期望状态）与 Status（实际状态）字段，是排查事件丢失、路由错误、订阅失效等故障的基础。本节将逐字段解析其数据结构，并揭示这些字段如何驱动控制面的通信逻辑。
2.1 Trigger Spec：声明事件路由规则
Trigger 的 spec 定义了“谁的事件（过滤器）”应该被发送到“哪个消费者（订阅者）”。以下是核心字段及其作用：
| 字段 | 类型 | 说明 | 控制面映射 |
|---|---|---|---|
broker |
string | 指定该 Trigger 关联的 Broker 名称。Trigger 只能从该 Broker 接收事件。 | Broker 控制器通过此字段将 Trigger 注册到对应 Broker 的内部路由表。 |
filter |
TriggerFilter | 定义事件过滤条件。支持基于 CloudEvent 属性的精确匹配（如 type、source）。 |
Broker 的 ingress 或过滤器组件根据此字段决定是否将事件投递到订阅者。 |
subscriber |
SubscriberSpec | 定义事件的目标接收者（如 Service、Channel、URI）。 | 控制面解析此字段，创建或更新内部的 HTTP 路由规则，将事件流量转发至目标地址。 |
delivery |
DeliverySpec | 可选字段，配置重试策略、死信队列（DLQ）、超时等投递保障。 | 控制面将投递配置注入到订阅者的 Sidecar 或代理中，影响事件投递行为。 |
故障排查要点： 当事件未到达预期目标时，首先检查 Trigger 的
spec.subscriber.uri 或 spec.subscriber.ref 是否指向一个可解析且处于 Ready 状态的资源。错误的订阅者引用是控制面通信失败的最常见原因之一。
2.2 Trigger Status：反映控制面协调结果
Trigger 的 status 字段由 Knative Eventing 控制面组件（如 trigger-controller 和 broker-controller）持续更新，用于反映当前 Trigger 在控制面中的实际状态。它是故障诊断的第一手信息来源。
| 字段 | 类型 | 说明 | 故障排查价值 |
|---|---|---|---|
status.conditions |
[]Condition | 一组标准化的状态条件，如 Ready、BrokerReady、SubscriberResolved、DependencyReady。 |
查看 Ready 条件是否为 True。若为 False，Reason 和 Message 字段会直接指出问题（如订阅者未就绪、Broker 不存在）。 |
status.subscriberUri |
string | 控制面解析 spec.subscriber 后得到的最终可访问 URI。 |
如果此字段为空或与预期不符，说明订阅者解析失败。这是控制面通信链路断裂的直接证据。 |
status.observedGeneration |
int64 | 控制器最后观察到的 Trigger 的 metadata.generation。 |
如果 observedGeneration 小于 generation，说明控制器尚未处理最新的 Spec 变更，路由规则可能仍为旧配置。 |
诊断命令示例：
该命令可快速查看所有条件状态，定位哪个环节阻塞了 Trigger 变为 Ready。
kubectl get trigger <trigger-name> -o jsonpath='{.status.conditions}' | jq .该命令可快速查看所有条件状态，定位哪个环节阻塞了 Trigger 变为 Ready。
2.3 Spec 与 Status 如何映射到控制面通信
Trigger 的 Spec 和 Status 并非静态配置，它们通过 Knative Eventing 控制面的多个组件协同工作，驱动着事件从 Broker 到订阅者的通信链路。下图展示了这一映射关系：
2.4 控制面通信的完整流程
基于上述数据结构，Trigger 从创建到生效的控制面通信流程可概括为以下步骤：
- 用户提交 Trigger CR：用户通过
kubectl apply或 API 创建一个包含spec的 Trigger 对象。 - Trigger Controller 监听：
trigger-controller监听到新 Trigger 创建事件，开始协调。 - 解析订阅者：控制器解析
spec.subscriber，通过 Kubernetes API 查找引用的资源（如 Service），获取其可访问的 URI，并写入status.subscriberUri。 - 注册到 Broker：控制器将 Trigger 的过滤规则和订阅者 URI 注册到关联 Broker 的内部路由表或过滤器链中。
- 更新 Status：控制器更新 Trigger 的
status.conditions，将Ready条件置为True，表示路由规则已生效。 - 事件路由：当事件到达 Broker 时，Broker 的 ingress 组件根据路由表匹配 Trigger 的过滤器，将事件转发至对应的订阅者 URI。
常见故障模式： 如果步骤 3 中订阅者解析失败（例如引用的 Service 不存在或未就绪），
status.subscriberUri 将为空，且 SubscriberResolved 条件为 False。此时控制面通信链路中断，事件无法路由。排查时应优先检查 kubectl get trigger <name> -o yaml 中的 Status 字段。
2.5 关键字段与故障排查的对应关系
下表总结了 Trigger 核心字段在故障排查中的直接应用：
| 故障现象 | 应检查的字段 | 预期正常值 | 异常时的可能原因 |
|---|---|---|---|
| 事件未到达订阅者 | status.subscriberUri |
非空，且为可访问的 HTTP(S) 地址 | 订阅者资源未就绪、名称错误、命名空间不匹配 |
| Trigger 一直处于未就绪状态 | status.conditions[?(@.type=="Ready")].status |
True |
Broker 未就绪、依赖资源缺失、过滤器语法错误 |
| 路由规则未更新 | status.observedGeneration vs metadata.generation |
两者相等 | 控制器未处理最新变更，可能因控制器重启或资源竞争 |
| 事件被错误过滤 | spec.filter.attributes |
与 CloudEvent 属性精确匹配 | 过滤器属性拼写错误、大小写敏感问题、空值导致匹配失败 |