[发明专利]基于Kubernetes集群的资源分配方法及其相关设备

说明书

本申请涉及一种基于Kubernetes集群的资源分配方法及其相关设备，该方法包括：获取运行在Kubernetes集群上的应用程序的当前运行状态；根据当前运行状态确定目标任务；根据目标任务对应用程序的Spark代码进行调整，生成与目标任务相关联的操作器；利用操作器在预设时间范围内批量申请与目标任务相匹配的至少一个执行器；基于至少一个执行器分配与应用程序对应的资源，其中：若至少一个执行器的数量小于对应于目标任务的目标数量，结束应用程序的运行，重新生成至少一个执行器；否则直接运行应用程序。本申请通过动态分配对应于应用程序的目标任务的资源，能够提升Spark在Kubernetes集群的迁移效率，降低应用程序出现故障的概率，增强Kubernetes集群的稳定性。

技术领域

本申请涉及大数据领域，尤其涉及一种基于Kubernetes集群的资源分配方法及其相关设备。

背景技术

随着大数据时代的兴起，传统的数据库系统逐渐无法适应企业数字化转型的需求，取而代之的是企业经常采用Spark来搭建数据系统。Spark是用于大规模数据处理的统一分析引擎，可以在集群上运行。当Spark在集群上运行时，驱动程序可以连接到集群管理器，以利用集群管理器在应用程序之间分配资源。集群管理器包括Spark自带的集群管理器、Mesos、YARN或Kubernetes，形成不同的调度系统。

在实际应用过程中，经常遇到需要将大规模的Spark集群任务从例如Mesos、YARN等其他调度系统迁移到Kubernetes(即K8S)的场景。然而，在具体迁移的过程中，会带来如下问题：

1、etcd容易撑爆。etcd是Kubernetes集群的关键组件，可用于共享配置和服务发现。但是，在从其他调度系统迁移到Kubernetes的过程中，由于同时产生的事件过多，且每次更新都会产生新的版本，导致数据量过大，从而容易迅速撑爆etcd。

2、资源死锁问题。在使用Kubernetes调度Spark任务时，若多个不同的任务同时申请一定数量的执行器，则这多个不同的任务可能均得不到足够的资源运行，只能申请到部分资源，从而导致资源死锁问题。

3、资源配置问题。Spark任务需要用户在任务配置里指定任务所需的执行器数量，但是无法衡量该执行器数量是否与任务量相匹配。若执行器数量过少，对应的任务会因资源不足被停止；若执行器数量过多，则会造成资源的浪费。

4、资源回收问题。在Spark2.4以上的版本中，一般会开启动态收集功能，将已经计算完成的执行器归还给调度器，以较少pod闲置时间。然而，pod回收会导致存储在该pod上的重排输出文件也一并回收，下游任务不得不重新计算rdd，影响下游任务的运行。

5、事件日志问题。由于Spark on Kubernetes集群的历史服务器一般存储在集群的持久化卷上，存在容量限制，而Spark的事件日志数量特别大，容易将磁盘容量占满，从而导致容量不足的问题。

因此，上述迁移过程不仅无法得知任务运行所需的资源量，进而导致资源浪费，迁移效率降低，也会导致多种程序故障的出现，加大了数据系统不稳定的风险，亟需进一步改善。

发明内容

有鉴于此，本申请提出了一种基于Kubernetes集群的资源分配方法及其相关设备，能够动态分配对应于应用程序的目标任务的资源，进而提升Spark在Kubernetes集群的迁移效率，降低应用程序出现故障的概率，增强Kubernetes集群的稳定性。