CN109271233A - 基于Kubernetes组建Hadoop集群的实现方法 - Google Patents

Abstract

本发明提供了一种基于Kubernetes组建Hadoop集群的实现方法，包括S1、Manager节点循环监听Hadoop集群中各节点的配置信息，并以所述配置信息动态地封装为系统文件；通过Kubernetes API将系统文件以挂载共享文件方式向Hadoop集群中各节点进行更新操作；S2、接收自用户对Hadoop集群发起的管理请求，对Hadoop集群中的节点根据所述管理请求执行更新操作并通知Manager节点，Manager节点接收执行更新操作的节点所发出的修改请求对所述配置信息进行更新，并根据更新后的配置信息对系统文件进行修改。本发明能够实现对Hadoop集群的动态维护，提高了Hadoop集群的高可用性及高扩展性。

Description

基于Kubernetes组建Hadoop集群的实现方法

技术领域

本发明涉及云计算的容器技术领域，尤其涉及一种基于Kubernetes组建Hadoop集群的实现方法。

背景技术

Kubernetes是开源容器集群管理项目，其可在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的开源平台。Kubernetes通常结合Docker容器工具工作，并且整合多个运行着Docker容器的主机集群。使用Kubernetes管理Docker容器集群非常方便，不但能动态监测容器的状态，还能维护管理容器。

Hadoop是一个开发和运行处理大规模数据的软件平台，是采用的基于JAVA语言实现的开源软件框架，其可实现在大量计算机组成的分布式集群，以对海量数据进行分布式计算。

通常情况下，搭建Hadoop集群时，需要事先知道Hadoop集群中所有节点的Hostname以及其对应的IP，并将Hostname和IP写入到Manager节点的Workers文件中去，之后才能组建、启动Hadoop集群。由于Kubernetes管理Docker容器的过程中，通常是动态地进行维护，以实现增加或者删除节点，同时Docker容器的IP也是动态分配的。因此在现有技术中，使得很难运用Kubernetes动态组建并维护Hadoop集群。

在Kubernetes维护的集群中，Docker容器节点的Hostname和IP无法事先获取，从而导致搭建Hadoop集群、动态增减Hadoop集群中的节点的过程中造成障碍；Hadoop集群中的主节点(Master节点)与新增从节点(Slave节点)无法直接沟通，因此进一步导致了对动态维护Hadoop集群造成巨大障碍与技术上的限制。其中，术语“动态维护”包括但不限于增加、删除、暂停从节点等操作。

Kubernetes管理集群网络有天生的优越性，简单方便易用，但目前业界对于Kubernetes管理Docker容器主要用在面向任务的管理上，尚无较成熟的管理Hadoop集群的方案。因为如果预先固定IP或者Hostname等配置信息与Kubernetes优势不符合，所以很少采用kubernetes管理hadoop集群。借助Kubernetes组建管理Docker集群，Hostname和IP是随机分配的，并不适用组建Hadoop集群。管理员在系统后台通过人为手动组建、维护Hadoop集群又面临着管理集群多个节点的复杂操作问题，也不推荐使用。

同时，动态新增、删除Hadoop集群中的一个或者多个节点(即Worker节点)需要预先知道节点的IP等信息，并在该节点上做相应的操作，因此基于Kubernetes组建Hadoop集群的操作层面上就存在了非常大的局限性和较大的运维难度与运维压力。

发明内容

本发明的目的在于揭示一种基于Kubernetes组建Hadoop集群的实现方法，用以解决基于Kubernetes组建Hadoop集群中当需要创建节点时需要获知节点的IP等配置信息的技术限制，以提高Hadoop集群的高可用性及高扩展性，以实现对Hadoop集群的动态维护。

为实现上述目的，本发明提供了基于Kubernetes组建Hadoop集群的实现方法，所述Hadoop集群中运行至少一个节点；包括：

S1、Manager节点循环监听Hadoop集群中各节点的配置信息，并以所述配置信息动态地封装为系统文件；通过Kubernetes API将系统文件以挂载共享文件方式向Hadoop集群中各节点进行更新操作；

S2、接收自用户对Hadoop集群发起的管理请求，对Hadoop集群中的节点根据所述管理请求执行更新操作并通知Manager节点，Manager节点接收执行更新操作的节点所发出的修改请求对所述配置信息进行更新，并根据更新后的配置信息对系统文件进行修改。

作为本发明的进一步改进，在Manager节点根据更新后所形成的配置信息对系统文件进行修改之后，还包括：Manager节点根据更新后的配置信息对系统文件执行刷新操作。

