CN112395039A - 一种Kubernetes集群的管理方法和装置 - Google Patents

Abstract

本申请实施例公开了一种Kubernetes集群的管理方法和装置。该Kubernetes集群的管理方法，包括：依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。本申请实施例解决了通过主机管理kubernetes集群的方式不能满足各Docker容器自身对kubernetes集群管理需求的技术问题。

Description

一种Kubernetes集群的管理方法和装置

技术领域

本申请涉及云计算机技术领域，具体涉及一种Kubernetes集群的管理方法和装置。

背景技术

Kubernetes是一种容器集群管理系统，其主要功能包括：使用Docker对应用程序进行打包、实例化及运行。Kubernetes以集群的方式运行及管理跨主机的容器。Docker是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中。

目前kubernetes集群的管理是依赖主机实现的，比如，登录主机，运行kubectl工具，用户通过命令行的方式对Kubernetes集群进行管理。这里的kubectl是Kubernetes集群自带的命令行工具，通过kubectl工具能够对Kubernetes集群进行管理，然而在云计算领域，考虑到一些应用场景，比如测试场景中，想要在各Docker容器内部访问Kubernetes集群，那么现有主机管理kubernetes集群的方式不能满足实际应用需求。

发明内容

有鉴于此，本申请实施例提供了一种Kubernetes集群的管理方法和装置，解决了通过主机管理kubernetes集群的方式不能满足各Docker容器内访问和管理kubernetes集群的需求的技术问题。

根据本申请的一个方面，提供了一种Kubernetes集群的管理方法，包括：

依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；

基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；

在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

根据本申请的另一个方面，提供了一种Kubernetes集群的管理装置，包括：

镜像生成模块，用于依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；

容器启动模块，用于基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；

管理模块，用于在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

根据本申请的又一个方面，提供了一种电子设备，所述电子设备包括：处理器，以及存储有可在处理器上运行的计算机程序的存储器；其中，所述处理器，用于在执行所述存储器中的计算机程序时执行本申请一个方面所述的方法。

根据本申请的再一个方面，提供了一种非瞬时性计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本申请一个方面所述方法的步骤。

有益效果：本申请实施例的Kubernetes集群管理的技术方案，依据宿主机中的基础镜像以及kubectl工具的二进制文件，在宿主机中生成目标镜像，基于目标镜像启动目标Docker容器，并将kubectl工具的指定目录挂载到目标Docker容器的目标目录，从而在目标Docker容器内部，通过kubectl工具管理Kubernetes集群。由此，实现了在Docker容器内部使用kubectl工具去管理kubernetes集群，做一些创建、查看、修改、配置、删除等操作，满足了实际应用需求。

附图说明

图1是本申请一个实施例的Kubernetes集群管理方法的流程图；

图2是本申请一个实施例的Kubernetes集群管理装置的框图；

图3是本申请一个实施例的电子设备的结构示意图；

图4是本申请一个实施例的非瞬时性计算机可读存储介质的结构示意图。

具体实施方式

为使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请实施例作进一步详细的说明。显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请实施例保护的范围。

图1是本申请一个实施例的Kubernetes集群管理方法的流程图，参见图1，本实施例的Kubernetes集群管理方法包括下列步骤：

步骤S101，依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像。

宿主机为Kubernetes集群中的一个主机，宿主机上存储有基础镜像以及kubectl工具的二进制文件。基础镜像是指定目录通过Dockerfile做出来的，包含操作系统基础文件和Docker软件运行环境，它使用分层的存储方式。kubectl工具的二进制文件是kubectl工具的二进制安装包。

步骤S102，基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录。

Docker最核心的三个组件是镜像(image)、容器(container)和仓库(repository)。镜像是Docker运行容器前拉取到的本地的对应的镜像，一个镜像可以包含一个完整的操作系统环境和用户需要的其它应用。Docker的镜像是只读的，一个镜像可以创建多个容器。容器是Docker中基于镜像创建的实例，容器可以被启动、开始、停止、删除。每个容器都是相互隔离的，保证安全性。简单理解容器与镜像的关系就是：Docker镜像相当于程序，容器相当于进程。仓库其实是镜像仓库，里面有很多已经打包好的镜像，可以直接使用docker pull命令将仓库中的镜像拉取到本地。

步骤S103，在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

启动目标Docker容器挂载kubectl工具的指定目录之后，即可在目标Docker容器内部去管理Kubernetes集群，而不是通过主机去管理Kubernetes集群，各目标Docker容器可以根据自己的需求访问Kubernetes集群，执行创建操作、删除等，满足了实际应用需求。

