CN115408110B

CN115408110B - Performance evaluation method and system for Kubernetes control plane component

Info

Publication number: CN115408110B
Application number: CN202211128576.7A
Authority: CN
Inventors: 张世明; 蔡威; 徐俊杰; 吴慧锋; 涂强; 郑松; 封宁
Original assignee: Chengdu Daoke Digital Technology Co ltd
Current assignee: Chengdu Daoke Digital Technology Co ltd
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2023-06-02
Anticipated expiration: 2042-09-16
Also published as: CN115408110A

Abstract

The application relates to the technical field of cloud protogenesis, and provides a performance evaluation method and system of a Kubernetes control surface component. The method comprises the following steps: creating a first sandbox in the target Kubernetes cluster, and running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox; monitoring a resource change event of a target Kubernetes cluster; when the event of the newly added first control surface component occurs to the target Kubernetes cluster is monitored, a connection request of the first control surface component to the target Kubernetes cluster is directed to a virtual Kubernetes cluster in a first sandbox, so that the performance of the first control surface component is evaluated. Therefore, by creating the first sandbox in the target Kubernetes cluster and running the virtual Kubernetes cluster in the first sandbox, the newly added control plane component operates the virtual Kubernetes cluster, and performance evaluation of the newly added first control plane component can be realized by only occupying little hardware resources in the target Kubernetes cluster, so that development cost is reduced, and development efficiency is improved.

Description

Performance evaluation method and system for Kubernetes control plane component

Technical Field

The application relates to the technical field of cloud protogenesis, in particular to a performance evaluation method and system of a Kubernetes control surface component, a computer-readable storage medium and electronic equipment.

Background

The Kubernetes system is a container orchestration engine of Google open source, supporting container automation deployment, large scale scalability, and application containerization management. The system architecture of Kubernetes includes a plurality of control plane components, such as API-Server components, controller-Manager components, scheduler components, ETCD components, and the like. In general, the control plane component built in the Kubernetes system can meet most of service requirements, and when special service requirements which cannot be met by the control plane component built in the Kubernetes system exist, the Kubernetes system can be expanded by introducing new custom resources and new control plane components (such as custom controllers) so as to meet the special service requirements.

However, introducing a new control plane component may have an impact on the overall operational state of the target Kubernetes cluster, and therefore, the new control plane component may need to be evaluated for its impact on the target Kubernetes cluster before introducing the new control plane component.

In the related art, the impact of a new control plane component on a target Kubernetes cluster is evaluated by deploying the new control plane component in a test environment, where the test environment is another Kubernetes cluster independent of the target Kubernetes cluster. By performing various operations related to the new control plane component in the test environment and monitoring the operating state of the test environment, it is determined whether the new control plane component has an impact on the normal operation of the target Kubernetes cluster.

However, with the continuous development of cloud computing technology, the scale of Kubernetes clusters used by enterprises is also continuously expanding, and the cost of building a test environment of the same scale as that of a target Kubernetes cluster to evaluate the performance of a new control plane component is too high.

Accordingly, there is a need to provide an improved solution to the above-mentioned deficiencies of the prior art.

Disclosure of Invention

It is an object of the present application to provide a method, system, computer-readable storage medium and electronic device for evaluating the performance of Kubernetes control plane components, which solve or alleviate the above-mentioned problems in the prior art.

In order to achieve the above object, the present application provides the following technical solutions:

The application provides a performance evaluation method of a Kubernetes control plane component, which comprises the following steps:

creating a first sandbox in a target Kubernetes cluster, and running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox;

monitoring a resource change event of the target Kubernetes cluster;

and responding to the event that the target Kubernetes cluster generates a new first control plane component, and directing a connection request of the first control plane component to the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox to evaluate the performance of the first control plane component.

In the above technical solution, the target Kubernetes cluster includes an injection resource definition file;

the injection resource definition file is used for defining the injection resource object, and the injection resource object is used for defining the first sandbox and specifying a target control surface component for injecting the first sandbox; the target control plane component is at least one control plane component in the target Kubernetes cluster;

correspondingly, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox, specifically:

Creating a container group according to the injected resource object, and taking the container group as a first sandbox;

and injecting a copy of the target control surface component in the first sandbox, and synchronizing all data stored in the ETCD in the target Kubernetes cluster to the first sandbox so as to synchronously run the target control surface component in the first sandbox.

In the above technical solution, a virtual node control application is further deployed in the first sandbox;

the virtual node control application is configured to simulate a working node of the target Kubernetes cluster in the first sandbox.

In the above technical solution, the target Kubernetes cluster includes a sandbox resource definition file, where the sandbox resource definition file is used to define a sandbox resource object, and the sandbox resource object is used to define a data synchronization mode of the first sandbox;

correspondingly, the method further comprises:

and periodically synchronizing all data stored in ETCD in the target Kubernetes cluster to the first sandbox according to the sandbox resource object.

In the above technical solution, in response to monitoring that the target Kubernetes cluster has an event of adding a first control plane component, the connection request of the first control plane component to the target Kubernetes cluster is directed to a virtual Kubernetes cluster in the first sandbox, specifically:

In response to monitoring an event of a new first control plane component of the target Kubernetes cluster, a network hook is called to intercept a deployment process of the first control plane component;

and modifying the pointing object of the connection request in the configuration information of the first control surface component from the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox.

In the above technical solution, the evaluating the performance of the first control surface component includes:

operating the first control plane component to operate on a virtual Kubernetes cluster in the first sandbox;

and evaluating the performance of the first control plane component according to the audit log of the API-Server component of the virtual Kubernetes cluster recorded by the first sandbox.

In the above technical solution, further includes:

creating a second sandbox in the target Kubernetes cluster, and running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the second sandbox;

responding to the event that a second control surface component is newly added to the target Kubernetes cluster, and directing a connection request of the second control surface component to the target Kubernetes cluster to a virtual Kubernetes cluster in the second sandbox; wherein the second control plane component is a new version of the first control plane component;

Operating the first control plane component and the second control plane component to respectively perform the same operation on virtual Kubernetes clusters in the first sandbox and the second sandbox;

and according to the audit logs of the API-Server components of the virtual Kubernetes cluster respectively recorded by the first sandbox and the second sandbox, realizing regression testing of the second control plane component.

The embodiment of the application also provides a performance evaluation system of the Kubernetes control surface component, which comprises:

the creating unit is configured to create a first sandbox in a target Kubernetes cluster and run a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox;

