Kubernetes满足高性能计算

编者注:今天的帖子由Univa总经理Robert Lalonde发表,主题是支持混合HPC和容器化应用程序  

与Docker合作的任何人都可以欣赏容器可以实现的效率方面的巨大收益。尽管Kubernetes在协调容器方面表现出色,但是高性能计算(HPC)应用程序在Kubernetes上部署可能会比较棘手。

在本文中,我讨论了使用Kubernetes运行HPC工作负载的一些挑战,解释了当今组织如何应对这些挑战,并提出了一种在共享Kubernetes集群上支持混合工作负载的方法。我们还将提供有关客户IHME案例研究的信息和链接,以显示Kubernetes如何扩展以无缝地为其HPC工作负载提供服务,同时保留HPC用户熟悉的可伸缩性和界面。

HPC工作负载面临的独特挑战

在Kubernetes中,调度的基本单位是Pod:调度到集群主机的一个或多个Docker容器。 Kubernetes假定工作负载是容器。虽然Kubernetes具有以下概念 克伦·乔布斯职位 运行到完成,部署在Kubernetes上的应用程序通常是长期运行的服务,例如Web服务器,负载平衡器或数据存储,并且它们随着Pod的出现而高度动态,但它们与HPC应用程序模式有很大不同。

传统的HPC应用程序通常表现出不同的特征:

  • 在财务或工程仿真中,一项工作可能包含成千上万个短期任务,需要低延迟和高吞吐量的调度才能在可接受的时间内完成仿真。
  • 使用消息传递库来同步状态,可以跨数百甚至数千个节点并行执行计算流体力学(CFD)问题。这需要专门的计划和作业管理功能来分配和启动此类作业,然后检查点,挂起/恢复或回填它们。
  • 其他HPC工作负载可能需要诸如GPU之类的专门资源,或者需要访问有限的软件许可证。组织可以针对谁可以使用哪些类型的资源来实施政策,以确保项目获得足够的资源并按时完成。

HPC工作负载调度程序已经发展为完全支持这些类型的工作负载。例子包括 Univa Grid Engine, IBM Spectrum LSF 和Altair的 PBS专业。管理HPC工作负载的站点已经开始依赖诸如阵列作业,可配置的抢占,基于用户,组或项目的配额以及各种其他功能之类的功能。

混淆容器和HPC之间的界线

HPC用户认为,由于与其他组织相同的原因,容器很有价值。在容器中进行包装的逻辑使其易于携带,不受环境的影响,并易于与其他容器进行交换,这显然具有价值。但是,切换到容器可能很困难。

HPC工作负载通常集成在命令行级别。作业不需要通过编码,而是通过命令行作为二进制文件或充当包装程序的简单shell脚本提交到队列中。实际上,HPC站点使用的数百种工程,科学和分析应用程序都采用这种方法,并且与流行的工作负载调度程序具有成熟且经过认证的集成。

虽然将工作负载打包到Docker容器中,将其发布到注册表中以及提交工作负载的YAML描述的概念是Kubernetes用户的第二天性,但对于大多数HPC用户而言这是陌生的。在R,MATLAB或Stata中运行模型的分析人员只想快速提交其仿真,监视其执行并尽快获得结果。

现有方法

为了应对迁移到容器的挑战,运行容器和HPC工作负载的组织有以下几种选择:

  • 维护独立的基础架构

对于在HPC中有大量投资的站点,这可能是首选方法。与破坏现有环境相比,将新的容器化应用程序部署在单独的群集上并让HPC环境独处可能更容易。挑战在于,这是以孤立的群集为代价的,从而增加了基础架构和管理成本。

  • 在现有的HPC工作负载管理器下运行容器化工作负载

对于运行传统HPC工作负载的站点,另一种方法是使用现有的作业提交机制来启动作业,这些作业进而实例化一个或多个目标主机上的Docker容器。使用这种方法的站点可以引入容器化的工作负载,而对环境的破坏最小。领先的HPC工作负载管理器,例如 Univa Grid Engine容器版IBM Spectrum LSF 正在添加对Docker容器的本机支持。 变速杆奇点 是支持此类部署的重要开源工具。虽然这对于希望遵循其HPC调度程序的简单要求的站点来说是一个很好的解决方案,但他们将无法访问Kubernetes的本机功能,这可能会限制管理Kubernetes擅长的长期运行服务的灵活性。

  • 在Kubernetes中使用本机作业调度功能

对现有HPC应用程序投资较少的站点可以使用Kubernetes中的现有调度工具来实现 即将完成的工作。尽管这是一个选项,但对于许多HPC用户而言可能不切实际。 HPC应用程序通常针对大型吞吐量或大规模并行性进行了优化。在这两种情况下,启动和拆卸延迟都有明显的影响。如今对于容器化微服务而言似乎可以接受的延迟将使此类应用程序无法扩展到所需的级别。

所有这些解决方案都需要权衡。第一个选项不允许共享资源(增加成本),第二个和第三个选项要求客户选择一个调度程序,从而限制了将来的灵活性。

Kubernetes上的混合工作负载

更好的方法是在同一共享环境中本地支持HPC和容器工作负载。理想情况下,用户应看到适合其工作量或工作流程类型的环境。

支持混合工作负载的一种方法是允许Kubernetes和HPC工作负载管理器共存于同一群集中,从而节流资源以避免冲突。尽管简单,但这意味着工作负载管理器都无法充分利用集群。

另一种方法是使用与Kubernetes调度程序协调的对等调度程序。 Univa的Navops Command是采用第三种方法的解决方案,它增强了Kubernetes调度程序的功能。 Navops Command提供了自己的Web界面和CLI,并允许在Kubernetes上启用其他调度策略,而不会影响Kubernetes调度程序和现有容器化应用程序的操作。 Navops Command通过pod规范中的'schedulerName'属性作为对等调度程序插入Kubernetes体系结构,工作负载可以选择使用该对等调度程序来代替Kubernetes库存调度程序,如下所示。

屏幕截图2017年8月15日上午9.15.45

通过这种方法,Kubernetes充当资源管理器,使资源可用于单独的HPC调度程序。集群管理员可以使用可视界面根据策略分配资源,也可以通过Web UI拖动滑块以将不同比例的Kubernetes环境分配给非容器(HPC)工作负载以及本机Kubernetes应用程序和服务。

从客户端的角度来看,HPC调度程序作为部署在Kubernetes Pod中的服务运行,就像在裸机集群上一样运行。 Navops Command提供了其他调度功能,包括资源预留,运行时配额,工作负载抢占等。对于本地部署,基于云的部署或混合部署,此环境同样适用。

在IHME上部署混合工作负载

华盛顿大学的独立健康研究中心健康指标与评估研究所(IHME)是在混合工作负载方面取得成功的一个客户。为了支持其全球公认的全球健康数据交换(GHDx),IHME运行着一个规模庞大的环境,该环境由500个节点和20,000个核心组成,在Kubernetes上运行混合了分析,HPC和基于容器的应用程序。 本案例研究 介绍了IHME使用Navops Command在共享Kubernetes集群上成功托管现有HPC工作负载的成功。

对于部署新集群的站点,这些站点希望访问Kubernetes的丰富功能,但需要灵活性来运行非容器化的工作负载,这种方法值得一看。它为站点提供了在Kubernetes和HPC工作负载之间共享基础架构的机会,而不会破坏现有的应用程序和业务流程。它还允许他们按照自己的步调迁移其HPC工作负载以使用Docker容器。