CN114443059A - Kubernetes集群的部署方法、装置及设备 - Google Patents

Abstract

本申请实施例提供一种Kubernetes集群的部署方法、装置及设备，该方法包括：接收用于部署第一Kubernetes集群的第一部署请求，该第一部署请求包括：用于部署第一Kubernetes集群的物理机或虚拟机的标识；根据物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群；接收用于部署至少一个第二Kubernetes集群的第二部署请求，第二部署请求包括：第一Kubernetes集群的标识；根据第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群，第一Kubernetes集群对至少一个第二Kubernetes集群进行管控。本申请实施例能够提高Kubernetes集群的部署效率。

Description

Kubernetes集群的部署方法、装置及设备

技术领域

本申请实施例涉及云计算技术领域，尤其涉及一种Kubernetes集群的部署方法、装置及设备。

背景技术

Kubernetes(简称K8s)作为一个开源的容器化管理平台，在容器化领域得到了越来越多的应用。但是，它的组件多、配置复杂，进而导致其安装、部署和管控都比较复杂。

现有的Kubernetes安装技术，包括手动安装和采用安装工具进行安装，而无论是手动安装(使用二进制文件安装)，还是采用安装工具(比如，kubeadm)进行安装,都存在安装过程复杂，以及无法同时安装和管控多个集群，导致Kubernetes集群安装部署效率低的问题。

发明内容

本申请实施例提供一种Kubernetes集群的部署方法、装置及设备，以提高Kubernetes集群的安装部署效率。

第一方面，本申请实施例提供一种Kubernetes集群的部署方法，包括：接收用于部署第一Kubernetes集群的第一部署请求，第一部署请求包括：用于部署第一Kubernetes集群的物理机或虚拟机的标识；根据物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群；接收用于部署至少一个第二Kubernetes集群的第二部署请求，第二部署请求包括：第一Kubernetes集群的标识；根据第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群，第一Kubernetes集群对至少一个第二Kubernetes集群进行管控。

第二方面，本申请实施例提供一种Kubernetes集群的部署装置，包括：接收模块，用于接收用于部署第一Kubernetes集群的第一部署请求，第一部署请求包括：用于部署第一Kubernetes集群的物理机或虚拟机的标识；部署模块，用于根据物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群；接收模块，还用于接收用于部署至少一个第二Kubernetes集群的第二部署请求，第二部署请求包括：第一Kubernetes集群的标识；部署模块，还用于根据第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群，第一Kubernetes集群对至少一个第二Kubernetes集群进行管控。

第三方面，本申请实施例提供一种电子设备，包括：存储器；处理器；通讯接口；以及计算机程序；其中，计算机程序存储在存储器中，并被配置为由处理器执行以实现如第一方面的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现第一方面的方法。

本申请实施例提供的Kubernetes集群的部署方法、装置及设备，通过接收用于部署第一Kubernetes集群的第一部署请求，并根据第一部署请求中携带的物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群；之后在接收到用于部署至少一个第二Kubernetes集群的第二部署请求的情况下，根据第二部署请求中包括的第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群，其中，第一Kubernetes集群对至少一个第二Kubernetes集群进行管控。由于第二Kubernetes集群是部署且运行在第一Kubernetes集群上，而不再是单个的物理机或虚拟机上，另外第一Kubernetes集群中主节点本身具有管控多个从节点的功能，而第二Kubernetes集群本身就是容器化应用平台，其包括多个从节点，因此至少一个第二Kubernetes集群相对于第一Kubernetes集群，就像是运行在第一Kubernetes集群上的容器化应用的集群，第一Kubernetes集群中的主节点能够对至少一个第二Kubernetes集群中的从节点进行管控、增加和删除，因此第一Kubernetes集群能够同时安装部署多个第二Kubernetes集群，从而简化Kubernetes集群的部署过程，提高Kubernetes集群的部署效率，以及方便管控。

附图说明

图1为现有技术中单个Kubernetes集群的架构图；

图2为本申请实施例提供的Kubernetes集群的部署方法流程图；

图3为本申请实施例提供的Kubernetes集群的部署系统的架构图；

图4A为本申请实施例提供的部署完成的Kubernetes集群的架构图；

图4B为本申请另一实施例提供的部署完成的Kubernetes集群的架构图；

图5为本申请另一实施例提供的部署完成的Kubernetes集群的架构图；

图6为本申请实施例提供的Kubernetes集群的部署装置的结构示意图；

图7为本申请实施例提供的电子设备的框图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