a monitoring unit configured to monitor a resource change event of the target Kubernetes cluster;

and the evaluation unit is configured to respond to the event that the target Kubernetes cluster generates a new first control plane component, and direct a connection request of the first control plane component to the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox so as to evaluate the performance of the first control plane component.

Embodiments of the present application also provide a computer readable storage medium having stored thereon a computer program that is a method of evaluating performance of a Kubernetes control plane component as described in any of the above.

The embodiment of the application also provides electronic equipment, which comprises: a memory, a processor, and a program stored in the memory and executable on the processor, which when executed implements the Kubernetes control plane component performance assessment method as described in any of the above.

The beneficial effects are that:

in the technical scheme provided by the application, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox; monitoring a resource change event of a target Kubernetes cluster; when the event of the newly added first control surface component occurs to the target Kubernetes cluster is monitored, a connection request of the first control surface component to the target Kubernetes cluster is directed to a virtual Kubernetes cluster in a first sandbox, so that the performance of the first control surface component is evaluated. The method comprises the steps of creating a first sandbox in a target Kubernetes cluster, operating a virtual Kubernetes cluster in the first sandbox, and taking the virtual Kubernetes cluster as a test environment, wherein an independent test environment is not required to be built outside the target Kubernetes cluster, and performance evaluation of a newly-added first control surface component can be realized by only occupying few hardware resources in the target Kubernetes cluster, so that hardware resources required for evaluating the performance of the first control surface component are reduced, and development and test costs are greatly reduced. In addition, the first sandbox is deployed in the target Kubernetes cluster, so that the running state information of the target Kubernetes cluster can be quickly, conveniently and safely synchronized to the virtual Kubernetes cluster, the efficiency of performance evaluation on the newly added first control surface component is improved, and the safety of the evaluation process is ensured.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. Wherein:

FIG. 1 is a flow diagram of a method of performance evaluation of a Kubernetes control surface component provided in accordance with some embodiments of the present application;

FIG. 2 is a logic diagram of a first sandbox performing performance evaluation of a first control surface component in accordance with some embodiments of the present application;

FIG. 3 is a logic diagram of a first sandbox and a second sandbox implementing regression testing according to some embodiments of the present application;

FIG. 4 is a schematic diagram of a performance evaluation system of a Kubernetes control surface component provided in accordance with some embodiments of the present application;

fig. 5 is a schematic structural diagram of an electronic device provided according to some embodiments of the present application;

fig. 6 is a hardware configuration diagram of an electronic device provided according to some embodiments of the present application.

Detailed Description

The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments. Various examples are provided by way of explanation of the present application and not limitation of the present application. Indeed, it will be apparent to those skilled in the art that modifications and variations can be made in the present application without departing from the scope or spirit of the application. For example, features illustrated or described as part of one embodiment can be used on another embodiment to yield still a further embodiment. Accordingly, it is intended that the present application include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

In the following description, the terms "first/second/third" are used merely to distinguish between similar objects and do not represent a particular ordering of the objects, it being understood that the "first/second/third" may be interchanged with a particular order or precedence where allowed, to enable embodiments of the present application described herein to be implemented in other than those illustrated or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing embodiments of the present disclosure only and is not intended to be limiting of the present disclosure.

In order to facilitate understanding of the technical solutions of the present application, the following describes the related art in detail.

Kubernetes is a lightweight and extensible open source orchestration engine for managing containerized cloud native applications and services, and a Kubernetes system is capable of hosting nodes (nodes) corresponding to physical or virtual machines into the same cluster for management, and we refer to the cluster in which the Kubernetes system is deployed as a Kubernetes cluster.

It should be noted that, the Kubernetes cluster includes a control node and a working node, where a plurality of control plane components of Kubernetes are deployed on the control node, and the control plane components are used to automatically implement management functions of resource management, container group scheduling, elastic expansion and contraction, security control, system monitoring and error correction of the Kubernetes system, where the control plane components may include an ETCD component, an API-Server component, a Controller-Manager component, a Scheduler component and the like.

The ETCD component is used for storing the running state of the whole cluster; the API-Server component is used for providing a unique entry for resource operation and providing mechanisms such as authentication, authorization, access control, API registration, discovery and the like; the Scheduler component is responsible for scheduling resources, and the container groups are scheduled to corresponding nodes according to a predetermined scheduling policy.

The Controller-Manager component is the Manager of the various controllers (controllers) in the Kubernetes system, while the Controller is responsible for maintaining the state of the Kubernetes cluster.

It should be appreciated that in a Kubernetes system, the state of a cluster refers to the desired state of the Kubernetes resource object specified in the resource definition file, which is maintained by the various controllers. Specifically, one Controller is responsible for the control flow of at least one type of Kubernetes resource to ensure that its current state is close to the desired state.

The Controller-Manager component is responsible for managing multiple controllers in the Kubernetes system, such as Replication Controller, node controllers, resourceQuota Controller, namespace Controller, serviceAccount Controller, token controllers, service Controller, endpoint Controller, etc., each of which is responsible for managing the state of at least one resource.

Typically, the control plane component built in the Kubernetes system can meet most of the service requirements. In addition, in order to meet the special service requirement, the Kubernetes system also provides an expansion mechanism, so that when the special service requirement appears and the existing control plane component cannot meet the service requirement, an administrator can implement expansion of the Kubernetes system by introducing new custom resources and new control plane components (such as custom controllers) to adapt to the special service requirement.

For ease of illustration, the Kubernetes cluster that requires the introduction of new custom resources and new control plane components is referred to as the target Kubernetes cluster.

It should be appreciated that the custom Controller belongs to one of the control plane components of the Kubernetes system, and is used as a Controller, which is managed by the Controller-Manager component and interacts with other components of the Kubernetes cluster through the API-Server component, so that introducing a new custom Controller may affect the overall normal operation of the target Kubernetes cluster.

For example, a Descheduler is one of custom controllers that reschedules a portion of the group of containers (Pod) in a Kubernetes cluster to other nodes when the Pod is too concentrated in that node. Where a container group refers to the smallest deployable computing unit created and managed in a Kubernetes cluster, is a group (one or more) of containers that share resources among themselves and that rely on each other to communicate. By running the container on the operating system, resources of a single operating system can be effectively partitioned, so that the cloud-native application process can be isolated from other parts of the system when the application process is run in the container.