作为本发明的进一步改进，所述步骤S1在Manager节点被启动的同时被执行，所述步骤S1在Manager节点中以后台运行方式被执行，并被配置为系统插件或者系统进程。

作为本发明的进一步改进，所述系统文件被配置为Hosts文件、txt格式文件、xml格式或者JS对象标记；

所述配置信息由Hostname、IP、GPU使用率、更新操作持续时间或者运行所述Hadoop集群所依赖的硬件设备的硬件功率值中的至少一种组成。

作为本发明的进一步改进，当Hadoop集群中的节点根据所述管理请求执行更新操作时，基于所述管理请求将发生更新操作的节点与未发生更新操作的节点所形成的更新后的配置信息对系统文件进行修改，并通知Manager节点。

作为本发明的进一步改进，当Hadoop集群中的节点执行更新操作时，基于所述管理请求先将未发生更新操作的节点所形成的更新后的配置信息对系统文件进行修改，然后将发生更新操作的节点所形成的配置信息对已经修改后的系统文件进行再次修改，并通知Manager节点，并由Manager节点根据更新后的配置信息对系统文件进行修改。

作为本发明的进一步改进，所述步骤S1中的更新操作包括：增量服务更新操作和/或缩量服务更新操作；

其中，

所述增量服务更新操作包括节点注册操作或者节点创建操作；

所述缩量服务更新操作包括节点删除操作、节点挂起操作、拒绝节点响应操作或者脱离Hadoop集群操作。

作为本发明的进一步改进，所述步骤S1中Manager节点通过往复的轮询操作，循环监听Hadoop集群中各节点的配置信息，并根据节点处理性能与节点网络状况，确定下一次执行轮询操作的间隔时间T，

间隔时间T＝γ*∑_节点数量(α/节点处理性能+β/节点网络状况)；

其中，γ∈[1，2]，α∈[1，2]，β∈[1，2]。

作为本发明的进一步改进，所述“确定下一次执行轮询操作的间隔时间T”包括：

首先，计算执行轮询Hadoop集群中响应最快的节点所需要的时间作为初始化间隔时间T’，并确定初始化γ；

然后，计算Hadoop集群中未被轮询到的节点的数量与Hadoop集群中全部节点的数量的比值1/K，以根据比值1/K确定初始化γ的增加倍数M，并符合M*1/K大于或者等于1的关系。

作为本发明的进一步改进，所述Manager节点与各个节点之间配置为星型拓扑结构；

步骤S1中对系统文件采用加密方式进行动态地封装，所述加密方式包括：对称加密方式或者非对称加密方式。

与现有技术相比，本发明的有益效果是：通过本发明所揭示的一种基于Kubernetes组建Hadoop集群的实现方法，可在基于Kubernetes组建Hadoop集群的整个过程中无需实现获得节点中所运行的容器的Hostname及IP，并通过将系统文件以挂载共享文件方式向Hadoop集群中各节点进行更新操作后由Manager节点根据更新后的配置信息对系统文件进行修改的方式，使得Hadoop集群中的各个节点以及节点中的容器在进行删除、增加、修改、迁移时更为方便，实现了对Hadoop集群的动态维护，提高了Hadoop集群的高可用性及高扩展性。

附图说明

图1为本发明基于Kuberbetes组建Hadoop集群的实现方法的流程图；

图2为通过本发明所揭示的实现方法所组建并形成的Docker容器集群的拓扑图；

图3为全局搜集Docker容器中各个节点的Hostname与IP后对系统文件进行动态维护的示意图；

图4为Manager节点搜集Hadoop集群中基于Docker容器所形成的实例以对系统文件进行动态维护的示意图；

图5为基于Kubernetes组建Hadoop集群的原理图；

图6为于后台启动并在后台运行的Worker节点将其所形成的实例对系统文件进行动态维护的原理图；

图7为系统文件在进行动态更新过程中所形成的数据流示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

Kubernetes是开源容器集群项目，其提供了一个在主机集群之间一个能够自动化部署、可扩展、应用容器可管理的平台。基于Kubernetes可方便的监控、管理并维护Docker容器。在本实施例中，所构建的Hadoop集群中所形成节点中包括主节点(Master节点)及从节点(Slave节点)，主、从节点中运行一个或者多个Docker容器。每个节点中所配置的Docker容器中具有唯一的属性(例如，IP)。Kubernetes运行管理单元为Pod，每个Pod中运行有一个或者多个容器。

