CN115202820A - Pod单元的创建方法、装置、设备及存储介质 - Google Patents

Abstract

本申请的实施例揭示了一种Pod单元的创建方法、装置、设备及存储介质。该方法包括：监控Kunbernetes集群中的Pod单元创建请求，所述Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息；获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在所述已安装的CNI信息中；若判断为否，则发起目标CNI的安装请求，以在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，并根据安装成功的所述目标CNI创建所述Pod单元。本申请的实施例能够不需要人工介入自动对Pod单元创建请求中包含的目标CNI进行安装，提高了Kunbernetes集群的工作效率和配置的灵活性。

Description

Pod单元的创建方法、装置、设备及存储介质

技术领域

本申请涉及云计算网络技术领域，具体涉及一种Pod单元的创建方法、装置、设备及存储介质。

背景技术

随着云原生技术的发展，越来越多的应用使用云原生的方式进行构建和部署。现有的Kubernetes集群是自动化部署、扩展和管理容器化应用程序的开源系统，是云原生应用首选的部署和管理平台，其中Pod单元是Kubernetes部署、管理的最小计算单元，Pod单元中可以包含一个或多个容器，Pod中的容器共享Pod单元的网络资源。Kubernetes创建的Pod单元默认只有一个网卡，而在云原生背景下运营商网络云化的过程中，一个网元的功能可能会由若干个Pod单元来承载，Pod单元需要配置多个网卡，每个网卡走不同的流量。为解决此问题，出现了给Pod单元配置多网卡的容器网络接口(CNI)，如Multus和CNI-Genie。但这两个CNI给Pod单元配置多网卡的前提是需要在Kubernetes集群中已经安装好需要的CNI(如Calico、Canal、Weave等)，而目前CNI的安装往往需要人工介入，无法实现按需自动安装。

发明内容

为解决上述技术问题，本申请的实施例提供了一种Pod单元的创建方法、装置、设备及存储介质。

根据本申请实施例的一个方面，提供了一种Pod单元的创建方法，包括：

监控Kunbernetes集群中的Pod单元创建请求，所述Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息；

获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在所述已安装的CNI信息中；

若判断为否，则发起目标CNI的安装请求，以在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，并根据安装成功的所述目标CNI创建所述Pod单元。

根据本申请实施例的一个方面，提供了一种Pod单元的创建装置，包括：

监控模块，用于监控Kunbernetes集群中的Pod单元创建请求，所述Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息；

获取模块，用于获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在所述已安装的CNI信息中；

创建模块，用于若判断为否，则发起目标CNI的安装请求，以在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，并根据安装成功的所述目标CNI创建所述Pod单元。

在本申请的一个实施例中，所述装置还包括：

判断模块，所述判断模块用于：

判断所述目标CNI是否安装成功；

若判断为是，则将所述目标CNI信息记录为所述Kubernetes集群中已安装的CNI信息；

若判断为否，则重新发起所述目标CNI的安装请求。

在本申请的一个实施例中，所述创建模块包括：

配置子模块，用于在所述选定创建所述Pod单元的节点上配置所述目标CNI的配置文件；

安装子模块，用于基于所述目标CNI的配置文件安装所述目标CNI对应的插件。

在本申请的一个实施例中，所述装置还包括：

解析模块，用于解析所述Pod单元创建请求，以获得创建所述Pod单元所需的目标CNI信息和选定创建所述Pod单元的节点。

在本申请的一个实施例中，所述创建模块还包括：

调用子模块，用于通过所述选定创建所述Pod单元的节点上的Kubelet服务进程调用所述目标CNI和对应的容器运行时接口CRI来创建所述Pod单元。

在本申请的一个实施例中，所述创建模块具体用于：

通过所述Kubelet服务进程，连接所述CRI调用相应的服务来创建并启动容器，以及调用所述目标CNI对应的插件来配置所述Pod单元的网络，以创建所述Pod单元。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如前所述的Pod单元的创建方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的Pod单元的创建方法。

在本申请的实施例所提供的技术方案中，通过监控Kunbernetes集群中的Pod单元创建请求，获取得到该Pod单元创建所需使用到的目标容器接口CNI信息，并在通过查询数据库中记录的Kunbernetes集群中已经安装的CNI信息中没有所需使用的目标CNI信息后，自动发起目标CNI的安装请求，并在安装目标CNI安装成功后基于该目标CNI创建Pod单元，以此，不需要人工介入，按照Pod单元创建请求中包含的目标CNI自动安装，提高了Kunbernetes集群系统的工作效率和配置的灵活性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本申请的一示例性实施例示出的Pod单元的结构示意图；

