CN112130965A - 部署分布式容器编排管理集群的方法、设备及存储介质 - Google Patents

Abstract

本申请公开了一种部署分布式容器编排管理集群的方法、设备及存储介质，涉及云技术领域。该方法包括：根据待部署的分布式容器编排管理集群中的任一主Master节点的物理IP地址配置工作节点；将配置后的工作节点加入分布式容器编排管理集群后，通过分布式容器编排管理集群在worker节点上自动生成虚拟路由规则；利用LVS规则更改工作节点中组件的配置，并重启组件。本申请利用任一Master节点的物理IP配置工作节点后，将该工作节点加入集群，在该工作节点上生成虚拟路由规则，再利用该虚拟路由规则更改该工作节点中kubelet组件和kube‑proxy组件的配置，重启工作节点中的组件后实现Master节点对工作节点的高可用，该方法不依赖ansible,haproxy和keepalived等外部组件，无需增加额外的资源消耗。

Description

部署分布式容器编排管理集群的方法、设备及存储介质

技术领域

本申请实施例涉及云技术领域，特别涉及一种部署分布式容器编排管理集群的方法、装置、电子设备及存储介质。

背景技术

随着云计算及大数据快速发展，新的技术框架层出不穷，Kubernetes(k8s)应运而生。它是一个全新的基于容器技术的分布式架构,建立在docker技术之上，为容器化的应用提供了资源调度、部署运行、服务发现和扩容缩容等丰富多样的功能。同时k8s是一个开放的平台，供社区用户直接参与应用和开发的框架。k8s的重要的特点是自动化，自动化是指能够实现自动部署，自动重启，自动复制，自动伸缩/扩展。

在集群管理方面，Kubernetes将集群中的机器划分为一个主Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制等管理能力。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

现有技术中对于Kubernetes集群中Master节点的高可用部署一般依赖ansible,haproxy和keepalived等外部组件来实现的，而采用这些外部组件实现kubernetes集群中的Master高可用的方式会存在以下几个问题：

1.因为需要获取一个虚拟IP，所有在某些私有化部署的情况下条件并不允许；

2.运行故障时的IP漂移会带来更多复杂度，使得突发问题的排查定位变得更加困难；

3.由于每个Master节点需要运行和监控额外的HAProxy和Keepalived服务，因此增加了整个集群的管理和运维的负担。

发明内容

本申请实施例提供了一种部署分布式容器编排管理集群的方法、设备及存储介质，可以不依赖ansible,haproxy和keepalived等外部组件来实现Master节点的高可用部署。所述技术方案如下：

一个方面，提供了一种部署分布式容器编排管理集群的方法，所述方法包括：

根据待部署的分布式容器编排管理集群中的任一主Master节点的物理IP地址配置工作节点；

将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系；

利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

在另一个可能的实现方式中，所述待部署的分布式容器编排管理集群为Kubernetes集群，则所述根据待部署的分布式容器编排管理集群中的任一Master节点的物理IP地址配置工作节点，包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

在又一个可能的实现方式中，所述虚拟路由规则为Linux虚拟服务器LVS规则，则所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的clusterIP，其中，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

在又一个可能的实现方式中，所述利用所述虚拟路由规则更改所述工作节点中组件的配置，包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetes service的cluster IP。

在又一个可能的实现方式中，在所述工作节点上自动生成虚拟路由规则，包括：

通过所述工作节点上的kube-proxy组件通过所述Kubernetes集群的监听接口，实时跟踪获取所述Kubernetes集群所创建的service和endpoints的变更信息，在所述工作节点上自动生成并维护所述LVS规则。

在又一个可能的实现方式中，还包括：

当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述虚拟路由规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

另一方面，提供了一种部署分布式容器编排管理集群的装置，所述装置包括：

配置模块，用于根据待部署的分布式容器编排管理集群中的任一主Master节点的物理IP地址配置工作节点；

生成模块，用于将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系；

更改模块，用于利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