当用户基于Kubernetes组件Hadoop集群时，用户登录管理界面，在管理界面上点击创建Hadoop集群的控件/按钮，管理门户向Kubernetes发出创建Hadoop集群服务器的请求。Kubernetes从镜像仓库中获取指定镜像并调用Docker API创建容器。管理门户直接向该用户创建的集群容器实例发送组件Hadoop集群脚本(Script)，自动完成SSH免密认证、设置主节点和从节点、同步Hadoop集群配置、启动Hadoop服务等动作，并将搭建结果通过管理门户向用户作出响应。上述过程被称作创建实例(instance)。具体的，在本申请中，所谓管理门户是指集成K8SClient接口的网站、托管服务器所形成的用户操作界面(GUI)，例如，ApacheTomcat的网站。

目前，当在运行Docker容器时，需要指定一个用户运行它。如果用户指定的是用户ID而不是用户名，假如这个用户ID不存在，它也会自动为用户创建用户。这种重新映射在遇到大量image的时候是无法正常工作的，也就意味着用户必须事先指定，如若不然，发起管理请求的用户将无法访问任何内容，也不能启动脚本和记录日志，从而导致Hadoop集群完全处于宕掉的状态。

当执行程序的时候，docker_run将隐含地从repo中拉出图像，虽然Spark和MapReduce都有10分钟的超时时间，但如果图像太大，网络下载时间超过了10分钟，程序就会报错。假如持续地重新提交程序，导致的最终结果将会是程序处在某个已经尝试过的节点上并运行。目前针对这种图像报错，YARN上对图像缓存暂无有效的解决方法。

Docker容器会将访问了client_config中安全备份的.docker/config.json文件进行存储备份，这个应该众所周知。这意味着当用户访问安全备份时，无论从哪个节点管理器登录，用户都会受到用户主目录中.docker/config.json文件的约束。

Kubernetes容器集群管理系统的主要功能包括：使用Docker对应用程序进行打包、实例化及运行；以集群的方式运行及管理跨主机的容器；解决位于不同主机之间所运行的容器之间的通信问题等等。其中，Scheduler(调度器)是Kubernetes容器集群管理系统中加载并运行的调度程序，其负责收集、统计分析容器集群管理系统中所有Node的资源使用情况，然后以此为依据将新建的Pod发送到优先级最高的可用Node上去建立。

参图1至图3所示，在本实施例中所揭示的一种基于Kubernetes组建Hadoop集群的实现方法，所述Hadoop集群100中运行至少一个节点。具体的，参图2所示，假设在一种场景中，在Hadoop集群100已经运行了三个work节点，即work-1节点20，work-2节点40，work-3节点30，且这三个节点均受控于Manager节点10。同时，每个work节点中可运行一个或者多个节点，并形成容器。例如，参图3所示，work-1节点20，work-2节点40，work-3节点30中可形成n个Node，从而形成n个Docker容器。在本实施方式中，术语“Docker容器”与“容器”具有等同含义。

在本实施方式中，该Manager节点10与各个节点(即work-1节点20，work-2节点40，work-3节点30，以及在下一阶段的操作中预期增加的work-4节点50)之间配置为星型拓扑结构。星型拓扑结构的组网逻辑结构具有结构简单、连接方便且维护相对容易的优点，具有扩展性能强大且网络延迟时间较小的技术优势。因此，在组建Hadoop集群100时被优先考虑采用。

结合图5所示，在本申请中的步骤S1与步骤S2可被等同视为Service1与Service2，并且Service1与Service2均为后台服务，其中，Service1运行于宿主机，即通过Manager节点10动态搜集各个节点的配置信息，并负责更新该配置信息，并确定更新间隔的设定时间。Service2作为另一种后台服务，运行于各个节点中。结合图4所示，Manager节点10中配置Service监听模块101(作为监控端)，work-1节点中配置Service请求模块201(作为请求端)，work-2节点中配置Service请求模块401(作为请求端)。

