CN112910937A - 容器集群中的对象调度方法、装置、服务器和容器集群 - Google Patents

Abstract

本发明提供了一种容器集群中的对象调度方法、装置、服务器和容器集群，容器集群中的工作节点上运行有反向代理服务，并通过该反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化；如果发生变化，则根据管理节点发送的反馈信息对该工作节点中的对象进行调度。该方法中，工作节点可以通过部署在自身节点上的反向代理服务与管理节点进行通信，各个工作节点上反向代理服务独立运行，当其中一个工作节点上的反向代理服务发生故障后，仅影响该工作节点与管理节点的通信，并不会影响集群中其他工作节点与管理节点之间的通信，避免因反向代理服务故障导致容器集群整体瘫痪的问题，从而提高了容器集群的高可用性。

Description

容器集群中的对象调度方法、装置、服务器和容器集群

技术领域

本发明涉及容器集群技术领域，尤其是涉及一种容器集群中的对象调度方法、装置、服务器和容器集群。

背景技术

Kubernetes容器集群中，用于实现负载均衡的反向代理web服务器通常仅设置一台，如果该服务器发生故障，则导致容器集群中的管理节点无法与工作节点正常通信，因而难以对容器集群中的对象进行调度，影响容器集群的高可用性。

发明内容

本发明的目的在于提供一种容器集群中的对象调度方法、装置、服务器和容器集群，以提高容器集群的高可用性。

本发明提供的一种容器集群中的对象调度方法，所述方法应用于容器集群中的工作节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；所述方法包括：通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化；如果接收到所述管理节点发送的反馈信息，根据所述反馈信息对所述工作节点中的对象进行调度；其中，所述反馈信息包括：发生变化的对象的描述信息。

进一步的，所述容器集群包括多个所述管理节点；所述通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化的步骤，包括：通过所述反向代理服务，以时间片轮转的方式逐一向每个所述管理节点监听与所述工作节点关联的对象是否发生变化。

进一步的，所述工作节点上还运行有节点代理服务；所述节点代理服务通过所述反向代理服务与所述管理节点中的接口服务连接；所述通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化的步骤，包括：按照预设的时间间隔，所述工作节点上的节点代理服务向所述反向代理服务发送监听请求；所述反向代理服务将所述监听请求转发至所述管理节点中的接口服务，以通过所述接口服务查询所述管理节点中的键值存储系统中，与所述工作节点关联的对象是否发生变化。

进一步的，根据所述反馈信息对所述工作节点中的对象进行调度的步骤，包括：如果所述反馈信息中，发生变化的对象为新增Pod，根据所述反馈信息中的描述信息，从镜像仓库中拉取镜像数据；基于所述镜像数据创建所述新增Pod对应的容器、以及所述容器的关联容器。

本发明提供的一种容器集群中的对象调度装置，所述装置应用于容器集群中的工作节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；所述装置包括：监听模块，用于通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化；调度模块，用于如果接收到所述管理节点发送的反馈信息，根据所述反馈信息对所述工作节点中的对象进行调度；其中，所述反馈信息包括：发生变化的对象的描述信息。

进一步的，所述容器集群包括多个所述管理节点；所述监听模块还用于：通过所述反向代理服务，以时间片轮转的方式逐一向每个所述管理节点监听与所述工作节点关联的对象是否发生变化。

进一步的，所述工作节点上还运行有节点代理服务；所述节点代理服务通过所述反向代理服务与所述管理节点中的接口服务连接；所述监听模块还用于：按照预设的时间间隔，所述工作节点上的节点代理服务向所述反向代理服务发送监听请求；所述反向代理服务将所述监听请求转发至所述管理节点中的接口服务，以通过所述接口服务查询所述管理节点中的键值存储系统中，与所述工作节点关联的对象是否发生变化。

进一步的，所述调度模块还用于：如果所述反馈信息中，发生变化的对象为新增Pod，根据所述反馈信息中的描述信息，从镜像仓库中拉取镜像数据；基于所述镜像数据创建所述新增Pod对应的容器、以及所述容器的关联容器。

本发明提供的一种服务器，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现上述任一项所述的容器集群中的对象调度方法。

本发明提供的一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述任一项所述的容器集群中的对象调度方法。

本发明提供的一种容器集群，所述容器集群包括工作节点和管理节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；所述工作节点用于执行上述任一项所述的容器集群中的对象调度方法。