在另一个可能的实现方式中，所述待部署的分布式容器编排管理集群为Kubernetes集群，所述配置模块，具体用于：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

在又一个可能的实现方式中，所述虚拟路由规则为Linux虚拟服务器LVS规则，所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的cluster IP，其中，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

在又一个可能的实现方式中，所述更改模块，具体用于：将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetesservice的cluster IP。

在又一个可能的实现方式中，所述生成模块具体用于，通过所述工作节点上的kube-proxy组件通过所述Kubernetes集群的监听接口，实时跟踪获取所述Kubernetes集群所创建的service和endpoints的变更信息，在所述工作节点上自动生成并维护所述LVS规则。

在又一个可能的实现方式中，还包括：

更新模块，用于当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述虚拟路由规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

另一方面，提供了一种电子设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的部署分布式容器编排管理集群的方法。

另一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的部署分布式容器编排管理集群的方法。

另一方面，提供了一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得计算机执行如上所述的部署分布式容器编排管理集群的方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过利用任一Master节点的物理IP配置工作节点后，将该工作节点加入集群，在该工作节点上生成虚拟路由规则，再利用该虚拟路由规则更改该工作节点中kubelet组件和kube-proxy组件的配置，重启工作节点中的组件后实现Master节点对工作节点的高可用，该方法不依赖ansible,haproxy和keepalived等外部组件，无需增加额外的资源消耗。

附图说明

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

图1示出了Kubernetes集群高可用部署方案的通用架构图；

图2示出了现有方案中利用HAProxy和Keepalived实现Master节点高可用的框架图；

图3示出了本申请一个示例性实施例提供的一种部署分布式容器编排管理集群的方法的示意性流程图；

图4示出了本申请另一个示例性实施例提供的一种部署分布式容器编排管理集群的方法的示意性流程图；

图5示出了本申请中利用LVS作为反向代理实现Master节点高可用的框架图；

图6示出了本申请另一个示例性实施例提供的一种部署分布式容器编排管理集群的方法的示意性流程图；

图7示出了本申请一个示例性实施例提供的一种部署分布式容器编排管理集群的装置的结构示意图；

图8示出了本申请一个示例性实施例提供的电子设备的框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面详细描述本申请的实施例，该实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为了更好的理解及说明本申请实施例的方案，下面对本申请实施例中所涉及到的一些技术用语进行简单说明：