The introduction of a custom Controller, descheduler, in the Kubernetes cluster, allows for rescheduling of a portion of a container group to other nodes when the container group is too concentrated on a node. However, the rescheduling function of the rescheduling device is partially overlapped with the scheduling function of the control plane component Scheduler built in the Kubernetes system, if performance evaluation is not performed before the rescheduling device is introduced into the target Kubernetes cluster, a situation that scheduling logics are contradictory may occur, for example, the Scheduler continuously schedules some container groups in the Kubernetes cluster to a certain node, and the rescheduling device continuously reschedules the container groups in the node to other nodes, so that the container group scheduling function of the Kubernetes cluster falls into a cycle, and the logic contradiction not only affects the overall normal operation of the target Kubernetes cluster, but also cannot reach the target designed by the rescheduling device.

It should be appreciated that the introduction of a new control plane component, in addition to the situation in which the above-described operating logic contradicts, may occur as follows: the new control plane component may cause an increase in hardware resource overhead, may affect the operation speed of other control plane components or node components, may cause an abnormality in a cloud native application running in the Kubernetes cluster, and the like.

Based on this, it is necessary to evaluate the impact that a target Kubernetes cluster may have on its proper functioning before introducing a new control plane component.

In the related art, in order to ensure the normal operation of the target Kubernetes cluster, when a new control plane component is evaluated, another Kubernetes cluster for testing needs to be built outside the target Kubernetes cluster as a testing environment, and when the evaluation is performed, the operation state of the testing environment is ensured to be consistent with the operation state of the target Kubernetes cluster, that is, each configuration of the testing environment needs to be ensured to be consistent with the target Kubernetes cluster.

However, with the development of cloud computing technology, the scale of Kubernetes clusters is also expanding, and the Kubernetes clusters used by enterprises typically include hundreds or thousands of nodes, which can cost too much if the same-scale test environment is built outside the Kubernetes clusters when evaluating new control plane components; if a Kubernetes cluster with the smallest scale is used as a test environment for saving cost, for example, the Kubernetes cluster only comprises one control node and two working nodes, on one hand, a small-scale test environment has a certain difference from the actual running state of a large-scale target Kubernetes cluster, so that the accuracy of a test result cannot be guaranteed, and on the other hand, even if a small-scale Kubernetes cluster consisting of only three nodes is used as the test environment, the cost is still high for some application developers.

After the operation principle of the Kubernetes cluster is deeply analyzed, the applicant finds that the Kubernetes cluster consists of a control node and a plurality of working nodes, wherein control plane components such as an API-Server component, a Controller-Manager component, a Scheduler component, an ETCD component and the like are deployed in the control node, node components such as a Kubelet component, a Kube-Proxy component, a Container Runtime component and the like are deployed in all the nodes, and the number of the working nodes is continuously increased along with the expansion of the cluster scale, so that the number of the control nodes is kept fixed. That is, the number of control plane components does not increase as the cluster size increases.

Based on the foregoing, it can be seen that the API-Server component is the only entry for the Kubernetes cluster resource operation, so after a new control plane component is deployed to a control node, the new control plane component needs to interact with other control plane components through the only entry for the API-Server component resource operation, and therefore, if performance evaluation is to be performed on the new control plane component, it is critical to keep the operation states of all control plane components in the test environment consistent with the operation states of the control plane components in the target Kubernetes cluster, and after the new control plane component is introduced into the test environment, whether the operation states of other control plane components are affected is monitored.

Therefore, the application provides a performance evaluation method, a system, a computer-readable storage medium and electronic equipment of a Kubernetes control surface component, wherein a first sandbox is created in a target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox to serve as a test environment of the target Kubernetes cluster; and monitoring a resource change event of the target Kubernetes cluster, and when the event of a new first control surface component (namely a new control surface component) of the target Kubernetes cluster is monitored, directing a connection request of the first control surface component to the target Kubernetes cluster to a virtual Kubernetes cluster in a first sandbox, thereby incorporating the first control surface component into the virtual Kubernetes cluster, and then monitoring the running state of the virtual Kubernetes cluster, namely evaluating the overall running state of the target Kubernetes cluster after the first control surface component is introduced. Because the test environment runs in the first sandbox and the first sandbox occupies very few resources, the resources required for performance evaluation of the newly added first control surface component are reduced, and the application development cost is reduced.

Exemplary method

The embodiment of the application provides a performance evaluation method of a Kubernetes control surface component, as shown in fig. 1-3, comprising the following steps:

step S101, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox.

It should be noted that, the Sandbox (Sandbox, sand table or Sandbox) is a special execution environment isolated from the target Kubernetes cluster environment, and the application developer can evaluate the performance of the new control plane component in the Sandbox without affecting the target Kubernetes cluster. By creating the sandbox as the test environment, the control surface components running in the sandbox do not affect the target Kubernetes cluster, and the generated changes of the control surface components running in the sandbox environment can be deleted after the impact evaluation of the new control surface components is completed, so that the impact evaluation of the new control surface components is more convenient and efficient.

In this embodiment, the virtual Kubernetes cluster in the first sandbox is used to simulate the operating environment of the target Kubernetes cluster, that is, by ensuring that the operating state of the virtual Kubernetes cluster is consistent with that of the target Kubernetes cluster, including the type of the control plane component deployed in the virtual Kubernetes cluster, the configuration of the control plane component, and the managed node scale are the same as those of the target Kubernetes cluster, so as to implement performance evaluation on the newly added control plane component in the virtual Kubernetes cluster.

In the embodiment of the application, the first sandbox is created in the target Kubernetes cluster, and the virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox, so that an independent test environment is not required to be built outside the target Kubernetes cluster, and the test and performance evaluation of the newly-added Kubernetes control surface component can be realized by occupying few hardware resources in the target Kubernetes cluster, so that hardware resources required by the test are saved, and the development cost is reduced. In addition, as the first sandbox is deployed in the target Kubernetes cluster, the running state information of the target Kubernetes cluster can be quickly, conveniently and safely synchronized into the virtual Kubernetes cluster, so that the workload of deployment of test environments by application developers is reduced, and the safety of an evaluation process is improved.

To create the first sandbox, in some embodiments, the target Kubernetes cluster includes an injection resource definition file (injection CRD); the injection resource definition file is used for defining an injection resource object, and the injection resource object is used for defining a first sandbox and designating a target control surface component for injecting the first sandbox; the target control plane component is at least one control plane component in the target Kubernetes cluster; correspondingly, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox, specifically: creating a container group according to the injected resource object, and taking the container group as a first sandbox; and injecting a copy of the target control surface component in the first sandbox, and synchronizing all data stored in the ETCD in the target Kubernetes cluster to the first sandbox so as to synchronously run the target control surface component in the first sandbox.

