关于容器:Armada|如何使用Kubernetes在数千个计算节点上运行数百万个批处理作业

9次阅读

共计 2505 个字符,预计需要花费 7 分钟才能阅读完成。

10 人将获赠 CNCF 商店 $100 美元礼券!

你填了吗?

问卷链接(https://www.wjx.cn/jq/9714648…)


客座文章作者:G-research 计算平台工程经理 Jamie Poole。博文最后在 G -research 的博客上发表

在过来的几年中,咱们曾经将越来越多的工作负载迁徙到 Linux 上的容器中。一种对咱们来说十分重要的非凡类型的工作负载是运行到实现的批处理作业。咱们的大部分业务应用大型计算网格来执行分布式数据迷信和数值解决——在大型、嘈杂的真实世界数据集中寻找模式。直到最近,咱们次要是应用运行在 Windows 上的 HTCondor 来实现这一点。

迁徙到 Linux 和容器,咱们有机会从新评估咱们想要如何去做这件事。咱们尝试在 Condor 和 Linux 上运行容器化作业,但在去了一遍巴塞罗那的 KubeCon,并与其余一些钻研机构进行了交谈后,咱们感觉应用 Kubernetes 能够做得更好。咱们曾经在 Kubernetes 上运行了许多服务,因而领有一个具备 Kubernetes 所带来的所有操作和性能劣势的逻辑计算平台是很有吸引力的。

很显著,原味的 Kubernetes 不能满足咱们的用例。咱们有一个大型的、固定的 on-prem 计算池,Condor 模型的长处之一是,你能够提交比你的基础设施一次解决的更多的作业,多余的作业在内部排队,并应用偏心共享零碎进行优先级排序。咱们曾经晓得 Kubernetes 是容器编排的最佳种类,但在适度供给时,它不足对作业进行排队或偏心调度的能力。如果咱们可能启用这些额定的个性,咱们是否可能将 Kubernetes 也用于批处理作业基础架构,并为所有计算提供一个繁多的逻辑平台?

咱们开始了一个外部试验,命名为 Armada。咱们有一些要害的架构准则要恪守:

  • 编写一些软件来增加排队和偏心共享,而不须要批改 Kubernetes 自身。让 Kubernetes 来做节点调度和容器生命周期治理的艰辛工作。
  • 反对多个集群,这样咱们就能够超过单个 Kubernetes 集群的限度,并取得多个集群的操作劣势。咱们的指标是运行一个由数千台服务器组成的机队。
  • 应用基于拉的模型来取得工作,让咱们更容易扩充规模

此外,咱们从一开始就心愿它是开源的。咱们曾经从开源技术中受害越来越多,尤其是 Kubernetes 自身。咱们认为,如果咱们可能生产出一些货色来解决咱们的问题,那么它很可能会对其他人有用,这可能是一个很好的机会来回馈咱们正在从中受害的生态系统。咱们没有太多建设绿地开源我的项目的教训,所以简略地在 GitHub 上开始,以确保咱们可能分享它。

咱们很快就产生了一个概念验证,并有了一个应用程序,咱们能够在 AWS 中应用它来证实 Kubernetes 可能在多个集群(每个集群有数百个节点)上运行数万个作业。重要的是,咱们可能证实,只有咱们在内部解决排队,Kubernetes 不须要进行任何非凡的调优,就能够解决数千个容器的启动和进行。

那么它是如何工作的呢?

Armada 的设计很简略。有一个地方服务器组件,用于存储要为不同用户或我的项目运行的作业队列。它负责保护整个零碎的状态。它有一个 API,容许客户端以 Kubernetes pod 标准的模式提交作业,还能够监督作业的进度或勾销作业。

在这上面,咱们有一个 executor 组件,它能够部署到任何给定的 Kubernetes 集群中,容许查看集群并发现有多少资源(例如 CPU/GPU/ 内存)可用。它定期与服务器组件分割并租用要运行的作业,而后在本地创立 pod,将进度报告给服务器组件。作业实现后,将清理 pod,并为下一个作业提供空间。

缩放能够在二维程度进行。咱们能够在专用的 executor 集群中减少节点,也能够依据须要减少更多的 executor 集群。因为应用基于拉的办法来租赁作业,咱们能够轻松地增加或删除 executor 集群,而无需更改任何配置。

咱们学到了什么?

依据咱们的教训,咱们曾经验证了 Kubernetes 能够作为咱们的计算场的计算基板的假如。它并不是齐全一帆风顺的,在这个过程中咱们遇到了一些乏味的边缘状况和问题。其中一些只是迁徙到 Linux 和容器,不可避免地发现咱们的代码在人不知; 鬼不觉中依赖于 Windows 操作系统及其生态系统。其余的是 Kubernetes 自身的问题,咱们发现这些问题通常是由社区来解决的(例如:https://github.com/kubernetes/kubernetes/pull/90530——在应用动态 CPU 管理器时修复集群的适度调配)。这类事件自身就是一种验证——通过应用 Kubernetes,咱们继承了所有社区的反对和我的项目的能源。

下一部

咱们的环境正在增长,随着批处理工作负载迁徙到 Linux,咱们有了一个牢靠的、可扩大的平台来运行它们。G-Research 中的 Kubernetes 是在 OpenStack 上提供的,咱们能够从新提供现有的硬件,将其增加到 OpenStack 计算池中,以供 Kubernetes 应用。随着更多的工作负载迁徙,看到环境的规模不断扩大是令人兴奋的。当初咱们曾经验证了平台的运行稳定性,咱们想把重点放在可用性上。咱们为用户设计了一个简略的 UI,使用户可能更容易地可视化他们的工作在零碎中的流动,同时也使管理员更容易地从整体上了解零碎。咱们正在努力提高平台部署的自动化水平,尽可能让零碎在部署后就能够“失常工作”。

咱们欢送你本人看看,尝试一下,并感激任何反馈:https://github.com/G-Research/armada

如果你想退出咱们的团队并与咱们一起在很酷的我的项目工作,G-Research 在英国和咱们的近程 GR 开源组总是在招聘有能力的开发者。

点击浏览网站原文。


CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月,隶属于 Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培养和保护一个厂商中立的开源生态系统,来推广云原生技术。咱们通过将最前沿的模式民主化,让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。

正文完
 0