图2是本申请的一示例性实施例示出的在Kubernetes集群中创建Pod单元的实施环境示意图；

图3是本申请的一示例性实施例示出的Pod单元的创建流程图；

图4是本申请另一示例性实施例示出的Pod单元的创建流程图；

图5是通过Kubelet创建Pod单元的架构图；

图6是本申请的另一示例性实施例示出的Pod单元的创建的架构图；

图7是另一示例性实施例示出的调用Kubelet创建container(容器)的示意图；

图8是本申请的另一示例性实施例示出的Pod单元的创建的流程图；

图9示意性地示出了本申请实施例提供的Pod单元的创建装置的结构框图；

图10示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

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

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

在本申请中提及的“多个”是指两个或者两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

首先需要说明的是，Kubernetes是一个开源的用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署，规划，更新，维护的一种机制。传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build(构建)或release(发行)的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

如图1所示，Pod单元是Kubernetes集群中的最小部署单元，请参见图1，Pod单元由一个或者多个容器组成，同一个Pod单元中容器共享网络命名空间，每个Pod单元都有一个根容器(pause容器)用来管理Pod单元中用户业务容器，Pod单元是Kubernetes集群中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在Kubernetes上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展Pod单元对象功能的，比如控制器对象是用来管控Pod单元对象的，Service(访问入口)或者Ingress(负载均衡器暴露集群内服务的工具)资源对象是用来暴露Pod单元引用对象的，PersistentVolume(持久卷)资源对象是用来为Pod单元提供存储等等，Kubernetes不会直接处理容器而是Pod单元，Pod单元是由一个或多个container(容器)组成，并且Pod单元是Kubernetes的最重要概念，每一个Pod单元都有一个特殊的被称为”根容器“的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，当然除Pause容器，每个Pod单元还包含一个或多个紧密相关的用户业务容器。

CNI(Conteinre Network Interface)是容器网络标准，旨在为容器平台提供网络的标准化。不同的容器平台(比如目前的Kubernetes、mesos和rkt)能够通过相同的接口调用不同的网络组件。CNI由一组用于配置Linux容器的网络接口的规范和库组成，同时还包含了一些插件，它本身并不是实现或者代码，可以理解成一个协议。这个标准是在rkt网络提议的基础上发展起来的，综合考虑了灵活性、扩展性、ip分配、多网卡等因素。在Kubernetes集群中已经内置了CNI，Kubelet通过这个标准的API来调用不同的网络插件以实现不同的网络配置方式，实现了这个接口的就是CNI插件，它实现了一系列的CNIAPI接口。常见的CNI插件包括Calico、flannel、Terway、Weave Net以及Contiv。Kubernetes集群通过CNI配置文件来决定使用什么CNI。

请参见图2，图2是本申请的实施例涉及的一种实施环境示意图，在Kunbernetes集群中创建一个新的Pod单元流程为：用户通过kubectl向APIServer发起一个create Pod单元的请求；APIServer接收到Pod单元创建请求后，不会去直接创建Pod单元，而是生成一个包含创建信息的文件；API Server将刚才的文件信息写入etcd数据库。到此为止仅仅是在etcd中添加了一条记录，还没有任何的实质性进展。还需要通过APIServer中的组件scheduler查看Kubernetes集群中的API接口，类似于通知机制，通过先判断：Pod.spec.Node是否为null？若为null，表示这个Pod单元请求是新来的，需要创建；因此先进行调度计算，找到最“闲”的Node(节点)，并将创建新的Pod单元的任务分配给这个最闲的“Node”。然后将信息etcd数据库中更新分配结果，通过Pod.spec.Node＝nodeA(设置一个具体的节点)，同样上述操作的各种信息也要写到etcd数据库中，Kubelet通过监测etcd数据库(即不停地看etcd中的记录)，发现APIServer中有了个新的Node；如果这条记录中的Node与自己的编号相同(即这个Pod单元由scheduler分配给自己)；则调用Node中的dockerapi，创建container(容器)，由此创建新的Pod单元。

请参阅图3，图3是本申请的一示例性实施例示出的一种Pod单元的创建方法的流程图。参见图3，Pod单元的创建方法包括步骤S310至步骤S330，详细介绍如下：

步骤S310，监控Kunbernetes集群中的Pod单元创建请求，Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息。