It should be noted that in the Kubernetes system, all contents are abstracted into resources, and Kubernetes provides many default Resource types, such as container group, deployment (Service), storage Volume (Volume), and so on, which can satisfy most of Service requirements, but in some special Service requirement scenarios, existing Resource types may not satisfy the requirements, and at this time, the special Service requirements may be satisfied by adding Custom resources (Custom Resource).

In this embodiment of the present application, the injection resource belongs to a custom resource of Kubernetes, a persistent entity (i.e., a resource instance) corresponding to the injection resource is referred to as an injection resource object, where the injection resource object is used to define a first sandbox and specify a target control plane component to be injected into the first sandbox, that is, kubernetes represents an expected state of the first sandbox through the injection resource object, and based on the injection resource object, the first sandbox can be created in the target Kubernetes cluster, and the specified target control plane component can be injected into the first sandbox.

Wherein the target control plane component is at least one control plane component in the target Kubernetes cluster. Here, the target control plane component may be a set of all control plane components in the target Kubernetes cluster, or may be a subset of some of the control plane components in the target Kubernetes cluster.

When the target control plane component contains all control plane components in the target Kubernetes cluster, by synchronizing the operation states of all control plane components in the target Kubernetes cluster to the first sandbox, the test environment which is completely the same as the target Kubernetes cluster can be copied in the first sandbox, at this time, a new control plane component is operated in the test environment, and the operation states of the test environment are monitored, so that whether the introduction of the new control plane component can affect the overall operation state of the target Kubernetes cluster can be determined.

When the target control plane component contains part of the target Kubernetes cluster control plane component, a copy of the designated part of the control plane component is injected into a first sandbox, and the running state of the control plane component designated by the target Kubernetes cluster is synchronized to the first sandbox, so that a test environment containing the target Kubernetes cluster part of the control plane component is constructed. At this time, the new control surface component is operated in the first sandbox, and the operation state of the test environment is monitored, so that the interrelation between the new control surface component and the target control surface component can be determined, and the influence of the new control surface component on the operation state of the target control surface component can be analyzed in a targeted manner.

It should be noted that, the injection resource object is defined by an injection resource definition file, which is a definition file (Custom Resource Definition, abbreviated as CRD) of a custom resource, specifically may be a yaml or json format file. The Kubernetes system creates an injection resource object according to the injection resource definition file, namely a first sandbox can be created according to the content of the injection resource object, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox.

For example, in one example of injecting a CRD, the example relates to injecting a CRD as follows:

when the target Kubernetes cluster comprises the injection resource definition file, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox, specifically: creating a container group according to the injected resource object, and taking the container group as a first sandbox; and injecting a copy of the target control surface component in the first sandbox, and synchronizing all data stored in the ETCD in the target Kubernetes cluster to the first sandbox so as to synchronously run the target control surface component in the first sandbox.

In practical application, after an injection resource definition file (yaml or json file) is stored in a target Kubernetes cluster, the Kubernetes creates an injection resource object according to the content of the injection resource definition file, creates a container group according to the injection resource object, and uses the container group as a first sandbox.

And then injecting a copy of the target control surface component into the first sandbox according to the target control surface component of the first sandbox appointed by the injection resource, and synchronizing all data stored in the ETCD in the target Kubernetes cluster to the first sandbox.

Based on the foregoing description, the running state of the entire cluster is stored in the ETCD component, and by synchronizing all data stored in the ETCD in the target Kubernetes cluster to the first sandbox, the running state of the target Kubernetes cluster can be copied to the first sandbox, that is, the running state of the target control plane component in the first sandbox is consistent with the running state of the control plane component corresponding to the target Kubernetes cluster, so as to realize the synchronous running of the target control plane component in the first sandbox, and construct the virtual Kubernetes cluster corresponding to the target Kubernetes cluster as the test environment of the target Kubernetes cluster.

It should be specifically noted that, in the embodiment of the present application, a single container group may be used as the first sandbox, which occupies very little hardware resources, that is, only a single container group needs to be started, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster may be operated in the container group, so as to construct a test environment of the target Kubernetes cluster, and save application development costs.

It should be appreciated that, in order to improve the operation efficiency of the virtual Kubernetes cluster, in some specific applications, multiple container groups may also be created in the target Kubernetes cluster, where the multiple container groups are used as a first sandbox, and the virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox.

In addition, the first sandbox is defined as a self-defined resource object, and the test environment of the target Kubernetes cluster is operated in the first sandbox, so that the Kubernetes can manage the first sandbox like the management of the original resource object, and the complexity of the test is reduced.

To create the first sandbox, the target Kubernetes cluster includes, in addition to the import injection resource definition file, a sandbox resource definition file (sandbox CRD) for defining a sandbox resource object for defining a data synchronization pattern of the first sandbox; correspondingly, the method further comprises: all data stored by ETCD in the target Kubernetes cluster is periodically synchronized to the first sandbox according to the sandbox resource object.

As previously described, in order to keep the virtual Kubernetes cluster running state in the first sandbox consistent with the target Kubernetes cluster, all data stored by the ETCD in the target Kubernetes cluster needs to be synchronized into the virtual Kubernetes cluster of the first sandbox in accordance with a certain data synchronization pattern. Therefore, the target Kubernetes cluster performs self-defined expansion on the resource type, and the synchronization of the virtual Kubernetes cluster running state in the first sandbox and the target Kubernetes cluster is realized by adding sandbox resources newly and designating the data synchronization mode of the first sandbox in the sandbox resources.

In particular implementations, the target Kubernetes cluster includes a sandboxed resource definition file for defining sandboxed resource objects, which may be yaml or json format files. The sandboxed resource object is a persistent instance of a sandboxed resource that is capable of defining a data synchronization pattern of the first sandbox.

The data synchronization mode refers to a synchronization strategy, which is used for specifying the content and the synchronization period of the first sandboxed synchronization target Kubernetes cluster. In practical applications, the synchronization content and synchronization period may be determined according to service requirements, for example, all data stored in ETCD in the regular synchronization target Kubernetes cluster, for example, all data stored in ETCD in the one-time synchronization target Kubernetes cluster, or not synchronize any data.