本发明提供的容器集群中的对象调度方法、装置、服务器和容器集群，容器集群中的工作节点上运行有反向代理服务，并通过该反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化；如果发生变化，则根据管理节点发送的反馈信息对该工作节点中的对象进行调度。该方法中，在容器集群中的每个工作节点上均部署有反向代理服务，工作节点可以通过部署在自身节点上的反向代理服务与管理节点进行通信，各个工作节点上反向代理服务独立运行，当其中一个工作节点上的反向代理服务发生故障后，仅影响该工作节点与管理节点的通信，并不会影响集群中其他工作节点与管理节点之间的通信，避免因反向代理服务故障导致容器集群整体瘫痪的问题，从而提高了容器集群的高可用性。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于Kubernetes容器集群的部署架构的示意图；

图2为本发明实施例提供的另一种基于Kubernetes容器集群的部署架构的示意图；

图3为本发明实施例提供的一种容器集群中的对象调度方法的流程图；

图4为本发明实施例提供的另一种容器集群中的对象调度方法的流程图；

图5为本发明实施例提供的另一种容器集群中的对象调度方法的流程图；

图6为本发明实施例提供的一种Kubernetes容器集群的工作机制示意图；

图7为本发明实施例提供的一种Kubernetes容器集群的工作流程示意图；

图8为本发明实施例提供的一种容器集群中的对象调度装置的结构示意图；

图9为本发明实施例提供的一种服务器的结构示意图。

具体实施方式

下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于理解，本实施例中以基于Kubernetes容器集群为例进行说明。Kubernetes是基于容器技术的编排调度系统，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等一整套功能，通过Kubernetes管理的容器集群，其机器使用效率、运维成本大幅降低。

图1所示的是一种基于Kubernetes容器集群的部署架构的示意图；该部署架构包括多个管理节点(也可以称为Master Node)、多个工作节点(也可以称为Worker Node)和一台反向代理服务器，该反向代理服务器上运行有反向代理服务。多个工作节点通过该反向代理服务器分别与多个管理节点通信连接。通常，在管理节点会部署API Server(Application Programming Interface Server，应用程序编程接口服务)、ControllerManager(控制管理程序)、Scheduler(调度程序)、Etcd(一种键值存储系统)服务，多个管理节点中可以选取一个作为主管理节点，其他管理节点为从管理节点。在工作节点上会部署Kubelet(节点代理服务)和Kube-proxy组件。

上述反向代理服务器可以选用能实现负载均衡的Nginx服务器，该Nginx服务器也可以称为Nginx(LB)，其中，LB(Load Balance)为负载均衡。管理节点上部署的API Server可以作为集群管理者，用于接收用户发出的Kubectl(用户命令行工具)的命令，然后将该命令转化成信令，再通过API Server构建相关对象，最终由Controller Manager、Scheduler和Kubelet感知到对象变化事件。上述所有组件均通过一种远程过程调用协议gRPC(RemoteProcedure Call，远程过程调用)通道与API Server通信，所有对象的变化均通过该gRPC通道传送给上述每个组件(其中包括Kubelet)。

容器集群中的每个工作节点的相关组件(比如kubelet)通过同一台反向代理服务器连向后端管理节点中的所有API Server，例如，反向代理服务器Nginx(LB)可以根据Nginx 4层反向代理机制实现反向代理的功能。一旦反向代理服务器发生故障，所有工作节点的Kubelet将无法连接到所有API Server获取服务，即容器集群的反向代理服务器为单点设置，存在较大的风险，影响容器集群的高可用性。

基于上述问题，本实施例首先提供另一种基于Kubernetes容器集群，再描述基于该容器集群的容器集群中的对象调度方法、装置、服务器和容器集群。

如图2所示的另一种基于Kubernetes容器集群的部署架构的示意图；该容器集群可以包括多个管理节点和多个工作节点，图2中以管理节点和工作节点的数量均为三个为例进行说明。