对于Kunbernetes集群中的节点而言，一般根据需要输入的Pod单元创建请求，在该Pod单元创建请求中包括新创建的Pod单元所需的多个网卡的信息，CNI的全称是Container Network Interface，即容器网络的API接口。它是Kunbernetes中标准的一个调用网络实现的接口。Kubelet通过这个标准的API来调用不同的网络插件以实现不同的网络配置方式。实现了这个接口的就是CNI插件，它实现了一系列的CNI API接口。在实际应用中常见的CNI插件包括Calico、flannel、Terway、Weave Net以及Contiv。

示例性地，Kubernetes集群中master(集群控制节点)接收到输入的Pod单元创建请求，在云原生网络演进应用场景下，一个网元的功能可能由若干个Pod单元来承载，Pod单元需要配置多个网卡，每个网卡走不同的流量，在Kubernetes作为主流的云原生应用部署、管理平台，在Kubernetes集群中创建的Pod单元默认只有一个网卡，为了给Pod单元配置多网卡，一般需要预先安装好需要的CNI，在本实施例中获取创建该Pod单元所需的CNI插件，一般情况下，在Pod单元创建请求中包含有创建该Pod单元所需的CNI插件信息。

步骤S320，获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在已安装的CNI信息中。

通过在数据库中获取Kubernetes集群中已经安装好的CNI信息，其中，可以是通过将Kubernetes集群中的CNI-Controller(CNI管理器)从数据库中记录的已经安装好的CNI信息，并且与Pod单元创建请求中的所需的目标CNI信息进行对比，确定Kubernetes集群中没有安装的目标CNI。由此，得到待安装的目标CNI信息。通过CNI-Controller自动判断创建Pod单元所需的目标CNI信息是否记录在已安装的CNI信息中。

示例性的，CNI-Controller监控Kubernetes集群中Pod单元创建请求，并获取Pod单元创建请求中的创建Pod单元所需的目标CNI信息，并从数据库中调取Kubernetes集群中已经安装的CNI信息，判断新建Pod单元所需的目标CNI信息是否已经安装。例如：CNI-Controller监控到Kubernetes集群中的Pod-1安装请求中包括有创建Pod-1所需的目标CNI：Calico、flannel、Terway；并从数据库中获取Kubernetes集群中已经安装好的CNI有：Calico、Weave Net、Contiv；由此可以判断出如果要新创建Pod-1需要预先安装好：flannel、Terway。

步骤S330，若判断为否，则发起目标CNI的安装请求，以在Kunbernetes集群中响应于安装请求，进行目标CNI的安装，并根据安装成功的目标CNI创建Pod单元。

若在数据库中保存的Kubernetes集群中已经安装的CNI信息中不存在创建新的Pod单元所需的目标CNI时，自动发起目标CNI创建的请求，以在Kubernetes集群中响应该目标CNI创建请求，进行对目标CNI的安装，并根据安装成功的目标CNI创建新的Pod单元，以此，无需人工介入对新创建Pod单元所需的CNI进行安装。

示例性的，在Kubernetes集群中当监测到用户发起的创建Pod单元的请求时，CNI-Controller获取该创建Pod单元请求中所需要的目标CNI信息并与数据库中记录的Kubernetes集群中已经安装的CNI信息进行对比，得到集群中还未安装的目标CNI，主动发起未安装的目标CNI的安装请求，以在Kubernetes集群中响应该安装请求，进行目标CNI的安装。当目标CNI安装成功后，基于创建新的Pod单元所需的目标CNI在Kubernetes集群中进行Pod单元创建的响应，以进行Pod单元的创建。例如：用户通过Kubectl发起Pod-2的创建请求，CNI-Controller监控到Pod-2创建所需要的目标CNI包括：Calico、Weave Net、Contiv，在Kubernetes集群数据库中记录已经集群中已经安装的CNI为：Calico、flannel、Terway，CNI-Controller经过对比得到Kubernetes集群中还需要安装的目标CNI为：Weave Net、Contiv，CNI-Controller则在Kubernetes集群中发起目标CNI:Weave Net、Contiv的安装请求，以在Kunbernetes集群中响应于目标CNI的安装请求，进行目标CNI的安装，并根据安装成功的目标CNI创建Pod-2。

在本实施例中，通过监控Kunbernetes集群中的Pod单元创建请求，获取得到该Pod单元创建所需使用到的目标容器接口CNI信息，并在通过查询数据库中记录的Kunbernetes集群中已经安装的CNI信息中没有所需使用的目标CNI信息后，自动发起目标CNI的安装请求，并在安装目标CNI安装成功后基于该目标CNI创建Pod单元，以此，不需要人工介入，按照Pod单元创建请求中包含的目标CNI自动安装，提高了Kunbernetes集群系统的工作效率和配置的灵活性。