In practical application, besides the data synchronization mode, the sandbox resource can be further expanded by a plug-in mode, for example, in order to further ensure that the testing process does not leak sensitive information of the target Kubernetes cluster, the sandbox resource is expanded by a plug-in mode, so that the sandbox resource can perform preprocessing operations on data to be synchronized, and the preprocessing operations can include: the data stored in the ETCD is firstly desensitized and then synchronized to a virtual Kubernetes cluster in a first sandbox, or the data stored in the ETCD is specially processed for meeting specific test targets, and the like.

For example, in an example of a sandboxed resource, the example relates to a sandboxed CRD as follows:

based on a sandbox resource definition file, the target Kubernetes cluster creates a sandbox resource object, and periodically synchronizes all data stored in the ETCD in the target Kubernetes cluster to the first sandbox according to the sandbox resource object, so that the running state of the virtual Kubernetes cluster in the first sandbox is consistent with that of the target Kubernetes cluster, and the accuracy of the performance evaluation result of the first control surface component is ensured.

After the injection and sandboxed resources are introduced, the target Kubernetes cluster needs to manage it. Kubernetes cluster management can be divided into two styles, one is directed management, with operating parameters or markers being passed into the Kubernetes system through a command line (such as kubectl command line tool) to quickly update the cluster state.

The other is declarative management, and the manner of declarative management of resources describes the expected state of a certain resource object through a resource definition file, so that the Kubernetes cluster can continuously correct the current state of the resource object to enable the current state to conform to the expected state described by the resource definition file.

Based on the foregoing, it can be seen that the desired state of the resource object in the Kubernetes system is specifically maintained by the various controllers. In practice, each Controller monitors the state change of a specific resource in the cluster in real time through a List-Watch interface provided by the API-Server component, and when various faults occur to cause the state change of a certain resource object, the corresponding Controller tries to adjust the state of the resource object to a desired state.

In the embodiment of the application, the management of the injection resources and the sandbox resources is realized by introducing a custom Controller, namely a sandbox Controller, into the target Kubernetes cluster. Thus, prior to creating the first sandbox, further comprising: sandboxed controllers are deployed at the target Kubernetes cluster to manage injection resources and sandboxed resources.

The sandbox controller can be deployed in a certain container group outside the container group where the first sandbox of the target Kubernetes cluster is located, and can also be deployed in a certain container of the container group where the first sandbox is located.

After the sandbox controller is deployed, the sandbox controller accesses the injected CRD and the sandbox CRD through the API-Server component of the target Kubernetes cluster, then creates a container group in the target Kubernetes cluster according to the content of the injected CRD and takes the container group as a first sandbox, and then injects a copy (such as API-Server, controller-Manager, scheduler, ETCD, etc.) of the target control surface component with the same running state as the target Kubernetes cluster into the first sandbox, so that the control node of the target Kubernetes cluster can be simulated in the first sandbox.

After simulating the control node of the target Kubernetes cluster in the first sandbox, in order to simulate the working node of the target Kubernetes cluster, in some embodiments, a virtual node control application is also deployed in the first sandbox; the virtual node control application is used to simulate the working nodes of the target Kubernetes cluster in the first sandbox.

In particular implementations, the virtual node controls the containerized deployment of the application in the first sandbox. It should be appreciated that when the first sandbox corresponds to multiple container groups, the virtual node control application may be deployed in the same container group as the control plane components of the virtual Kubernetes cluster, or may be located in a different container group than the control plane components of the virtual Kubernetes cluster. Similarly, when the first sandbox is a single container group, the virtual node control application may be deployed in the same container as the control plane components of the virtual Kubernetes cluster, or may be located in a different container than the control plane components of the virtual Kubernetes cluster. The embodiments of the present application are not limited in this regard.

Wherein the virtual node control application is for simulating a working node of the target Kubernetes cluster in the first sandbox.

In the Kubernetes cluster, the Kubelet component is configured to register information of a node to the Kubernetes cluster, and periodically report usage of node resources to the Kubernetes cluster, so as to implement management of the node incorporated into the cluster. Only one Kubelet component is started on each node, that is, when a new Kubelet component registers new node information in the control plane component of the Kubernetes cluster, the relevant control plane component can truly exist a new node for the Kubernetes cluster and manage the new node.

Based on the above, the virtual node control application sends the virtual registration information and the virtual heartbeat information packet to the virtual Kubernetes cluster in the first sandbox, and adjusts the content of the virtual heartbeat information packet according to the task issued by the control plane component in the virtual Kubernetes cluster, so that the related control plane component of the virtual Kubernetes cluster is mistakenly a real working node, and therefore the running state of any multiple working nodes in the target Kubernetes cluster can be simulated in the virtual Kubernetes cluster, namely the virtual node control application can simulate the working nodes of the target Kubernetes cluster in the first sandbox in any scale.

Because the virtual node control application adopts a mode of sending the virtual node registration information and the virtual heartbeat data packet to realize the simulation of the working node, the resources occupied by the virtual node registration information and the virtual heartbeat data packet are almost negligible, so that the occupation of hardware resources cannot be increased along with the increase of the number of the simulation nodes, the number of the simulation nodes can be increased continuously during the test, and the occurrence of hardware resource bottlenecks is not worried.

Step S102, monitoring a resource change event of the target Kubernetes cluster.

In the embodiment of the application, the sandbox controller can monitor the resource change event of the target Kubernetes cluster in real time through a List-Watch interface provided by the API-Server component so as to capture the event of the newly added first control surface component in real time and respond.

Step 103, responding to the event that the target Kubernetes cluster generates the new first control plane component, and directing a connection request of the first control plane component to the target Kubernetes cluster to the virtual Kubernetes cluster in the first sandbox to evaluate the performance of the first control plane component.

For the first control plane component newly added in the target Kubernetes cluster, it is required to implement interaction with other control plane components by sending a connection request to the target Kubernetes cluster. To evaluate whether the first control plane component would have an impact on the normal operation of the target Kubernetes cluster, it may first be evaluated for performance by means of the virtual Kubernetes cluster in the first sandbox.

Therefore, when the event that the target Kubernetes cluster generates the new first control surface component is monitored, the sandbox controller in the target Kubernetes cluster directs the connection request of the first control surface component to the target Kubernetes cluster to the virtual Kubernetes cluster in the first sandbox, so that the connection request interacts with other control surface components in the virtual Kubernetes cluster to achieve the purpose of performance evaluation.

After the virtual Kubernetes cluster in the first sandbox receives the connection request of the first control plane component, the virtual Kubernetes cluster is brought into the virtual Kubernetes cluster, and at this time, the influence of the newly added first control plane component on the running state of the target Kubernetes cluster can be estimated by monitoring the running state of the virtual Kubernetes cluster, namely, the performance of the first control plane component is estimated.

