文章内容大部分翻译自 kubernetes 官方博文 Kubernetes Meets High-Performance Computing ,文章编写时间较早,结合自身认知对内容进行标注解释。
但凡使用过 Docker 的人,都能切实感受到容器在提升效率方面展现出的巨大潜力。Kubernetes 在容器编排领域表现卓越,然而,将高性能计算(HPC)1应用程序部署在 Kubernetes 之上,却并非易事。
本文将深入探讨在 Kubernetes 上运行 HPC 工作负载时面临的一系列挑战,详细阐述当下各组织应对这些挑战的策略,并提出一种在共享 Kubernetes 集群上支持混合工作负载的有效方法。此外,文章还会引入客户 IHME 的案例研究,通过该案例展示如何对 Kubernetes 进行扩展,使其能够无缝为 HPC 工作负载提供服务,同时还能保留 HPC 用户所熟悉的扩展性与接口,让用户在使用过程中不会产生陌生感,确保工作的高效开展。
在 Kubernetes 体系中,调度的基础单元是 Pod,它能够将一个或多个 Docker 容器调度至集群中的某一台主机之上。Kubernetes 默认工作负载以容器形式存在。尽管 Kubernetes 拥有 Cron Jobs 和 Jobs 的概念,但在 Kubernetes 上部署的应用程序通常是长期运行的服务,例如网络服务器、负载均衡器或数据存储。这些应用程序具有高度动态性,Pod 不断地创建和销毁。这与 HPC 应用程序的模式存在显著差异。
传统的 HPC 应用程序,通常呈现出截然不同的特点:
高性能计算(HPC)工作负载调度程序已经发展到能够完全支持这类工作负载。例如 Univa Grid Engine2、IBM Spectrum LSF3 和 Altair 的 PBS Professional4。管理 HPC 工作负载的站点已经开始依赖诸如阵列作业、可配置的抢占、基于用户、组或项目的配额以及各种其他功能。其中,HPC 工作负载调度程序是为了高效管理 HPC 工作负载而设计的软件工具,它们不断演进以适应不同类型的 HPC 任务需求。
HPC 用户认为容器对他们有价值的原因与其他组织相同。将逻辑封装在容器中可以使其具有可移植性、不受环境依赖的影响,并且易于与其他容器进行交换,这显然是有价值的。然而,切换到容器可能会很困难。
高性能计算(HPC)工作负载通常在命令行级别进行集成。不需要进行编码,作业通过命令行以二进制文件或充当包装器的简单 shell 脚本的形式提交到队列中。实际上,HPC 站点使用的数百个工程、科学和分析应用程序采用这种方法,并且与流行的工作负载调度程序有成熟且经过认证的集成。
对于 Kubernetes 用户来说,将工作负载打包进 Docker 容器、发布到注册中心并提交该工作负载的 YAML 描述是自然而然的事情。但这对于大多数高性能计算(HPC)用户来说却很陌生。使用 R、MATLAB 或 Stata 运行模型的分析师仅仅希望快速提交他们的模拟,监控执行过程,并尽快得到结果。
为了应对迁移到容器的挑战,运行容器和高性能计算(HPC)工作负载的组织有以下几种选择:
对于在高性能计算(HPC)方面有大量前期投入的站点,这可能是一种较好的方法。与其扰乱现有的环境,在一个单独的集群上部署新的容器化应用程序并让 HPC 环境保持不变可能更容易。但挑战在于,这会带来孤立集群的代价,增加基础设施和管理成本。具体来说,这种做法是为了避免影响已有的 HPC 环境,选择在新的集群部署容器化应用,然而这样做会导致集群之间相互隔离,从而增加了基础设施的投入以及管理的成本。
对于运行传统高性能计算(HPC)工作负载的站点,另一种方法是使用现有的作业提交机制来启动作业,这些作业进而在一个或多个目标主机上实例化 Docker 容器。采用这种方法的站点可以引入容器化工作负载,同时对其环境的干扰最小。像 Univa Grid Engine Container Edition5 和 IBM Spectrum LSF 这样的领先 HPC 工作负载管理器正在添加对 Docker 容器的原生支持。Shifter6 和 Singularity7 也是支持这种类型部署的重要开源工具。虽然对于需求简单且希望坚持使用其 HPC 调度程序的站点来说,这是一个很好的解决方案,但这些站点将无法访问原生的 Kubernetes 功能,这可能会限制在管理 Kubernetes 擅长的长时间运行服务方面的灵活性。
对于在现有高性能计算(HPC)应用程序中投入较少的站点,可以使用 Kubernetes 中的现有调度设施来处理运行到完成的 Jobs。虽然这是一种选择,但对于许多 HPC 用户来说可能并不实际。HPC 应用程序通常针对大规模吞吐量或大规模并行性进行优化。在这两种情况下,启动和关闭延迟都会产生重大影响。如今对于容器化微服务来说看似可以接受的延迟,会使这些应用程序无法扩展到所需的级别。
所有这些解决方案都涉及权衡。第一种选择不允许资源共享(增加成本),第二种和第三种选择要求客户选择单个调度程序,从而限制了未来的灵活性。
一种更好的方法是在同一个共享环境中原生支持高性能计算(HPC)和容器工作负载。理想情况下,用户应该看到适合其工作负载或工作流类型的环境。这意味着创建一个能够同时处理 HPC 任务和容器化任务的环境,无需为不同类型的工作负载分别设置不同的环境。
一种支持混合工作负载的方法是让 Kubernetes 和高性能计算(HPC)工作负载管理器在同一个集群中共存,通过限制资源来避免冲突。虽然这种方法简单,但这意味着无论是 Kubernetes 还是 HPC 工作负载管理器都无法充分利用整个集群。也就是说,这种共存方式虽然在一定程度上实现了混合工作负载的支持,但由于需要对资源进行限制,两个工作负载管理器都不能完全发挥集群的全部性能。
另一种方法是使用与 Kubernetes 调度器协同工作的对等调度器。Univa 的 Navops Command8 是采用这种第三种方法的解决方案,它增强了 Kubernetes 调度器的功能。Navops Command 提供自己的 Web 界面和命令行界面(CLI),并允许在 Kubernetes 上启用额外的调度策略,而不会影响 Kubernetes 调度器和现有的容器化应用程序的运行。Navops Command 通过 Pod 规范中的“schedulerName”属性接入 Kubernetes 架构,作为一个对等调度器,工作负载可以选择使用它而不是 Kubernetes 默认调度器。
在这种方法下,Kubernetes 充当资源管理器,将资源提供给一个独立的高性能计算(HPC)调度器。集群管理员可以使用可视化界面根据策略分配资源,或者通过网络用户界面简单地拖动滑块,将 Kubernetes 环境的不同比例分配给非容器(HPC)工作负载以及原生的 Kubernetes 应用程序和服务。
从客户端的角度来看,高性能计算(HPC)调度程序作为部署在 Kubernetes 容器组(pods)中的服务运行,其运行方式与在裸机集群上一样。Navops Command 提供了额外的调度功能,包括资源预留、运行时配额、工作负载抢占等。这种环境对于本地部署、基于云的部署或混合部署同样有效。
一个在混合工作负载方面取得成功的客户是健康指标与评估研究所(IHME),它是华盛顿大学的一个独立健康研究中心。为了支持其全球公认的全球健康数据交换平台(GHDx),IHME 运营着一个规模可观的环境,由 500 个节点和 20000 个核心组成,在 Kubernetes 上运行分析、高性能计算(HPC)和基于容器的应用程序的混合体。这个案例研究描述了 IHME 使用 Navops Command 在共享的 Kubernetes 集群上成功托管现有 HPC 工作负载的情况。
对于正在部署新集群且希望获得 Kubernetes 丰富功能但又需要灵活运行非容器化工作负载的站点来说,这种方法值得一看。它为站点提供了在 Kubernetes 和 HPC 工作负载之间共享基础设施的机会,且不会破坏现有的应用程序和业务流程。同时,它还允许这些站点按照自己的节奏将其 HPC 工作负载迁移到使用 Docker 容器。
HPC即高性能计算(High Performance Computing),是使用超级计算机或计算机集群,通过并行计算、分布式存储等技术,快速处理海量复杂数据,以解决如气候模拟、基因测序、工程设计、金融风险分析等对计算能力要求极高问题的技术,能大幅提升运算速度和效率,推动科学研究、工业生产等领域的发展。 ↩︎
Univa Grid Engine是一款功能强大且广泛应用的集群资源管理与作业调度系统。它主要用于高效调配计算集群中的各种资源,如CPU、内存、存储等,让集群内的众多计算节点协同工作。科研人员在进行大规模数据模拟,企业开展复杂数据分析时,都能通过它将作业任务合理分配到集群各节点并行处理,从而大大缩短任务执行时间。同时,它支持多样化的操作系统和硬件架构,具备灵活的作业队列管理、资源监控和弹性扩展能力,可满足不同规模和复杂程度的计算需求,帮助用户充分发挥集群的计算性能,提升工作效率 。 Univa Grid Engine 的前身是 Sun Grid Engine,最初由 Sun Microsystems 开发。Sun 公司在服务器和操作系统等领域有深厚技术积累,开发 Sun Grid Engine 旨在为用户提供高效的集群资源管理和作业调度解决方案,以充分利用集群计算资源,满足日益增长的计算需求。随着时间推移,Sun Microsystems 被甲骨文(Oracle)收购,Sun Grid Engine 的部分功能和技术被整合到 Oracle 的产品体系中。之后,Univa 公司从 Oracle 获得相关技术授权等,对其进行进一步开发和完善,将其发展为 Univa Grid Engine,不断拓展功能,提升性能和稳定性,使其在集群计算领域保持领先地位。 ↩︎
IBM Spectrum LSF是一款强大的负载共享设施(Load Sharing Facility)软件,它是IBM在高性能计算(HPC)和企业级计算领域的重要产品,旨在帮助用户高效管理和调度计算资源。它能够智能地分配任务到集群中的不同节点,根据系统资源的使用情况动态调整任务分布,以提高整体计算效率,支持多种操作系统和硬件平台,可广泛应用于科研、金融、制造等对计算资源需求高的行业,帮助企业和机构充分利用集群计算能力,加速业务流程和科研项目的进展,提升竞争力。 ↩︎
PBS Professional是一款功能强大且应用广泛的作业调度和资源管理系统,由Altair公司开发,旨在为高性能计算(HPC)环境以及企业级计算集群提供高效的任务调度与资源分配解决方案。它能够智能地管理计算资源,根据用户设定的策略和资源使用情况,灵活调度各种作业任务,支持多种操作系统和不同类型的计算资源,可显著提高计算资源的利用率和作业执行效率,广泛应用于科研机构、高校、企业等领域,帮助用户在大规模计算任务处理中实现资源的优化配置和工作流的高效管理。 ↩︎
Univa Grid Engine Container Edition是一款强大的计算资源管理与任务调度软件,它可将Docker容器全面集成到Univa Grid Engine资源管理器中,能大规模运行容器并将其与其他工作负载融合,支持异构应用和技术环境。具有Docker目录映射、全面的作业控制、作业记账等功能,可实现容器内并行作业、自动处理输入输出及错误文件、运行交互式应用。能与任何基础设施、操作系统及大量应用和框架协同工作,帮助用户优化资源分配,提升计算效率,降低配置和部署问题,广泛适用于多种对计算资源管理有需求的场景。 ↩︎
Shifter 为高性能计算(HPC)启用容器映像。简而言之,Shifter 使得 HPC 系统能够高效且安全地允许最终用户运行 Docker 镜像。Shifter 由几个部分组成:一是通常在计算节点上运行的实用程序,它为应用程序创建运行时环境;二是图像网关服务,从注册表中提取镜像并以适合 HPC 系统的格式(通常是 squashfs)重新打包;三是示例脚本 / 插件,用于将 Shifter 与各种批处理调度系统集成。该项目代码最近更新日期为三年前。 ↩︎
Singularity 容器可用于封装整个科学工作流程、软件、库甚至数据。这意味着用户不必请求集群管理员为其安装任何东西,可以将所需内容放入 Singularity 容器中并运行。如果用户已经在 Docker 上进行了投入,Singularity 软件可以导入用户的 Docker 镜像,无需安装 Docker 或成为超级用户。如果需要分享代码,将其放入 Singularity 容器中,合作者就不必经历安装缺失依赖项的痛苦。如果需要完全运行不同的操作系统,可以在 Singularity 容器内将主机上的操作系统 “替换” 为另一个操作系统。作为用户,可以控制容器与主机交互的程度,可以实现无缝集成,也可以几乎没有通信。还询问了用户的工作流程是什么样的。 ↩︎
是 Altair 公司推出的一款用于混合云扩展和成本管理的工具。它能与众多云服务提供商和工作负载管理器协同工作,帮助企业将计算密集型的高性能计算(HPC)工作负载迁移到云端。用户可通过其易用界面和对基础设施即代码(IaC)的支持,集成到任何环境中,实现动态扩展按需云资源、自动化工作负载调度、控制云支出等功能,还能提供对云操作和 HPC 云支出的集中管理与全局可视性。 ↩︎