管理节点上部署有API Server、Controller Manager、Scheduler、Etcd服务，其中，管理节点上的API Server可以作为集群管理者，用于接收用户发出的Kubectl(用户命令行工具)的命令，API Server还用于接收其他服务的gRPC连接请求，并完成对象生成、转化、关联、销毁等生命周期维护工作，最终将相关对象存放于Etcd集群中。上述ControllerManager和Scheduler用于通过gRPC通道的notification机制，监听Etcd集群中相关对象变化，当监听到相关对象数量、内容变化时，就会触发notification事件并通知到对应的Controller Manager和Scheduler服务，该Controller Manager和Scheduler服务进一步获取变化的内容，以完成相关任务。上述Scheduler还可以用于根据对象的分配策略，将对象与工作节点进行关联。

上述工作节点上部署Nginx(LB)、Kubelet和Kube-proxy服务(服务也可以称为组件)。其中，Kubelet和Kube-proxy用于通过gRPC通道的notification机制，监听Etcd集群中相关对象变化，当监听到相关对象数量或内容变化时，就会触发notification事件并通知到对应的Kubelet或Kube-proxy服务，该Kubelet或Kube-proxy服务进一步获取变化的内容，并调用对应的容器平台接口达到变化后的状态。在工作节点中可以将必需的组件划分为部署单元，比如，工作节点包括的kubelet和kube-proxy可以认为是一个部署单元。

上述容器集群中，每个工作节点中部署一个与kubelet绑定的反向代理服务器，如Nginx(LB)。每个工作节点中Nginx(LB)均配置反向代理至图2中的三个API server，即，将API Server作为Nginx(LB)的负载后端，该Nginx(LB)通过Nginx 4层反向代理机制实现反向代理功能，具体的反向代理对象可以通过配置文件指定，每个工作节点的部署单元中相关组件(比如kubelet)通过Nginx(LB)与API Server相连接。

基于上述图2所示的容器集群，提供一种容器集群中的对象调度方法的流程图，如图3所示，该方法可以应用于容器集群中的工作节点；该工作节点上运行有反向代理服务；该工作节点通过反向代理服务与容器集群中的管理节点通信连接；该方法包括以下步骤：

步骤S302，通过反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化。

上述管理节点和工作节点具体可以为上述图2中的Master Node和Worker Node；上述反向代理服务可以为上述图2中部署在Worker Node中的Nginx(LB)。Master Node可以接收用户指令，根据该指令构建相关对象，并存储至该Master Node上所部署的Etcd中，其中，对象可以理解为将根据用户指令所构建的与Controller Manager、Scheduler或Kubelet所对应的实例，该实例是将根据指令所构建的应用程序打包成容器，若干个容器的集合，如Pod对象。工作节点与对象之间的关联关系可以通过对象的分配策略描述，如对象所需资源、调度要求等，并基于预设规则对每个Worker Node进行打分排序，根据排序结果将对象与评分最高的Worker Node进行关联。

在实际实现时，Worker Node中的部署单元可以定时发出监听请求，通过所绑定的Nginx(LB)连接API Server，并监听相应Master Node的Etcd中与该Worker Node关联的对象是否发生变化，该变化可以包括新增的对象、删除的对象或更新逻辑的对象等。

步骤S304，如果接收到管理节点发送的反馈信息，根据该反馈信息对该工作节点中的对象进行调度；其中，该反馈信息包括：发生变化的对象的描述信息。

对象的描述信息可以包括对象所需要的资源、调度要求以及镜像信息等。当APIServer监听到Etcd中与该Worker Node关联的对象集合发生变化时，相应的Master Node会向该Worker Node发送反馈信息，具体的，该API Server通过Nginx(LB)将变化对象(比如新增的对象、删除的对象或更新逻辑的对象)的描述信息反馈至对应Worker Node中的部署单元，部署单元中的相关组件(如Kubelet)根据接收到的反馈信息，对该工作节点中的对象进行调度，调度的具体方式与对象变化的具体方式相关联，比如，变化方式为新增，则调度方式为新建；变化方式为删除，则调度方式为删除。

本发明提供的一种容器集群中的对象调度方法，容器集群中的工作节点上运行有反向代理服务，并通过该反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化；如果发生变化，则根据管理节点发送的反馈信息对该工作节点中的对象进行调度。该方法中，在容器集群中的每个工作节点上均部署有反向代理服务，工作节点可以通过部署在自身节点上的反向代理服务与管理节点进行通信，各个工作节点上反向代理服务独立运行，当其中一个工作节点上的反向代理服务发生故障后，仅影响该工作节点与管理节点的通信，并不会影响集群中其他工作节点与管理节点之间的通信，避免因反向代理服务故障导致容器集群整体瘫痪的问题，从而提高了容器集群的高可用性。