To change the direction of the connection request of the first control plane group, in some embodiments, in response to monitoring that the target Kubernetes cluster has an event of adding the first control plane component, the connection request of the first control plane component to the target Kubernetes cluster is directed to the virtual Kubernetes cluster in the first sandbox, specifically: in response to monitoring an event of a target Kubernetes cluster that a first control plane component is newly added, a network hook is called to intercept a deployment process of the first control plane component; the pointing object of the connection request in the configuration information of the first control plane component is modified from the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox.

It should be noted that in the Kubernetes system, a web hook (MutatingAdmissionWebhook) is an extensible admission controller (Admission Controller) in the form of a plug-in that is configurable into an API-Server component for intercepting requests to the API-Server component according to preset rules. Specifically, the mutatingAdmission Webhook plug-in can acquire all interesting Admission Webhooks, monitor requests of the API-Server component, intercept the requests according to rules before resource objects related to the requests are persisted to ETCD, and realize resource modification by sending admission requests to Webhook Server.

In particular to the present application scenario, the first control plane component is abstracted into resources by the target Kubernetes cluster, and therefore, the configuration information of the first control plane component is actually a resource definition file, typically in yaml or json format. The sandbox controller monitors a newly added yaml file in the target Kubernetes cluster, after monitoring that the yaml file corresponding to the first control surface component is stored in the target Kubernetes cluster, the sandbox controller calls a mutatingAdmission Webhook plug-in to intercept the deployment process of the first control surface component, and modifies relevant configuration information of the yaml file of the first control surface component by sending an admission request to the Webhook Server, namely, modifies a pointing object of a connection request in the yaml file of the first control component from the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox, thereby incorporating the first control component into the virtual Kubernetes cluster, and at the moment, the first control surface component is operated, only the operation state of the virtual Kubernetes cluster is required to be monitored, and the performance of introducing the first control surface can be evaluated.

It should be understood that after modifying the relevant configuration information of the yaml file of the first control plane component, the relevant control plane component of the target Kubernetes cluster will continue to complete the deployment process of the first control plane component according to the modified configuration information, that is, the first control plane component is deployed in a certain container group, so as to implement the containerized deployment of the first control plane component.

After deployment is completed, the first control surface component initiates a connection request to an API-Server component of the virtual Kubernetes cluster in the first sandbox, and interacts with the virtual Kubernetes cluster through the connection request, so that the effect of introducing the first control surface component into the virtual Kubernetes cluster as a new control surface component is achieved, and the performance of the first control surface component is evaluated.

It should be specifically noted that, after performance evaluation of the first control plane component is completed, relevant configuration information in the yaml file of the first control plane component can be modified to an initial state, so that the first control plane component can initiate a connection request to an API-Server component of the target Kubernetes cluster, and deployment of the first control plane component in the target Kubernetes cluster is completed, so that time for deployment of the first control plane component in the target Kubernetes cluster is saved, and working efficiency is improved.

In a specific implementation, in order to enable the yaml file of the first control plane component to be modified to an initial state, before the mutatingAdmission Webhook plug-in modifies the configuration information of the first control plane component, the initial state of the first control plane component may be saved, for example, the initial state may be saved in a certain field of the yaml file, or the initial state may be saved in external data.

After introducing the first control plane component as a new control plane component to the virtual Kubernetes cluster, in some embodiments, evaluating the performance of the first control plane component includes: operating a first control plane component to operate on a virtual Kubernetes cluster in a first sandbox; the performance of the first control plane component is evaluated according to an audit (audit) log of an API-Server component of the virtual Kubernetes cluster recorded by the first sandbox.

The function designed by the first control surface component is executed by running the first control surface component, so that the virtual Kubernetes cluster in the first sandbox is operated, and the influence of the first control surface component on the whole running state of the virtual Kubernetes cluster in the process of executing the function is monitored, so that the performance evaluation of the first control surface component is realized. Because the environment of the virtual Kubernetes cluster is consistent with that of the target Kubernetes cluster, the performance of the first control surface component in the virtual Kubernetes cluster is basically the same as that of the first control surface component in the target Kubernetes cluster, and the method can evaluate the influence of the first control surface component on the target Kubernetes cluster under the condition of ensuring the normal operation of the target Kubernetes cluster.

In order to objectively record and continuously monitor the running state of the virtual Kubernetes cluster, an audit log of an API-Server component of the virtual Kubernetes cluster is also recorded in the first sandbox.

Wherein the audit log can provide security-related, chronological records that include information for each request sent to the API-Server at a different execution stage. It should be appreciated that the Kubernetes system collects audit logs according to an audit policy, which is a rule of information logging, such as which events should be logged and which data should be included.

After the audit log record is completed, the audit log can be exported by setting a log receiver so as to facilitate the analysis of the audit log. For example, the audit log may be exported to an external system or sent to the HTTP API in the form of a callback function.

The configuration function of the audit strategy is realized by expanding sandboxed resources in the form of plug-in units, and after the audit strategy is configured, a receiver of the audit log can be specified. That is, setting corresponding fields in the sandbox CRD, for specifying a recording mode for recording related data generated in the operation process of the first control plane component, and specifying a receiver of the related data, so as to collect audit logs according to rules, and export the audit logs to the receiver.

Based on the analysis of the audit log, it is possible to evaluate whether the newly added first control plane component would affect the normal operation of the target Kubernetes cluster.

After the performance evaluation of the first control plane component is completed, the hardware resources occupied by the first sandbox can be released only by deleting the container group included in the first sandbox, so that the resources can be quickly recovered, and the normal operation of the target Kubernetes cluster can not be influenced.

In some embodiments, the first control surface assembly may also be considered to be part of a first sandbox, i.e., a plurality of container groups as the first sandbox, with the first control surface assembly running in a certain container group in the first sandbox. After performance evaluation of the first control plane component is completed, all container groups (including the container groups where the first control plane component is located) included in the first sandbox are deleted, and when the first control plane component needs to be deployed in the target Kubernetes cluster, a new container group is created for deployment.

