Pod从同一Persistent Volume读取输入文件并避免重复处理的正确方式

核心结论 #

Kubernetes 本身不会自动帮你避免多个Pod读取同一份待处理文件。
K8s的PV/PVC体系只负责提供共享存储的挂载能力，没有内置针对共享存储内文件的并发访问控制逻辑，两个Pod同时读取、处理同一个文件的问题需要你从应用或架构层面解决。

可行的解决方案 #

下面是几种不同复杂度的实现方案，你可以根据自己的场景选择：

• 应用侧轻量修改（改动最小）
  可以利用文件系统的原子操作避免冲突：每个Pod扫描到待处理文件后，先尝试将文件重命名为带唯一标识的后缀（比如待处理文件名.processing.${POD_UID}，POD_UID可以通过环境变量注入到Pod里），重命名操作在绝大多数主流文件系统中是原子操作，只要重命名成功就代表当前Pod抢到了该文件的处理权，重命名失败就说明该文件已经被其他Pod抢占，直接跳过处理下一个文件即可。
  处理完成后直接删除该临时文件或者移动到归档目录即可，不需要额外引入其他组件。如果担心Pod处理中途异常退出导致文件一直卡在processing状态，可以加个定时逻辑，扫描超过一定时长的processing后缀文件，重置为原文件名重新排队。
• 引入分布式任务队列（稳定性最高）
  把直接扫描PV的逻辑替换成从分布式队列拉取任务：先一次性把所有待处理的文件路径写入队列（比如Redis、RabbitMQ都可以），每个Pod启动后只对接队列拉取任务，队列会保证同一个任务只会被一个消费者获取。
  这种方案的扩展性最好，后续如果需要增加处理Pod的数量完全不需要调整逻辑，也不会出现文件锁遗留的问题，适合待处理文件数量多、需要长期运行的场景。
• 使用K8s原生Job资源（无需改应用）
  如果不想修改现有应用代码，可以把每个待处理文件对应为一个独立的Job任务，设置Job的parallelism参数为2（和你现有Pod数量一致），K8s会保证每个Job只会被调度到一个节点执行，不会出现重复处理的问题。
  这种方案的缺点是如果待处理文件数量非常多，会产生大量Job资源，增加集群管控组件的压力，适合文件量不大的一次性处理场景。
• 使用支持对象锁的存储
  你用的是GKE，也可以直接把输入存储从块/文件存储替换为GCS对象存储，GCS原生支持对象持有锁的能力，处理前先给目标对象加临时锁，处理完成后释放锁，也能避免并发访问冲突。

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