Kubernetes是自动化容器操作的开源平台，这些操作包括：对容器的部署、调度和节点集群间扩展等功能。Kubernetes集群是一组节点，这些节点可以是物理服务器或虚拟机，安装有Kubernetes平台的物理服务器或虚拟机称作Kubernetes节点。通常来说，需要多个Kubernetes节点组建为Kubernetes集群(Kubernetes Cluster)以实现对容器的部署和管理。下面将结合图1对Kubernetes集群的结构及其各个结构的功能进行具体介绍：

如图1所示，一个Kubernetes集群包括主节点(Master)和从节点(Node)；其中，主节点用于对从节点进行管控，以及对从节点中的资源进行资源调度等。

主节点Master：是K8S集群的网关和中枢枢纽，主要作用是暴露应用程序接口(Application Programming Interface，API)接口，对从节点进行管控，例如跟踪从节点的健康状态、以最优方式调度从节点中的资源，以及编排其他组件之间的通信。

从节点Node：是K8S的工作节点，其上部署有Pod对象，一个Pod对象包括一个或多个容器，一个应用程序可以运行在一个Pod上，称之为容器化应用。从节点负责接收来自主节点Master的指令，并根据指令相应地创建和销毁Pod对象以实现从节点的增加或删除，以及调整网络规则进行合理的路由和流量的转发。

在K8S集群中，主节点主要负责接收请求、资源调度以及对从节点进行管理，从节点(Kubernetes Node)用于实际运行由主节点分配的容器。

其中，Master包括：API Server、Controller-Manager、Scheduler和Etcd等组件。下面将对Master的各个组件进行介绍：

API Server：作为整个K8S集群的网关，是K8S对外的唯一接口，所有的资源请求/调用操作都通过该接口实现通信。其主要负责接收、校验并响应所有的REST请求，结果状态被持久存储在Etcd当中，是增加、删除、修改、查询所有资源的唯一入口。

Controller-Manager：负责管理集群中的各种资源，保证资源处于预期的状态。主要功能包括生命周期功能和API业务逻辑，其中，生命周期功能包括命名空间(Namespace)创建和生命周期、事件(Event)垃圾回收、Pod终止相关的垃圾回收、级联垃圾回收及Node垃圾回收等。API业务逻辑包括由副本控制器(ReplicaSet)执行的Pod扩展等。虽然Pod是K8S的最小调度单位，但是K8S并不直接地部署和管理Pod对象，而是借助于Controller-Manager进行管理。Controller-Manager包括：Replication Controller、ReplicaSet、Deployment、StatefulSet、Job等。

Schedule(调度器)：用于资源调度。Scheduler在调度时会对集群的结构进行分析，当前各个节点的负载，以及应用对高可用、性能等方面的需求，从而决定将Pod放到哪个Node上运行。

Etcd：负责保存K8S集群的配置信息和各种资源的状态信息，当数据发生变化时，Etcd会快速地通知K8S相关组件。

其中，从节点Node包括kubelet、kube-proxy、docker等组件。下面将对从节点Node的各个组件进行介绍：

kubelet：kubelet是从节点Node的代理组件，当调度器Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息(image、存储卷(volume)等)发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向Master报告运行状态。

Service：是建立在一组Pod对象之上的资源对象，它是通过标签选择器选择一组Pod对象，并为这组Pod对象定义一个统一的固定访问入口(通常是一个IP地址)，如果K8S存在DNS附件(如coredns)它就会在Service创建时为它自动配置一个DNS名称，用于客户端进行服务发现。

kube-proxy：Service接收到请求就需要通过kube-proxy转发到对应的Pod。每个Node都会运行kube-proxy服务，负责将访问的Service的TCP/UDP数据流转发到后端的容器。

Container Runtime：每个Node都需要提供一个容器的运行(Container Runtime)环境，其主要负责下载镜像并运行容器。

应当理解，以上仅对K8S集群中的主要组件进行了介绍，实际应用中，K8S集群的架构还会包括其它一些组件和结构，具体可以参见已有K8S的架构介绍，本实施例在此不再一一介绍。

