本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 与高性能计算相遇
任何使用过 Docker 的人都能体会到容器带来的巨大效率提升。虽然 Kubernetes 擅长于编排容器，但在 Kubernetes 上部署高性能计算 (HPC) 应用程序可能很棘手。
在本文中，我将讨论在 Kubernetes 上运行 HPC 工作负载的一些挑战，解释当今企业如何应对这些挑战，并提出一种在共享 Kubernetes 集群上支持混合工作负载的方法。我们还将提供有关客户 IHME 的案例研究的信息和链接，展示 Kubernetes 如何扩展以无缝地服务其 HPC 工作负载，同时保留 HPC 用户熟悉的可扩展性和接口。
HPC 工作负载的独特挑战
在 Kubernetes 中，调度的基本单位是 Pod：一个或多个调度到集群主机的 Docker 容器。Kubernetes 假设工作负载是容器。虽然 Kubernetes 有Cron 作业和运行到完成的作业的概念，但部署在 Kubernetes 上的应用程序通常是长期运行的服务，例如 Web 服务器、负载均衡器或数据存储，虽然它们高度动态，pod 来来往往，但它们与 HPC 应用程序模式大不相同。
传统的 HPC 应用程序通常表现出不同的特征
- 在金融或工程模拟中，一项作业可能包含数万个短期运行的任务，需要低延迟和高吞吐量调度才能在可接受的时间内完成模拟。
- 计算流体动力学 (CFD) 问题可以使用消息传递库同步状态，在数百甚至数千个节点上并行执行。这需要专门的调度和作业管理功能来分配和启动此类作业，然后对其进行检查点、暂停/恢复或回填。
- 其他 HPC 工作负载可能需要 GPU 等专用资源或需要访问有限的软件许可证。组织可以强制执行有关哪些类型的资源可以被谁使用的策略，以确保项目获得足够的资源并按时完成。
HPC 工作负载调度程序已经发展到支持这些类型的工作负载。例如Univa Grid Engine、IBM Spectrum LSF和 Altair 的PBS Professional。管理 HPC 工作负载的站点已经依赖数组作业、可配置的抢占、基于用户、组或项目的配额以及各种其他功能等功能。
模糊容器和 HPC 之间的界限
HPC 用户认为容器与其他组织出于相同的原因而有价值。将逻辑打包到容器中以使其可移植、与环境依赖项隔离并易于与其他容器交换，这显然具有价值。但是，切换到容器可能很困难。
HPC 工作负载通常在命令行级别集成。作业不是通过编码提交到队列，而是作为二进制文件或充当包装器的简单 shell 脚本通过命令行提交。HPC 站点使用的此类工程、科学和分析应用程序 literally 有数百种，它们与流行的工作负载调度程序具有成熟且经过认证的集成。
虽然将工作负载打包到 Docker 容器、将其发布到注册表并提交工作负载的 YAML 描述的概念对于 Kubernetes 用户来说是第二天性，但这对大多数 HPC 用户来说是陌生的。在 R、MATLAB 或 Stata 中运行模型的分析师只想快速提交他们的模拟、监控其执行并尽快获得结果。
现有方法
为了应对迁移到容器的挑战，运行容器和 HPC 工作负载的组织有几种选择
- 维护单独的基础架构
对于在 HPC 上投入巨资的站点，这可能是一种首选方法。与其破坏现有环境，不如在单独的集群上部署新的容器化应用程序并保留 HPC 环境。挑战在于这需要付出孤立集群的代价，增加了基础架构和管理成本。
- 在现有的 HPC 工作负载管理器下运行容器化工作负载
对于运行传统 HPC 工作负载的站点，另一种方法是使用现有的作业提交机制来启动作业，这些作业反过来会在一个或多个目标主机上实例化 Docker 容器。使用这种方法的站点可以引入容器化工作负载，而对其环境的干扰最小。领先的 HPC 工作负载管理器，例如Univa Grid Engine Container Edition和IBM Spectrum LSF，正在添加对 Docker 容器的原生支持。Shifter和Singularity是支持这种部署的重要开源工具。虽然这对于希望坚持使用其 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 库存调度程序的对等调度程序，如下所示。
使用这种方法，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 容器。