本发明实施例还提供另一种容器集群中的对象调度方法，该方法在上述实施例方法的基础上实现；该方法重点描述通过反向代理服务，向管理节点监听与工作节点关联的对象是否发生变化的具体实现过程。本实施例中，容器集群中包括多个管理节点，如图4所示，该方法包括如下步骤：

步骤S402，通过反向代理服务，以时间片轮转的方式逐一向每个管理节点监听与该工作节点关联的对象是否发生变化。

由上述实施例可知，反向代理服务相当于上述图2中部署在Worker Node中的Nginx(LB)；时间片轮转可以用RR(Round-Robin)来表示，该时间片轮转的方式可以理解为通过Nginx(LB)，Worker Node按时间顺序逐一向每个Master Node发送监听请求，以监听与该Worker Node关联的对象是否发生变化，具体的，对每个Master Node的监听进程会被分配一定的时间段，该时间段即为向该Master Node监听所允许运行的时间。

作为示例，容器集群中包括三个Master Node，对每个Master Node所分配的监听时间均为T，当某一Worker Node向Master Node发送监听请求时，具体执行过程如下：该Worker Node通过部署在该节点上的Nginx(LB)，向第一个Master Node发送监听请求，并记录时间，当该监听过程达到预设的监听时间T时，停止对第一个Master Node的监听，同时开始向第二个Master Node发送监听请求，并重新记录时间，当该监听过程达到预设的监听时间T时，停止对第二个Master Node的监听，同时开始向第三个Master Node发送监听请求，并重新记录时间，当该监听过程达到预设的监听时间T时，停止对第三个Master Node的监听。上述过程通过时间片轮转的方式，完成了该Worker Node对容器集群中三个MasterNode的监听。

由前述实施例可知，工作节点与对象之间的关联关系可以通过对象的分配策略描述，如对象所需资源、调度要求等；然后，具体可以根据Worker Node当前负载压力、相关资源的可用性等因素，基于预选、优选策略对每个Worker Node进行打分排序，根据排序结果将对象与评分最高的Worker Node进行关联。

另外一种方式中，容器集群的工作节点上还运行有节点代理服务；该节点代理服务通过反向代理服务与管理节点中的接口服务连接；基于此，通过反向代理服务，向管理节点监听与工作节点关联的对象是否发生变化的过程，还可以通过下述步骤01和步骤02实现：

步骤01，按照预设的时间间隔，工作节点上的节点代理服务向反向代理服务发送监听请求。

该节点代理服务可以理解为Worker Node的部署单元中的相关组件，如Kubelet，Kubelet通过gRPC通道定期向Nginx(LB)发送监听请求，该监听请求也可以用watchnotification(监听通知)请求来表示。上述时间间隔可以理解为Worker Node中的Kubelet向Nginx(LB)发送的相邻两次监听请求之间的时间间隔，该时间间隔可以根据实际需求进行设定。

步骤02，反向代理服务将监听请求转发至管理节点中的接口服务，以通过接口服务查询管理节点中的键值存储系统中，与该工作节点关联的对象是否发生变化。

该接口服务可以理解为上述图2中部署在Master Node上的API Server，键值存储系统可以理解为上述图2中部署在Master Node上的Etcd，所有对象都存储在Etcd中；当接收到Worker Node发送的监听请求后，部署在该Worker Node中的Nginx(LB)通过gRPC通道将该请求转发至API Server中，API Server通过gRPC通道与本地Etcd节点进行通信，读取本地Etcd中与该Worker Node关联的对象信息，以确认与该Worker Node关联的对象是否发生变化。

步骤S404，如果接收到管理节点发送的反馈信息，根据该反馈信息对该工作节点中的对象进行调度；其中，该反馈信息包括：发生变化的对象的描述信息。