通过以上对Kubernetes集群的介绍，可以看出，Kubernetes集群的组件很多，如果手动部署一个Kubernetes集群，就需要手动挨个部署Kubernetes集群中的每个组件，这使得Kubernetes集群的部署很复杂。而使用安装工具部署Kubernetes集群，需要首先确定待部署Kubernetes集群的物理机或虚拟机，然后再在相应的物理机或虚拟机上部署Kubernetes集群，导致每次只能安装一个Kubernetes集群。针对上述问题，本申请通过首先安装一个Kubernetes集群，再借助该Kubernetes集群安装部署其它的Kubernetes集群，如此，其它的Kubernetes集群相当于运行在首先安装的Kubernetes集群上，而不再是运行在物理机或虚拟机上，由于Kubernetes集群本身就具有调度和管控等功能，因此可以同时安装部署多个其它的Kubernetes集群，从而简化Kubernetes集群的部署过程，提高部署效率。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的Kubernetes集群的部署方法流程图。如图2所示，该方法具体步骤如下：

步骤S201、接收用于部署第一Kubernetes集群的第一部署请求。

其中，第一部署请求包括：用于部署第一Kubernetes集群的物理机或虚拟机的标识。

图3为本申请实施例提供的Kubernetes集群的部署系统的架构图。如图3所示，该系统包括：用户终端21、计算设备22和服务器23，其中，计算设备22可以是物理机22或虚拟机22；示例性地，若用户想要在某一台物理机或虚拟机上部署第一Kubernetes集群，用户可以通过用户终端21发送第一部署请求至该物理机或虚拟机。

步骤S202、根据物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群。

可选的，第一Kubernetes集群可以是如图1所示的Kubernetes集群，第一Kubernetes集群的结构可以参见如图1所示的Kubernetes集群的介绍，此处不再重复介绍。

本实施例可以采用手动部署的方式部署第一Kubernetes集群，也可以采用Kubernetes集群的安装工具，例如Kubeadm来安装部署第一Kubernetes集群，本实施例对此不做具体限定。采用安装工具部署第一Kubernetes集群相较于手动部署而言，可以避免手动部署误操作、漏操作等现象，缩短Kubernetes集群的部署时间，提高部署效率。

其中，在第一Kubernetes集群的部署过程中，需要从服务器23中获取Kubernetes集群的二进制数据包，该Kubernetes集群的二进制数据包中包括Kubernetes集群中各个组件的二进制数据包，之后再安装每个组件的二进制数据包，即可完成第一Kubernetes集群的部署。

步骤S203、接收用于部署至少一个第二Kubernetes集群的第二部署请求。

请继续参阅图3，示例性地，在第一Kubernetes集群部署完成后，用户可以通过用户终端21发送第二部署请求至第一Kubernetes集群，其中，第二部署请求包括：第一Kubernetes集群的标识。

可选的，步骤S203不限制是在步骤S201之后执行，用户也可以通过发送一个部署请求，该部署请求包括用于部署第一Kubernetes集群的物理机或虚拟机的标识，以及在完成第一Kubernetes集群的部署之后，在第一Kubernetes集群上部署至少一个第二Kubernetes集群的请求。

步骤S204、根据第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群。

图4A为本申请实施例提供的部署完成的Kubernetes集群的架构图。如图4A所示，包括第一Kubernetes集群41和至少一个第二Kubernetes集群42，本实施例的第一Kubernetes集群运行在物理机或虚拟机上，而至少一个第二Kubernetes集群运行在第一Kubernetes集群之上，由第一Kubernetes集群进行管控。

图4B为本申请另一实施例提供的部署完成的Kubernetes集群的架构图。如图4B所示，第一Kubernetes集群41中示出了N个主节点Master，应当理解，第一Kubernetes集群41并不限于N个主节点Master，还可以包括多个从节点Node(图中未示出)，第一Kubernetes集群41的结构具体可以参见如图1所示的结构，本实施例在此不再赘述。

图4B中的一个方框代表一个物理机或虚拟机，图4B中的一个椭圆代表一个Pod。其中，每个第二Kubernetes集群42包括多个从节点Node，以图4B中的一个第二Kubernetes集群42为例，其包括3个从节点Node，可以看到第一Kubernetes集群41中的一个主节点Master，均可以对第二Kubernetes集群42中的一个组件，即椭圆示出的Pod进行调度和监控。