It should be noted that, the method provided in the embodiment of the present application may also be used for performing regression testing on a control plane component, and referring to fig. 3, when the method is applied to the regression testing of a control plane component, the method further includes: creating a second sandbox in the target Kubernetes cluster, and operating a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the second sandbox; responding to the event that a new second control surface component is added to the target Kubernetes cluster, and directing a connection request of the second control surface component to the target Kubernetes cluster to a virtual Kubernetes cluster in a second sandbox; wherein the second control plane component is a new version of the first control plane component; operating the first control plane component and the second control plane component to respectively perform the same operation on the virtual Kubernetes clusters in the first sandbox and the second sandbox; and according to the audit logs of the API-Server components of the virtual Kubernetes cluster recorded by the first sandbox and the second sandbox respectively, realizing regression testing of the second control plane component.

The regression test refers to an iterative update test of the control plane component, that is, after the old code of the control plane component is modified, a test is performed again to confirm that the modification does not introduce new errors or cause other codes to generate errors. Therefore, in the context of regression testing, there are multiple versions of the control plane component, any 2 of which may be referred to as a first control plane component and a second control plane component, respectively, where the second control plane component is a new version of the modified first control plane component.

In order to achieve regression testing, a second control plane component needs to be deployed in the target Kubernetes cluster in addition to the first control plane component. Specifically, when the sandbox controller monitors that the target Kubernetes cluster generates an event of adding a second control surface component, a second sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the second sandbox. Specifically, the sandbox controller monitors the yaml file newly added to the target Kubernetes cluster, after monitoring that the yaml file of the second control surface component is stored in the target Kubernetes cluster, creates a second sandbox in the target Kubernetes cluster according to the content of the injected CRD and the sandbox CRD, and injects a copy of the target control surface component and a virtual node control application in the second sandbox to construct the same test environment as the target Kubernetes cluster. That is, the target Kubernetes cluster runs two sets of sandboxes simultaneously, a first sandbox and a second sandbox, respectively, and the virtual Kubernetes clusters of the two sets of sandboxes are identically configured.

After creating the second sandbox, the sandbox controller also directs a connection request of the second control plane component to the target Kubernetes cluster to the virtual Kubernetes cluster in the second sandbox, thereby managing the virtual Kubernetes cluster in which the second control plane component is incorporated into the second sandbox.

Specifically, when an event that a second control plane component is newly added to the target Kubernetes cluster is monitored, the sandbox controller calls a mutatingAdmission Webhook plug-in to intercept a deployment process of the second control plane component, and a connection request of the second control plane component to the target Kubernetes cluster is directed to a virtual Kubernetes cluster in a second sandbox by modifying relevant configuration information in a resource definition file (yaml file) of the second control plane component.

Based on the modified configuration information, the relevant control plane components of the target Kubernetes cluster continue to deploy the second control plane component into a certain container group.

After the second control plane component is deployed to a certain container group, the first control plane component and the second control plane component respectively initiate connection requests to the API-Server components of the virtual Kubernetes clusters in the sandboxes corresponding to the first control plane component and the second control plane component respectively incorporate the first control plane component and the second control plane component into the two virtual Kubernetes clusters for management.

And running the first control surface component and the second control surface component when the regression test is specifically performed, respectively sending connection requests to the first sandbox and the second sandbox by the first control surface component and the second control surface component so as to respectively perform the same operation on the virtual Kubernetes clusters in the first sandbox and the second sandbox, and respectively monitoring audit logs of the API-Server components of the virtual Kubernetes clusters in the first sandbox and the second sandbox so as to record the information of the test process. And then, comparing audit logs recorded in the first sandbox and the second sandbox, and finishing regression testing of the new version of the second control surface assembly.

In some embodiments, performance evaluation of the control plane component of the target Kubernetes cluster may be performed as follows:

creating a container group in a target Kubernetes cluster according to the content of the injected CRD by a sandbox controller, taking the container group as a first sandbox, and injecting a copy of a target control surface component and a virtual node control application in the first sandbox;

step two, the sandbox controller monitors a yaml file newly added in the target Kubernetes cluster;

step three, after the yaml file of the first control surface component is monitored to be stored in the target Kubernetes cluster, the sandbox controller calls a MutingAdmissionWebhook plug-in to intercept the deployment process of the first control surface component, modifies relevant configuration information in the yaml file of the first control surface component, and modifies a pointing object of a connection request sent by the first control surface component to the target Kubernetes cluster into a virtual Kubernetes cluster in the first sandbox;

Step four, the first control surface component initiates a connection request to an API-Server component of a virtual Kubernetes cluster in the first sandbox, and the connection request becomes a control surface component in the virtual Kubernetes cluster;

step five, the first sandbox monitors the running state of the control surface component deployed therein and reports the running state to a designated receiver;

and step six, analyzing the reported monitoring data to evaluate whether the first control surface component can influence the normal operation of the target Kubernetes cluster.

To sum up, in the embodiment of the present application, a first sandbox is created in the target Kubernetes cluster, and a virtual Kubernetes cluster corresponding to the target Kubernetes cluster is operated in the first sandbox; monitoring a resource change event of a target Kubernetes cluster; when the event of the newly added first control surface component occurs to the target Kubernetes cluster is monitored, a connection request of the first control surface component to the target Kubernetes cluster is directed to a virtual Kubernetes cluster in a first sandbox, so that the performance of the first control surface component is evaluated. The method comprises the steps of creating a first sandbox in a target Kubernetes cluster, operating a virtual Kubernetes cluster in the first sandbox, and taking the virtual Kubernetes cluster as a test environment, wherein an independent test environment is not required to be built outside the target Kubernetes cluster, and performance evaluation of a newly-added first control surface component can be realized by only occupying few hardware resources in the target Kubernetes cluster, so that hardware resources required for evaluating the performance of the first control surface component are reduced, and development and test costs are greatly reduced. In addition, the first sandbox is deployed in the target Kubernetes cluster, so that the running state information of the target Kubernetes cluster can be quickly, conveniently and safely synchronized to the virtual Kubernetes cluster, the efficiency of performance evaluation on the newly added first control surface component is improved, and the safety of the evaluation process is ensured.

Exemplary System

An embodiment of the present application provides a performance evaluation system of a Kubernetes control plane component, as shown in fig. 4, the system includes: a creation unit 401, a listening unit 402, an evaluation unit 403. Wherein:

the creating unit 401 is configured to create a first sandbox in the target Kubernetes cluster, and run a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox.

A listening unit 402, configured to listen for resource change events of the target Kubernetes cluster.

An evaluation unit 403, configured to respond to the event that the target Kubernetes cluster generates the newly added first control plane component, and direct a connection request of the first control plane component to the target Kubernetes cluster to the virtual Kubernetes cluster in the first sandbox, so as to evaluate the performance of the first control plane component.

