eBPF 程序在内核钩子看到的是事件时刻的进程和内核对象，不会自动附赠“这一定属于 Pod A”的可靠标签。31 的身份链需要把 PID、cgroup、namespace inode、容器 ID 与 Pod UID 在时间窗口内对齐，尤其要考虑容器退出后 PID 被重用。

先判定事件是什么

选择一个自编 probe-app 可控的事件，例如打开自己的状态文件；在 eBPF 程序里采集时间戳、PID/TGID 与 cgroup 标识，在用户态按同一时刻运行时映射关联到容器 ID、Pod UID。权限、内核 BPF 功能和事件丢失都应写进记录。若只装了探针、打印几行带 PID 的事件，却没有证明进程当时属于哪一代容器，就仍是错误归因风险。访问 /proc 获取当前 PID 的属性只能证明读取时的状态，不保证事件发生时该 PID 还属于同一进程。

正例在独立 kind VM 中对自有探针触发一次文件打开，核对事件、实际 PID、cgroup/namespace 与 Pod UID；边界例立即重建同名 Pod，检验新旧事件能否正确分组，即使宿主 PID 以后复用也不能并为一条轨迹。身份字段与版本前提及应用输入可单独获取。本云端未校验 BPF 权限、没有 Pod/CRI/固定探针实现，所有事件归属与重建案例 NOT_RUN。

现象 关键证据 限定条件
已加载 BPF 程序 事件与正确 cgroup/UID 加载不等于归属正确
相同 PID 再出现 进程起始时间、容器 ID PID 可能重用
事件丢失 缓冲区丢弃/采样设置 不能当成程序没执行

练习

  1. 预测同名 Pod 删除重建后，只靠 PID 聚合日志会出现什么误判；关联 Pod UID、进程出生时间核验。
  2. 先预测一条文件打开事件能否推断状态文件已持久化，再对照应用写入结果和卷内容。

先修：26：Pod UID、31：指标归属。下一篇：E04：Windows 容器。

系列总目录：从进程隔离到运行时与编排。

参考资料