在本申请的另外一个示例性实施例中，请参照图4，图3所示的实施例中在发起目标CNI的安装请求之后，该方法还包括如下所示的步骤S340至步骤S360：

步骤S340，判断目标CNI是否安装成功。

由上述内容可知，CNI(container network interface)是容器网络接口，它是一种标准设计和库，为了让用户在容器创建或者销毁时都能够更容易的配置容器网络。目前比较流行的CNI插件：Flannel、Calico、Weave、Canal(技术上是多个插件的组合)。这些插件即可以确保满足Kubernetes集群的网络要求，又能为Kubernetes集群管理员提供他们所需的某些特定的网络功能。CNI规范中用于配置网络的插件接口，可以让容器运行时与插件进行协调，具体机制如下：插件负责为接口配置和管理IP地址，并且同于提供与IP管理、每个容器的IP分配、以及多主机连接相关的功能。容器运行时会调用网络插件，从而在容器启动时分配IP地址并配置网络策略，并在删除容器时再次调用插件以清理这些资源。在Kubernetes集群中，Kubelet可以在适当的时间调用插件，来为通过Kubelet启动的Pod单元进行自动的网络配置。检测在Kubernetes集群中是否成功安装目标CNI，其中，检测方法不限于对目标CNI的配置文件是否安装完成。

示例性的，根据判断对比Kubernetes集群中没有安装创建Pod单元所需的目标CNI为：Flannel相对容易安装和配置。它被打包为单个二进制文件flanneld，许多常见的Kubernetes集群部署工具和许多Kubernetes集群发行版都可以默认安装Flannel。Flannel可以使用Kubernetes集群的现有etcd集群来使用API存储其状态信息，因此不需要专用的数据存储。Flannel配置第三层IPv4 overlay网络。它会创建一个大型内部网络，跨越集群中每个节点。在此overlay网络中，每个节点都有一个子网，用于在内部分配IP地址，在配置Pod单元时，每个节点上的Docker桥接口都会为每个新容器分配一个地址，同一主机中的Pod单元可以使用Docker桥接进行通信，而不同主机上的Pod单元会使用flanneld将其流量封装在UDP数据包中，以便路由到适当的目标。

步骤S350，若判断为是，则将目标CNI信息记录为Kubernetes集群中已安装的CNI信息。

当检测到目标CNI已经安装成功后，即检测到目标CNI的配置文件已经安装在Kubernetes集群中对应的节点上时，将该已经安装好的CNI信息记录在数据库中已经安装的CNI信息中，以便于查阅Kubernetes集群中已经安装好的CNI，并在再次调用的时候自动化调用已经配置好的CNI。

示例性地，当CNI-Controller监控到Kubernetes集群中新发起的Pod-3创建请求时，在Pod-3的创建请求中解析出创建Pod-3需要的目标CNI包括Calico、flannel、Terway，根据数据库中记录的创建Pod-2时新建的CNI：flannel、Terway，可知创建Pod-3的仅需发起Calico的创建即可，由此提高了Pod单元的创建效率。

步骤S360，若判断为否，则重新发起目标CNI的安装请求。

当目标CNI在Kubernetes集群的节点上的安装没有成功时，重新在Kubernetes集群中发起目标CNI的安装请求，以使得在Kubernetes集群中响应目标CNI的安装。在本实施例中，判断CNI是否安装成功的方案可以是检查Kubernetes集群中对应的节点上是否安装该CNI对应的插件，本实施例在此不作任何限制。在检测到目标CNI在Kubernetes集群上没有安装成功后，继续发起目标CNI的安装请求直至目标CNI在Kubernetes集群上安装成功，以保证后续的Pod单元能够成功安装。

在本实施例中，通过判断目标CNI是否安装成功，对已经成功安装的CNI记录在数据库的Kubernetes集群已经安装完成的CNI信息中，对未能成功安装的CNI重新发起安装请求，直至安装成功。以此，不仅保证了后续创建新的Pod单元可以直接使用安装完成的CNI，而且保证了所有需要的目标CNI全部安装成功。

在本申请的另一个示例性实施例中，图3的实施例中的步骤S330可进一步实现如下所示的步骤S331至步骤S332:

步骤S321，在选定创建Pod单元的节点上配置目标CNI的配置文件。

步骤S322，基于目标CNI的配置文件安装目标CNI对应的插件。