本发明实施例提供的另一种容器集群中的对象调度方法，详细描述了通过反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化的具体实现过程，因容器集群中包括多个管理节点，工作节点通过反向代理服务，以时间片轮转的方式，逐一监听每个管理节点中与该工作节点关联的对象是否发生变化；具体通过工作节点上的节点代理服务，定期向反向代理服务发送监听请求，该反向代理服务再将该监听请求转发至管理节点中的接口服务，进而查询相应的键值存储系统中与工作节点关联的对象是否发生变化。该方法中，在容器集群中的每个工作节点上均部署有反向代理服务，工作节点可以通过部署在自身节点上的反向代理服务与管理节点进行通信，各个工作节点上反向代理服务独立运行，当其中一个工作节点上的反向代理服务发生故障后，仅影响该工作节点与管理节点的通信，并不会影响集群中其他工作节点与管理节点之间的通信，避免因反向代理服务故障导致容器集群整体瘫痪的问题，从而提高了容器集群的高可用性。

本发明实施例还提供另一种容器集群中的对象调度方法，该方法在上述实施例方法的基础上实现；该方法以Pod为例，重点描述根据反馈信息对工作节点中的对象进行调度的具体实现过程，如图5所示，该方法包括如下步骤：

步骤S502，通过反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化。

步骤S504，如果接收到管理节点发送的反馈信息，且该反馈信息中，发生变化的对象为新增Pod，根据反馈信息中的描述信息，从镜像仓库中拉取镜像数据。

其中，上述Pod是一组容器的集合，在同一Pod中的容器共享网络或存储空间，在Kubernetes系统中，Pod是最小的可被调用的原子单位。如果API Server监听到Etcd中与该Worker Node关联的对象集合中有新增的对象Pod，则通过Nginx(LB)将新增Pod的描述信息告知对应的Kubelet，该Kubelet根据接收到的反馈信息，调用本地镜像仓库，将反馈信息与本地镜像仓库中的镜像数据进行信息匹配，当匹配信息一致时，从该镜像仓库中拉取相应的镜像数据至该Worker Node对应的服务器，该镜像数据可以理解为用户向Master Node所提交的指令的备份数据，其中包含应用部署需要的相关描述，如：应用部署需要的CPU、内存和存储空间等。上述镜像仓库也可以用docker engine来表示。

步骤S506，基于镜像数据创建新增Pod对应的容器、以及容器的关联容器。

在上述镜像数据基础上增加可读写层，得到新增Pod对应的容器，该容器中运行有用户指定的应用程序。关联容器中的元素是按关键字或关键值来保存和访问的，可以支持高效的关键字或关键值的查找和访问，该关联容器也可以用sidecar表示，最终完成新增Pod在该Worker Node中的部署。

本发明实施例提供的另一种容器集群中的对象调度方法，详细描述了根据反馈信息对工作节点中的对象进行调度的具体实现过程，当管理节点反馈的信息显示有新增Pod时，则根据该反馈信息中的描述信息，从镜像仓库中拉取镜像数据，并基于该镜像数据创建新增Pod对应的容器、以及容器的关联容器。该方法通过在容器集群中的每个工作节点上部署反向代理服务，不同工作节点之间可以通过对应的反向代理服务各自独立运行，当其中一个工作节点上的反向代理服务故障后，不会影响集群中其他工作节点与管理节点之间的通信，从而提高了容器集群的高可用性。

基于上述实施例，为了进一步理解上述容器集群中的对象调度方法，下面提供一种Kubernetes容器集群的工作机制示意图，如图6所示，以对Kubernetes系统中的核心服务功能进行介绍。

图6中所示的Kubernetes容器集群的工作机制示意图中包括管理节点MasterNode和节点连接池Node Pool，该节点连接池中包括多个工作节点，其中，Master Node上部署有API Server、Controller Manager、Scheduler和Etcd服务，各服务功能可参考前述实施例中的说明；需要说明的是，Controller Manager通常包括若干个子Controller，其中Deployment Controller和ReplicaSet Controller是比较关键的Controller。DeploymentController负责管理ReplicaSet对象，而ReplicaSet的主要作用是确保Pod以用户指定的副本数运行，即如果有容器异常退出，会自动创建新的Pod来替代；而异常多出来的容器也会自动回收；ReplicaSet Controller负责创建、销毁Pod对象。Etcd集群作为所有对象的存储服务，保证所有对象内容强一致。

