如何获取挂载至Kubernetes的AWS EBS卷的文件变更通知

首先明确核心前提：EBS是块存储服务，没有EFS、S3这类托管存储的原生文件事件推送能力，所有可落地的检测方案都围绕挂载点层面的操作捕获、周期性元数据比对两个核心思路展开，不存在AWS侧直接推送EBS文件变更的原生能力。

可落地的技术路径 #

• Pod内sidecar + Linux内核inotify钩子方案
  这是和K8s工作流适配度最高的实时检测方案。实现方式为在挂载了EBS持久卷的业务Pod内新增一个轻量sidecar容器，直接复用Linux内核原生的inotify接口，对EBS卷的本地挂载目录做递归监听，捕获目录下文件的新增、删除、修改、移动四类核心变更事件，再将事件信息（文件路径、变更类型、操作时间、关联Pod标识）投递到下游系统。
  典型的监听命令可参考：
  inotifywait -m -r -e create,delete,modify,move /path/to/ebs-mount | while read path action file; do 事件上报逻辑; done
  适用场景：需要实时检测、对检测隔离性要求高的工作负载。优点是检测逻辑随Pod调度自动漂移，不会因为节点重调度漏报，权限边界清晰不会误采集节点上的无关文件；缺点是每个Pod加sidecar会产生固定的资源开销，这里要注意，默认的inotify watch阈值通常只支持监控几万个文件，如果监控目录下文件总量超了，一定要提前调整节点的fs.inotify.max_user_watches内核参数，不然会静默丢事件，是这类方案最常见的踩坑点。

• 节点级DaemonSet + eBPF旁路检测方案
  适合节点上运行大量挂载EBS卷的工作负载的集群。实现方式为部署DaemonSet到所有可调度EBS卷的节点，通过内核态eBPF程序捕获所有文件系统操作，再通过路径规则过滤出EBS卷挂载目录对应的操作事件，统一汇聚到集群内的审计中心。实际落地不用从零开发eBPF探针，直接复用现有成熟开源组件的预定义文件操作捕获规则即可，能减少大量开发和调试成本。
  适用场景：需要降低检测开销、覆盖全节点所有EBS卷变更的场景。优点是资源开销远低于逐Pod加sidecar，不受inotify watch数量的阈值限制，还能捕获到绕过业务容器的手动文件操作（比如exec进容器直接修改文件的行为）；缺点是要求节点内核版本支持eBPF特性，需要精细配置路径过滤规则，避免把系统目录的操作误判为EBS卷变更。

• 周期性元数据快照比对方案
  适合不需要实时检测、仅需要定期审计卷上变更的场景。实现方式为部署独立的审计Pod，按固定周期临时将目标EBS卷以只读模式挂载到审计Pod上，全量扫描卷上的文件元数据（文件路径、大小、修改时间、inode编号），和上一次留存的快照做差异比对，输出周期内的新增、删除、修改文件清单。
  注意：非Multi-Attach类型的EBS卷不支持跨节点同时挂载，这类场景下的审计操作需要在业务低峰期临时释放业务Pod的卷挂载，扫描完成后再重新挂载回去；开启Multi-Attach的EBS卷可以直接和业务Pod并行做只读扫描，不影响业务运行。实际扫描时别全从卷的根目录开始遍历，很多临时缓存、系统类文件占了大量空间，把扫描范围限定到业务实际使用的目录，扫描效率会提升一个量级。
  适用场景：合规审计、周期性数据校验类需求。优点是对业务运行完全无运行时性能影响，检测逻辑独立不受业务进程干扰；缺点是有检测周期的延迟，大容量卷的全量扫描耗时较长。

常见思路的可行性说明 #

• 关于Lambda+SNS的联动路径：EBS本身没有原生文件事件，无法直接触发Lambda，但Lambda可以作为检测链路的下游处理节点——不管是inotify、eBPF还是离线扫描生成的变更事件，都可以先投递到SNS主题，再触发Lambda完成后续流程（比如生成告警、写入审计数据库、触发增量备份），这套链路是完全可落地的。
• 关于SQL查询的检测路径：如果业务应用和EBS卷上的文件是强绑定关系（比如业务系统把EBS作为附件存储，数据库里存了所有合法文件的元数据），可以通过定时比对数据库记录的文件清单和卷上实际的文件列表，发现绕过业务接口的异常变更（比如手动新增未入库的文件、手动删除已有业务记录的文件）。这种方案仅能覆盖和业务逻辑关联的文件，无法捕获卷上所有零散的文件变更。

落地注意事项

• 不要尝试在云平台侧通过解析EBS块设备的扇级IO来识别文件变更，该方式的性能开销极高、解析可靠性极差，远不如在挂载点层面做检测的落地效率。
• 如果是Windows容器场景，可替换为Windows系统原生的ReadDirectoryChangesW API实现同样的文件变更捕获能力，逻辑和Linux下的inotify完全一致。
• 实时检测的事件上报逻辑需要做幂等处理，避免文件连续修改产生的高频重复事件冲击下游系统。

内容的提问来源于stack exchange，提问作者hevi