Service监听模块101通过与Service请求模块101及Service请求模块401的相互通讯，以搜集work-1节点10与work-2节点40的配置信息，例如Hostname或者IP等。当启动Hadoop集群100的Manager节点10时，即刻在Manager节点10上后台运行Service2(监控端)，监听Worker节点的注册信息；如当需要新增节点时，启动Worker节点，即刻在新节点上后台运行Service2的请求端，完成启动Hadoop集群100的相关服务，并向主节点(即Manager节点10)发送注册请求，主节点(即Manager节点10)接受到请求，更新配置文件后刷新系统，这样就完成了Hadoop集群100的动态节点增加。关于集群动态节点删除，原理类似，当某个Work节点收到上层的Manager节点10所发出的命令并需要脱离Hadoop集群100的时候，利用Service2服务，先关闭本机Hadoop相关服务，再由该指定的Work节点向Manager节点10发送脱离请求，主节点(即Manager节点10)接受到请求，更新配置文件后刷新系统，完成动态的Work节点的删除操作。

步骤S1、Manager节点10循环监听Hadoop集群100中各节点的配置信息，并以所述配置信息动态地封装为系统文件；通过Kubernetes API将系统文件以挂载共享文件方式向Hadoop集群100中各节点进行更新操作。

具体的，Kubernetes200通过其原生的Kubernetes API与work-1节点20，work-2节点40，work-3节点30建立监听，以通过该Kubernetes200持续地监听work-1节点20，work-2节点40，work-3节点30的状态。在本实施方式中，该系统文件被配置为Hosts文件、txt格式文件、xml格式或者JS对象标记。系统文件作为Hadoop集群100中的用以全局描述主、从节点的名称、虚拟地址、命名空间等信息，从而唯一的表征各个节点的属性与彼此之间的逻辑关系。同时，在本实施方式中，该配置信息由Hostname、IP、GPU使用率、更新操作持续时间或者运行所述Hadoop集群100所依赖的硬件设备的硬件功率值中的至少一种组成。

参图5所示，在本实施方式中，所谓“更新操作持续时间”是指，某个节点基于Service1与Service2对该指定节点发出的修改请求并对配置信息进行更新操作所花费的时间。该更新操作持续时间基于某个节点所预先加载的计算资源、配置选项相互关联。由此，Manager节点10通过确定更新操作持续时间，可以更加准确的获知配置信息，从而使得Manager节点10对各个节点的配置信息执行监听的效果更为准确。

基于已经启动或者正在运行的work节点必然占用或者消耗一定的物理计算资源或者带宽，因此将运行所述Hadoop集群100所依赖的硬件设备的硬件功率值作为配置信息中的一种参数是非常合适且必要的。因为，通过对硬件功率值的统计，能够为在执行Service2时启动新的work节点时提供准确且合理的依据，防止计算机硬件无法支撑业务情况的出现，并能够有效地防止计算机或者数据中心出现宕机或者无法支撑业务等情况的出现。

步骤S1在Manager节点10被启动的同时被执行，所述步骤S1在Manager节点10中以后台运行方式被执行，并被配置为系统插件或者系统进程，并具体运行在运行Hadoop集群100的计算机、计算机装置或者数据中心的内存中，甚至可以运行在与计算机、计算机装置或者数据中心相通讯的外置式存储装置中，例如，与CPU通过DMA(Direct Memory Access)协议直连的非易失性存储器中，从而进一步加速Hadoop集群100中增加、删除、中止work节点的速度。

具体的，在本实施方式中，该步骤S1中的更新操作包括：增量服务更新操作和/或缩量服务更新操作；

其中，

所述增量服务更新操作包括节点注册操作或者节点创建操作；

所述缩量服务更新操作包括节点删除操作、节点挂起操作、拒绝节点响应操作或者脱离Hadoop集群操作。

所述步骤S1中Manager节点10通过往复的轮询操作，循环监听Hadoop集群100中各节点的配置信息，并根据节点处理性能与节点网络状况，确定下一次执行轮询操作的间隔时间T，

间隔时间T＝γ*∑_节点数量(α/节点处理性能+β/节点网络状况)；

其中，γ∈[1，2]，α∈[1，2]，β∈[1，2]。

在本实施方式中，所述“确定下一次执行轮询操作的间隔时间T”通过以下技术方案实现。

首先，计算执行轮询Hadoop集群100中响应最快的节点所需要的时间作为初始化间隔时间T’，并确定初始化γ。

由于对Hadoop集群100中响应最快的节点进行轮询所需要的时间最小，因此，对Hadoop集群100中响应最快的节点进行首次轮询后，就能以此场景确定初始化间隔时间T’，当初始化间隔时间T’及节点处理性能与节点网络状况被确定后，并初始化γ也能够被准确地被确定下来。