在实际实现时，通常会从多个Master Node中选取其中一个作为主管理节点，其他节点作为从管理节点，主管理节点可以用Leader Master Node表示，从管理节点可以用Follower Master Node表示；API Server通过连接与本地Etcd节点通信，如果对应管理节点是Leader Master Node，则API Server可以直接从对应的Etcd中完成读写操作；如果对应管理节点是Follower Master Node，则API Server可以从对应的Etcd中读取数据，如果Follower Master Node中的API Server向该Follower Master Node中的Etcd发送写请求，则该写请求会路由至Leader Master Node中的Etcd完成。如果Leader Master Node中的Etcd服务节点故障，可以通过raft协议自选举主Etcd，最终保证集群高可用。

Controller Manger和Scheduler服务集群中各节点分别通过API Server在Etcd中抢占各自的分布式锁对象，当节点发生故障后，可以自动选取新的主Controller Manger或主Scheduler，最终保证集群高可用，如图1和图2所示，主Controller Manger和主Scheduler可以并存于Leader Master Node上；在实际实现时，由于分布式锁对象抢占机制是随机的，主Controller Manager与主Scheduler完全可以分布在不同的Master Node上。

上述Node Pool中可以包括多个工作节点Worker Node，每个Worker Node中包括多个功能单元，如：Networking(关系网)、Kubelet(节点代理服务)、Container Runtime(容器运行时间)、OS(操作系统)和Hardware(硬件)，Worker Node中各个功能单元之间通过相应的通道进行通信连接。

基于上述Kubernetes容器集群的工作机制，下面对采用上述Kubernetes容器集群的工作流程进行说明，如图7所示，该工作流程以新增Pod对象为例进行说明，包括如下步骤：

步骤1，用户通过Kubectl向管理节点中的主管理节点(Leader Master Node)中的API Server提交文件app_deployment.yml，该文件包括应用部署需要的相关描述信息，比如：应用部署需要的CPU、内存、存储空间、调度策略等，该文件中所包含的数据镜像已经上传到镜像仓库中。

API Server接收到文件app_deployment.yml后，解析该文件相关字段，生成Deployment_App描述对象，该描述对象转变为内存对象，与接收到的原文件相比，部分字段有转化，所生成的Deployment_App描述对象存储至相应的Etcd中。

步骤2，Controller Manager中的Deployment Controller依赖gRPC通道，通过APIServer监听Etcd中Deployment对象变化，当API Server创建并存储Deployment_App到Etcd中后，Deployment Controller将感知到新创建了一个Deployment_App。

步骤3，Deployment Controller根据Deployment_App创建一个ReplicaSet_App描述对象，该描述对象用于描述该App在集群中存在多少实例，存放该ReplicaSet_App描述对象到Etcd中。

步骤4，Controller Manager中的ReplicaSet Controller依赖gRPC通过APIServer监听Etcd中ReplicaSet对象变化，当Deployment Controller创建并存储ReplicaSet_App到Etcd中后，ReplicaSet Controller将感知到新创建了一个ReplicaSet_App。

步骤5，ReplicaSet Controller根据ReplicaSet_App创建若干个Pod_App_xxx描述对象，该描述对象的具体个数由步骤3中ReplicaSet_App所描述的实施例的数量进行确定，一个实施例对应一个Pod_App_xxx描述对象，将所创建的Pod_App_xxx描述对象存放至Etcd中。

步骤6，Scheduler依赖gRPC通过API Server监听Etcd中Pod_App_xxx对象变化，当ReplicaSet Controller创建并存储Pod_App_xxx到Etcd中后，Scheduler将感知到新创建了若干个Pod_App_xxx对象。

步骤7，Scheduler循环遍历每个Pod_App_xxx对象：根据每个Pod_App_xxx的分配策略描述，以及每个工作节点Worker Node的打分排序，依次将Pod_App_xxx与当前评分最高的工作节点Worker Node关联，并将该关联关系存储于Etcd中。

步骤8，对于某一工作节点Worker Node，该Worker Node中的Kubelet依赖gRPC通过API Server监听Etcd中与本Worker Node对象关联Pod对象集合的变化，每个Kubelet即代表一个Worker Node；具体地，Kubelet通过gRPC定期发送watch notification请求，该请求通过与该Kubelet绑定的Ngnix(LB)向API Server转发；API Server在接收到该请求后，监听Etcd里与本Worker Node关联的Pod对象集合是否发生了变化，并在发现本WorkerNode关联的Pod对象集合发生了变化的情况下，通过Nginx(LB)将变化的Pod对象(比如新增的Pod对象)告知对应的Kubelet。

