【Tetragon / eBPF】TracingPolicy：CRD、三条加载路径与 collectionKey
内容提要
本文介绍Tetragon v1.7.0的TracingPolicy机制：集群级与命名空间级策略差异、spec字段（含fentries）、三条加载路径共享collectionKey导致同名冲突，以及list/enable/disable语义。v1.7.0中Enable/Disable gRPC默认报错，需用ConfigureTracingPolicy替代。排障时先list确认来源，再删除对侧路径。
延伸解读
同名策略冲突的根源
三条加载路径（CR、gRPC、文件）最终都通过 Manager.AddTracingPolicy 进入同一个 collectionMap，键为 (name, namespace)。这意味着即使你只通过 kubectl apply 了一份 YAML，如果之前通过文件或 gRPC 加载了同名策略，新策略可能被拒绝，因为键已被占用。排障时先使用 tetra tracingpolicy list 确认键的来源，再决定删除哪一侧，而不是盲目重试 apply。
v1.7.0 中 Enable/Disable gRPC 的坑
在 v1.7.0 中，EnableTracingPolicy 和 DisableTracingPolicy 这两个 gRPC 方法默认直接返回错误，除非显式开启 --enable-deprecated-tracingpolicy-grpc 标志。因此，如果旧脚本或文档仍调用这些方法，会失败，但这并非策略 YAML 写错，而是版本行为变更。应改用 ConfigureTracingPolicy 来切换策略的启用状态。
加载失败后的重试逻辑
addTracingPolicy 允许在集合处于 LoadErrorState 时用同键重试加载，但如果集合处于其他状态（如 Enabled 或 Disabled），同键 add 会返回“collection with the key already exists”错误。这解释了为什么修完 YAML 后再次 apply 仍可能失败：旧集合仍占用键，需要先 delete 再重新添加，而不是期望 add 覆盖。