请参见图5，在Kubernetes集群中对应的节点上搭建安装目标CNI的整体框架，并从目标CNI的配置文件中获取出必要信息。其中必要的信息一共有两部分组成，第一个是在/etc/cni/net.d下的配置文件会被以标准输出的方式传送给CNI，第二个是容器运行时信息会以环境变量的方式由CNI使用。从环境变量中获取容器运行时信息，主要包括containerID，netns，ifName(容器内的网卡名)，args(从CNI_ARGS环境变量中获取的)，path(CNI的二进制文件地址)，stdinData(配置文件的标准输出内容，[]byte类型)。再通过设置etcd客户端实现CNI需要实现的PodIP地址管理功能。创建IP地址管理服务，即除了需要在etcd中设置一个pool(数据池)用来保存网段之外，还在etcd中为每个节点设置了一个用来记录“当前节点已使用的ip”的key(秘钥)，以使得当某个节点上又有新的Pod单元被创建的时候，就去遍历这个key下已经使用了的所有ip，然后选择最后一个ip+1的ip地址作为当前新Pod单元的ip，并将这个ip地址重新写回到这个key下。最后通过veth pair(虚拟网络接口)设备和bridge(桥接)设备实现相互隔离的两个Pod单元之间通信，由此即完成了在Kubernetes集群中CNI的安装。

进一步地，基于上述实施例，在本申请另外一个示例性的实施例中，步骤S310之后还包括步骤S3101：

步骤S3101，解析Pod单元创建请求，以获得创建Pod单元所需的目标CNI信息和选定创建Pod单元的节点。

当监控到Kubernetes集群中的Pod单元创建指令，集群里面创建一个Pod单元的时候，首先会通过APIServer将Pod单元的配置写入。APIServer的一些管控组件(比如Scheduler)会调度到某个具体的节点上去，Kubelet监听到这个Pod单元的创建之后，会在本地进行一些创建的操作。当执行到创建网络这一步骤时，首先它会读取刚才我们所说的配置目录中的配置文件，配置文件里面会声明所使用的是哪一个CNI，然后去执行具体的CNI插件的二进制文件，再由CNI插件进入Pod单元的网络空间去配置Pod单元的网络。配置完成之后，Kubelet也就完成了整个Pod单元的创建过程，这样这个Pod单元就在线了。

进一步地，请参见图6，基于上述实施例，在本申请所提供的另一个示例性实施例中，方法还包括：

通过选定创建Pod单元的节点上的Kubelet服务进程调用目标CNI和对应的容器运行时接口CRI来创建Pod单元。

由上述内容可知，Pod单元是Kubernetes集群创建或部署的最小/最简单的基本单位，一个Pod单元代表集群上正在运行的一个进程。一个Pod单元封装一个应用容器(也可以有多个容器)，存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod单元代表部署的一个单位：Kubernetes集群中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。

首先Kubelet会启动CRI Runtime，也就是container runtime interface(接口)，具体的，就是在Kubelet端启动一个grpc的客户端，然后需要有个对应的CRI Server端，这里一般实现就是containerd(容器虚拟化技术)，也就是说containerd会启动一个grpc的服务端，接收来自Kubelet的“创建Pod单元”的请求。

在接到这个请求后，containerd(容器虚拟化技术)会调用“创建Sandbox(沙箱)”的接口，所谓创建Sandbox就是给Pod单元中的容器们提前启动一个具有稳定网络资源以及存储资源的隐藏根pause容器。但是containerd属于“高级运行时”，真正去拉起容器的地方在OCI(容器标准Open Container Initiative)中，也叫“低级运行时”，一般实现可能由runc或者kata等小型容器引擎，其中最常用的是runc。然后由于为了给Sandbox创建网络资源，会先去/etc/cni/net.d文件夹目录下加载网络配置文件，然后根据配置文件中的type字段，去/opt/cni/bin文件夹目录下找对应的二进制插件，随后把容器的运行时信息作为环境变量，再把配置文件作为标准输出，对这个二进制进行调用。其中，二进制插件调用的过程主要就是要实现三个点：1.Pod单元ip的管理，2.通主机Pod单元间通信，3.不同主机间Pod单元通信。等以上三点都实现后，需要二进制插件在标准输出上打印点东西，CRI读取这些信息做后续的操作。

进一步地，基于上述实施例，在本申请所提供的另一个示例性实施例中，方法还包括：