步骤9，Kubelet根据新增的Pod对象描述，调用本地Docker Engine，并从该DockerEngine中拉取镜像数据至该Worker Node对应的服务器。

步骤10，基于上述镜像数据创建新增Pod对应的容器、以及该容器的关联容器，最终完成新增Pod在该工作节点Worker Node中的部署。

其他Worker Node按上述步骤8-步骤10完成发生变化的对象在相应Worker Node中的部署，另外，对于变化的Pod对象为删除的Pod对象或更新逻辑的Pod对象，相应的对象变化感知方式与上述新增Pod对象的感知方式相同，具体的操作逻辑可以参考现有技术的操作方式。

当主Controller Manager或主Scheduler发生故障后，通过Etcd分布式锁的机制从其他Controller Manager或Scheduler中选举出新的主Controller Manager或主Scheduler，同时Kubelet根据每个Nginx(LB)可以顺利路由到其他API Server，进一步可以感知Etcd集群相关对象变化，从而新的主Controller Manager/Scheduler通过所在机器的API Server依然可以对每个Kubelet提供服务。

当某个Worker Node中的Nginx(LB)发生故障，只有该Worker Node本地部署的Kubelet不能与API Server通信，其他Worker Node上所部署的Kubelet依然可以通过本地对应的Nginx(LB)与其他API Server通信。

通过上述在每个Worker Node上部署独立的Nginx(LB),并配置后端反向代理指向所有API Server，达到关键服务高可用的目的，免去了单台Nginx(LB)的单点风险，同时由于Nginx(LB)部署在各个Worker Node上，不需单独配置部署Nginx(LB)的单台或多台机器，因而也节约了硬件成本。

参照图8所示的一种容器集群中的对象调度装置的结构示意图，该装置应用于容器集群中的工作节点；工作节点上运行有反向代理服务；工作节点通过反向代理服务与容器集群中的管理节点通信连接；该装置包括：监听模块80，用于通过反向代理服务，向管理节点监听与工作节点关联的对象是否发生变化；调度模块81，用于如果接收到管理节点发送的反馈信息，根据反馈信息对工作节点中的对象进行调度；其中，反馈信息包括：发生变化的对象的描述信息。

本发明提供的一种容器集群中的对象调度装置，容器集群中的工作节点上运行有反向代理服务，并通过该反向代理服务，向管理节点监听与该工作节点关联的对象是否发生变化；如果发生变化，则根据管理节点发送的反馈信息对该工作节点中的对象进行调度。该装置中，在容器集群中的每个工作节点上均部署有反向代理服务，工作节点可以通过部署在自身节点上的反向代理服务与管理节点进行通信，各个工作节点上反向代理服务独立运行，当其中一个工作节点上的反向代理服务发生故障后，仅影响该工作节点与管理节点的通信，并不会影响集群中其他工作节点与管理节点之间的通信，避免因反向代理服务故障导致容器集群整体瘫痪的问题，从而提高了容器集群的高可用性。

进一步的，容器集群包括多个管理节点；监听模块80还用于：通过反向代理服务，以时间片轮转的方式逐一向每个管理节点监听与工作节点关联的对象是否发生变化。

进一步的，工作节点上还运行有节点代理服务；节点代理服务通过反向代理服务与管理节点中的接口服务连接；监听模块80还用于：按照预设的时间间隔，工作节点上的节点代理服务向反向代理服务发送监听请求；反向代理服务将监听请求转发至管理节点中的接口服务，以通过接口服务查询管理节点中的键值存储系统中，与工作节点关联的对象是否发生变化。

进一步的，调度模块81还用于：如果反馈信息中，发生变化的对象为新增Pod，根据反馈信息中的描述信息，从镜像仓库中拉取镜像数据；基于镜像数据创建新增Pod对应的容器、以及容器的关联容器。

本发明实施例所提供的容器集群中的对象调度装置，其实现原理及产生的技术效果和前述容器集群中的对象调度方法实施例相同，为简要描述，容器集群中的对象调度装置实施例部分未提及之处，可参考前述容器集群中的对象调度方法实施例中相应内容。

本发明实施例还提供了一种服务器，参见图9所示，该服务器包括处理器90和存储器91，该存储器91存储有能够被处理器90执行的机器可执行指令，该处理器90执行机器可执行指令以实现上述容器集群中的对象调度方法。

