一种用于Kubernetes控制面测试的集群模拟方法及系统与流程

一种用于kubernetes控制面测试的集群模拟方法及系统
技术领域
1.本技术涉及云原生技术领域，特别涉及一种用于kubernetes控制面测试的集群模拟方法、系统、计算机可读存储介质和电子设备。


背景技术：

2.kubernetes系统是google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，容器组(pod)是kubernetes系统能够管理的最小单元。kubernetes系统能够将多个节点(node)中的容器组纳入同一集群进行管理，安装有kubernetes系统的集群即被称作kubernetes集群。
3.kubernetes集群的控制节点上运行有多个控制面组件(control plane components，也称作容器编排组件)，用于管理节点和运行在节点上的容器组，集群中部署的容器组数量越多，控制面组件的压力也就越大，因此，需要对集群中部署的节点数量和容器组数量进行模拟，以对kubernetes系统进行整体压力测试，从而发现kubernetes系统中的性能短板，针对性地进行性能优化。
4.相关技术中，对kubernetes系统进行整体压力测试通过集群模拟技术来实现，实现集群模拟的方案有2种：一、通过在控制节点上运行virtual-kubelet来模拟管理节点，从而对kubernetes系统中的控制面组件进行性能测试；二、通过在外部kubernetes集群部署虚拟容器组(hollow pod)来对kubemark集群中的控制节点的控制面组件的性能进行测试
5.然而，上述技术方案中，模拟节点与virtual-kubelet的数量或者hollow pod的数量相同，每个virtual-kubelet或者hollow pod由一个独立的系统进程维持，每个系统进程都需要占用一定的硬件资源。当模拟节点的数量超过一定数量时，就会让运行virtual-kubelet或者hollow pod的节点因出现资瓶颈而无法创建出更多的模拟节点，故上述方案无法实现对超大规模集群进行模拟。
6.因此，需要提供一种针对上述现有技术不足的改进技术方案。


技术实现要素：