The performance evaluation system of the Kubernetes control surface component provided by the embodiment of the present application can implement the flow and steps of the performance evaluation method of the Kubernetes control surface component provided by any embodiment, and achieve the same technical effects, which are not described in detail herein.

Exemplary apparatus

Fig. 5 is a schematic structural diagram of an electronic device provided according to some embodiments of the present application; as shown in fig. 5, the electronic device includes:

One or more processors 501;

a computer readable medium may be configured to store one or more programs 502, the one or more processors 501, when executing the one or more programs 502, implement the steps of: creating a first sandbox in the target Kubernetes cluster, and running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox; monitoring a resource change event of a target Kubernetes cluster; and in response to monitoring that the target Kubernetes cluster generates an event of adding the first control surface component, directing a connection request of the first control surface component to the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox so as to evaluate the performance of the first control surface component.

FIG. 6 is a hardware architecture of an electronic device provided in accordance with some embodiments of the present application; as shown in fig. 6, the hardware structure of the electronic device may include: a processor 601, a communication interface 602, a computer readable medium 603 and a communication bus 604.

Wherein the processor 601, the communication interface 602, and the computer readable storage medium 603 communicate with each other via a communication bus 604.

Alternatively, the communication interface 602 may be an interface of a communication module, such as an interface of a GSM module.

Wherein the processor 601 may specifically be configured to: creating a first sandbox in the target Kubernetes cluster, and running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox; monitoring a resource change event of a target Kubernetes cluster; and in response to monitoring that the target Kubernetes cluster generates an event of adding the first control surface component, directing a connection request of the first control surface component to the target Kubernetes cluster to a virtual Kubernetes cluster in the first sandbox so as to evaluate the performance of the first control surface component.

The processor 601 may be a general purpose processor including a central processing unit (central processing unit, CPU for short), a network processor (Network Processor, NP for short), etc., and may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The electronic device of the embodiments of the present application exist in a variety of forms including, but not limited to:

(1) A mobile communication device: such devices are characterized by mobile communication capabilities and are primarily aimed at providing voice, data communications. Such terminals include: smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones, etc.

(2) Ultra mobile personal computer device: such devices are in the category of personal computers, having computing and processing functions, and generally also having mobile internet access characteristics. Such terminals include: PDA, MID, and UMPC devices, etc., such as iPad.

(3) Portable entertainment device: such devices may display and play multimedia content. The device comprises: audio, video players (e.g., iPod), palm game consoles, electronic books, and smart toys and portable car navigation devices.

(4) And (3) a server: the configuration of the server includes a processor, a hard disk, a memory, a system bus, and the like, and the server is similar to a general computer architecture, but is required to provide highly reliable services, and thus has high requirements in terms of processing capacity, stability, reliability, security, scalability, manageability, and the like.

(5) Other electronic devices with data interaction function.

It should be noted that, according to implementation requirements, each component/step described in the embodiments of the present application may be split into more components/steps, and two or more components/steps or part of operations of the components/steps may be combined into new components/steps, so as to achieve the purposes of the embodiments of the present application.

The above-described methods according to embodiments of the present application may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine storage medium and to be stored in a local recording medium downloaded through a network, so that the methods described herein may be stored on such software processes on a recording medium using a general purpose computer, a special purpose processor, or programmable or dedicated hardware such as an ASIC or FPGA. It is understood that a computer, processor, microprocessor controller, or programmable hardware includes a memory component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the Kubernetes control plane component performance assessment methods described herein. Furthermore, when a general purpose computer accesses code for implementing the methods illustrated herein, execution of the code converts the general purpose computer into a special purpose computer for performing the methods illustrated herein.

Those of ordinary skill in the art will appreciate that the elements and method steps of the examples described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or as a combination of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.

It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part.

The above-described apparatus and system embodiments are merely illustrative, in which elements illustrated as separate elements may or may not be physically separate, and elements illustrated as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the same, but rather, various modifications and variations may be made by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A method for evaluating performance of a Kubernetes control plane component, comprising:

creating a container group in a target Kubernetes cluster, and taking the container group as a first sandbox;

injecting a copy of a target control surface component in the first sandbox, and synchronizing all data stored in ETCD in the target Kubernetes cluster to the first sandbox so as to synchronously operate the target control surface component in the first sandbox, thereby operating a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox; the target control plane component is at least one control plane component in the target Kubernetes cluster;

monitoring a resource change event of the target Kubernetes cluster;

2. The method of claim 1, wherein the target Kubernetes cluster comprises an injection resource definition file;

the injection resource definition file is used for defining an injection resource object, and the injection resource object is used for defining the first sandbox and specifying a target control surface component for injecting the first sandbox.

3. The method for evaluating the performance of a Kubernetes control surface assembly of claim 2,

the first sandbox is also provided with a virtual node control application;

4. The method of claim 3, wherein the target Kubernetes cluster includes a sandboxed resource definition file, the sandboxed resource definition file defining a sandboxed resource object, the sandboxed resource object defining a data synchronization pattern of the first sandbox;

correspondingly, the method further comprises:

5. The method for evaluating the performance of the Kubernetes control plane assembly according to claim 1, wherein the responding to the event that the target Kubernetes cluster generates the newly added first control plane assembly directs the connection request of the first control plane assembly to the target Kubernetes cluster to the virtual Kubernetes cluster in the first sandbox specifically comprises:

6. The method of evaluating the performance of a Kubernetes control plane assembly of claim 5, wherein the evaluating the performance of the first control plane assembly comprises:

7. The method of evaluating the performance of a Kubernetes control plane assembly of claim 1, further comprising:

8. A Kubernetes control plane component performance evaluation system, comprising:

a creation unit configured to create a container group in a target Kubernetes cluster and take the container group as a first sandbox;

The running unit is configured to inject a copy of a target control surface component into the first sandbox, and synchronize all data stored in ETCD in the target Kubernetes cluster to the first sandbox so as to synchronously run the target control surface component in the first sandbox, thereby running a virtual Kubernetes cluster corresponding to the target Kubernetes cluster in the first sandbox; the target control plane component is at least one control plane component in the target Kubernetes cluster;

9. A computer readable storage medium having stored thereon a computer program, wherein the computer program is a method of evaluating performance of a Kubernetes control plane assembly according to any of claims 1-7.

10. An electronic device, comprising: a memory, a processor, and a program stored in the memory and executable on the processor, the processor implementing the method of evaluating performance of Kubernetes control plane components of any of claims 1-7 when the program is executed.