进一步地，图9所示的服务器还包括总线92和通信接口93，处理器90、通信接口93和存储器91通过总线92连接。

其中，存储器91可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口93(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线92可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器90可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器90中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器90可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器91，处理器90读取存储器91中的信息，结合其硬件完成前述实施例的方法的步骤。

本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述容器集群中的对象调度方法，具体实现可参见方法实施例，在此不再赘述。

本发明实施例所提供的容器集群中的对象调度方法及装置和服务器的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

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

本发明实施例还提供了一种容器集群，该容器集群包括工作节点和管理节点；工作节点上运行有反向代理服务；工作节点通过反向代理服务与容器集群中的管理节点通信连接；工作节点用于执行上述的容器集群中的对象调度方法。

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

Claims (11)

1.一种容器集群中的对象调度方法，其特征在于，所述方法应用于容器集群中的工作节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；所述方法包括：

通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化；

如果接收到所述管理节点发送的反馈信息，根据所述反馈信息对所述工作节点中的对象进行调度；其中，所述反馈信息包括：发生变化的对象的描述信息。

2.根据权利要求1所述的方法，其特征在于，所述容器集群包括多个所述管理节点；

所述通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化的步骤，包括：通过所述反向代理服务，以时间片轮转的方式逐一向每个所述管理节点监听与所述工作节点关联的对象是否发生变化。

3.根据权利要求1或2所述的方法，其特征在于，所述工作节点上还运行有节点代理服务；所述节点代理服务通过所述反向代理服务与所述管理节点中的接口服务连接；

所述通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化的步骤，包括：

按照预设的时间间隔，所述工作节点上的节点代理服务向所述反向代理服务发送监听请求；

所述反向代理服务将所述监听请求转发至所述管理节点中的接口服务，以通过所述接口服务查询所述管理节点中的键值存储系统中，与所述工作节点关联的对象是否发生变化。

4.根据权利要求1所述的方法，其特征在于，根据所述反馈信息对所述工作节点中的对象进行调度的步骤，包括：

如果所述反馈信息中，发生变化的对象为新增Pod，根据所述反馈信息中的描述信息，从镜像仓库中拉取镜像数据；

基于所述镜像数据创建所述新增Pod对应的容器、以及所述容器的关联容器。

5.一种容器集群中的对象调度装置，其特征在于，所述装置应用于容器集群中的工作节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；所述装置包括：

监听模块，用于通过所述反向代理服务，向所述管理节点监听与所述工作节点关联的对象是否发生变化；

调度模块，用于如果接收到所述管理节点发送的反馈信息，根据所述反馈信息对所述工作节点中的对象进行调度；其中，所述反馈信息包括：发生变化的对象的描述信息。

6.根据权利要求5所述的装置，其特征在于，所述容器集群包括多个所述管理节点；

所述监听模块还用于：通过所述反向代理服务，以时间片轮转的方式逐一向每个所述管理节点监听与所述工作节点关联的对象是否发生变化。

7.根据权利要求5或6所述的装置，其特征在于，所述工作节点上还运行有节点代理服务；所述节点代理服务通过所述反向代理服务与所述管理节点中的接口服务连接；

所述监听模块还用于：

按照预设的时间间隔，所述工作节点上的节点代理服务向所述反向代理服务发送监听请求；

所述反向代理服务将所述监听请求转发至所述管理节点中的接口服务，以通过所述接口服务查询所述管理节点中的键值存储系统中，与所述工作节点关联的对象是否发生变化。

8.根据权利要求5所述的装置，其特征在于，所述调度模块还用于：

如果所述反馈信息中，发生变化的对象为新增Pod，根据所述反馈信息中的描述信息，从镜像仓库中拉取镜像数据；

基于所述镜像数据创建所述新增Pod对应的容器、以及所述容器的关联容器。

9.一种服务器，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1至4任一项所述的容器集群中的对象调度方法。

10.一种机器可读存储介质，其特征在于，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现权利要求1至4任一项所述的容器集群中的对象调度方法。

11.一种容器集群，其特征在于，所述容器集群包括工作节点和管理节点；所述工作节点上运行有反向代理服务；所述工作节点通过所述反向代理服务与所述容器集群中的管理节点通信连接；

所述工作节点用于执行权利要求1至4任一项所述的容器集群中的对象调度方法。

Images