7.本技术的目的在于提供一种用于kubernetes控制面测试的集群模拟方法及系统，以解决或缓解上述现有技术中存在的问题。
8.为了实现上述目的，本技术提供如下技术方案：
9.本技术提供了一种用于kubernetes控制面测试的集群模拟方法，包括：
10.在kubernetes集群的控制节点上容器化部署虚拟节点控制应用；
11.响应于接收到所述kubernetes集群的控制面组件发出的节点创建指令，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；
12.响应于接收到所述kubernetes集群的控制面组件发出的容器组调度指令，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
13.上述方案中，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送节
点创建的虚拟反馈信息，具体为：
14.所述虚拟节点控制应用向所述kubernetes集群的api-server组件发送虚拟节点注册信息，所述kubernetes集群的api-server组件在接收到所述虚拟节点注册信息之后，将节点创建完成的信息写入所述kubernetes集群的etcd组件。
15.上述方案中，在将节点创建完成的信息写入所述kubernetes集群的etcd组件之后，还包括：
16.所述虚拟节点控制应用向所述kubernetes集群的api-server组件发送虚拟心跳数据包；所述虚拟心跳数据包用于所述kubernetes集群的控制面组件判定节点是否处于正常运行状态。
17.上述方案中，所述虚拟节点控制应用由单个进程维持，所述虚拟节点控制应用发出的所有所述虚拟心跳数据包由单个线程负责发送。
18.上述方案中，所述容器组调度指令具体由scheduler组件发出，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息，具体为：
19.所述虚拟节点控制应用向所述kubernetes集群的api-server组件发送容器组注册信息。
20.上述方案中，所述容器组注册信息中包括容器组状态信息，所述容器组状态信息标识容器组的运行状态，所述方法还包括：
21.响应于所述容器组状态信息被修改为异常，所述scheduler组件通过所述kubernetes集群的api-server组件获取异常的容器组，并对所述容器组进行重新调度。
22.上述方案中，所述kubernetes集群的控制面组件还包括运行在所述kubernetes集群中的服务网格的控制平面组件；所述服务网格用于连接所述kubernetes集群中的容器组，所述服务网格的控制平面组件用于对所述服务网格进行配置和管理。
23.本技术实施例还提供一种用于kubernetes控制面测试的集群模拟系统，包括：
24.部署单元，配置为在kubernetes集群的控制节点上容器化部署虚拟节点控制应用；
25.创建单元，配置为响应于接收到所述kubernetes集群的控制面组件发出的节点创建指令，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；
26.调度单元，配置为响应于接收到所述kubernetes集群的控制面组件发出的容器组调度指令，所述虚拟节点控制应用向所述kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
27.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的用于kubernetes控制面测试的集群模拟方法。
28.本技术实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的用于kubernetes控制面测试的集群模拟方法。
29.有益效果：
30.本技术提供的技术方案中，通过在kubernetes集群的控制节点上容器化部署虚拟节点控制应用，当接收到kubernetes集群的控制面组件发出的节点创建指令时，虚拟节点
控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；当接收到kubernetes集群的控制面组件发出的容器组调度指令时，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。如此，只需在控制节点上容器化部署虚拟节点控制应用，并通过虚拟节点控制应用向控制面组件发送节点创建/容器组调度的虚拟反馈信息以模拟创建节点和容器组，从而能够模拟出控制面组件对任意多个节点和任意多个容器组的集群进行管理的场景，以实现对任意规模集群的模拟。由于虚拟节点控制应用向控制面组件发送虚拟反馈信息仅需要占用少量的硬件资源，因此不会随着模拟节点数量和容器组数量的增大而增加对硬件资源的占用，能够实现对超大规模集群的模拟，进而实现对kubernetes控制面组件的性能测试。
附图说明
31.构成本技术的一部分的说明书附图用来提供对本技术的进一步理解，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。其中：
32.图1为相关技术中通过virtual-kubelet实现集群模拟的逻辑示意图；
33.图2为相关技术中通过kubemark实现集群模拟的逻辑示意图；
34.图3为根据本技术的一些实施例提供的用于kubernetes控制面测试的集群模拟方法的流程示意图；
35.图4为根据本技术的一些实施例提供的用于kubernetes控制面测试的集群模拟方法的逻辑示意图；
36.图5为根据本技术的一些实施例提供的结合组件性能监测系统对控制面组件进行性能测试的逻辑示意图；
37.图6为根据本技术的一些实施例提供的用于kubernetes控制面测试的集群模拟系统的结构示意图；
38.图7为根据本技术的一些实施例提供的电子设备的结构示意图；
39.图8为根据本技术的一些实施例提供的电子设备的硬件结构图。
具体实施方式
40.下面将参考附图并结合实施例来详细说明本技术。各个示例通过本技术的解释的方式提供而非限制本技术。实际上，本领域的技术人员将清楚，在不脱离本技术的范围或精神的情况下，可在本技术中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本技术包含归入所附权利要求及其等同物的范围内的此类修改和变型。
41.在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
42.除另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。
43.基于背景技术的说明可知，集群中部署的容器组数量越多，控制面组件的压力也就越大，因此，为了提升kubernetes系统中部署容器组的数量，必须提升控制面组件的抗压能力，在提升抗压能力的过程中，必然需要对kubernetes系统进行整体压力测试，以发现kubernetes系统中的性能短板，针对性地进行性能优化。
44.在对kubernetes系统进行整体压力测试时，如果采用在kubernetes集群中部署大量节点和容器组的方案来进行压力测试，一方面研发人员和测试人员需要占用大量的资源来完成这项工作，成本过高，另一方面无法根据压力测试的需求实时增减节点的数量，不易操作。因此，在对kubernetes系统进行整体压力测试时通过集群模拟技术模拟集群的状态相对来说是一种易操作且成本较低的方法。
45.可以理解，采用集群模拟技术对部署在kubernetes集群中的云原生应用进行测试还能够大大提高测试的效率。
46.具体来说，在云原生应用开发过程中，需要创建一个用于测试的kubernetes集群，并将云原生应用部署至kubernetes集群中，使该应用与kubernetes系统中的其他组件进行交互，调用kubernetes系统中的资源。
47.kubernetes系统本身作为一个不断迭代更新的系统，存在多个系统版本，不同企业使用的kubernetes系统的版本各不相同，为了让云原生应用能够适配不同版本的kubernetes系统，就需要将云原生应用在不同版本的kubernetes集群中进行部署和测试，最小规模的kubernetes集群也需要包括一个控制节点和两个工作节点，而要分别创建不同版本的kubernetes集群，就需要占用大量的硬件资源。若通过集群模拟对云原生应用进行测试，不仅可以节约大量的硬件资源，而且大大减少部署集群所需的时间，提高了云原生应用的测试效率。
48.相关技术中，实现集群模拟有如下2种技术方案：
49.第一种集群模拟相关技术是virtual-kubelet。参见图1，kubernetes集群中包括多个工作节点以及由virtual-kubelet实现的模拟节点。virtual-kubelet通过伪装成kubelet组件与kubernetes控制面组件提供的api进行交互，使得kubernetes集群将其作为一个节点来管理，从而模拟节点能够对接kubernetes系统的原生资源对象。
50.需要说明的是，kubelet组件作为最重要的节点组件之一，是kubernetes集群为了维护运行的容器组并为容器组提供kubernetes运行环境而在每个节点(包括控制节点和工作节点)上部署的组件。kubelet组件负责维护容器的生命周期，同时也负责volume(cvi)和网络(cni)的管理。此外，节点组件还包括：kube-proxy组件和container runtime组件，其中，container runtime组件负责镜像管理以及为容器组和容器提供真正运行的环境，即容器运行时接口(container runtime interface，简称cri)；kube-proxy组件负责为service提供cluster内部的服务发现和负载均衡。
51.具体地，在kubernetes集群中的每个节点上均启动一个kubelet组件，用于处理控制节点下发到本节点的任务，管理本节点上容器组和容器组中的容器。每个kubelet组件都会在api-server组件上注册节点自身的信息，定期向控制节点汇报本节点资源的使用情况，并通过cadvisor组件监控容器和节点资源。也就是说，部署在每个节点上的kubelet组件负责处理与所在节点上容器组相关的各项工作，包括但不限于在容器的创建和销毁，节点和容器的资源使用情况上报。
52.virtual-kubelet在伪装kubelet组件过程中，并不会调度kubernetes集群中硬件资源，而是通过virtual-kubelet提供的api实现与其他云平台的对接，从而允许kubernetes管理来自其他平台(例如无服务器容器平台)提供支持的模拟节点。其中，virtual-kubelet提供的api包括：
53.getpod——获取容器组；
54.getpods——获取所有容器组；
55.getpodstatus——获取容器组的状态；
56.capacity——获取模拟节点的容量；
57.operationsystem——获取模拟节点的操作系统；
58.createpod——创建容器组；
59.updatepod——更新容器组；
60.nodeconditions——获取模拟节点的状态。
61.可以理解，基于virtual-kubelet的功能特性，kubernetes系统会将virtual-kubelet视作一个节点进行管理。也就是说，在kubernetes系统中运行多个virtual-kubelet时，就相当于kubernetes系统在对相同数量的节点进行管理。基于此，在对kubernetes系统中控制面组件的性能进行测试时，只需运行大量的virtual-kubelet，即可模拟kubernetes系统中控制面组件同时对大量节点进行管理的场景，而无需在物理上部署和管理大量节点。
62.第二种集群模拟相关技术是kubemark。kubemark是kubernetes官方给出的性能测试工具，能够不受资源限制，模拟出一个大规模kubernetes集群。
63.图2是kubemark实现集群模拟的逻辑示意图，参见图2，在采用kubemark进行集群模拟时，需要由控制节点和工作节点组成的外部kubernetes集群(external cluster)，以及一个kubemark集群(仅包括控制节点)来实现。
64.其中，外部kubernetes集群的控制节点中部署有控制面组件，以管理集群中的各个节点。在外部kubernetes集群的至少一个工作节点中部署虚拟容器组(hollow pod)，hollow pod主动向kubemark集群中的控制节点进行注册，成为kubemark集群中的模拟节点(hollow node)。hollow node能够模拟真实节点，对kubemark集群的控制节点中的控制面组件做出正确响应，但是不会实际创建对应的pod等资源。因此，可以在外部kubernetes集群中部署大量的hollow pod来模拟大量的hollow node，对kubemark集群中的控制节点的控制面组件的性能进行测试。
65.具体地，在hollow node中，分别使用hollowkubelet和hollowproxy代替真实节点中的kubelet组件和kubeproxy组件与kubemark集群中的控制节点进行通信，通过模拟kubelet组件和kubeproxy组件的相关功能，使得kubemark集群中的控制节点误以为hollow node为真实的节点。
66.以上相关技术提供的技术方案虽然能够对控制面组件的性能进行测试，然而，在使用现有技术方案对kubernetes集群中控制面组件的性能进行测试时，所运行的virtual-kubelet或者hollow pod的数量与模拟节点的数量相同。当需要增加模拟节点的数量时，就需要创建新的virtual-kubelet或者hollow pod，每个virtual-kubelet和hollow pod由一个独立的系统进程维持，因此每个virtual-kubelet和hollow pod都需要占用一定的硬件
资源。
67.当模拟节点的数量超过一定数量上限(比如100个)时，就会让运行virtual-kubelet或者hollow pod的节点不堪重负，无法创建出更多的模拟节点，而随着kubernetes集群规模的不断扩大，在生产实际中需要kubernetes系统能够同时纳管成千上万个节点，采用现有技术对控制面组件的性能进行测试无法实现对超大规模集群进行模拟。
68.此外，在对多个kubernetes系统版本的测试场景中，使用kubemark进行性能测试时，需要为测试每个版本的kubernetes系统至少创建两个kubernetes集群，即便每个集群中包含的节点较少，仍需要占用大量的硬件资源。
69.经过对kubernetes系统相关的技术原理进行深入分析后，申请人发现，容器编排所包括的具体事项有资源调配和部署、配置和调度、资源分配、容器可用性、跨基础架构根据负载压力扩展或移除容器、负载平衡和流量路由、监控容器运行状况、根据将要运行的容器配置应用、保障容器之间交互的安全，而这一切都需要与对容器进行直接管理的kubelet组件进行交互，来间接对容器进行编排操作。因此容器编排组件管理和操作节点和容器组所依赖的工具就是kubelet组件，kubelet组件负责处理控制节点下发到本节点的任务，并向控制节点上报本节点上容器组的运行状态和资源使用情况。
70.为此，本技术提供一种用于kubernetes控制面测试的集群模拟方法、系统、计算机可读存储介质和电子设备，通过在kubernetes集群的控制节点上容器化部署虚拟节点控制应用，用于对任意多个kubelet组件的行为进行模拟，能够在kubernetes集群中模拟出任意多个节点和任意多个容器组，从而实现对任意规模集群进行模拟。
71.示例性方法
72.本技术实施例提供一种用于kubernetes控制面测试的集群模拟方法，如图3-5所示，该方法包括：
73.步骤s101、在kubernetes集群的控制节点上容器化部署虚拟节点控制应用。
74.本技术实施例中，为了实现对kubernetes集群的控制面组件进行压力测试，在kubernetes集群的控制节点上容器化部署了虚拟节点控制应用。虚拟节点控制应用能够对任意多个kubelet组件的行为进行模拟，以模拟出任意多个节点和任意多个容器组在kubernetes集群运行的假象。
75.本技术实施例中，kubernetes集群中的控制节点上除了部署容器化部署之外，还至少部署一个控制面组件，用于承担相应的具体容器编排工作，并通过暴露api和接口来定义、部署容器和管理容器的生命周期。
76.其中，控制面组件包括但不限于：etcd组件、api-server组件、controller-manager组件、scheduler组件等。
77.etcd组件用于保存整个集群的状态；api-server组件用于提供资源操作的唯一入口，并提供认证、授权、访问控制、api注册和发现等机制；controller-manager组件用于负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；scheduler组件负责资源的调度，按照预定的调度策略将容器组调度到相应的节点上。
78.本技术实施例中，kubernetes集群可以是由一个控制节点组成的集群，也可以是由控制节点和工作节点组成的集群。
79.优选地，当kubernetes集群由单个控制节点组成，并在该单个控制节点上部署虚
拟节点控制应用时，只需要单个节点就可以模拟出一个包括任意多个节点的kubernetes集群，并且在kubernetes集群中可以部署任意多个容器组，能够在实现集群模拟的同时最大限度节约硬件资源。
80.步骤s102、响应于接收到kubernetes集群的控制面组件发出的节点创建指令，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息。
81.本技术实施例中，当接收到kubernetes集群的控制面组件发出的节点创建指令时，虚拟节点控制应用根据节点创建指令生成节点创建的虚拟反馈信息，并向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息，使控制面组件误以为节点确实已被创建，并将其作为真实节点进行管理。
82.这里，控制面组件发出的节点创建指令可以包含模拟节点的配置信息，例如，至少包括模拟节点的标识信息以及模拟节点的数量，虚拟节点控制应用根据模拟节点的数量，在模拟节点的标识信息后添加随机标识码，生成模拟节点的唯一标识码，以区分每一个模拟节点，并基于唯一标识码向控制面组件注册对应数量的模拟节点。
83.通常情况下，kubernetes集群中的真实节点可以是一个虚拟机或者物理机器，每个虚拟机或者物理机器上的资源可由kubernetes集群进行管理和分配。
84.本技术实施例中，在对kubernetes集群的控制面组件进行性能测试时，为了节约硬件资源，仅在控制节点上注册模拟节点的信息，使得控制面组件误以为该模拟节点确实存在，但模拟节点并不与任何虚拟机或者物理机器相关联。
85.具体实施时，对kubernetes集群的控制面组件通过对象资源文件或者命令行生成节点创建指令，根据性能测试的需求，控制面组件可以在对象资源文件或命令行中指定所需要创建的模拟节点数量。
86.在接收到kubernetes集群的控制面组件发出的节点创建指令后，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息，使得控制面组件误以为模拟节点确实创建完成，并像管理真实节点一样对所创建的模拟节点进行管理。
87.为了对模拟节点进行管理，在一些实施例中，虚拟节点控制应用向kubernetes集群的控制面组件送节点创建的虚拟反馈信息，具体为：虚拟节点控制应用向kubernetes集群的api-server组件发送虚拟节点注册信息，kubernetes集群的api-server组件在接收到虚拟节点注册信息之后，将节点创建完成的信息写入kubernetes集群的etcd组件。
88.本技术实施例中，通过虚拟节点控制应用与kubernetes集群的api-server组件进行交互，实现像管理真实节点一样对模拟节点进行管理。
89.需要说明的是，在kubernetes集群中，api-server组件是kubernetes控制面的前端，其公开了kubernetes api，并负责处理对kubernetes集群的管理请求。
90.本技术实施例中，接收到kubernetes集群的控制面组件发出的节点创建指令后，虚拟节点控制应用对真实的kubelet组件的行为进行模拟，根据节点创建指令所指示的模拟节点数量模拟生成相应的虚拟节点注册信息，并将这些虚拟节点注册信息作为虚拟反馈信息，向kubernetes集群的api-server组件发送节点注册的虚拟反馈信息，但并不会将这些模拟节点与任何硬件资源相关联。
91.基于前述说明可知，在kubernetes集群中，每个节点上只会启动一个kubelet组件，也就是说，一旦虚拟节点控制应用模拟真实的kubelet组件向api-server组件发送节点
注册的虚拟反馈信息，控制面组件就会以为kubernetes集群真实存在新的节点，并像管理真实节点一样对其进行管理。
92.实际应用中，在kubernetes集群的api-server组件在接收到虚拟节点注册信息之后，api-server组件会检查节点对象是否合法，然后将通过合法检查的模拟节点创建完成的信息写入到kubernetes集群的etcd组件。
93.应当理解，etcd组件用于保存整个集群各个对象的期望状态(desired state)，通过将节点创建完成的信息写入kubernetes集群的etcd组件，其他控制面组件就会通过api-server组件不断监测kubernetes集群各个对象当前的真实状态，并致力于使kubernetes集群的真实状态与期望状态保持一致，而真实状态与期望状态保持一致的过程，即为控制面组件对节点进行管理的过程。
94.这里，集群的期望状态定义了一个集群的工作负载状态看起来应是什么样子，api-server组件通过暴露接口管理和更新集群的期望状态，并将集群的期望状态记录在etcd组件中。
95.需要说明的是，在集群初始化时，集群的期望状态通常由运维人员预先定义，并存储在etcd组件中，控制面组件根据etcd组件的记录，致力于使kubernetes集群的真实状态与期望状态保持一致。例如，运维人员期望的编排结果是实现无状态实例的动态扩缩容，则只需要用deployment部署无状态实例，部署hpa(horizontal pod autoscaling，容器水平伸缩)组件并设置hpa的扩缩容策略。当hpa的metric-server检测到每个容器组负载超过扩容阈值时，由hpa的控制器增大deployment的副本数量，controller-manager组件负责新增容器组的创建控制，scheduler组件负责将新增容器组的调度至最佳节点上，该节点上的kubelet组件负责将新增容器组启动，从而实现动态扩容。当hpa的metric-server检测到每个容器组负载低于缩容阈值时，由hpa控制器减小deployment的副本数量，controller-manager组件负责多余容器组的删除控制，kubelet组件具体负责将多余容器组停止并删除，从而实现动态缩容。
96.由此可见，在运维人员预先定义一个最终期望的编排结果后，控制面组件便会各自发挥自身的功能，相互配合，使kubernetes集群最终演变为与期望状态相一致。
97.具体到本技术实施例，kubernetes集群的api-server组件在接收到虚拟节点注册信息之后，只需将节点创建完成的信息写入kubernetes集群的etcd组件，控制面组件便会根据模拟节点的配置信息，自动对其进行管理，使其保持与配置信息的定义一致。
98.可以理解，所创建的模拟节点越多，控制面组件对其管理的压力越大，通过创建不同数量的模拟节点，实现对控制面组件的性能测试。
99.为了获取模拟节点的真实状态，使控制面组件按真实节点对其进行管理，在将节点创建完成的信息写入kubernetes集群的etcd组件之后，还包括：虚拟节点控制应用向kubernetes集群的api-server组件发送虚拟心跳数据包；虚拟心跳数据包用于kubernetes集群的控制面组件判定节点是否处于正常运行状态。
100.本技术实施例中，通过虚拟节点控制应用向kubernetes集群的api-server组件发送虚拟心跳数据包，从而模拟kubelet组件向api-server组件上报节点状态信息的心跳机制，不断向api-server组件发送虚拟心跳数据包，以维持该模拟节点在控制面组件管理下的健康状态。
101.应当理解，虚拟心跳数据包中包含模拟节点当前的运行状态，能够帮助kubernetes集群的控制面组件判定每个模拟节点的可用性。如果虚拟心跳数据包反馈该模拟节点所有必要的服务都在运行，则api-server组件将被判定该模拟节点为处于正常运行状态的节点，即该模拟节点可以用于运行容器组，否则，控制面组件在执行调度时，将忽略该模拟节点。
102.应当理解，除了能够判定节点是否处于正常运行状态，虚拟心跳数据包还可以包括模拟节点的虚拟资源情况，例如模拟节点是否存在磁盘空间压力、是否存在内存压力、所运行的进程是否过多等。通过上报模拟节点的虚拟资源情况，使控制面组件能够根据虚拟资源情况对集群进行相应的调度与管理，从而模拟出控制面组件更真实的管理场景，使控制面组件的性能测试更全面。
103.实际应用中，虚拟节点控制应用可以按照预设的时间间隔(例如40秒)向kubernetes集群的api-server组件发送虚拟心跳数据包，以使kubernetes集群的控制面组件能够判定节点处于正常运行状态。
104.为了进一步减少kubernetes集群控制面组件测试场景下对硬件资源、特别是对内存资源的占用，在一些实施例中，虚拟节点控制应用由单个进程维持，虚拟节点控制应用发出的所有虚拟心跳数据包由单个线程负责发送。
105.本技术实施例中，虚拟节点控制应用容器化部署在kubernetes集群中，并由单个进程维持，并且模拟任意多个节点发出虚拟心跳数据包的行为均由该进程中的单个线程负责，仅需占用极少的内存。由于虚拟节点控制应用采用发送虚拟节点注册信息和虚拟心跳数据包的方式实现节点和容器组的模拟，生成虚拟节点注册信息和虚拟心跳数据包所占用的资源对整个节点来说几乎可以忽略不计，因此不会随着模拟节点和容器组数量的增大而增加对硬件资源的占用，从而在进行压力测试时可以不断增加模拟节点和容器组的数量，而无需担心出现硬件资源瓶颈。
106.需要特别说明的是，虽然virtual-kubelet与kubemark均为通过模拟kubelet组件实现集群模拟，但virtual-kubelet、kubemark的构思与本技术的构思均不同。
107.具体来说，在virtual-kubelet实现集群模拟的方案中，通过在kubernetes集群中运行virtual-kubelet，virtual-kubelet在与kubernetes系统的控制面组件进行交互时，将自身伪装成真实的kubelet组件，让kubernetes系统将virtual-kubelet作为一个节点进行管理。可见，在该技术方案中，每增加一个模拟节点，就需要运行一个对应的virtual-kubelet系统进程，模拟节点的数量与virtual-kubelet进程的数量相同，当模拟大规模集群时，由于virtual-kubelet进程的数量过多，就会让部署virtual-kubelet的节点出现资源瓶颈。
108.类似地，在kubemark实现集群模拟的方案中，hollow node使用hollowkubelet代替kubelet组件与kubemark集群中的控制节点的相关组件进行通信，使得kubemark集群中的控制节点误以为hollow node为真实的节点。具体来说，kubelet组件在管理和操作容器组时，直接与containerd组件进行对接，再由containerd组件管理和操作底层低级容器运行时，从而实现对容器组的编排操作。hollowkubelet将kubelet组件中用于调用containerd的部分进行替换，使其不再调用真实的containerd，而是调用一个虚拟的containerd，而虚拟的containerd并不会实际创建容器组，只是接收hollowkubelet的指
令，以及向hollowkubelet和其他组件反馈虚假信息。由于hollowkubelet仅是对kubelet组件中调用containerd的部分进行替换，因此每部署一个hollow pod都需要运行对应的hollowkubelet，从而占用部署hollow pod的节点的硬件资源，而当部署的hollow pod的数量过多时，就会让部署hollow pod的节点不堪重负。
109.可见，相关技术中，每个模拟节点都需要一个独立的系统进程维持，大量的模拟节点需要占用大量硬件资源。
110.而本技术实施例所提供的虚拟节点控制应用在模拟节点和容器组时，整个程序由一个系统进程维持，当需要增大模拟集群的规模时，只需向kubernetes集群的api-server组件发送更多的虚拟节点注册信息和虚拟心跳数据包即可，对硬件资源的占用几乎不会增加。
111.此外，与kubemark实现集群模拟的方案相比，本技术实施提供的方案可以使用单个节点模拟出一个kubernetes集群来对应用进行测试，在对不同版本的kubernetes系统进行适配时，可以节省下大量的硬件资源。
112.步骤s103、响应于接收到kubernetes集群的控制面组件发出的容器组调度指令，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
113.本技术实施例中，当接收到kubernetes集群的控制面组件发出的容器组调度指令，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息，从而能够模拟出容器组调度过程中各控制面组件的性能。
114.需要说明的是，在kubernetes集群中，容器组是资源调度的最小单元，容器组可以被创建、赋予一个唯一的标识(uid)，然后被调度到节点，并在容器组终止或删除之前一直运行在该节点。
115.在对kubernetes集群中的控制面组件进行性能测试的场景下，当模拟容器组调度时，由kubernetes集群的控制面组件发出容器组调度指令，虚拟节点控制应用接收容器组调度指令，并确定该容器组调度指令指示将容器组调度到模拟出的虚拟节点后，虚拟节点控制应用模拟该容器组已在该虚拟节点上部署完毕的状态。
116.本技术实施例中，虚拟节点控制应用通过发送虚拟反馈信息，模拟出该容器组已在虚拟节点上部署完毕的假象，使控制面组件误以为容器组已调度到模拟节点上。
117.在一些实施例中，容器组调度指令具体由scheduler组件发出，对应地，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息，具体为：虚拟节点控制应用向kubernetes集群的api-server组件发送容器组注册信息。
118.基于前述说明可知，scheduler组件负责资源的调度，按照预定的调度策略将容器组调度到相应的节点上。当需要测试在大规模资源调试场景下控制面组件的性能时，scheduler组件发出容器组调度指令，指示将容器组调度到模拟节点。
119.由于虚拟节点控制应用能够模拟出任意多个的模拟节点，因此，通过scheduler组件发出容器组调度指令，能够实现对超大规模集群的资源调度的模拟，从而能够得到各控制面组件在超大规模集群中进行资源调度的性能，进而确定控制面组件的性能瓶颈。
120.具体实施时，在接收到由scheduler组件发出的容器组调度指令之后，虚拟节点控制应用向kubernetes集群的api-server组件发送容器组注册信息，并在容器组注册信息将容器组的注册设置为ready状态，从而模拟出该容器组已在虚拟节点上部署完毕的假象。
121.由于虚拟节点控制应用模拟容器组调度时，无需大量占用硬件资源，只需不断向api-server组件发送容器组注册信息，从而可以模拟出任意多个容器组在kubernetes集群调度和运行的状态，来对kubernetes集群中的控制面组件的性能进行测试。
122.在一些实施例中，容器组注册信息中包括容器组状态信息，容器组状态信息标识容器组的运行状态，方法还包括：响应于容器组状态信息被修改为异常，scheduler组件通过kubernetes集群的api-server组件获取异常的容器组，并对容器组进行重新调度。
123.本技术实施例中，为了模拟出容器组在虚拟节点上的运行状态，容器组注册信息中包括容器组状态信息。容器组在虚拟节点上部署完毕后，虚拟节点控制应用将容器组状态信息设置为正常运行状态，并向kubernetes集群的api-server组件发送包含该正常状态的容器组注册信息，以模拟出容器组在虚拟节点上正常运行的假象。
124.需要说明的是，在容器组的生命周期中包括多种状态标识，例如：悬决(pending)、失败(failed)、未知(unknown)、运行中(running)、成功(succeeded)。其中，pending指的是容器组已被kubernetes系统接受，但有一个或者多个容器尚未创建亦未运行的状态；running指的是容器已经绑定到了某个节点，容器组中所有的容器都已被创建，且至少有一个容器仍在运行，或者正处于启动或重启状态；succeeded指的是容器组中的所有容器都已成功终止，并且不会再重启的状态；failed指的是容器组中的所有容器都已终止，并且至少有一个容器是因为失败终止的状态；unknown指的是因为某些原因(如与容器组所在的节点通信失败)无法取得容器组的状态。
125.本技术实施例中，当容器组的状态标识被修改为running或者succeeded时，判定容器组正常运行，虚拟节点控制应用将容器组状态信息设置为正常运行状态，并向kubernetes集群的api-server组件发送该容器组状态信息；当容器组的状态标识被修改为failed或者unknown时，判定容器组运行异常，虚拟节点控制应用将容器组状态信息设置为异常，并向kubernetes集群的api-server组件发送该容器组状态信息。
126.应当理解，在容器组调度完毕后，容器组状态信息可以根据容器组的实际运行状态而被测试人员或者外部程序修改。
127.本技术实施例中，当容器组状态信息被修改为异常时，说明对应的容器组的运行状态出现了异常，scheduler组件能够像管理真实的容器组一样做出响应，通过kubernetes集群的api-server组件获取异常的容器组，并发出新的容器组调度指令，对处于异常状态的容器组进行重新调度。
128.本技术实施例中，通过容器组状态信息反映容器组在虚拟节点上的运行状态，测试人员能够通过修改容器组状态信息模拟出任意多个容器组出现异常的假象，以测试scheduler组件对超大规模集群的调度性能。
129.在一些实施例中，kubernetes集群的控制面组件还包括运行在kubernetes集群中的服务网格的控制平面组件；服务网格用于连接kubernetes集群中的容器组，服务网格的控制平面组件用于对服务网格进行配置和管理。
130.本技术实施例中，服务网格(service mesh)用于连接kubernetes集群中的容器组，并处理容器组间网络通信，实现在云原生应用复杂的拓扑中实现可靠的请求传递。
131.实际应用中，服务网格以边车代理的形式实现，用于加强容器组中的业务容器的网络功能。
132.为了对服务网格进行配置和管理，需要在kubernetes集群中部署服务网格的控制平面组件。
133.在kubernetes集群中部署服务网格的控制平面组件之后，可以通过虚拟节点控制应用模拟出的超大规模的容器组，对服务网格的控制平面组件的性能进行测试。
134.以kubernetes集群中的服务网格istio为例，istio以envoy组件作为边车代理，envoy组件和业务容器一同部署在容器组中，istio的控制面组件包括mixer组件、galley组件、citadel组件、pilot组件。上述控制面组件通过配置和管理边车代理来进行流量控制，并通过mixer组件执行策略和收集遥测数据(telemetry)。
135.其中，mixer组件用于提供策略控制，并从envoy组件处收集遥测数据；galley组件用于配置的获取、处理和分发；citadel组件用于负责密钥和证书的管理，提供服务间和终端用户的身份认证，还可以加密服务网格中的流量；pilot组件用于配置和管理envoy组件，例如为envoy组件之间设置特定的流量规则，或者配置超时、重试、熔断的弹性能力。
136.基于以上描述可知，当容器组的规模增大时，服务网格的控制面组件的管理压力也随之增大。在kubernetes集群中部署服务网格的控制平面组件，通过虚拟节点控制应用在kubernetes集群中模拟出任意多个的容器组，从而实现对服务网格的控制面组件进行性能测试，以根据服务网格的控制平面组件的性能信息进行调整和优化。
137.进一步地，为了实现对控制面组件的性能监测，本技术引入prometheus系统作为组件性能监测系统。
138.参见图5，通过在kubernetes集群的控制节点上部署prometheus server组件，用于收集控制节点上的控制面组件的性能信息，并在客户端上的prometheus web ui中进行展示。由此，用户可以从客户端设置要模拟的节点和容器组的数量，并在prometheus web ui中查看此种情况下控制面组件的性能信息，进而调整模拟的节点和容器组的数量，直至确定kubernetes系统能够承受的节点和容器组的最大数量，以及与该性能上限直接相关的控制面组件。
139.本实施例中，对kubernetes集群的控制面组件进行压力测试可以按照如下步骤进行：
140.步骤1、在kubernetes集群中的控制节点上容器化部署虚拟节点控制应用。
141.步骤2、在客户端中设置需要模拟节点和容器组的初始数量。
142.步骤3、启动虚拟节点控制应用，在客户端中查看相关控制面组件的性能信息。
143.步骤4、如果没有达到任意一个控制面组件的最大性能，则在客户端中增大所模拟节点和容器组的数量，如果超过了某个控制面组件的最大性能，则在客户端中减小所模拟节点和容器组的数量。
144.步骤5、重复步骤4，直至确定kubernetes系统能够承受的节点和容器组的数量的临界数值，以及与该性能上限直接相关的控制面组件。
145.步骤6、对该控制面组件进行性能优化，以实现对kubernetes系统的整体性能提升。
146.综上所述，本技术提供的技术方案中，通过在kubernetes集群的控制节点上容器化部署虚拟节点控制应用，当接收到kubernetes集群的控制面组件发出的节点创建指令时，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；当
接收到kubernetes集群的控制面组件发出的容器组调度指令时，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。由于虚拟节点控制应用向控制面组件发送虚拟反馈信息仅需要占用少量的硬件资源，因此不会随着模拟节点数量和容器组数量的增大而增加对硬件资源的占用，只需在控制节点上容器化部署虚拟节点控制应用，就能够实现对超大规模集群的模拟，进而实现对kubernetes控制面组件的性能测试。
147.本技术中，虚拟节点控制应用容器化部署在kubernetes集群的控制节点上，借助kubernetes系统自动化部署、大规模可伸缩、应用容器化管理等优势，使得虚拟节点控制应用具有高可用、易扩缩、鲁棒性强等优势。
148.本技术中，在对云原生应用进行测试时，只需单个节点即可模拟出任意规模的kubernetes集群，极大地降低了对硬件资源的占用。
149.本技术中，虚拟节点控制应用向api-server组件发送节点创建/容器组调度的虚拟反馈信息和虚拟心跳数据包，以实现对任意多个节点和任意多个容器组的模拟，无需真实大量部署节点和容器组，大大降低了研发和测试成本。
150.本技术中，虚拟节点控制应用的整个程序由一个系统进程维持即可，极大地节约超大规模集群模拟所需的硬件资源，在增大模拟集群的规模时，对硬件资源的占用几乎不会增加。
151.在对kubernetes集群中的控制面组件进行压力测试时，利用prometheus系统作为组件性能监测系统，并将组件性能信息可视化展示给用户，操作简便，易上手。
152.示例性系统
153.本技术实施例还提供一种用于kubernetes控制面测试的集群模拟系统，图6为根据本技术的一些实施例提供的用于kubernetes控制面测试的集群模拟系统的结构示意图，如图6所示，该系统包括：部署单元601、创建单元602和调度单元603。其中：
154.部署单元601，配置为在kubernetes集群的控制节点上容器化部署虚拟节点控制应用。
155.创建单元602，配置为响应于接收到kubernetes集群的控制面组件发出的节点创建指令，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息。
156.调度单元603，配置为响应于接收到kubernetes集群的控制面组件发出的容器组调度指令，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
157.本技术实施例提供的用于kubernetes控制面测试的集群模拟系统能够实现上述任一用于kubernetes控制面测试的集群模拟方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。
158.示例性设备
159.图7为根据本技术的一些实施例提供的电子设备的结构示意图；如图7所示，该电子设备包括：
160.一个或多个处理器701；
161.计算机可读介质，可以配置为存储一个或多个程序702，一个或多个处理器701执行一个或多个程序702时，实现如下步骤：在kubernetes集群的控制节点上容器化部署虚拟
节点控制应用；响应于接收到kubernetes集群的控制面组件发出的节点创建指令，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；响应于接收到kubernetes集群的控制面组件发出的容器组调度指令，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
162.图8为根据本技术的一些实施例提供的电子设备的硬件结构；如图8所示，该电子设备的硬件结构可以包括：处理器801、通信接口802、计算机可读介质803和通信总线804。
163.其中，处理器801、通信接口802、计算机可读存储介质803通过通信总线804完成相互间的通信。
164.可选地，通信接口802可以为通信模块的接口，如gsm模块的接口。
165.其中，处理器801具体可以配置为：在kubernetes集群的控制节点上容器化部署虚拟节点控制应用；响应于接收到kubernetes集群的控制面组件发出的节点创建指令，虚拟节点控制应用向kubernetes集群的控制面组件发送节点创建的虚拟反馈信息；响应于接收到kubernetes集群的控制面组件发出的容器组调度指令，虚拟节点控制应用向kubernetes集群的控制面组件发送容器组调度的虚拟反馈信息。
166.处理器801可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等，还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
167.本技术实施例的电子设备以多种形式存在，包括但不限于：
168.(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iphone)、多媒体手机、功能性手机，以及低端手机等。
169.(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：pda、mid和umpc设备等，例如ipad。
170.(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：ipod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。
171.(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
172.(5)其他具有数据交互功能的电子装置。
173.需要指出，根据实施的需要，可将本技术实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本技术实施例的目的。
174.上述根据本技术实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如cd rom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。可以理解，计算机、处理
器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，ram、rom、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的用于kubernetes控制面测试的集群模拟方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。
175.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术实施例的范围。
176.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。
177.以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
178.以上所述仅为本技术的优选实施例，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。