本申请实施例通过接收用于部署第一Kubernetes集群的第一部署请求，并根据第一部署请求中携带的物理机或虚拟机的标识，在对应的物理机或虚拟机上部署第一Kubernetes集群；之后在接收到用于部署至少一个第二Kubernetes集群的第二部署请求的情况下，根据第二部署请求中包括的第一Kubernetes集群的标识，在对应的第一Kubernetes集群上部署至少一个第二Kubernetes集群，其中，第一Kubernetes集群对至少一个第二Kubernetes集群进行管控。由于第二Kubernetes集群是部署且运行在第一Kubernetes集群上，而不再是单个的物理机或虚拟机上，另外第一Kubernetes集群中主节点本身具有管控多个从节点的功能，而第二Kubernetes集群本身就是容器化应用平台，其包括多个从节点，因此至少一个第二Kubernetes集群相对于第一Kubernetes集群，就像是运行在第一Kubernetes集群上的容器化应用的集群，第一Kubernetes集群中的主节点能够对至少一个第二Kubernetes集群中的从节点进行管控、增加和删除，因此第一Kubernetes集群能够同时安装部署多个第二Kubernetes集群，从而简化Kubernetes集群的部署过程，提高Kubernetes集群的部署效率，以及方便管控。

上述实施例在部署完成第一Kubernetes集群、至少一个第二Kubernetes集群之后，在已部署的至少一个第二Kubernetes集群的基础上，还可以通过第一Kubernetes集群实现对至少一个第二Kubernetes集群的扩容和缩容。下面通过具体的实施方式对通过第一Kubernetes集群实现对至少一个第二Kubernetes集群的扩容和缩容进行详细说明：

其中，通过第一Kubernetes集群对至少一个第二Kubernetes集群进行扩容，包括：

步骤a1、接收扩容请求。

其中，扩容请求包括待扩容的第二Kubernetes集群的标识，请继续参阅图1，第二Kubernetes集群包括从节点，且从节点包括多个从节点组件。第二Kubernetes集群的从节点组件具体可以参见图1所示实施例的介绍，此处不再赘述。

本实施例中，对第二Kubernetes集群进行扩容包括对第二Kubernetes集群中从节点进行扩容。

步骤a2、从镜像仓库中获取从节点组件的docker镜像。

具体的，是根据从节点组件的标识从镜像仓库中获取对应的从节点组件的docker镜像，其中，从节点组件的标识包括从节点组件的名称，例如Kubelet组件的名称、Container Runtime组件的名称、Kube-proxy组件的名称等。

步骤a3、在第一Kubernetes集群中运行从节点组件的docker镜像，生成相应的从节点。

具体的，是将从节点组件的docker镜像文件下载到第一Kubernetes集群所在的物理机或虚拟机上，并在物理机或虚拟机上运行该从节点组件的docker镜像文件，从而生成相应的从节点。

步骤a4、将生成的从节点添加至待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群中。

对于步骤a4而言，可以有以下两种不同的实施方式：

在第一种可选的实施方式中，步骤a4包括：发送通知消息至待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，其中，该通知消息包括：生成的从节点的标识；且该通知消息用于使第二Kubernetes集群根据生成的从节点的标识从第一Kubernetes集群中获取生成的从节点的配置信息，并根据获取的配置信息在第二Kubernetes集群中增加从节点。

本实施方式中，第一Kubernetes集群在生成从节点之后，会将该从节点的配置信息存储至第一Kubernetes集群的数据库中，并发送通知消息至第二Kubernetes集群，该通知消息中携带有该从节点的标识，第二Kubernetes集群在接收到该通知消息后，根据该从节点的标识从第一Kubernetes集群的数据库中获取该从节点的配置信息，并根据获取的配置信息在第二Kubernetes集群中增加相应的从节点。其中，第二Kubernetes集群根据获取的配置信息在第二Kubernetes集群中增加相应的从节点的具体实施过程可以参见现有技术的介绍，此处不再赘述。

在第二种可选的实施方式中，步骤a4包括：发送通知消息至待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，其中，该通知消息包括：生成的从节点的配置信息和待扩容的第二Kubernetes集群的标识；且该通知消息用于使生成的从节点根据待扩容的第二Kubernetes集群的标识确定对应的第二Kubernetes集群，并根据生成的从节点的配置信息在确定的第二Kubernetes集群中进行注册。

本实施方式中，第一Kubernetes集群在生成从节点之后，会将该从节点的配置信息携带在通知消息中，并发送至第二Kubernetes集群，第二Kubernetes集群在接收到该通知消息后，根据该从节点的配置信息在第二Kubernetes集群中增加相应的从节点。其中，第二Kubernetes集群根据获取的配置信息在第二Kubernetes集群中增加相应的从节点的具体实施过程可以参见现有技术的介绍，此处不再赘述。

上述实施例介绍的步骤a4的两种不同实施方式，对于第二Kubernetes集群而言，第一种实施方式属于主动获取方式，即第二Kubernetes集群从第一Kubernetes集群主动获取已生成的节点信息，第二种实施方式属于被动获取方式，即已生成的节点主动去寻找待扩容的第二Kubernetes集群，并将自身注册到该待扩容的第二Kubernetes集群中。