然后，计算Hadoop集群100中未被轮询到的节点的数量与Hadoop集群100中全部节点的数量的比值1/K，以根据比值1/K确定初始化γ的增加倍数M，并符合M*1/K大于或者等于1的关系。通过上述技术手段，可以合理地确定与下一次轮询操作之间的间隔时间，从而根据该Hadoop集群100在不同场景或者不同时间下需要下一次执行轮询操作的间隔时间T。

由于过短的执行轮询操作的间隔时间T会导致因轮询操作所导致的不必要的计算开销，并存在可能有部分的work节点无法被轮询操作访问到的可能性；同时，过长的执行轮询操作的间隔时间T也存在Manager节点10对各个work节点无法获悉最新的监听信息的缺陷，从而存在Manager节点10所执行的监听操作效果不佳的缺陷。由此可知，适当的执行轮询操作的间隔时间T对Manager节点10准确的监听并减少整个Hadoop集群100不必要的计算开销是非常重要的工作。通过上述技术手段，能够以最合理的计算开销并避免不遗漏轮询操作所执行的对象，从而最准确且合理地确定下一次执行轮询操作的间隔时间T。

在本实施方式中，步骤S1中还包括对系统文件采用加密方式进行动态地封装，所述加密方式包括：对称加密方式或者非对称加密方式，并优选为非对称加密方式，且该非对称加密方式所采用的加密算法包括但不限于RSA、Elgamal、背包算法、Rabin、D-H、ECC。在本实施方式中，对系统文件采用加密方式具体包括如下子步骤：

子步骤S21、私钥生成中心输入系统安全参数λ和合法属性集合U，构造一个m维向量，并将该m维向量嵌入到系统公钥PK和系统主密钥MSK，m＝poly(log₂λ)，其中，poly(log₂λ)为关于log₂λ的多项式函数；

子步骤S22、私钥生成中心认证用户拥有的属性集合ω，利用系统主密钥MSK和系统公钥PK，生成包含一个m维向量的用户私钥SK_ω；

子步骤S23、加密方利用系统公钥PK和设定的访问策略，对待加密处理的信息进行加密，生成包含一个mn₁维向量的密文，其中，n₁是访问策略中矩阵的行数；

子步骤S24、仅在用户私钥SK_ω的属性满足密文的访问策略时，该用户才解密得到明文。

通过上述加密方式，能够显著地提高抗密钥泄密容忍性，在保证加密信息的安全性的前提下降低系统主密钥长度及用户私钥的长度，并有效抵抗连续辅助输入泄漏攻击，且允许主密钥和用户私钥的连续无界泄漏，允许基于属性加密的属性密钥引用到其他密码系统中去，提高基于属性加密的属性密钥的兼容性，且主密钥更新后无需将旧版本的主密钥从内存中完全清除，即允许泄漏旧版本的主密钥信息。

然后执行步骤S2、接收自用户对Hadoop集群100发起的管理请求，对Hadoop集群100中的节点根据所述管理请求执行更新操作并通知Manager节点10，Manager节点10接收执行更新操作的节点所发出的修改请求对所述配置信息进行更新，并根据更新后的配置信息对系统文件进行修改。具体的，在本实施方式中，“更新操作的节点”包括但不限于增加节点(例如，如图2中所增加/删除的work节点50)。其中，所谓的“管理请求”包括但不限于对Hadoop集群100中所执行的增加或者删除work节点的操作，也包括对某个具体的work节点中组建、管理、维护Node的操作。

结合图6及图7所示，在本实施方式中，当Hadoop集群100中的节点执行更新操作时，基于所述管理请求先将未发生更新操作的节点所形成的更新后的配置信息对系统文件进行修改，然后将发生更新操作的节点所形成的配置信息对已经修改后的系统文件进行再次修改，并通知Manager节点10，并由Manager节点10根据更新后的配置信息对系统文件进行修改；具体的，上述过程的具体实现过程请参图7中子步骤S11至步骤S14所示。

同时，在本实施方式中，在Manager节点10根据更新后所形成的配置信息对系统文件进行修改之后，还包括：Manager节点10根据更新后的配置信息对系统文件执行刷新操作。刷新后的配置信息能够更为准确地反应出Hadoop集群100中各个节点的状态信息，从而为下一次的轮询操作提供依据。上述依据可以是上文所述的配置信息的一种或者多种的组合，并能够全局的、真实的反应出work-1节点20至work-4节点50的真实开销。

