Kubernetes 遇上 HPC

云头条 · 公众号 · 科技媒体 · 2017-09-18 22:19

正文

作者Robert Lalonde在本文中写道，Kubernetes为支持混合的HPC和容器化应用程序提供了激动人心的新方法。

用过Docker的人都明白可以通过容器大幅提升效率。虽然Kubernetes擅长编排容器，但高性能计算（HPC）应用程序部署在Kubernetes上可能很棘手。

我在本文中将探讨让Kubernetes与HPC工作负载一起运行所面临的几个挑战，解释了如今企业如何应对这些挑战，介绍了在共享的Kubernetes集群上支持混合工作负载的一种方法。我们还将提供关于IHME客户案例研究的信息和链接，表明了如何扩展Kubernetes以便无缝处理HPC工作负载，同时保留了HPC用户熟悉的可扩展性和接口。

HPC工作负载带来独特挑战

在Kubernetes中，基本的调度单位是Pod：为一个集群主机调度了一个或多个Docker容器。Kubernetes假设工作负载是容器。虽然Kubernetes拥有运行到完成（run to completion）的Cron Job和Job这一概念，但部署在Kubernetes上的应用程序通常是长时间运行的服务，比如Web服务器、负载均衡系统或数据存储区；虽然它们具有高度动态性，pod时而启用时而撤销，但它们的HPC应用程序模式大不一样。

传统的HPC应用程序常常具有不同特点：

在金融或工程模拟中，一个作业可能包含数万个短时间运行的任务，需要低延迟和高吞吐量调度，以便在可接受的时间内完成模拟。

计算流体动力学（CFD）问题跨数百个节点、甚至数千个节点并行执行，使用消息传递库来同步状态。这需要专门的调度和作业管理功能，以便分配和启动这类作业，然后检查、暂停/恢复或全量拷贝作业。

其他HPC工作负载可能需要像GPU这样的专门资源，或者需要访问有限的软件许可证。企业可能执行谁可以使用什么类型的资源方面的策略，以确保项目有充足的资源、如期完工。

HPC工作负载调度器已得到了发展，完全支持这处类型的工作负载。这类调度器包括IBM Spectrum LSF、Altair的PBS Professional和Univa Grid Engine。管理HPC工作负载的站点已逐渐依赖诸如此类的功能：阵列作业（array job），可配置抢占，基于配额的用户、用户组或项目以及其他众多功能。

容器和HPC之间的界限模糊

HPC用户认为，由于同样的原因，容器对其他企业来说颇有价值。将逻辑包装到容器中让它具有可移植性，与环境依赖项隔离开来，并易于与其他容器交换，这显然有其重要性。然而，改用容器可能很难。

HPC工作负载常常在命令行层面加以整合。作业通过命令行，以二进制代码或简单的外壳脚本（充当封装器）这种形式提交到队列，而不需要编写代码。采用这种方法的HPC站点实际上使用成百上千个工程、科学和分析应用程序，它们与流行的工作负载调度器实现了成熟、通过认证的集成。

虽然Kubernetes用户习惯于这个概念：将工作负载打包到Docker容器中，将其发布到注册中心，然后提交工作负载的YAML描述，但是这对于大多数HPC用户来说很陌生。使用R、MATLAB或Stata运行模型的分析师只想快速提交模拟，监控执行情况，并尽快获得结果。

现有方法

为了应对迁移到容器带来的挑战，运行容器和HPC工作负载的企业有几个选择：

维护单独的基础设施。对于HPC方面已有投入的站点而言，这可能是首选方法。比较容易在单独的集群上部署新的容器化应用程序、不用去管HPC环境，而不是破坏现有环境。难题在于，这带来了孤立的集群，因而增加了基础设施和管理成本。

在现有的HPC工作负载管理器下运行容器化工作负载。对于运行传统HPC工作负载的站点而言，另一种方法是使用现有的作业提交机制来启动作业，而作业反过来在一个或多个目标主机上为Docker容器创建实例。使用这种方法的站点可以引入容器化的工作负载，对环境的干扰极小。像IBM Spectrum LSF和Univa Grid Engine容器版这些知名的HPC工作负载管理器在添加直接支持Docker容器的功能。Shifter和Singularity也是支持这种部署的重要开源工具。虽然这种解决方案很适合要求简单、又想坚持使用HPC调度器的站点，但是它们无法享用原生的Kubernetes功能，这可能会限制管理长时间运行的服务方面的灵活性，而Kubernetes恰恰擅长管理长时间运行的服务。

使用Kubernetes的原生作业调度功能。现有HPC应用程序方面投入较少的站点可以使用Kubernetes中现有的调度工具来处理运行到完成的作业。虽然这是一种选择，但是对许多HPC用户来说不切实际。HPC应用程序常常是针对高吞吐量或大规模并行处理而优化的。在这两种情况下，启动和撤销带来的延迟都会带来影响。对于如今的容器化微服务来说似乎可接受的延迟会让这种应用程序无法扩展到所需的级别。

所有这些解决方案各有利弊。第一种方案无法让资源得以共享（增加了成本），第二种方案和第三种方案要求客户选择单一的调度器，因而限制了未来的灵活性。

Kubernetes上的混合工作负载

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

支持混合工作负载的一种方法是，允许Kubernetes工作负载管理器和HPC工作负载管理器在同一个集群上共存，限制资源以避免冲突。虽然很简单，但这意味着任何一种工作负载管理器都无法充分利用集群。

另一种方法是使用与Kubernetes调度器协调的对等调度器（peer scheduler）。借助这种方法，Kubernetes充当资源管理器，让资源可供单独的HPC调度器使用。集群管理员可以使用可视化界面，基于策略来分配资源，或者只需通过Web UI来拖动滑块，从而为非容器（HPC）工作负载、原生Kubernetes应用程序及服务分配Kubernetes环境不同比例的资源。

从客户端的角度来看，HPC调度器作为部署在Kubernetes pod中的服务来运行，就像它在裸机集群上一样运行。一些解决方案提供了额外的调度功能，包括资源预留、运行时配额和工作负载抢占等功能。这种环境同样适用于本地部署、基于云的部署或混合部署。

IHME部署混合工作负载

成功部署混合工作负载的一个客户是健康指标和评估研究所（IHME），这是华盛顿大学下面的一个独立健康研究中心。为了支持其全球公认的全球健康数据交换中心（GHDx），IHME运行着一个规模庞大的环境，包括500个节点和20000个核心，它们在Kubernetes上运行分析、HPC和基于容器的应用程序。该案例研究描述了IHME在共享的Kubernetes集群上成功托管运行现有的HPC工作负载。

如果站点部署了新的集群，想享用Kubernetes中的丰富功能，但需要可以灵活地运行非容器化的工作负载，这种方法值得关注。它让站点有机会让Kubernetes工作负载和HPC工作负载共享基础设施，又不干扰现有的应用程序和业务流程。它还让站点得以按照自己的步伐来迁移HPC工作负载来使用Docker容器。