上述实施例中，从节点的配置信息包括：Pod相关yaml文件中的spec数据。

其中，通过第一Kubernetes集群对第二Kubernetes集群进行缩容，包括：

步骤b1、接收缩容请求。

其中，缩容请求包括待缩容的第二Kubernetes集群的标识和待缩容的第二Kubernetes集群中待删除的从节点的标识。

本实施例中，对第二Kubernetes集群进行缩容包括第二Kubernetes集群中的从节点进行缩容。

步骤b2、根据待缩容的第二Kubernetes集群的标识和待缩容的第二Kubernetes集群中待删除的从节点的标识，将对应的第二Kubernetes集群中对应的从节点进行下线操作。

步骤b3、接收缩容后的第二Kubernetes集群发送的通知消息。

其中，通知消息包括缩容后的第二Kubernetes集群中下线的从节点的标识。

步骤b4、根据缩容后的第二Kubernetes集群中下线的从节点的标识，在第一Kubernetes集群中将对应的从节点资源进行回收。

通过步骤b2的下线操作，可以将待删除的从节点从第二Kubernetes集群中删除，对于第二Kubernetes集群而言，其第二Kubernetes集群的数据库中不再存储有该从节点的相关信息。但对于第一Kubernetes集群而言，其数据库中仍然存储有该第二Kubernetes集群的已删除从节点的相关信息，因此，在本步骤的下线操作之后，还需要第二Kubernetes集群发送通知消息以通知第一Kubernetes集群已下线的从节点的标识，从而使第一Kubernetes集群根据已下线的从节点的标识，将已下线的从节点从第一Kubernetes集群的数据库中删除，从而完成资源回收。

其中，第一Kubernetes集群还可以对至少一个第二Kubernetes集群的状态信息进行监控。具体的，至少一个第二Kubernetes集群中每个从节点设置有状态检查功能，至少一个第二Kubernetes集群中每个从节点通过状态检查功能能够监测到自身的状态信息，并将监测到的状态信息上报给第一Kubernetes集群。在一种可选的实施方式中，至少一个第二Kubernetes集群中每个从节点将监测到的自身的状态信息上报给第一Kubernetes集群时，可以是将监测到的自身的状态信息通过第一Kubernetes集群的API server组件上报给第一Kubernetes集群。

Kubernetes集群本身就具有资源调度的功能，在本申请实施例中，Kubernetes集群同样能够进行资源调度，本申请实施例提供的资源调度包括如下步骤：

步骤c1、接收数据处理请求。

其中，第一Kubernetes集群的主节点通过API server组件接收该数据处理请求。

步骤c2、根据数据处理请求，确定资源调度策略。

其中，第一Kubernetes集群的主节点通过API server组件将该数据处理请求转发至调度组件scheduler，调度组件scheduler进而会根据当前所有第二Kubernetes集群中资源的应用情况以及该数据处理请求所需要的资源，确定可利用的第二Kubernetes集群以及可利用的第二Kubernetes集群中可利用的Pod资源。

其中，步骤c2包括：根据数据处理请求生成多个处理任务，并将该多个处理任务分配到可利用的各个第二Kubernetes集群中。

步骤c3、根据资源调度策略，对至少一个第二Kubernetes集群中的Pod资源进行资源调度。

在将该多个处理任务分配到可利用的各个第二Kubernetes集群中之后，各个可利用的第二Kubernetes集群就会通过自身可利用的Pod资源对分配到自身的任务进行任务处理。

可选的，第二部署请求还包括第二Kubernetes集群的部署数量和第二Kubernetes集群的版本标识；相应的，步骤S203包括：

步骤S203a、根据Kubernetes组件的docker镜像的标识，从镜像仓库中获取对应的Kubernetes组件的docker镜像。

本实施例中，Docker包括镜像、容器和仓库；其中，镜像是Docker运行容器的前提，仓库用于存放镜像。Docker镜像可以认为是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含为容器运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。Docker的镜像仓库根据docker镜像的标识可以实现Docker镜像的分发。

可选的，Kubernetes组件的docker镜像的标识包括docker镜像所在镜像仓库的地址信息、docker镜像文件的文件名称等。

步骤S203b、将对应版本的Kubernetes集群中组件的docker镜像运行部署数量对应的次数。

