我将Sails.js用于API，该API是从Google Cloud kubernetes集群中的Dockerfile部署的，并通过3-5个Pod扩展工作负载。该API提供的端点可以上传单个图像文件和较大的zip文件，这些文件可以直接从当前API窗格/实例中提取。
单个图像文件和提取的存档内容（100-1000个文件，共包含15-85mb的内容），我必须上载到各个存储分区。这是redis kue发挥作用的地方。为了确保API不会太长时间阻止上传请求，我创建了延迟的kue作业，将所有上传的文件和文件夹移动到存储桶或链作业，并首先借助ImageMagick创建缩略图。
所有这些可能要花费一些时间，具体取决于集群当前的工作量，有时更多，有时更少。
所有这些对于单个实例都可以很好地工作，但是在集群中却是另一回事。由于该API的kubernetes实例可以在请求之间更改，因此上传可以降落在实例 A 上，但是文件的作业由实例 B 处理和处理。 （工作程序以及API本身都在同一实例上运行！），可能没有可用的上传文件，导致失败的工作。
Google需要花费一些时间来保持Pod同步，并将上传的内容分散到所有其他Pod。
我尝试过的是：
由于当前容器的名称可通过env变量 HOSTNAME 获得，因此我将 HOSTNAME 与所有kue作业一起存储，并在工作程序中检查作业中的> HOSTNAME 与当前环境的HOSTNAME匹配，并且仅在两个HOSTNAME都匹配时才允许处理作业。
需要尽快提供上载；为什么我不能增加几分钟的工作延迟，并希望在处理工作之前，Google已同步其pod。
与HOSTNAME不匹配的待处理作业，我推回队列并为其添加延迟。
我想要的是一个队列，该队列不必照顾主机名和条件检查即可成功地在我的集群中处理其作业。
答案 0 :(得分：0)
对于这个“ 可能没有可用的上传文件导致失败的工作”，您可以考虑使用“ Persistent Volumes ”。
在这种情况下，您的工作可以独立进行，以将提取的存档内容查找到共享存储中。
希望此帮助。请分享您的发现。