在本申请中，利用Kubernetes技术组建基于Docker容器所组建的Hadoop集群100；利用后台服务，通过Manager节点10监听Hadoop集群100的配置信息，动态实时收集以及定时检查集群中节点的Hostname、IP等配置信息并更新配置信息；通过挂载共享文件的方式，利用Kubernetes200将Hosts文件等配置文件共享给基于Docker容器所构成的Hadoop集群100中的所有节点；启动Hadoop集群100的Manager节点10时，在Manager节点10上后台运行Service1(即步骤S1)，监听Worker节点的注册信息；当需要启动Worker节点时，在新节点上后台运行Service2(即步骤S2)，完成启动Hadoop相关服务，并向主节点发送注册请求，完成动态节点增加；当某个work节点收到上层命令，脱离Hadoop集群100的时候，利用Service1及Service2服务，先关闭本机Hadoop集群100的相关服务，再向Manager节点100发送脱离请求，完成动态节点删除。

在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.基于Kubernetes组建Hadoop集群的实现方法，所述Hadoop集群中运行至少一个节点；其特征在于，包括：

S1、Manager节点循环监听Hadoop集群中各节点的配置信息，并以所述配置信息动态地封装为系统文件；通过Kubernetes API将系统文件以挂载共享文件方式向Hadoop集群中各节点进行更新操作；

S2、接收自用户对Hadoop集群发起的管理请求，对Hadoop集群中的节点根据所述管理请求执行更新操作并通知Manager节点，Manager节点接收执行更新操作的节点所发出的修改请求对所述配置信息进行更新，并根据更新后的配置信息对系统文件进行修改。

2.根据权利要求1所述的实现方法，其特征在于，在Manager节点根据更新后所形成的配置信息对系统文件进行修改之后，还包括：Manager节点根据更新后的配置信息对系统文件执行刷新操作。

3.根据权利要求1所述的实现方法，其特征在于，所述步骤S1在Manager节点被启动的同时被执行，所述步骤S1在Manager节点中以后台运行方式被执行，并被配置为系统插件或者系统进程。

4.根据权利要求1或2或者3所述的实现方法，其特征在于，所述系统文件被配置为Hosts文件、txt格式文件、xml格式或者JS对象标记；

所述配置信息由Hostname、IP、GPU使用率、更新操作持续时间或者运行所述Hadoop集群所依赖的硬件设备的硬件功率值中的至少一种组成。

5.根据权利要求4所述的实现方法，其特征在于，当Hadoop集群中的节点根据所述管理请求执行更新操作时，基于所述管理请求将发生更新操作的节点与未发生更新操作的节点所形成的更新后的配置信息对系统文件进行修改，并通知Manager节点。

6.根据权利要求4所述的实现方法，其特征在于，当Hadoop集群中的节点执行更新操作时，基于所述管理请求先将未发生更新操作的节点所形成的更新后的配置信息对系统文件进行修改，然后将发生更新操作的节点所形成的配置信息对已经修改后的系统文件进行再次修改，并通知Manager节点，并由Manager节点根据更新后的配置信息对系统文件进行修改。

7.根据权利要求4所述的实现方法，其特征在于，所述步骤S1中的更新操作包括：增量服务更新操作和/或缩量服务更新操作；

其中，

所述增量服务更新操作包括节点注册操作或者节点创建操作；

所述缩量服务更新操作包括节点删除操作、节点挂起操作、拒绝节点响应操作或者脱离Hadoop集群操作。

8.根据权利要求7所述的实现方法，其特征在于，所述步骤S1中Manager节点通过往复的轮询操作，循环监听Hadoop集群中各节点的配置信息，并根据节点处理性能与节点网络状况，确定下一次执行轮询操作的间隔时间T，

间隔时间T＝γ*∑_节点数量(α/节点处理性能+β/节点网络状况)；

其中，γ∈[1，2]，α∈[1，2]，β∈[1，2]。

9.根据权利要求8所述的实现方法，其特征在于，所述“确定下一次执行轮询操作的间隔时间T”包括：

首先，计算执行轮询Hadoop集群中响应最快的节点所需要的时间作为初始化间隔时间T’，并确定初始化γ；

然后，计算Hadoop集群中未被轮询到的节点的数量与Hadoop集群中全部节点的数量的比值1/K，以根据比值1/K确定初始化γ的增加倍数M，并符合M*1/K大于或者等于1的关系。

10.根据权利要求5至9中任一项所述的实现方法，其特征在于，所述Manager节点与各个节点之间配置为星型拓扑结构；

步骤S1中对系统文件采用加密方式进行动态地封装，所述加密方式包括：对称加密方式或者非对称加密方式。