具体的，本步骤是将Kubernetes组件的docker镜像下载到第一Kubernetes集群所在的物理机或虚拟机上，并运行docker镜像，从而实现至少一个第二Kubernetes集群的部署。其中，对于如何运行docker镜像实现至少一个第二Kubernetes集群的部署过程，具体可以参见现有技术的介绍，此处不再赘述。

另外，本实施例还可以通过第一Kubernetes集群对至少一个第二Kubernetes集群进行升级。具体的，通过第一Kubernetes集群对至少一个第二Kubernetes集群进行升级，包括：

步骤d1、接收第二Kubernetes集群的升级请求。

其中，该升级请求包括待升级的第二Kubernetes集群的标识，以及Kubernetes集群组件的升级版本标识。

步骤d2、根据升级版本标识，从镜像仓库获取对应版本的Kubernetes集群组件的docker镜像。

步骤d3、运行对应版本的Kubernetes集群组件的docker镜像，生成相应的第二Kubernetes集群。

步骤d4、将生成的第二Kubernetes集群添加至待升级的第二Kubernetes集群的标识对应的第二Kubernetes集群中，并从第二Kubernetes集群中删除待升级的第二Kubernetes集群的组件。

其中，对于步骤d1至步骤d4的具体实施过程与步骤a1至步骤a4的具体实现过程类似，具体可以参见步骤a1至步骤a4的具体实施方式，本实施例在此不再赘述。

另外，在一种可选的实施方式中，还可以是由第二Kubernetes集群直接从镜像仓库获取对应版本的Kubernetes集群组件的docker镜像，然后通过重启机制，将原有的Kubernetes集群组件进行替换，实现Kubernetes集群组件的升级。

为了方便用户部署Kubernetes集群，以及提供可视化的操作过程。可选的，在上述实施例的基础上，本实施例的方法还可以包括：设置控制台页面，该控制台页面用于为第一用户提供至少一个第二Kubernetes集群的控制功能；和/或，为第二用户提供第二用户对应的第二Kubernetes集群的控制功能；其中，第一用户的控制权限大于第二用户。

图5为本申请另一实施例提供的部署完成的Kubernetes集群的架构图。如图5所示，第一Kubernetes集群还连接至控制终端51，该控制终端51可以是图3中所示的用户终端，控制终端51的图形用户界面上设置有控制台页面。

本实施例中，第一用户的控制权限为管理员权限，其可以对所有的第二Kubernetes集群进行管控，第二用户的控制权限为普通用户权限，其只能对自己权限内的第二Kubernetes集群，例如属于自己租户账号下的第二Kubernetes集群进行管控。

其中，控制功能包括：发送用于部署第一Kubernetes集群的第一部署请求，发送用于部署至少一个第二Kubernetes集群的第二部署请求，发送对第二Kubernetes集群的升级请求。例如，可以开发一客户端，该客户端包括图形用户界面，该图形用户界面包括第一部署请求按钮、第二部署请求按钮、升级按钮等，用户可以通过点击第一部署请求按钮、第二部署请求按钮、升级按钮等，发送第一部署请求、第二部署请求和升级请求，以部署第一Kubernetes集群，在第一Kubernetes集群上部署至少一个第二Kubernetes集群，以及对某一个第二Kubernetes集群进行升级。

可选的，该图形用户界面还可以包括：扩容按钮、缩容按钮，通过扩容按钮、缩容按钮可以分别实现对至少一个第二Kubernetes集群的扩容、缩容。

在上述实施例的基础上，本申请的第一Kubernetes集群还可以使用其他的容器管理平台或者虚拟机管理平台代替，例如dcos、openstack等，对于其他的容器管理平台或者虚拟机管理平台的部署方式，可以参见现有技术的介绍，此处不再赘述。则本实施例的方法还可以包括：

步骤e1、接收用于部署容器管理平台或虚拟机管理平台的第一部署请求，第一部署请求包括：用于部署容器管理平台的物理机或虚拟机的标识，或者用于部署虚拟机管理平台的物理机或虚拟机的标识。

步骤e2、根据物理机或虚拟机的标识，在对应的物理机或虚拟机上部署容器管理平台或虚拟机管理平台。

步骤e3、接收用于部署至少一个第二Kubernetes集群的第二部署请求，第二部署请求包括：容器管理平台或虚拟机管理平台的标识。

步骤e4、根据容器管理平台或虚拟机管理平台的标识，在对应的容器管理平台或虚拟机管理平台上部署至少一个第二Kubernetes集群，容器管理平台或虚拟机管理平台对至少一个第二Kubernetes集群进行管控。