通过Kubelet服务进程，连接CRI调用相应的服务来创建并启动容器，以及调用目标CNI对应的插件来配置Pod单元的网络，以创建Pod单元。

在Kubernetes集群中创建一个Pod单元时，首先会通过APIServer将创建该Pod单元所需的配置写入。APIServer的一些管控组件(例如scheduler)会调度到某个具体的节点上去，Kulebet监听到这个Pod单元的创建信息之后，会在本地进行一些创建的操作，当执行到创建网络这一步骤时，它首先会读取到配置目录中的配置文件，其中，配置文件里面会声明所使用的是哪一个CNI插件，然后去执行具体的CNI插件的二进制文件。

请参见图7，Kubelet调用下层容器运行时的执行过程，并不会直接调用Docker的API，而是通过一组叫作CRI(Container Runtime Interface，容器运行时接口)的gRPC接口来间接执行的。Kubelet实际上就会调用一个叫作GenericRuntime的通用组件来发起创建Pod单元的CRI请求。Kubernetes集群通过虚拟出一个CRI shim(实现了CRI接口的容器运行时通常称为CRI shim，)(例如：dockershim)让容器项目能够自主开发，进而为Kubernete集群提供一个统一的容器抽象层，使得下层容器运行时可以自由地对接进入Kubernetes集群当中。

需要说明的是，CRI是Container Runtime Interface(容器运行时接口)的简写，CRI解耦了Kubelet与容器运行时，让Kubelet无需重新编译就可以支持多种容器运行时，Kubelet将通过CRI接口来跟第三方容器运行时进行通信，来操作容器与镜像。实现了CRI接口的容器运行时通常称为CRI shim，dockershim属于Kubelet内置CRI shim，其余remoteCRI shim的创建Pod单元调用流程其实与dockershim调用基本一致，只不过是调用了不同的容器引擎来操作容器，但一样由CRI shim调用CNI来构建Pod单元的网络，这是一个gRPCServer(通信服务器)，监听在本地的unix socket通信的路径配置上；而Kubelet作为gRPC的客户端来调用CRI接口，来进行Pod单元和容器、镜像的生命周期管理。

在Kubernetes集群中，每个Node都会启动Kubelet进程，用来处理Master节点下发到本节点的任务，管理Pod单元和其中的容器。Kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源。可以把Kubelet理解成【Server-Agent】架构中的agent(代理人)，是Node上的Pod单元管家。

Kubelet启动时，具体通过network-plugin＝cni指令启用CNI，通过--cni-bin-dir参数指定CNI插件所在主机目录(默认为/opt/cni/bin/)、通过--cni-conf-dir参数指定CNI配置文件所在主机目录(默认为/etc/cni/net.d)在节点上创建Pod单元前，会先读取CNI配置文件(xxnet.conf)，执行安装在主机上的CNI二进制插件(xxnet)通过这些API调用网络插件为Pod单元配置网络。

在本实施例中，通过预创建Pod单元的节点上的Kubelet调用已经成功安装的目标CNI和对应的容器运行接口(CRI)创建Pod单元，减少了在创建过程中再去安装目标CNI的过程，并且直接调用已经已经自动安装成功的目标CNI大大提高了Pod单元的创建效率。

进一步地，基于上述实施例，在本申请所提供的另一个示例性实施例中，还包括：

Pod单元创建请求中包括多个创建Pod单元所需使用的目标CNI信息，用以指示在Kubernetes集群中进行各目标CNI的安装，并根据安装成功的各目标CNI创建Pod单元。

也就是说，在用户发送的创建Pod单元的请求中，包括多个创建Pod单元需要的目标CNI，例如：Canal、Flannel等。判断Pod单元创建请求中包括的目标CNI是否在Kubernetes集群中已经安装。对没有安装的目标CNI进行安装，确定Pod单元创建的节点，通过节点上的Kubelet调用Pod单元创建请求中声明的需要的多个目标CNI和容器运行时间接口创建Pod单元。

请参照图8，图8示出了本申请一个据图实施例提供的Pod单元的创建方法的流程图，具体如下：

步骤S1.API Server接收Pod单元创建请求；

步骤S2.CNI-Controller监听到Pod单元创建请求；

步骤S3.CNI-Controller加载集群中已安装的CNI列表，得出未安装的目标CNI；

步骤S4.CNI-Controller构建未安装的目标CNI的安装请求发送给API Server；

步骤S5.API Server发送安装目标CNI的任务给对应的节点(Node)，对应的节点拉取安装目标CNI所需的资源对所述目标CNI进行安装；