考虑到在一些Docker测试场景中，需要通过在Docker容器内部执行kubectl命令以返回想要的结果，比如通过流水线(即工作流)操作创建容器，并在容器内部调用kubernetes接口去创建、删除或者更新一些操作，这些操作仅仅通过主机是不可达到的。因为服务容器化，Docker容器内部调用kubernetes获取数据，只能通过Docker容器内部调用，直接在主机层面操作显得苍白无力。基于此，本申请实施例改进了现有技术，将原来由主机执行的Kubernetes集群管理功能下放到各个Docker容器内部，从而方便在Docker容器内部去管理Kubernetes集群，满足实际应用需求。

本实施例中通过镜像打包工具Dockerfile生成目标镜像，前述依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像包括：利用编写的Dockerfile配置文件，将所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像。

即，通过编写的Dockerfile文件，将kubectl工具的二进制文件打包到基础镜像中生成目标镜像，比如，新建一个Dockerfile，把kubectl工具的二进制文件中的命令复制到Dockerfile文件中，执行docker build命令，编译执行该Dockerfile文件，执行完毕后运行docker images即可得到目标镜像。

由于目标镜像只可读，所以实际应用中需要运行目标镜像创建容器实例。即基于目标镜像启动目标Docker容器，本实施例在启动目标Docker容器的过程中，将宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录。这里的所述宿主机本地的kubectl工具的指定目录具体是/root/.kube目录，目标Docker容器的目标目录具体是/home/kubectl/.kube目录，即，将/root/.kube目录挂载到目标Docker容器的/home/kubectl/.kube。

需要说明的是，之所以将kubectl工具的指定目录，即/root/.kube目录挂载到目标Docker容器是因为容器内部需要.kube文件，通过docker的共享目录方式，把宿主机的目录共享给Docker容器使用，这样就不必二次生成此目录了。该kube目录下面主要是连接Kubernetes集群的密钥文件，在通过https(Hypertext Transfer Protocol Secure，超文本传输安全协议)访问Kubernetes集群时需要做证书加密所以使用.kube文件。

另外，为了保证可以在目标Docker容器内部管理Kubernetes集群，本实施例中还在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群之前，进入所述目标Docker容器内部，执行预设命令验证所述kubectl工具是否可用，如果kubectl工具不可用，则输出提示检查信息。比如提示检查挂载目录文件是否挂载失败，或者网络是否通信，是否与kubernetes在同一网络等。

一个实施例中通过kubectl工具执行执行预设命令验证所述kubectl工具是否可用，包括：在所述目标Docker容器内部，执行kubectl创建命令，创建一个资源；如果返回资源创建成功的结果，则确定所述kubectl工具可用。比如，执行Kubectl create ns xxx，如果创建成功，则确定在容器内部可以使用kubectl工具管理Kubernetes集群。当然，验证kubectl工具是否可用不限于前述创建命令，还可以是kubectl get nodes、kubectl getpod、kubectl delete命令等。

考虑到现实中还有在目标Docker容器内部管理Docker的需求，本实施例中，依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像包括：利用编写的Dockerfile配置文件，将Docker的二进制文件以及所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像。也就是说，将Docker的二进制文件与kubectl工具的二进制文件一起打包生成目标镜像，后续，在启动该目标Docker容器的过程中，将宿主机本地的/var/run/docker.sock目录挂载到目标Docker容器的/var/run/，从而，在目标Docker容器内部，既可以实现对Docker的管理又能够通过kubectl工具对Kubernetes集群进行管理。前述在目标Docker容器内部，对Docker的管理比如，在目标Docker容器内部打包镜像、创建新的Docker，快速拉起业务应用，拉起应用集群，上传镜像到镜像仓库，下载镜像到本地等。

前述Docker的二进制文件是Docker官方提供的安装方式，目前Docker的安装方式有源码方式和二进制文件安装方式，由于源码需要编译而二进制文件不需要编译，所以这里是将Docker的二进制文件直接打包到镜像中生成目标镜像。

由上可知，本申请实施例的Kubernetes集群管理方法能够实现在Docker容器内部打包镜像，上传镜像到镜像仓库等操作以及在Docker容器内部管理kubernetes集群，进行增、删、改、查等操作，满足了实际需求。

与前述Kubernetes集群管理方法同属于一个技术构思，本申请实施例还提供了一种Kubernetes集群管理装置，图2是本申请一个实施例的Kubernetes集群管理装置的框图，参见图2，本实施例的Kubernetes集群的管理装置200，包括：

镜像生成模块201，用于依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；

容器启动模块202，用于基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；

管理模块203，用于在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

在本申请的一个实施例中，所述镜像生成模块201，具体用于利用编写的Dockerfile配置文件，将所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像。

在本申请的一个实施例中，所述宿主机本地的所述kubectl工具的指定目录为/root/.kube目录，所述目标Docker容器的目标目录为/home/kubectl/.kube目录。