图6为本申请实施例提供的Kubernetes集群的部署装置的结构示意图。本申请实施例提供的Kubernetes集群的部署装置可以执行Kubernetes集群的部署方法实施例提供的处理流程，如图6所示，Kubernetes集群的部署装置60包括：接收模块61和部署模块62；其中，接收模块61，用于接收用于部署第一Kubernetes集群的第一部署请求，所述第一部署请求包括：用于部署所述第一Kubernetes集群的物理机或虚拟机的标识；部署模块62，用于根据所述物理机或虚拟机的标识，在对应的物理机或虚拟机上部署所述第一Kubernetes集群；所述接收模块61，还用于接收用于部署至少一个第二Kubernetes集群的第二部署请求，所述第二部署请求包括：所述第一Kubernetes集群的标识；所述部署模块62，还用于根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群，所述第一Kubernetes集群对所述至少一个第二Kubernetes集群进行管控。

可选的，该装置还包括：获取模块63、运行模块64、添加模块65；其中，接收模块61，还用于接收扩容请求，所述扩容请求包括待扩容的第二Kubernetes集群的标识，所述第二Kubernetes集群包括从节点，所述从节点包括从节点组件；获取模块63，用于从镜像仓库中获取所述从节点组件的docker镜像；运行模块64，用于在所述第一Kubernetes集群中运行所述从节点组件的docker镜像，生成相应的从节点；添加模块65，用于将生成的从节点添加至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群中。

可选的，添加模块65，包括：发送单元651，用于发送通知消息至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，所述通知消息包括：生成的从节点的标识；所述通知消息用于使所述第二Kubernetes集群根据所述生成的从节点的标识从所述第一Kubernetes集群中获取生成的从节点的配置信息，并根据获取的配置信息在所述第二Kubernetes集群中增加所述从节点。

可选的，添加模块65，包括：发送单元651，用于发送通知消息至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，所述通知消息包括：生成的从节点的配置信息和待扩容的第二Kubernetes集群的标识；所述通知消息用于使所述生成的从节点根据待扩容的第二Kubernetes集群的标识确定对应的第二Kubernetes集群，并根据生成的从节点的配置信息在确定的第二Kubernetes集群中进行注册。

可选的，该装置还包括：回收模块66；其中，接收模块61，还用于接收缩容请求，所述缩容请求包括待缩容的第二Kubernetes集群的标识和待缩容的第二Kubernetes集群中待删除的从节点的标识；接收模块61，还用于接收缩容后的第二Kubernetes集群发送的通知消息，所述通知消息包括所述缩容后的第二Kubernetes集群中下线的从节点的标识；回收模块66，用于根据所述缩容后的第二Kubernetes集群中下线的从节点的标识，在所述第一Kubernetes集群中将对应的从节点资源进行回收。

可选的，所述第一Kubernetes集群对所述至少一个第二Kubernetes集群的状态信息进行监控。

可选的，该装置还包括：获取模块63、运行模块64、添加模块65；其中，接收模块61，用于接收第二Kubernetes集群的升级请求；获取模块63，用于根据升级版本标识，从镜像仓库获取对应版本的Kubernetes集群组件的docker镜像；运行模块64，用于运行对应版本的Kubernetes集群组件的docker镜像，生成相应的第二Kubernetes集群；添加模块65，用于将生成的第二Kubernetes集群添加至待升级的第二Kubernetes集群的标识对应的第二Kubernetes集群中。

可选的，第二部署请求还包括第二Kubernetes集群的部署数量和版本标识；该装置还包括：获取模块63、运行模块64、添加模块65；其中，获取模块63，还用于根据第二Kubernetes集群的版本标识，从镜像仓库中获取对应版本的Kubernetes集群中组件的docker镜像；运行模块64，用于将对应版本的Kubernetes集群中组件的docker镜像运行部署数量对应的次数。

图6所示实施例的Kubernetes集群的部署装置可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图7为本申请实施例提供的电子设备的结构示意图。本申请实施例提供的电子设备可以执行Kubernetes集群的部署方法实施例提供的处理流程，如图7所示，电子设备70包括：存储器71、处理器72、计算机程序和通讯接口73；其中，计算机程序存储在存储器71中，并被配置为由处理器72执行以上方法实施例的方法步骤。

图7所示实施例的电子设备可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

另外，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的Kubernetes集群的部署方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (12)

1.一种Kubernetes集群的部署方法，其特征在于，包括：

