【问题标题】:Kubernetes Queue with Pod Per Work Item autoscaling具有 Pod 每个工作项自动缩放的 Kubernetes 队列
【发布时间】:2019-06-21 21:44:17
【问题描述】:

我希望应用程序从队列中拉出一个项目,处理队列中的项目,然后自行销毁。拉 -> 处理 -> 销毁。

我已经研究过将作业模式 Queue 与 Pod Per Work Item 一起使用,因为它适合用例,但是当我需要作业在队列为空并缩放到某个点时自动缩放 aka 0/1 pods 时,它是不合适的添加项目时。我能看到这样做的唯一方法是通过部署,但这消除了每个工作项的 Queue with Pod 模式。每件商品必须有一个新鲜的容器。

有没有办法让作业模式队列与每个工作项的 Pod 但具有自动缩放功能?

【问题讨论】:

  • The only way I can see doing this is via a deployment but that removes the pattern of Queue with Pod per Work Item.这是你的痛点吗?您想确保 pod 只处理一条消息然后自行销毁吗?如果是这样,那么您可以通过仅获取一项并在您的代码中相应地退出来实现这一点。
  • 部署中的 pod 会成功(完成并销毁)并创建一个新的 pod 来代替它吗?保持在我可以用来扩大和缩小规模的副本数量范围内?
  • 如果 pod “成功”退出,我看不出它为什么会被 K8s 重新启动。我不明白你的第二个实例,对不起。

标签: kubernetes


【解决方案1】:

我有点困惑,所以我就这么说吧:如果你不介意失败的 pod,并且希望 Kubernetes 不会重新创建失败的 pod,你可以在你的代码中通过 catch所有错误并正常退出(不建议)。 另请注意,对于部署,唯一接受的 restartPolicy 始终是。因此,崩溃的部署的 pod 将始终由 Kubernetes 重新启动,并且可能由于相同的原因而失败,从而导致 CrashLoopBackOff

如果您想根据 RabbitMQ 队列的长度来扩展部署,请查看KEDA。它是一个事件驱动的自动缩放平台。 确保还使用RabbitMQ查看他们的示例

另一种可能性是作业/部署,它会定期检查相关队列的长度并执行kubectl 命令来扩展您的部署。 Here 是我能找到的最干净的,至少对我来说是这样

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-03-09
    • 2021-01-26
    • 2019-08-07
    • 1970-01-01
    • 2021-06-10
    • 2014-11-19
    • 2017-05-20
    • 1970-01-01
    相关资源
    最近更新 更多