Kubernetes Event 是只读审计副产品，非消息总线；手动调用 EventsV1().Create() 创建的 Event 因缺少 ReportingController、OwnerReferences 不合法、不满足 Type/Reason 格式或被 EventRateLimit 拒绝，导致不可见或快速消失。
不能直接用 client-go 的 EventsV1().Create() 向集群“发送通知”——Kubernetes Event 是只读的审计副产品，不是消息总线；你只能创建 Event 对象，但它的生命周期、去重、TTL、聚合全由 kube-controller-manager 控制，且普通用户无法触发广播或推送。
为什么 EventsV1().Create() 创建的 Event 看不到或很快消失
Kubernetes v1.25+ 的 EventsV1 API 要求严格匹配 event.Type（必须是 Normal 或 Warning），且 event.Reason 长度不能超过 128 字符；更重要的是，Event 对象会被 eventttl controller 自动清理（默认 1 小时），且不保证被 kube-eventer 或 tekton-events-controller 捕获——它们监听的是 APIServer 的 watch 流，但只处理由核心控制器（如 scheduler、kubelet）发出的、带合法 ReportingController 和 ReportingInstance 的事件。
- 手动创建的 Event 缺少
ReportingController字段（如kube-scheduler），会被 event aggregator 忽略或降级为 debug 级别 -
event.ObjectMeta.OwnerReferences若未正确指向真实资源（如某个 Pod 或 Deployment），该 Event 将无法在kubectl describe中关联显示 - 集群若启用了
EventRateLimit准入控制器，高频创建会直接被拒绝，返回429 Too Many Requests
真正可用的替代方案：用 Webhook 接收端 + 自定义 sink
如果你的目标是“让告警系统收到某件事发生了”，不要碰 Event API，而是走标准 Webhook 路径：
- 在你的 Golang 服务中用
http.Post()直接调用钉钉/企业微信/Webhook 服务 URL，传入 JSON 格式消息（含namespace、resource、message等字段） - 部署一个轻量 Webhook 接收器（比如用
gin写个 20 行 endpoint），接收你服务发来的 POST，再转发给kube-eventer支持的 sink（如dingtalk:URL） - 如果必须和 Kubernetes 资源绑定，可在自定义资源（CR）的
Status字段里写状态变更日志，然后用controller-runtime的r.Status().Update()提交——这比 Event 更可靠、可查、可追溯
硬要写 Event？必须满足这 4 个条件
仅当你要模拟 kubelet 行为（如开发 CSI 插件或设备插件）才需创建 Event，此时必须：
立即学习“go语言免费学习笔记（深入）”；
- 使用
EventsV1客户端（非已废弃的EventsV1beta1） - 设置
event.ReportingController = "my-device-plugin.example.com"（需提前注册到集群） - 设置
event.ReportingInstance = "node-abc123"（值必须与 Node 名一致） - OwnerReferences 指向一个真实存在的对象，例如：
&metav1.OwnerReference{Kind: "Node", Name: "node-abc123", UID: node.UID}
否则，clientset.EventsV1().Events("default").Create() 调用虽成功，但该 Event 不会出现在 kubectl get events 默认视图里，也不会被任何事件转发器消费。
真正的事件链路从来不是“你发我收”，而是“你改状态 → 控制器感知 → 控制器发 Event → 转发器监听 → 推送”。跳过中间环节，就等于绕开 Kubernetes 的控制平面设计哲学。
