混合云环境中的Kubernetes HPC使用经验

作者：Daniel Gruber，Burak Yenier和Wolfgang Gentzsch，UberCloud。

该公司成立于2013年，致力于开发HPC容器技术和容器化工程应用程序，以促进在共享的本地或按需云环境中访问和使用工程HPC工作负载。本文及上一篇文章中，他们描述了过去12个月在Kubernetes上使用UberCloud HPC容器的经验。

随着云服务的兴起，CIO意识到在各种计算环境中运行的应用程序，中间件和基础架构需要通用的管理和操作模型。通过为每个云提供商使用不同的专用基础架构和应用程序管理解决方案，在本地和云环境中维护不同的应用程序和中间件堆栈，会在动态分配，使用和管理这些资源时增加很多麻烦。

混合云环境中缺乏通用的管理和运营模型可能导致：

不均匀，分散的环境给管理人员，操作人员和安全性带来了额外的复杂性。

由于没有通用管理的混合环境，创新速度降低了。

当依赖于云提供商的特定服务时，很难更改或关闭云资源。

当绑定到特定的云环境设置时，工作负载不容易迁移回本地环境，反之亦然。

正如上一篇文章中指出的那样，Kubernetes已成为事实上的标准容器编排器。所有主要公司都在随处可用的标准化API之上提供并构建解决方案。CIO现在正在研究Kubernetes在混合云中对HPC的适用性，因为它为每种环境提供了通用的管理和操作模型。

Kubernetes：混合云的通用管理和运营模型

Kubernetes促进了服务器队列中运行的无数容器的使用和管理，它是由许多IT供应商和云提供商支持的用于混合环境的新标准平台。现在，CIO可以分配一个完全配置并受支持的容器编排器，作为其所有应用程序工作负载的基础。

与专有基础架构解决方案不同，Kubernetes具有可移植性，易于管理，高可用性，可集成性和监视功能。在Kubernetes上管理资源时，CIO不再绑定到特定的基础架构。他们可以使用相同的应用程序堆栈为用户提供相同的功能集，无论是本地还是在任何云中。用户甚至不知道自己的应用程序正在Kubernetes上运行，也不知道它们在哪个基础架构上运行：是在自己的数据中心还是在特定的云提供商（例如Google，Microsoft或Amazon）上。

通过使用像Kubernetes这样的标准化软件栈来降低混合云环境的复杂性具有许多优点：对一个平台进行的改进可以自动在其他平台上使用；部署和运营方面可以简化；安全审核更容易，更严格地执行。

Kubernetes和HPC

Kubernetes已经是AI和ML的事实平台，但是，当涉及到传统的高性能计算时，仍然存在一些挑战。HPC工作负载管理器中内置了一组功能，Kubernetes中尚不可用。我们之前在第一篇文章已经讨论了主要差异，Kubernetes在HPC方面的主要差距是：对分布式内存作业（即MPI应用程序）的本机支持，以及与现有HPC应用程序兼容的缺少的作业排队系统。

Kubernetes在许多层上都内置了高可用性。但是，对于HPC作业，仅重启一个失败的容器是不够的，因为整个分布式作业本身可能已经失败了。在这种情况下，需要对整个分布式内存作业进行自动重新计划。这是Kubernetes无法处理的。

除了这些挑战之外，Kubernetes还为HPC带来了许多好处：例如，工程师和容器化HPC应用程序的环境始终是相同的，无论是本地部署还是在基于云的环境中运行；快速从一种基础架构转换为另一种基础架构的能力使HPC团队能够与其公司的云路线图保持一致。在基于通用API（Kubernetes API）的基础架构之间移动工作负载的自由变得很有价值。

Kubernetes上的容器化HPC应用程序

在过去的五年中，已经将数十种HPC应用程序进行了容器化，无论是商业化的，例如ANSYS，COMSOL，STAR-CCM +，还是开源软件包（如OpenFOAM和GROMACS），以及HPC集群调度程序，例如Univa Grid Engine和Slurm。由于采用了容器技术，因此可以提供持续不断的更新和改进，客户可以快速，无缝地对其进行更新。此外，容器映像允许用户随时返回到先前的应用程序版本，以便他们始终可以重现其先前的结果。

在托管Kubernetes上运行的示例HPC应用程序集群架构

同时，通过使用诸如Terraform和Puppet之类的基础架构和配置管理工具或通过将特定于云的HPC集成构建到现有门户中，已经实现了许多容器环境。但是随着Kubernetes的到来，容器环境变得更易于维护并且更加动态。控制器不断驱动集群，从而将集群推出，重新调整工作节点的规模，使用一组恒定的可抢占实例以及高可用性。

因此，Kubernetes和HPC主要差距已被消除。这样，今天，任何Kubernetes环境都可以支持分布式内存/ MPI作业，该环境提供了在HPC容器内运行的内置HPC工作负载管理器集成。这使传统的HPC应用程序无需任何更改即可运行。同时，通过在内部运行的高性能支持GPU的Pod，已成功启动了基于Ansys和COMSOL的GPU和未支持GPU的应用程序。登录到桌面后，工程师可以开始提交批处理作业或单个MPI应用程序，这些应用程序分布在多个节点上分配的一组Pod中。

结论

Kubernetes不仅支持基于微服务的企业应用程序，而且还支持自助服务工程HPC应用程序。总而言之，正如该研究表明的那样，使用Kubernetes作为运行容器化工程应用程序的基础的主要优点是：

几乎所有基础架构上均可使用统一应用程序堆栈；

真正的混合云使用方案，可满足工程负载的需求。对于工程师而言，无论在本地还是在云中运行应用程序，它都是透明的；

通过始终分配云中可用的最新和最快的机器，从而为运行工程应用程序提供最佳性能；

作为工程师的自助服务，构建并调整独立的HPC应用程序和计算集群的大小，并且仅受每个时间段的云配额和预算限制；

强大的管理堆栈，得到许多云提供商的支持；

仅通过支付使用费用来优化成本。不需要闲置资源，这些闲置资源将在使用前被分配；

通过独立的专用计算集群实现高安全性；

通过自我配置和一次性组件（将更新简单地销毁并重新创建命令），将操作开销降至最低；

基于Kubernetes的工作负载更易于集成到广泛采用的持续集成和部署解决方案中（例如Tekton，Concourse或Jenkins的未来版本）。

在这项研究中，基于容器的HPC应用程序环境已在Kubernetes之上实现（例如，在Google GCP和Amazon AWS上），并且还用作自助服务测试环境，可由HPC应用程序专家而非运营商从头开始部署。它也已用于CI / CD管道中，以自动构建测试环境，以针对现有容器解决方案运行测试并随后关闭基础架构。在客户环境中，IT部门受益于使用受支持的托管Kubernetes易于维护的系统，该系统可以在几分钟之内增加，调整大小和删除计算资源。