在本申请的一个实施例中，所述镜像生成模块201，具体用于利用编写的Dockerfile配置文件，将Docker的二进制文件以及所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像；还用于，将所述宿主机本地的/var/run/docker.sock目录挂载到目标Docker容器的/var/run/目录。

在本申请的一个实施例中，Kubernetes集群的管理装置200还包括：验证模块，用于进入所述目标Docker容器内部，通过kubectl工具执行预设命令验证所述kubectl工具是否可用；如果所述kubectl工具不可用，则输出提示检查信息。

在本申请的一个实施例中，所述验证模块，具体用于在所述目标Docker容器内部，执行kubectl创建命令，创建一个资源；如果返回资源创建成功的结果，则确定所述kubectl工具可用。

关于图2所示装置中的各模块所执行的各个功能的举例解释说明，与前述方法实施例中的举例解释说明一致，这里不再一一赘述。

综上所述，本申请实施例的Kubernetes集群的管理方案，通过编写的Dockerfile模板文件将Docker的二进制文件以及kubectl工具的二进制文件打包到基础镜像中生成目标镜像，基于目标镜像启动目标Docker容器，并在容器启动的过程中赋予Docker容器执行权限(即，挂载宿主机的sock文件到容器以及挂载kubectl工具的/root/.kube目录到容器)。如此，在目标Docker容器启动后即可在目标Docker容器中管理Docker以及kubernetes集群，满足了实际应用需求。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请实施例的内容，并且上面对特定语言所做的描述是为了披露本申请实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个申请方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，申请方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的页面性能测试装置中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

例如，图3是本申请一个实施例的电子设备的结构示意图。该电子设备300包括：处理器301，以及存储有可在所述处理器301上运行的计算机程序的存储器302。处理器301，用于在执行所述存储器302中的计算机程序时执行本申请实施例中方法的各步骤。存储器302可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器302具有存储用于执行上述方法中的任何方法步骤的计算机程序304的存储空间303。计算机程序304可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图4所示的非瞬时性计算机可读存储介质。

图4是本申请一个实施例的非瞬时性计算机可读存储介质的结构示意图。该计算机可读存储介质400存储有用于执行根据本申请实施例的方法步骤的计算机程序304，可以被电子设备300的处理器301读取，当计算机程序304由电子设备300运行时，导致该电子设备300执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算程序304可以执行上述任一实施例中示出的方法。计算机程序304可以以适当形式进行压缩。

应该注意的是上述实施例对本申请实施例进行说明而不是对本申请实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词、第二、以及第三等的使用不表示任何顺序，可将这些单词解释为名称。

Claims (10)

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

依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；

基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；

在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

2.如权利要求1所述的方法，其特征在于，所述依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像包括：

利用编写的Dockerfile配置文件，将所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像。

3.如权利要求1所述的方法，其特征在于，所述宿主机本地的所述kubectl工具的指定目录为/root/.kube目录，

所述目标Docker容器的目标目录为/home/kubectl/.kube目录。

4.如权利要求1所述的方法，其特征在于，所述依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像包括：

利用编写的Dockerfile配置文件，将Docker的二进制文件以及所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像；

该方法还包括：

将所述宿主机本地的/var/run/docker.sock目录挂载到目标Docker容器的/var/run/目录。

5.如权利要求1所述的方法，其特征在于，在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群之前，该方法还包括：

进入所述目标Docker容器内部，通过kubectl工具执行预设命令验证所述kubectl工具是否可用；如果所述kubectl工具不可用，则输出提示检查信息。

6.如权利要求5所述的方法，其特征在于，所述通过kubectl工具执行预设命令验证所述kubectl工具是否可用包括：

在所述目标Docker容器内部，执行kubectl创建命令，创建一个资源；

如果返回资源创建成功的结果，则确定所述kubectl工具可用。

7.一种Kubernetes集群的管理装置，其特征在于，包括：

镜像生成模块，用于依据宿主机中的基础镜像以及kubectl工具的二进制文件，在所述宿主机中生成目标镜像；

容器启动模块，用于基于所述目标镜像启动目标Docker容器，并将所述宿主机本地的所述kubectl工具的指定目录挂载到所述目标Docker容器的目标目录；

管理模块，用于在所述目标Docker容器内部，通过所述kubectl工具管理所述Kubernetes集群。

8.如权利要求7所述的装置，其特征在于，所述镜像生成模块，具体用于利用编写的Dockerfile配置文件，将所述kubectl工具的二进制文件打包到所述基础镜像中，在所述宿主机中生成目标镜像。

9.一种电子设备，其特征在于，所述电子设备包括：处理器，以及存储有可在处理器上运行的计算机程序的存储器；

其中，所述处理器，用于在执行所述存储器中的计算机程序时执行权利要求1-6中任一项所述的方法。

10.一种非瞬时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1-6中任一项所述方法的步骤。

Images