步骤S6.CNI-Controller获取到目标CNI安装成功，并将安装成功的目标CNI信息更新值数据库；

步骤S7.对应的节点调用目标CNI对Pod单元进行创建。

用户根据实际需要，在运行的Kubernetes集群中API Server监控到用户提交Pod单元创请求，并在该创建请求中声明创建该Pod单元所需的目标CNI，CNI-Controller监听到API Server中的Pod单元创建请求，并提取到创建该Pod单元所需的目标CNI，CNI-Controller从数据库中加载集群已安装的CNI列表，判断出未安装的目标CNI，CNI-Controller构建目标CNI的安装请求发送给API Server，API Server将目标CNI的安装任务发送到对应的节点(Node)上，Node接到目标CNI安装任务后，拉取安装目标CNI所需的资源对目标CNI进行安装，CNI-Controller确认目标CNI安装成功后，将目标CNI的信息更新到数据库中，并在对应的节点上完成Pod单元的创建。

示例性的，CNI-Controller监听到API Server上用户提交的Pod单元创建请求，并在所提交Pod单元创建请求中声明创建该Pod单元所需要使用到的Canal和Flannel两个目标CNI，Kubernetes集群中的CNI-Controller从API-Server监听到Pod单元创建请求，并提取得到创建新的Pod单元的Canal和Flannel两个CNI的需求。CNI-Controller从预置的数据库中加载Kubernetes集群已安装的CNI列表，与需求的Canal和Flannel进行对比，得出Canal和Flannel两个CNI都未安装。CNI-Controller分别构建Canal和Flannel的安装请求并发送到APIServer，APIServer将Canal和Flannel的安装任务分配到对应的节点Node，Node接到Canal和Flannel的安装任务后，分别拉取安装Canal和Flannel所需的资源进行安装，CNI-Controller确认Cannel和Flannel安装成功能，将Canal和Flannel的信息更新到数据库中，被选定Pod单元创建节点上的Kubelet调用CNI和CRI等资源创建Pod单元,完成多网卡Pod单元的创建。

在本实施例中，通过对Pod单元创建请求进监控，并通过在预置数据库中加载创建Pod单元请求中声明的所需要的CNI是否已经安装在Kubernetes集群中，对没有安装的CNI发起安装请求，以使在对应的节点上对所需要的CNI进行安装，并通过选定创建Pod单元的节点上的Kubelet调用CNI和CRI等资源创建Pod单元，以此实现多网口Pod单元的创建，以此通过自动提取创建Pod单元所需的CNI信息，自动化地按需安装对应的目标CNI避免了人工介入，并预先判断所需的目标CNI是否在Kubernetes集群中存在，减少了对CNI的重复安装，提高了创建Pod单元的效率。

应当注意，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

图9是本申请一示例性实施例示出的Pod单元的创建装置400。该装置可以应用于图2所示的实施环境，并具体配置在Kubernetes集群中，该装置也可以适用于其他示例性实施环境，并具体配置在其他设备中，本实施例不对该装置所适用的实施环境进行限制。

如图9所示，该示例性的Pod单元的创建装置400包括：

监控模块410，用于监控Kunbernetes集群中的Pod单元创建请求，Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息。

获取模块420，用于获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在已安装的CNI信息中。

创建模块430，用于若判断为否，则发起目标CNI的安装请求，以在Kunbernetes集群中响应于安装请求，进行目标CNI的安装，并根据安装成功的目标CNI创建Pod单元。

在该示例性的Pod单元的创建装置中，自动化地按需安装对应的目标CNI避免了人工介入，并预先判断所需的目标CNI是否在Kubernetes集群中存在，减少了对CNI的重复安装，提高了创建Pod单元的效率。

在本申请的一个实施例中，Pod单元的创建装置400还包括：

判断模块用于：

判断目标CNI是否安装成功；

若判断为是，则将目标CNI信息记录为Kubernetes集群中已安装的CNI信息；

若判断为否，则重新发起目标CNI的安装请求。

在本申请的一个实施例中，创建模块410包括：

配置子模块，用于在选定创建Pod单元的节点上配置目标CNI的配置文件；

安装子模块，用于基于目标CNI的配置文件安装目标CNI对应的插件。

在本申请的一个实施例中，Kunbernetes集群中Pod单元创建装置400还包括：

解析模块，用于解析Pod单元创建请求，以获得创建Pod单元所需的目标CNI信息和选定创建Pod单元的节点。

在本申请的一个实施例中，创建模块410还包括：

