首页 > 解决方案 > 在多个 kubernetes pod/实例中处理 Redis KUE 作业

问题描述

我将 Sails.js 用于 API,我从 Google Cloud kubernetes 集群中的 Dockerfile 部署该 API,并使用 3-5 个 Pod 扩展工作负载。API 提供端点来上传单个图像文件和更大的 zip 文件,我直接在当前 API pod/实例上提取这些文件。

无论是单个图像文件还是提取的存档内容(100-1000 个文件,总共 15-85mb 的内容),我都必须上传到各种存储桶。这就是 redis kue 发挥作用的地方。为了确保 API 不会长时间阻止上传请求,我创建了延迟的 kue 作业以将所有上传的文件和文件夹移动到存储桶或链作业,并首先在 ImageMagick 的帮助下创建缩略图。

所有这些都可能需要一些时间,具体取决于集群的当前工作负载,有时更多,有时更少。

所有这一切都适用于单个实例,但在集群中,情况就不同了。由于 API 的 kubernetes 实例可以从请求到请求发生变化,因此上传可以在实例A上进行,但文件的作业正在由实例B处理和处理(worker 以及 API 本身都在同一个实例!),它可能没有可用的上传,从而导致作业失败。

Google 需要时间来保持 pod 同步并将上传内容传播到所有其他 pod。

我尝试过的是以下内容:

由于当前 pod 的名称可通过 env 变量HOSTNAME获得,因此我将HOSTNAME与所有 kue 作业一起存储,并在工作人员中检查作业中的HOSTNAME是否与当前环境的 HOSTNAME 匹配并且只允许处理作业如果两个主机名都匹配。

需要尽快上传;为什么我不能添加几分钟的作业延迟,并希望在处理作业时,Google 已经同步了它的 pod。

与主机名不匹配的待处理作业,我推回队列并添加延迟。

我想要的是一个队列,它不需要处理主机名和条件检查来成功处理它在像我这样的集群中的作业。

标签: node.jskubernetesredissails.jskue

解决方案


对于这个“可能无法提供导致作业失败的上传”,您能否考虑使用“持久卷”。

在这种情况下,您的工作可以独立工作,将提取的存档内容查找到共享存储中。

希望这有帮助。请分享您的发现。


推荐阅读