Kubernetes 动态作业扩展

Posted 2023-02-16

【中文标题】Kubernetes 动态作业扩展

【英文标题】：Kubernetes dynamic Job scaling

【发布时间】：2019-01-02 20:55:17

【问题描述】：

我终于开始涉足 kubernetes 池，并希望获得一些关于解决我遇到的问题的最佳方法的建议：

我们正在使用的技术：

GCP GKE GCP 发布/订阅

我们需要在整个车队中进行批量处理，并决定采用以下方法：

新的原始数据流入 一个节点对此进行分析并将数据分解为可管理的部分，这些部分被推送到队列中 我们有一个启用 Autoscaling 且最小大小为“0”的集群 Kubernetes 作业为该集群上的每条新消息启动一个 pod 当 pod 无法再提取消息时，它们会成功终止

问题是：

触发此类作业的标准方法是什么？ 您是否每次都创建一个新工作，或者工作是否意味着长期存在并重新运行？ 我只看到了使用 yaml 文件的示例，但是我们可能希望分担工作的节点来创建作业，因为它知道应该运行多少个并行 pod。是否建议使用 python sdk 以编程方式创建作业规范？或者，如果工作寿命很长，您是否只需点击 k8 api 并修改所需的并行 pod，然后重新运行工作？

【问题讨论】：

这是一个有点通用/设计问题恕我直言，通常不符合关于 SO 的问题标准。您必须提出一些具体问题并展示您为获得帮助所做的工作。

很抱歉，这种架构太糟糕了。您正在尝试使用非常昂贵且矫枉过正的基础设施进行编码。在您的管道中采用 kafka 可以轻松解决您的数据管道问题。流服务 -> kafka-consumer -> kafka-broker -> Multiple-kafka-consumers -> kafka-producer -> 任何你想要的地方.

@RodrigoLoza：你的回答是非常消极的。此外，您的建议是高度自以为是的，既不是正确也不是错误，它只是众多潜在解决方案中的一个，在这方面似乎没有任何显着优势案例。

我同意，有十亿种方法可以解决您的问题。构建您的应用程序并亲自检查一下。大多数公司采用这条管道是有原因的。

设计很大程度上取决于以下几点：需要并行运行多少作业？你能承受多大的延迟（你是否需要让工作尽可能快地运行并返回结果）？一项工作通常需要多长时间（是否需要毫秒、秒、分钟？） 上下旋转 pod 不是瞬时的，如果您的工作需要几分钟，这是一个选择，但如果您的工作运行时间少于几秒，为每个作业旋转一个 k8s 作业最终会慢得多。您是否查看过 Cloud Functions 的工作负载？它们为您承担所有调度/扩展的负担，但它有一些延迟。

【参考方案1】：

Kubernetes 中的作业是短暂的，并非旨在重复使用。作业专为运行一次、运行到完成的工作负载而设计。通常他们被分配一个特定的任务，即处理单个队列项。

但是，如果您想使用单个实例处理工作队列中的多个项目，则通常建议改为使用部署来扩展继续处理队列中项目的工作人员池，从而扩展池的数量工作人员取决于队列中的项目数。如果没有剩余的工作项，那么您可以将部署扩展为 0 个副本，当有工作要做时再扩展。

要在 Kubernetes 中创建和控制您的工作负载，最佳做法是使用 Kubernetes SDK。虽然您可以使用 SDK 生成 YAML 文件并转至 kubectl 等其他工具，但它简化了配置和错误处理，并且还允许简化集群中资源的自省。