云技术(Cloud technology)：基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云计算(Cloud computing)：指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(Network StorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。

Kubernetes(缩写k8s):一个全新的用于自动部署，扩展和管理容器化应用程序的开源系统，是谷歌严格保密十几年的秘密武器—Borg的一个开源版本。Kubernetes基于容器技术，采用分布式架构，具备完备的集群管理能力和多层次的安全防护，提供容器化的服务发现与负载均衡、自动化更新和回滚、自动调度和修复等功能，是一个一站式的完备的分布式系统开发和支撑平台。

Linux Virtual Server(缩写LVS):LVS是利用Linux操作系统充当负载均衡器(Load Balancer)，将一组服务器，构建为高扩展性和高可用服务器的一种技术。对于最终用户而言，这一组服务器的架构是完全透明的。用户与这一组服务器交互，就如同在与单个高性能虚拟服务器在交互。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。Master节点扮演着总控中心的角色，其上运行的kube-apiserver、kube-controller-mansger和kube-scheduler组件通过不断与工作节点Node上的kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master的服务无法访问某个Node，则会将该Node标记为不可用，不再向其调度新建的Pod。但对Master自身则需要进行额外监控，使Master不成为集群的单故障点，所以对Master服务也需要进行高可用部署。

如图1，Kubernetes集群中的每个Master节点上包含api-服务器(api-server)，调度器(scheduler)，控制器(controller-manager)三个组件。而api-server又依赖存储器(etcd)存储数据，etcd的部署具有两种拓扑结构，一是和api-server一起在master节点上堆叠部署，二是直接使用外部集群。Master节点的高可用体现在三个组件和etcd的高可用：

1.etcd是一个采用http协议的分布式键值对存储系统，etcd的高可用由其本身的集群进行保障；

2.对于控制器和调度器而言,高可用不仅意味着需要启动多个实例，还需要这些个实例能实现选举并选举出主实例，以保证同一时间只有一个实例可以对集群状态信息进行读写，避免出现同步问题和一致性问题。Kubernetes对于这种选举机制的实现是采用租赁锁(leaselock)来实现的，可以通过在控制器和调度器的每个实例的启动参数中设置--leader-elect＝true来保证同一时间只会运行一个可修改集群信息的实例；

3.api-server部署了多个实例后，访问任意的实例都可以正常工作。一般通过一个统一的负载均衡器对外服务。

由此可见，实现kubernetes集群中的Master节点高可用的关键在于实现api-server的高可用。一般会通过部署一个负载均衡器来实现。在不同的平台下，负载均衡的实现方式不同：在一些公用云如GCE、AWS、阿里云上都有现成的负载均衡器。而对于本地集群，一般使用软件的方式来实现负载均衡，最常用的方案是使用HAProxy和Keepalived，其中HAProxy负责负载均衡，而Keepalived负责对HAProxy进行监控和故障切换。

在堆叠式的etcd部署下，利用HAProxy和Keepalived充当负载均衡器层的方案架构如下图2。Keeplived的主要作用是为HAProxy提供vip，在三个HAProxy实例之间提供主备，降低当其中一个HAProxy失效的时对服务的影响。而HAProxy则提供反向代理的功能，在多个api-server实例之间实现负载均衡。

然而，利用HAProxy和Keepalived实现kubernetes的master高可用方式会存在以下几个问题：

1.因为需要获取一个虚拟IP，所有在某些私有化部署的情况下条件并不允许；

2.运行故障时的IP漂移会带来更多复杂度，使得突发问题的排查定位变得更加困难；

3.由于每个master节点需要运行和监控额外的HAProxy和Keepalived服务，因此增加了整个集群的管理和运维的负担。

本申请的发明人在研究“解决master高可用部署的问题”的过程中发现：可以利用envoy，nginx等组件在工作节点上实现本地反向代理，已实现master节点对工作节点的高可用，但是，使用这些组件会有以下缺点：

1.工作节点对master节点访问的流量到用户态的进程后转包，负载均衡能力有限；

2.需要在每个节点上都跑一个进程，消耗更多资源；

3.需要额外的守护进程或者脚本，来检测和动态更新envoy或者nginx的负载均衡规则。

因此，为了解决上述问题，本申请提出了一种不依赖外部组件，仅通过LVS技术在工作节点配置本地内核态负载均衡的方式，配合kubernetes自身创建的service的endpoints探测和自动更新机制，实现master节点的高可用部署。

具体的，本申请实施例中提出的一种部署Kubernetes集群的方法，利用kube-proxy在ipvs模式下时，Kubernetes集群自身产生和维护的LVS规则，在工作节点上做反向代理，可以在不引入额外组件的情况下，实现master上api-server服务对所有工作节点访问的高可用。本申请提出的方法，与现有方案相比,具有以下优势：

1、由于是Kubernetes集群自身产生LVS规则，因此不受私有化部署条件的限制；

2、一旦有运行故障，Kubernetes集群自动维护LVS规则，无需进行IP漂移，排查定位更容易；

3、无需增加额外的资源消耗。

因此，本申请的方法以极小的代价和维护成本，实现了master节点对于工作节点的高可用。

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

图3是本申请一个示例性实施例提供的一种部署分布式容器编排管理集群的方法100。该方法100包括：

101、根据待部署的分布式容器编排管理集群中的任一Master节点的物理IP地址配置工作节点；

102、将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系

103、利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

也就是说，在该实施例中，利用任一Master节点的物理IP配置工作节点后，将该工作节点加入集群，在该工作节点上生成虚拟路由规则，再利用该虚拟路由规则更改该工作节点中kubelet组件和kube-proxy组件的配置，重启工作节点中的组件后实现Master节点对工作节点的高可用。

其中，kube-proxy是Kubernetes的核心组件，部署在每个工作节点Node上，是实现Kubernetes Service的通信与负载均衡机制的重要组件。kube-proxy负责为Pod创建代理服务，从api-server获取所有server信息，并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。

在k8s中，提供相同服务的一组pod可以抽象成一个service，通过service提供的统一入口对外提供服务，每个service都有一个虚拟IP地址(VIP)和端口号供客户端访问。kube-proxy存在于各个Node上，主要用于Service功能的实现，具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。

在一些该实施例中，所述待部署的分布式容器编排管理集群为Kubernetes集群，则步骤101具体可以包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

具体的，在该实施例中，将配置后所述的工作节点加入所述kubernetes集群后，该工作节点上的kube-proxy组件会通过集群的监听接口，实时跟踪service和endpoints的变更信息，从而实现在本工作节点上自动生成和维护虚拟路由规则。

所述虚拟路由规则为Linux虚拟服务器LVS规则，则所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的cluster IP，其中，所述kubernetesservice的cluster IP为Cluster IP地址池里的第1个地址。

由于ipvs模式采用的哈希hash表作为基础数据结构，并且工作在内核空间，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。

kube-proxy负责为Service提供cluster内部的服务发现和负载均衡，它运行在每个工作节点上，负责Pod网络代理,它会定时从etcd服务获取到service信息来做相应的策略，维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的，它是K8s集群内部的负载均衡器，也是一个分布式代理服务器，在K8s的每个Node上都有一个，从而具有伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。

service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。

在该实施例中，kube-proxy组件的转发模式为ipvs模式时，Kube-Proxy会监视Kubernetes Service对象和Endpoints，调用Netlink接口以相应地创建IP虚拟服务器IPVS规则并定期与Kubernetes Service对象和Endpoints对象同步IPVS规则，以确保IPVS状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。

其中，Endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。service配置selector，Endpoint controller才会自动创建对应的Endpoint对象；否则，不会生成Endpoint对象。

例如，k8s集群中创建一个名为hello的service，就会生成一个同名的Endpoint对象，Endpoints就是service关联的pod的ip地址和端口。

一个Service由一组backend Pod组成。这些Pod通过endpoints暴露出来。ServiceSelector将持续评估，评估结果被POST到一个名称为Service-hello的Endpoint对象上。当Pod终止后，它会自动从Endpoint中移除，新的能够匹配上Service Selector的Pod将自动地被添加到Endpoint中。检查该Endpoint，注意到IP地址与创建的Pod是相同的。

Endpoints是实现实际服务的端点集合。

Kubernetes在创建Service时，根据Service的标签选择器(Label Selector)来查找Pod，据此创建与Service同名的Endpoints对象。当Pod的地址发生变化时，Endpoints也随之变化。Service接收到请求时，就能通过Endpoints找到请求转发的目标地址。

该实施例中将调度算法设置为wrr，即加权轮询调度，使得负载均衡。加权轮询算法的原理就是：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。

每收到7个客户端的请求，会把其中的1个转发给后端a，把其中的2个转发给后端b，把其中的4个转发给后端c。

加权轮询算法的结果，就是要生成一个服务器序列。每当有请求到来时，就依次从该序列中取出下一个服务器用于处理该请求。比如针对上面的例子，加权轮询算法会生成序列{c,c,b,c,a,b,c}。这样，每收到7个客户端的请求时，会把其中的1个转发给后端a，把其中的2个转发给后端b，把其中的4个转发给后端c。收到的第8个请求，重新从该序列的头部开始轮询。

总之，加权轮询算法要生成一个服务器序列，该序列中包含n个服务器。n是所有服务器的权重之和。在该序列中，每个服务器的出现的次数，等于其权重值。并且，生成的序列中，服务器的分布应该尽可能的均匀。

而在该实施例中，将工作节点的kube-prox组件转发模式设置为ipvs模式，调度算法设置为wrr算法，在这种情况下，客户端访问service时，kube-proxy组件会以更短的时延，在内核态下依次轮询Endpoints，并根据每个endpoint的权重大小最终定向。

具体的，在该实施例中，步骤103可以包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetes service的cluster IP。

具体的，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

在一些实施例中，如图4所示，该方法100还可以包括：

104、当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述LVS规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

也就是说，当一个Master节点出现故障时，可以准确地获知该节点物理IP地址，并从虚拟路由规则中删除该节点的物理IP地址，同时告知其他节点该节点不可用。

为了更加详细的描述本申请提供的一种部署分布式容器编排管理集群的方法，下面结合图5和图6所示的示例，以部署Kubernetes集群为例，对本申请实施例中提供的方法进行详细的描述。

以图5为例，三个已经初始化的Master节点分别为Master1-3，工作节点上配置了一个地址端口为10.254.0.1:443的LVS规则，该地址端口使用TCP协议，wrr调度算法以及NAT模式，三个真实服务器的地址即指向三个Master节点的api-server服务。

地址10.254.0.1是Kubernetes service本身的地址，Kubernetes集群的api-server本身也是一个Service，名称就是kubernetes，并且该Service的Cluster IP地址是Cluster IP地址池里的第1个地址，所服务的端口是HTTPS端口443，正如图3所示。

如果部署工作节点时将kube-proxy的代理模式设置为ipvs，那么在该工作节点成功加入集群之后，Kubernetes会自行生成如同图3的kubernetes Service的LVS规则，并且Kubernetes还会清除所有用户自行创建的LVS规则。在api-server任意一个副本发生故障(即：当Master1-3中的任一个节点发生故障)时，Kubernetes会更新所有工作节点上kubernetes Service的endpoints列表，即：更新各个工作节点中的LVS规则。

由此，无需任何其他组件，利用Kubernetes的这个特性，在工作节点加入集群并成功在本节点创建kubernetes Service的规则后，重启工作节点的kube-proxy和kubelet组件，然后将其server地址配置设置为kubernetes Service本身的地址(即Cluster IP地址池里的第1个地址，例如：https://10.254.0.1:443)，即可实现Master1-3节点对该工作节点的高可用。

具体的高可用部署步骤如下：

1.首先以集群的方式部署etcd:可与Master节点共用机器堆叠部署，也可以部署在kubernetes集群机器之外；

etcd的具体部署过程采用现有技术中的部署方法实现，为了描述的简洁，在此不再赘述。

2.Master节点的高可用部署：以Master的api-server、控制器和调度器三个服务作为一个部署单元，类似于etcd集群的典型部署配置，使用至少三台服务器安装Master服务。这三个服务可以二进制部署使用systemd进行管理，也可以容器化static pod部署利用kubelet进行监控和自动重启。确保每个master节点的控制器和调度器启用了leader选举配置，并且api-server都可以正常服务之后，进入下一步；

3.工作节点加入集群：

利用集群中任意一个master节点的物理IP地址配置工作节点，然后将该工作节点加入集群。如图6所示，将工作节点加入集群的过程包括：

11、将工作节点的kubelet以及kube-proxy组件的cluster server配置为集群中任意一个Master节点的物理IP地址；

12、将该工作节点的kube-proxy的转发模式设置为ipvs，调度算法scheduler设置为wrr，然后将该工作节点加入集群。

13、将配置后的该工作节点加入集群后，此时一个名为kubernetes的Service将被kube-proxy自动创建，该工作节点的kube-proxy组件通过该集群的监听接口，实时跟踪获取该集群所创建的service和Endpoints的变更信息，在该工作节点上自动生成并维护LVS规则。该LVS规则包括虚拟IP地址与该集群中所有Master节点的物理IP地址之间的映射关系，其中，LVS规则中的虚拟IP地址为该集群的kubernetes service的cluster IP，而kubernetes service的cluster IP为Cluster IP地址池里的第1个地址，例如：图5中的https://10.254.0.1:443。

4.工作节点利用LVS反向代理，实现对api-server服务访问的高可用：具体是利用步骤13中生成的LVS规则更改该工作节点的组件的配置，并重启该工作节点的组件，即可实现Master上api-server服务对所有工作节点访问的高可用。

具体过程如图6所示：

14、将该工作节点的kubelet组件和kube-proxy组件的配置中的cluster server更改为kubernetes service的cluster IP，重启kubelet和kube-proxy服务。至此，就实现了Master上api-server服务对所有工作节点访问的高可用。

15、当检测到该集群中的任一Master节点发生故障时，通过该集群从LVS规则中删除发生故障的Master节点的物理IP地址，从而可以更新该集群中所有工作节点上的LVS规则。

本申请提出的分布式容器编排管理集群的部署方法应用于Kubernetes集群时，可以利用kube-proxy在ipvs模式下Kubernetes集群自身产生和维护的LVS规则，在工作节点上做反向代理，可以在不引入额外组件的情况下，实现Master上api-server服务对所有工作节点访问的高可用。本申请提出的方法，与现有方案相比，不受私有化部署条件的限制、无需进行IP漂移，排查定位更容易，无需增加额外的资源消耗，以极小的代价和维护成本，实现了Master节点对于工作节点的高可用。

基于相同的发明构思，本申请实施例还提供了一种部署分布式容器编排管理集群的装置，该装置的结构示意图如图7所示，该装置200包括：配置模块201、生成模块202和更改模块203，其中，

配置模块201，用于根据待部署的分布式容器编排管理集群中的任一Master节点的物理IP地址配置工作节点；

生成模块202，用于将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系；

更改模块203，用于利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

在一些实施例中，所述待部署的分布式容器编排管理集群为Kubernetes集群，所述配置模块，具体用于：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

在一些实施例中，所述虚拟路由规则为Linux虚拟服务器LVS规则，所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的cluster IP，其中，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

具体的，在该实施例中，生成模块202具体用于，通过所述工作节点上的kube-proxy组件通过所述Kubernetes集群的监听接口，实时跟踪获取所述Kubernetes集群所创建的service和endpoints的变更信息，在所述工作节点上自动生成并维护所述LVS规则。

在一些实施例中，所述更改模块203，具体用于：将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetes service的clusterIP。

在一些实施例中，如图7所示，装置200还包括：更新模块204。

更新模块204，用于当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述虚拟路由规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

本申请实施例提供的部署分布式容器编排管理集群的装置中未详述的内容，可参照上述实施例中提供的部署分布式容器编排管理集群的方法，本申请实施例提供的部署分布式容器编排管理集群的装置能够达到的有益效果与上述实施例中提供的部署分布式容器编排管理集群的方法相同，在此不再赘述。

基于相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备的结构示意图如图8所示，该电子设备300包括至少一个处理器301、存储器302和总线303，至少一个处理器301均与存储器302电连接；存储器302被配置用于存储有至少一个计算机可执行指令，处理器301被配置用于执行该至少一个计算机可执行指令，从而执行如本申请实施例一中任意一个实施例或任意一种可选实施方式提供的任意一种部署分布式容器编排管理集群的方法的步骤。

进一步，处理器301可以是FPGA(Field－Programmable Gate Array，现场可编程门阵列)或者其它具有逻辑处理能力的器件，如MCU(Microcontroller Unit，微控制单元)、CPU(Central Process Unit，中央处理器)。

基于相同的发明构思，本申请实施例还提供一种计算机可读存储介质，存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述方法实施例提供的部署分布式容器编排管理集群的方法。

本申请实施例提供的计算机可读存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(RandomAccess Memory，随即存储器)、EPROM(Erasable Programmable Read-OnlyMemory，可擦写可编程只读存储器)、EEPROM(Electrically Erasable ProgrammableRead-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本申请还提供了一种计算机程序产品，当其在电子设备上运行时，使得电子设备执行上述各个方法实施例的部署分布式容器编排管理集群的方法。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，程序可以存储于一种计算机可读存储介质中。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本申请公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本申请中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本申请中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本申请中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (14)

1.一种部署分布式容器编排管理集群的方法，其特征在于，所述方法包括：

根据待部署的分布式容器编排管理集群中的任一主Master节点的物理IP地址配置工作节点；

将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系；

利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

2.根据权利要求1所述的方法，其特征在于，所述待部署的分布式容器编排管理集群为Kubernetes集群，则所述根据待部署的分布式容器编排管理集群中的任一Master节点的物理IP地址配置工作节点，包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

3.根据权利要求2的方法，其特征在于，所述虚拟路由规则为Linux虚拟服务器LVS规则，则所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的clusterIP，其中，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

4.根据权利要求3的方法，其特征在于，所述利用所述虚拟路由规则更改所述工作节点中组件的配置，包括：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetes service的cluster IP。

5.根据权利要求3的方法，其特征在于，在所述工作节点上自动生成虚拟路由规则，包括：

通过所述工作节点上的kube-proxy组件通过所述Kubernetes集群的监听接口，实时跟踪获取所述Kubernetes集群所创建的service和endpoints的变更信息，在所述工作节点上自动生成并维护所述LVS规则。

6.根据权利要求2至5中任一项所述的方法，其特征在于，还包括：

当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述虚拟路由规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

7.一种部署分布式容器编排管理集群的装置，其特征在于，所述装置包括：

配置模块，用于根据待部署的分布式容器编排管理集群中的任一主Master节点的物理IP地址配置工作节点；

生成模块，用于将配置后的所述工作节点加入所述分布式容器编排管理集群后，在所述工作节点上自动生成虚拟路由规则，

其中，所述虚拟路由规则包括虚拟IP地址与所述分布式容器编排管理集群中所有Master节点的物理IP地址之间的映射关系；

更改模块，用于利用所述虚拟路由规则更改所述工作节点的组件的配置，并重启所述工作节点的组件。

8.根据权利要求7的装置，其特征在于，所述待部署的分布式容器编排管理集群为Kubernetes集群，所述配置模块，具体用于：

将所述工作节点的kubelet组件和kube-proxy组件的cluster server配置为所述任一Master节点的物理IP地址；

将所述工作节点的kube-proxy组件的转发模式设置为ipvs模式，调度算法设置为wrr算法。

9.根据权利要求8的装置，其特征在于，所述虚拟路由规则为Linux虚拟服务器LVS规则，所述LVS规则中的虚拟IP地址为所述Kubernetes集群的kubernetes service的clusterIP，其中，所述kubernetes service的cluster IP为Cluster IP地址池里的第1个地址。

10.根据权利要求9的装置，其特征在于，所述更改模块，具体用于：将所述工作节点的kubelet组件和kube-proxy组件的cluster server更改为所述LVS规则中的kubernetesservice的cluster IP。

11.根据权利要求9的装置，其特征在于，所述生成模块具体用于，通过所述工作节点上的kube-proxy组件通过所述Kubernetes集群的监听接口，实时跟踪获取所述Kubernetes集群所创建的service和endpoints的变更信息，在所述工作节点上自动生成并维护所述LVS规则。

12.根据权利要求8至11中任一项所述的装置，其特征在于，还包括：

更新模块，用于当检测到所述Kubernetes集群中的任一所述Master节点发生故障时，通过所述Kubernetes集群从所述虚拟路由规则中删除发生故障的所述Master节点的物理IP地址，以更新所述Kubernetes集群中所有工作节点上的虚拟路由规则。

13.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至6任一所述的部署分布式容器编排管理集群的方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至6任一所述部署分布式容器编排管理集群的方法。

Images