虚拟节点状态监控器部署方法、装置、存储介质及设备与流程

1.本公开涉及信息技术领域，尤其涉及虚拟节点状态监控器部署方法、装置、存储介质及设备。


背景技术：

2.随着容器技术的发展，容器技术和虚拟化技术已经成为一种被大家广泛认可的容器技术服务器资源共享方式，容器技术可以在按需构建容器技术操作系统实例的过程当中，为操作人员提供极大的灵活性。kubernetes(k8s)是由谷歌(google)创建管理的开源平台。kubernetes的名字来自于希腊语，意思是“舵手”或“领航员”。k8s是一个容器集群管理系统。k8s可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
3.virtual kubelet是开源kubernetes kubelet的一个实现方案，它伪装成一个虚拟的kubelet链接kubernetes集群和其他平台的api，可以在云无服务器api中调度容器，但是，相关技术中对于virtual kubelet的部署方案可能导致布设于virtual kubelet中的业务容器组频繁重建和驱逐失效等问题。


技术实现要素：

4.为了降低业务容器组重建频率，并且降低驱逐失效的概率理，本公开实施例提供虚拟节点状态监控器部署方法、装置、存储介质及设备。
5.一方面，本公开提供了一种虚拟节点状态监控器部署方法，所述方法包括：
6.提供一个kubernetes集群,该集群包含至少一个子网；
7.在每个子网中部署至少三个包含虚拟节点状态监控器的容器组的副本；其中至少一个子网中部署至少一个业务容器组；所述至少一个业务容器组被所述至少一个子网中的至少一个虚拟节点状态监控器监控；
8.使用无头服务暴露所述至少一个虚拟节点状态监控器中的业务容器组。
9.另一方面，本公开提供一种虚拟节点状态监控器处理装置，所述装置包括：
10.子网确定模块，用于提供一个kubernetes集群,该集群包含至少一个子网；
11.部署模块，用于在每个子网中部署至少三个包含虚拟节点状态监控器的容器组的副本；其中至少一个子网中部署至少一个业务容器组；所述至少一个业务容器组被所述至少一个子网中的至少一个虚拟节点状态监控器监控；
12.无头服务模块，用于使用无头服务暴露所述至少一个虚拟节点状态监控器中的业务容器组。
13.另一方面，本公开提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现上述的一种虚拟节点状态监控器部署方法。
14.另一方面，本公开提供了一种虚拟节点状态监控器处理设备，其特征在于，包括至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可
被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现上述的一种虚拟节点状态监控器部署方法。
15.本公开提供了虚拟节点状态监控器部署方法、装置、存储介质及设备。本公开通过在kubernetes集群的各个子网中布设至少三个包含虚拟节点状态监控器的容器组的副本的方式使得kubernetes中第二容器组驱逐策略的启动频率降低，降低了驱逐失效的概率，并且进一步可以通过设置部署模式，降低虚拟节点状态监控器中的业务容器组的重建概率，从而实现了一种虚拟节点状态监控器管理的高可用方案，为虚拟节点状态监控器的故障重启，升级重建提供保障，并且为调度虚拟节点状态监控器中的业务容器组提供了可靠性保障。
附图说明
16.为了更清楚地说明本公开实施例或相关技术中的技术方案和优点，下面将对实施例或相关技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
17.图1是本公开提供的在相关技术的虚拟节点状态监控器部署示意图；
18.图2是本公开提供的一种虚拟节点状态监控器部署方法的框架示意图；
19.图3是本公开实施例提供的一种虚拟节点状态监控器部署方法的流程示意图；
20.图4是本公开实施例提供的子网a中的容器部署示意图；
21.图5是本公开提供的一个场景中kubernetes的架构示意图；
22.图6是本公开提供的对每个虚拟节点状态监控器进行重启的方法的流程示意图；
23.图7是本公开提供的对每个虚拟节点状态监控器进行升级的方法的流程示意图；
24.图8是本公开提供的一种虚拟节点状态监控器处理装置框图；
25.图9是本公开提供的一种用于实现本公开实施例所提供的方法的设备的硬件结构示意图。
具体实施方式
26.下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
27.需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
28.为了使本公开实施例公开的目的、技术方案及优点更加清楚明白，以下结合附图
及实施例，对本公开实施例进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本公开实施例，并不用于限定本公开实施例。
29.以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。为了便于理解本公开实施例上述的技术方案及其产生的技术效果，本公开实施例首先对于相关专业名词进行解释：
30.kubernetes：kubernetes是google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，目标是让部署容器化的应用简单并且高效,kubernetes提供了应用部署，规划，更新，维护的一种机制，在设计结构上定义了一系列的构建模块，其目的是为了提供一个可以共同提供部署、维护和扩展应用程序的机制。组成kubernetes的组件设计概念为松耦合和可扩展的，这样可以使之满足多种不同的工作负载。可扩展性在很大程度上由kubernetes api提供，此api主要被作为扩展的内部组件以及kubernetes上运行的容器来使用。kubernetes可以部署在分布式计算机集群中，每个计算机可以形成一个节点，每个节点可以运行一个或多个应用，每个容器组可以支持一个或多个应用，每个节点可以运行一个或多个容器组。
31.pod：kubernetes的基本调度单元称为“pod”，本公开中将其解释为容器组。通过该种抽象类别可以把更高级别的抽象内容增加到容器化组件。一个pod一般包含一个或多个容器，这样可以保证它们一直位于主机上，并且可以共享资源。kubernetes中的每个pod都被分配一个唯一的(在集群内的)ip地址这样就可以允许应用程序使用同一端口，而避免了发生冲突的问题。pod可以定义一个卷，例如本地磁盘目录或网络磁盘，并将其暴露在pod中的一个容器之中。pod可以通过kubernetes api手动管理，也可以委托给控制器来实现自动管理。
32.kubelet：kubelet负责每个节点的运行状态，即确保节点上的所有容器都正常运行，本公开中将其解释为节点状态监控器。它按照控制面板的指示来处理启动，停止和维护应用程序容器。kubelet会监视pod的状态，如果不处于所需状态，则pod将被重新部署到同一个节点。节点状态每隔几秒就会传递消息至中继主机。主控器检测到节点故障后，可以在其他健康节点上启动pod。
33.apiserver：api服务器是一个关键组件并使用kubernetes api和json over http来提供了kubernetes的内部和外部接口，其可以布设在某个节点上。
34.vk：virtual kubelet的缩写，本公开中将其解释为虚拟节点状态监控器。virtual kubelet是开源kubernetes kubelet的一个实现方案，它是伪装成一个虚拟的kubelet链接kubernetes集群和其他平台的api。vk的主要场景是支持kubernetes api扩展到aci和fargate等无服务器容器平台中。从kubernetes apiserver的角度来看，virtual kubelet看起来像普通的kubelet，但其关键区别在于它们在其他地方调度容器，例如在云无服务器api中，而不是在节点上。vk具有可插拔的体系结构，可以直接使用kubernetes原语。
35.service：是kubernetes中的一种资源，提供了我们访问单个或多个容器应用的能力。每个服务在其生命周期内，都拥有一个固定的ip地址和端口。每个服务对应了后台的一个或多个pod，通过这种方式，客户端就不需要关心pod所在的位置，方便后端进行方便的
pod扩容、缩容等操作。headless services(无头服务)是一种特殊的service，在实际运行时不会被分配固定的ip地址，当客户端访问headless service时，由集群中的dns(域名系统)返回该服务的pod的ip地址集合，能够让客户端自行定义负载均衡策略。
36.deployment：本公开将其解释为无状态服务部署模式；statefulset：本公开将其解释为有状态服务部署模式；statefulset和deployment都是kubernetes提供的管理应用的负载管理控制器api。statefulset在pod组管理的基础上，保证pod组中pod的顺序和一致性，与deployment不同的是，statefulset创建的pod在生命周期中会保持持久的标记(例如pod name)。
37.pod-eviction-timeout：容器组驱逐超时时间。
38.node-eviction-rate：驱逐速度，默认为0.1pod/秒。
39.kube-controller-manager：容器组控制器。
40.第一容器组驱逐策略：由kubernetes提供的一种驱逐非健康节点的pod策略，由kube-controller-manager周期性检查节点状态，每当节点状态为notready，并且超出podevictiontimeout时间后，就把该节点上的pod全部驱逐到其它节点，其中具体驱逐速度还受驱逐速度参数，集群大小等的影响。最常用的2个参数为pod-eviction-timeout和node-eviction-rate。
41.large-cluster-size-threshold：大集群容量阈值。判断集群是否为大集群，默认为50，即50个节点以上的集群为大集群。
42.unhealthy-zone-threshold：故障节点比例阈值。默认为55％。
43.secondary-node-eviction-rate：第二驱逐速率。
44.第二容器组驱逐策略：由kubernetes提供的另一种驱逐非健康节点的pod策略，当某个子网中故障节点的数目超过一定阈值时，有可能触发该第二容器组驱逐策略。当大集群的故障节点超过55％时，基于第二容器组驱逐策略进行驱逐，第二驱逐速率默认为0.01pod/秒。当小集群故障节点超过55％时，基于第二容器组驱逐策略进行驱逐，第二驱逐速率为0pod/秒。
45.下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
46.相关技术中基于kubernetes部署虚拟节点状态监控器(virtual kubelet)的部署方案中，通常在kubernetes集群中基于无状态服务部署模式(deployment)布设单个虚拟节点状态监控器。请参考图1，其示出了在相关技术的虚拟节点状态监控器部署示意图。显然，虚拟节点状态监控器在kubernetes集群中将自身注册为一个节点，并且允许在其中布设容器组和容器。在kubernetes视角，布设在节点中的节点状态监控器和该单个虚拟节点状态监控器差别不大，都可以调度kubernetes的相关api，比如capacity，operatingsystem，createpod，updatepod，getpod，getpodstatus，getpods，nodeconditions。只是虚拟节点状态监控器可以在云无服务器api中调度容器，而并不是在节点上调度容器。虚拟节点状态监控器的布设不影响其他普通节点状态监控器的正常工作。
47.但是，相关技术若以deployment模式部署单个虚拟节点状态监控器，则该单个虚
拟节点状态监控器每次在重新启动后，都会被赋不同的网络标记。这就会触发容器组控制器驱逐原单个虚拟节点状态监控上的业务容器组，从而引发业务容器组重建，这导致业务容器组可能被频繁重建。
48.进一步地，相关技术若以deployment模式部署单个虚拟节点状态监控器，如果该单个虚拟节点状态监控器遇到故障，无法与apiserver进行通讯，且无法通讯的时间超过了容器组驱逐超时时间，此时若该方案应用于云无服务器服务场景中，则由于云无服务器服务场景中不存在普通节点状态监控器，而该单个虚拟节点状态监控器所在子网中没有其他能够正常运行的虚拟节点状态监控器，则该子网的故障节点比例可能达到100％，已然超过故障节点比例，此时，可以触发第二容器组驱逐策略的执行，若该单个虚拟节点状态监控器所在子网对应的集群为小集群，则第二驱逐速率为0pod/秒，这相当于驱逐失效，这将会导致该单个虚拟节点状态监控器上布设的业务容器无法通过虚拟节点状态监控器继续与kubernetes通讯。
49.可见，相关技术中以deployment模式部署单个虚拟节点状态监控器的部署方案可能会引发频繁的业务容器组重建，并且，若将其应用于云无服务器服务场景中还可能导致驱逐失效，为了解决上述技术问题，本公开提供一种虚拟节点状态监控器处理方案，该方案可以被应用于云无服务器服务场景中，降低业务容器组重建频率，并且降低驱逐失效的概率。
50.如图2所示，其示出了本公开实施例提供的一种虚拟节点状态监控器部署方法的框架示意图，本公开的实施可以基于kubernetes的容器网络框架。示例性的，容器网络包括多个子网，每个子网中可以包含至少三个虚拟节点状态监控器，每个虚拟节点状态监控器包括0个或至少一个业务容器组，本公开实施例适用于云无服务器服务场景中，因此该各个子网中可以仅仅部署虚拟节点状态监控器，而不部署节点状态监控器。该实施框架形成了一种容器云，容器云是主要由容器构成的云计算网络，例如，可基于开源的kubernetes和moby(docker的社区项目)定制优化实现，交付云计算caas(communication as a service，通信即服务)能力，主要是持续集成、持续部署和面向应用的微服务能力。
51.容器云以容器的形式支持可扩展的各种业务服务从而提供面向应用的服务能力，按照应用类型的不同，可以形成被应用于医疗云、云物联、云安全、云呼叫、私有云、公有云、混合云、云游戏、云教育、云会议、云社交、人工智能云服务等多种场景之中。
52.其中，医疗云(medical cloud)，是指在云计算、移动技术、多媒体、4g通信、大数据、以及物联网等新技术基础上，结合医疗技术，使用“云计算”来创建医疗健康服务云平台，实现了医疗资源的共享和医疗范围的扩大。因为云计算技术的运用于结合，医疗云提高医疗机构的效率，方便居民就医。像现在医院的预约挂号、电子病历、医保等等都是云计算与医疗领域结合的产物，医疗云还具有数据安全、信息共享、动态扩展、布局全局的优势。
53.云安全(cloud security)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念，通过网状的大量客户端对网络中软件行为的异常监测，获取互联网中木马、恶意程序的最新信息，并发送到服务端进行自动分析和处理，再把病毒和木马的解决方案分发到每一个客户端。
54.私有云(private cloud)是将云基础设施与软硬件资源创建在防火墙内，以供机
构或企业内各部门共享数据中心内的资源。创建私有云，除了硬件资源外，一般还有云设备(iaas，infrastructure as a service，基础设施即服务)软件。
55.公有云(public cloud)通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过internet使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务。
56.混合云(hybrid cloud)融合了公有云(public cloud)和私有云(private cloud)，是近年来云计算的主要模式和发展方向。私有云主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。
57.云游戏(cloud gaming)又可称为游戏点播(gaming on demand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。
58.云教育(cloud computing education简称：ccedu)，是指基于云计算商业模式应用的教育平台服务。在云平台上，所有的教育机构，培训机构，招生服务机构，宣传机构，行业协会，管理机构，行业媒体，法律结构等都集中云整合成资源池，各个资源相互展示和互动，按需交流，达成意向，从而降低教育成本，提高效率。
59.云会议是基于云计算技术的一种高效、便捷、低成本的会议形式。使用者只需要通过互联网界面，进行简单易用的操作，便可快速高效地与全球各地团队及客户同步分享语音、数据文件及视频，而会议中数据的传输、处理等复杂技术由云会议服务商帮助使用者进行操作。
60.云社交(cloud social)是一种物联网、云计算和移动互联网交互应用的虚拟社交应用模式，以建立著名的“资源分享关系图谱”为目的，进而开展网络社交，云社交的主要特征，就是把大量的社会资源统一整合和评测，构成一个资源有效池向用户按需提供服务。参与分享的用户越多，能够创造的利用价值就越大。
61.所谓人工智能云服务，一般也被称作是aiaas(ai as a service，中文为“ai即服务”)。这是目前主流的一种人工智能平台的服务方式，具体来说aiaas平台会把几类常见的ai服务进行拆分，并在云端提供独立或者打包的服务。这种服务模式类似于开了一个ai主题商城：所有的开发者都可以通过api接口的方式来接入使用平台提供的一种或者是多种人工智能服务，部分资深的开发者还可以使用平台提供的ai框架和ai基础设施来部署和运维自己专属的云人工智能服务。
62.以下介绍本公开的一种虚拟节点状态监控器部署方法，图3示出了本公开实施例提供的一种虚拟节点状态监控器部署方法的流程示意图，本公开提供了如实施例或流程图上述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执
行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，上述方法可以包括：
63.s101.提供一个kubernetes集群,该集群包含至少一个子网。
64.kubernetes集群可以包括至少一个子网，本公开实施例中可以对于各个子网均独立执行后续的处理步骤。
65.上述kubernetes集群可以被布设于云无服务器环境中，上述每个虚拟节点状态监控器中的业务容器组用于提供云无服务器服务。
66.s103.在每个子网中部署至少三个包含虚拟节点状态监控器的容器组的副本；其中至少一个子网中部署至少一个业务容器组；上述至少一个业务容器组被上述至少一个子网中的至少一个虚拟节点状态监控器监控。
67.本公开中各个业务容器组可以独立被同子网中的任意一个虚拟节点状态监控器监控，并且只被一个虚拟节点监控器监控。示例性的，请参考图4，其示出了子网a中的容器部署示意图。若一个子网a中部署有a0,a1,a2，a3四个虚拟节点状态监控器，并且在所述子网a中存在bo,b1两个业务容器组，则业务容器组bo可以被调度至a0,a1,a2，a3四个虚拟节点状态监控器中的任意一个，若bo被调度至ao，则bo不可以同时被调度至a1,a2和a3。业务容器组b1的调度与业务容器组b0无关，其可以被独立调度至a0,a1,a2，a3四个虚拟节点状态监控器中的任意一个，若b1被调度至a2，则b1不可以同时被调度至a0,a1和a3。
68.在子网a构建伊始，a0,a1,a2，a3四个虚拟节点状态监控器可以均未部署任何业务容器组，伴随服务的构建，迁移和扩展，可以将服务对应的业务容器组调度至子网a中的任意一个虚拟节点状态监控器。
69.请参考图5，其示出了一个场景中kubernetes的架构示意图。图5中的kubernetes集群包括两个子网，分别为zonea和zoneb，其中，zonea包括三个虚拟节点状态监控器，zoneb也包括三个虚拟节点状态监控器。zonea包括的三个虚拟节点状态监控器分别为za-vk-0，za-vk-1，za-vk-2，zoneb包括的三个虚拟节点状态监控器分别为zb-vk-0，zb-vk-1，zb-vk-2，zoneb还部署了两个业务容器组，即业务3和业务4，这两个业务容器组都被调度到虚拟节点状态监控器zb-vk-0上，即虚拟节点状态监控器zb-vk-0监控两个业务容器组业务3和业务4。
70.本公开中可以在各个子网中均部署三个包含虚拟节点状态监控器的容器组的副本，也可以根据实际需求部署更多的包含虚拟节点状态监控器的容器组的副本。
71.本公开中使用有状态服务部署模式部署每个包含虚拟节点状态监控器的容器组的副本。有状态服务部署模式可以保证在对子网中的虚拟节点状态监控器进行重启或升级的场景中，充分保证虚拟节点状态监控器的顺序重启和升级。
72.步骤s105.使用无头服务暴露所述至少一个虚拟节点状态监控器中的业务容器组。
73.本公开可以确保子网中的虚拟节点状态监控器进行重启或升级的场景的顺序一致性，具体地，本公开对于至少一个子网中的全部虚拟节点状态监控器进行重启的方法进行详述。上述对于至少一个子网中的全部虚拟节点状态监控器进行重启的方法包括顺序对上述至少一个子网中的各个虚拟节点状态监控器进行重启，请参考图6，其示出了对每个虚拟节点状态监控器进行重启的方法，上述方法包括：
74.s201.若上述虚拟节点状态监控器的重启时间小于容器组驱逐超时时间，则直接对上述虚拟节点状态监控器进行重启。
75.本公开中使用有状态服务部署模式部署虚拟节点状态监控器，这使得虚拟节点状态监控器重启后可以继续使用原来的网络标记，若上述虚拟节点状态监控器的重启时间小于容器组驱逐超时时间，则无需对虚拟节点状态监控器监控的业务容器组进行重建，直接对上述虚拟节点状态监控器进行重启即可。
76.s203.若上述虚拟节点状态监控器的重启时间大于等于上述容器组驱逐超时时间，则将上述虚拟节点状态监控器监控的各个业务容器组驱逐至上述至少一个子网中的不同于上述虚拟节点状态监控器的其它虚拟节点状态监控器中，对上述虚拟节点状态监控器进行重启。
77.以图4中的虚拟节点状态监控器中a0为例，虚拟节点状态监控器中a0监控业务容器组b0，若虚拟节点状态监控器中a0的重启时间为6分钟，超过了预设的容器组驱逐超时时间5分钟，则会触发业务容器组的驱逐，业务容器组b0可能会被驱逐至a1,a2，a3三个虚拟节点状态监控器中的任意一个。若虚拟节点状态监控器中a0的重启时间为4分钟，尚未超过上述的容器组驱逐超时时间，则直接重启该虚拟节点状态监控器中a0即可。
78.本公开中的每个子网包括至少三个虚拟节点状态监控器，若其中一个需要进行重启，其它虚拟节点状态监控器还可以正常运行。以图4中的子网a为例，若虚拟节点状态监控器中a0进行重启，在重启时无法进行正常的状态监控工作，此时，相当于一个故障节点，因为子网a中一共有四个虚拟节点状态监控器，而a1,a2，a3正常工作中，因此，子网a的故障节点比例为25％，没有达到kubernetes的故障节点比例阈值55％，因此不会触发kubernetes的第二容器组驱逐策略的执行，但是可以触发第一容器组驱逐策略的执行，按照第一容器组驱逐策略可以将需要进行重启的虚拟节点状态监控器对应的各个业务容器组驱逐到同一个子网的其它虚拟节点状态监控器，比如，可以将a0对应的业务容器组b0驱逐至a1,a2，a3三个虚拟节点状态监控器中的任意一个，然后再对需要重启的虚拟节点状态监控器进行重启。
79.在一个实施方式中，可以将上述虚拟节点状态监控器监控的各个业务容器组独立随机驱逐至上述至少一个子网中的不同于上述虚拟节点状态监控器的任意一个其它虚拟节点状态监控器中。
80.在一个实施方式中，对于上述虚拟节点状态监控器中的任意一个业务容器组，可以确定接收上述业务容器组的目标虚拟节点状态监控器，上述目标虚拟节点状态监控器为上述至少一个子网中的不同于上述虚拟节点状态监控器的其它虚拟节点状态监控器；然后，重建上述任意一个业务容器组，并将上述任意一个业务容器组调度至上述目标虚拟节点状态监控器，以此实现业务容器组的驱逐。
81.示例性的，本公开以图5示出的kubernetes的架构中的子网zoneb进行重启为例，详述重启过程如下：
82.按照子网zoneb中虚拟节点状态监控器的顺序，zb-vk-0首先被重启，若zb-vk-0的重启时间小于容器组驱逐超时时间，则直接对zb-vk-0进行重启，若zb-vk-0的重启时间大于等于容器组驱逐超时时间，则触发对zb-vk-0监控的业务容器组业务3和业务4的驱逐，在驱逐后对zb-vk-0进行重启。
83.驱逐的过程中业务3和业务4可以分别独立被随机驱逐到zb-vk-1或zb-vk-2，若业务3被驱逐到zb-vk-1，则重建业务3并将其调度至zb-vk-1；若业务4被驱逐到zb-vk-2，则重建业务4并将其调度至zb-vk-2。
84.当zb-vk-0重启后，可以按照相同逻辑依次重启zb-vk-1和zb-vk-2。
85.基于相同构思，可以对于包括n(n》3)个虚拟节点状态监控器任意一个子网zonem进行重启，按照zonem中的n个虚拟节点状态监控器的顺序依次重启上述n个虚拟节点状态监控器，对于任意一个虚拟节点监控器，若其的重启时间小于容器组驱逐超时时间，则直接对其进行重启；否则，将上述虚拟节点监控器监控的业务容器驱逐至其他n-1个虚拟节点状态监控器后，对上述虚拟节点监控器进行重启。
86.基于相同构思，本公开还可以对于至少一个子网中的全部虚拟节点状态监控器进行升级，上述对于至少一个子网中的全部虚拟节点状态监控器进行升级的方法包括顺序对上述至少一个子网中的各个虚拟节点状态监控器进行升级，请参考图7，其示出了对每个虚拟节点状态监控器进行升级的方法，上述方法包括：
87.s301.若上述虚拟节点状态监控器的重启时间小于容器组驱逐超时时间，则直接对上述虚拟节点状态监控器进行升级。
88.s203.若上述虚拟节点状态监控器的重启时间大于等于上述容器组驱逐超时时间，则将上述虚拟节点状态监控器监控的各个业务容器组驱逐至上述至少一个子网中的不同于上述虚拟节点状态监控器的其它虚拟节点状态监控器中，对上述虚拟节点状态监控器进行升级。
89.本公开中对至少一个子网中的全部虚拟节点状态监控器进行升级的方法的执行细节与至少一个子网中的全部虚拟节点状态监控器进行重启的方法的执行细节相似，在此不做赘述。
90.示例性的，本公开以kubernetes的架构中的子网zoneb进行升级为例，详述升级过程如下：
91.按照子网zoneb中虚拟节点状态监控器的顺序，zb-vk-0首先被升级，若zb-vk-0的重启时间小于容器组驱逐超时时间，则直接对zb-vk-0进行升级，若zb-vk-0的重启时间大于等于容器组驱逐超时时间，则触发对zb-vk-0监控的业务容器组业务3和业务4的驱逐，在驱逐后对zb-vk-0进行升级。
92.驱逐的过程中业务3和业务4可以分别独立被随机驱逐到zb-vk-1或zb-vk-2，若业务3被驱逐到zb-vk-1，则重建业务3并将其调度至zb-vk-1；若业务4被驱逐到zb-vk-2，则重建业务4并将其调度至zb-vk-2。
93.当zb-vk-0升级后，可以按照相同逻辑依次升级zb-vk-1和zb-vk-2。
94.本公开示出的一种虚拟节点状态监控器部署方法，通过使用有状态服务部署模式部署每个包含虚拟节点状态监控器的容器组的副本，可以降低在进行虚拟节点状态监控器进行重启或升级时，虚拟节点状态监控器监控的业务容器组的驱逐重建的概率，并且由于在子网中布设了至少三个虚拟节点状态监控器，可以降低第二容器组驱逐策略的执行概率，降低业务容器组驱逐失败的概率，从而确保子网中的虚拟节点状态监控器重启或升级的鲁棒性和成功率。本公开示出的虚拟节点状态监控器部署方法提供了一种管理虚拟节点状态监控器的高可用方案，也为调度到虚拟节点状态监控器的业务容器组提供了可靠性保
障。
95.本公开实施例还公开了一种虚拟节点状态监控器处理装置，如图8所示，上述装置包括：
96.子网确定模块401，用于提供一个kubernetes集群,该集群包含至少一个子网；
97.部署模块403，用于在每个子网中部署至少三个包含虚拟节点状态监控器的容器组的副本；其中至少一个子网中部署至少一个业务容器组；上述至少一个业务容器组被上述至少一个子网中的至少一个虚拟节点状态监控器监控；
98.无头服务模块405，用于使用无头服务暴露上述至少一个虚拟节点状态监控器中的业务容器组。
99.具体地，本公开实施例公开一种虚拟节点状态监控器处理装置与上述对应的方法实施例均基于相同发明构思。详情请参见方法实施例，在此不再赘述。
100.本公开实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述一种虚拟节点状态监控器部署方法。
101.本公开实施例还提供了一种计算机可读存储介质，上述计算机可读存储介质可以存储有多条指令。上述指令可以适于由处理器加载并执行本公开实施例上述的一种虚拟节点状态监控器部署方法。
102.进一步地，图9示出了一种用于实现本公开实施例所提供的方法的设备的硬件结构示意图，上述设备可以参与构成或包含本公开实施例所提供的装置或系统。如图9所示，设备10可以包括一个或多个(图中采用102a、102b，
……
，102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图9所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。
103.应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
104.存储器104可用于存储应用软件的软件程序以及模块，如本公开实施例中上述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种虚拟节点状态监控器部署方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
105.传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
106.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。
107.需要说明的是：上述本公开实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本公开特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
108.本公开中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和服务器实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
109.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
110.以上上述仅为本公开的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。