接收用于部署第一Kubernetes集群的第一部署请求，所述第一部署请求包括：用于部署所述第一Kubernetes集群的物理机或虚拟机的标识；

根据所述物理机或虚拟机的标识，在对应的物理机或虚拟机上部署所述第一Kubernetes集群；

接收用于部署至少一个第二Kubernetes集群的第二部署请求，所述第二部署请求包括：所述第一Kubernetes集群的标识；

根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群，所述第一Kubernetes集群对所述至少一个第二Kubernetes集群进行管控。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群之后，所述方法还包括：

接收扩容请求，所述扩容请求包括待扩容的第二Kubernetes集群的标识，所述第二Kubernetes集群包括从节点，所述从节点包括从节点组件；

从镜像仓库中获取所述从节点组件的docker镜像；

在所述第一Kubernetes集群中运行所述从节点组件的docker镜像，生成相应的从节点；

将生成的从节点添加至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群中。

3.根据权利要求2所述的方法，其特征在于，所述将生成的从节点添加至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群中，包括：

发送通知消息至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，所述通知消息包括：生成的从节点的标识；

所述通知消息用于使所述第二Kubernetes集群根据所述生成的从节点的标识从所述第一Kubernetes集群中获取生成的从节点的配置信息，并根据获取的配置信息在所述第二Kubernetes集群中增加所述从节点。

4.根据权利要求2所述的方法，其特征在于，所述将生成的从节点添加至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群中，包括：

发送通知消息至所述待扩容的第二Kubernetes集群的标识对应的第二Kubernetes集群，所述通知消息包括：生成的从节点的配置信息和待扩容的第二Kubernetes集群的标识；

所述通知消息用于使所述生成的从节点根据待扩容的第二Kubernetes集群的标识确定对应的第二Kubernetes集群，并根据生成的从节点的配置信息在确定的第二Kubernetes集群中进行注册。

5.根据权利要求1所述的方法，其特征在于，所述根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群之后，所述方法还包括：

接收缩容请求，所述缩容请求包括待缩容的第二Kubernetes集群的标识和待缩容的第二Kubernetes集群中待删除的从节点的标识；

接收缩容后的第二Kubernetes集群发送的通知消息，所述通知消息包括所述缩容后的第二Kubernetes集群中下线的从节点的标识；

根据所述缩容后的第二Kubernetes集群中下线的从节点的标识，在所述第一Kubernetes集群中将对应的从节点资源进行回收。

6.根据权利要求1所述的方法，其特征在于，所述第一Kubernetes集群对所述至少一个第二Kubernetes集群的状态信息进行监控。

7.根据权利要求1所述的方法，其特征在于，所述根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群之后，所述方法还包括：

接收第二Kubernetes集群的升级请求；

根据升级版本标识，从镜像仓库获取对应版本的Kubernetes集群组件的docker镜像；

运行对应版本的Kubernetes集群组件的docker镜像，生成相应的第二Kubernetes集群；

将生成的第二Kubernetes集群添加至待升级的第二Kubernetes集群的标识对应的第二Kubernetes集群中。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述第二部署请求还包括第二Kubernetes集群的部署数量和版本标识；

所述根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群，包括：

根据所述第二Kubernetes集群的版本标识，从镜像仓库中获取对应版本的Kubernetes集群中组件的docker镜像；

将对应版本的Kubernetes集群中组件的docker镜像运行部署数量对应的次数。

9.根据权利要求1-7任一项所述的方法，其特征在于，所述第一部署请求是用户通过预设的控制台页面发送的；

和/或，

所述第二部署请求是用户通过所述预设的控制台页面发送的。

10.一种Kubernetes集群的部署装置，其特征在于，包括：

接收模块，用于接收用于部署第一Kubernetes集群的第一部署请求，所述第一部署请求包括：用于部署所述第一Kubernetes集群的物理机或虚拟机的标识；

部署模块，用于根据所述物理机或虚拟机的标识，在对应的物理机或虚拟机上部署所述第一Kubernetes集群；

所述接收模块，还用于接收用于部署至少一个第二Kubernetes集群的第二部署请求，所述第二部署请求包括：所述第一Kubernetes集群的标识；

所述部署模块，还用于根据所述第一Kubernetes集群的标识，在对应的所述第一Kubernetes集群上部署所述至少一个第二Kubernetes集群，所述第一Kubernetes集群对所述至少一个第二Kubernetes集群进行管控。

11.一种电子设备，其特征在于，包括：

存储器；

处理器；

通讯接口；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如权利要求1-9中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-9任一项所述的方法。

Images