调用子模块，用于通过选定创建Pod单元的节点上的Kubelet服务进程调用目标CNI和对应的容器运行时接口CRI来创建Pod单元。

在本申请的一个实施例中，述创建模块410具体用于：

通过Kubelet服务进程，连接CRI调用相应的服务来创建并启动容器，以及调用目标CNI对应的插件来配置Pod单元的网络，以创建Pod单元。

需要说明的是，上述实施例所提供的路况刷新装置与上述实施例所提供的路况刷新方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的路况刷新装置在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得电子设备实现上述各个实施例中提供的Pod单元的创建方法。

图10示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是，图10示出的电子设备的计算机系统1200仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图10所示，计算机系统1200包括中央处理单元(Central Processing Unit，CPU)1201，其可以根据存储在只读存储器(Read-Only Memory，ROM)1202中的程序或者从储存部分1208加载到随机访问存储器(Random Access Memory，RAM)1203中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM 1203中，还存储有系统操作所需的各种程序和数据。CPU 1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(Input/Output，I/O)接口1205也连接至总线1204。

以下部件连接至I/O接口1205：包括键盘、鼠标等的输入部分1206；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1207；包括硬盘等的储存部分1208；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1209。通信部分1209经由诸如因特网的网络执行通信处理。驱动器1210也根据需要连接至I/O接口1205。可拆卸介质1211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1210上，以便于从其上读出的计算机程序根据需要被安装入储存部分1208。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1209从网络上被下载和安装，和/或从可拆卸介质1211被安装。在该计算机程序被中央处理单元(CPU)1201执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如前的Pod单元的创建方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的Pod单元的创建方法。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。

Claims (10)

1.一种Pod单元的创建方法，其特征在于，包括：

监控Kunbernetes集群中的Pod单元创建请求，所述Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息；

获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在所述已安装的CNI信息中；

若判断为否，则发起目标CNI的安装请求，以在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，并根据安装成功的所述目标CNI创建所述Pod单元。

2.如权利要求1所述的方法，其特征在于，在所述发起所述目标CNI的安装请求之后，所述方法还包括：

判断所述目标CNI是否安装成功；

若判断为是，则将所述目标CNI信息记录为所述Kubernetes集群中已安装的CNI信息；

若判断为否，则重新发起所述目标CNI的安装请求。

3.如权利要求1所述的方法，其特征在于，所述在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，包括：

在所述选定创建所述Pod单元的节点上配置所述目标CNI的配置文件；

基于所述目标CNI的配置文件安装所述目标CNI对应的插件。

4.如权利要求3所述的方法，其特征在于，在监控Kubernetes集群中的Pod创建请求之后，所述方法还包括：

解析所述Pod单元创建请求，以获得创建所述Pod单元所需的目标CNI信息和选定创建所述Pod单元的节点。

5.如权利要求3所述的方法，其特征在于，所述根据安装成功的所述目标CNI创建所述Pod单元，包括：

通过所述选定创建所述Pod单元的节点上的Kubelet服务进程调用所述目标CNI和对应的容器运行时接口CRI来创建所述Pod单元。

6.如权利要求5所述的方法，其特征在于，所述通过所述选定创建所述Pod单元的节点上的Kubelet服务进程调用所述目标CNI和对应的容器运行时接口CRI来创建所述Pod单元，包括：

通过所述Kubelet服务进程，连接所述CRI调用相应的服务来创建并启动容器，以及调用所述目标CNI对应的插件来配置所述Pod单元的网络，以创建所述Pod单元。

7.如权利要求1-6任意一项所述的方法，其特征在于，所述Pod单元创建请求中包括多个创建Pod单元所需使用的目标CNI信息，用以指示在所述Kubernetes集群中进行各目标CNI的安装，并根据安装成功的各目标CNI创建所述Pod单元。

8.一种Pod单元的创建装置，其特征在于，包括：

监控模块，用于监控Kunbernetes集群中的Pod单元创建请求，所述Pod单元创建请求包括创建Pod单元所需使用的目标容器网络接口CNI信息；

获取模块，用于获取数据库中记录的Kunbernetes集群中已安装的CNI信息，并判断目标CNI信息是否记录在所述已安装的CNI信息中；

创建模块，用于若判断为否，则发起目标CNI的安装请求，以在所述Kunbernetes集群中响应于所述安装请求，进行所述目标CNI的安装，并根据安装成功的所述目标CNI创建所述Pod单元。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至7中任一项所述的Pod单元的创建方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1至7中任一项所述的Pod单元的创建方法。

Images