Resource object scheduling methods, systems, clusters, and computer-readable media

Abstract

This invention provides a resource object scheduling method, system, cluster, and computer-readable medium. The resource object scheduling method includes: receiving a user-initiated access request for a specified resource object by an extended component; searching the compatibility between the current version resource object corresponding to the access request and the specified resource object in the system; if the current version resource object is incompatible with the specified resource object, invoking a conversion rule to perform a conversion on the current version resource object according to the conversion rule, so as to convert the current version resource object associated with the access request into a resource object compatible with the current version resource object; updating the current version resource object associated with the access request in the resource access component, and modifying the attribute values ​​of the extended component to update the extended component. This application solves the problem that the same resource object cannot be identified and invoked due to changes in system version, and ensures the smoothness of the resource object invocation process.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a resource object scheduling method, system, cluster, and computer-readable medium. Background Technology

[0002] Kubernetes clusters use a declarative resource object definition model to define resource objects. Upgrading the Kubernetes version can lead to call failures and unresponsiveness for the same resource object across different Kubernetes versions. In distributed or multi-resource-type Kubernetes cluster scenarios, using declarative API files to customize resource objects not only results in cumbersome definition due to the large variety of resource object types, but also suffers from instability and poor availability due to Kubernetes version upgrades (or downgrades), even with identical definitions of the same resource object. Ultimately, this leads to a situation where business containers deployed on various worker nodes in a Kubernetes cluster cannot effectively respond to user requests when the Kubernetes cluster version changes.

[0003] Meanwhile, after searching, the applicant pointed out that Chinese invention patent CN108964958A discloses "A Service Access Management Method and System in a Container Cloud Environment." This prior art uses YAML files to orchestrate service components to create service instances that meet different needs. Therefore, this prior art only addresses how to provide a more convenient access method for services on cloud management platforms, and thus cannot solve the aforementioned technical problem. Chinese invention patent CN109831500A discloses "A Method for Synchronizing Configuration Files and Pods in a Kubernetes Cluster." The tag selector built into the Kubelet component in this prior art does not wait for the synchronization operation between the previous version of the current configuration file and the Pod to be completed, but instead injects the current configuration file into the Pod to complete the synchronization operation between the Pod and the current configuration file. The applicant points out that this prior art aims to reduce frequent invalid synchronization operations between the Pod and the configuration file; therefore, it still cannot solve the technical problem of the same resource object being unrecognizable and failing to be invoked due to Kubernetes version upgrades or downgrades.

[0004] In view of this, it is necessary to improve the existing methods for defining resource objects in Kubernetes clusters built by Kubernetes when version information is iteratively upgraded or downgraded, in order to solve the aforementioned technical problems in the resource object invocation process in the existing technology. Summary of the Invention

[0005] The purpose of this invention is to disclose a resource object scheduling method, system, cluster, and computer-readable medium to solve the problem that the same resource object cannot be identified and invoked due to changes in system version, to ensure the smoothness of the system version change process, and to improve the reliability and stability of the invocation process of the same resource object during system version changes.

[0006] To achieve one of the above objectives, the present invention provides a resource object scheduling method for scheduling resource objects in a system, comprising:

[0007] The extended component receives a user's access request for a specified resource object and searches the system for the compatibility between the current version resource object corresponding to the access request and the specified resource object.

[0008] If the current version resource object is incompatible with the specified resource object, the conversion rule is invoked to perform a conversion on the current version resource object according to the conversion rule, so as to convert the current version resource object associated with the access request into a resource object compatible with the current version resource object;

[0009] Update the current version of the resource object associated with the access request in the resource access component, and modify the attribute values ​​of the extended component to update the extended component.

[0010] As a further improvement to the present invention, it also includes:

[0011] The system loads the conversion rules formed between current version resource objects of different system versions and saves the conversion rules to the rule base. When a user initiates an access request, the system calls the conversion rules from the rule base in a loop according to the user's namespace to determine the compatibility between the extended component and the current version resource object corresponding to the access request. When the extended component is incompatible with the current version resource object corresponding to the access request, the system calls the conversion rules to convert the current version resource object.

[0012] As a further improvement to the present invention, it also includes:

[0013] The status information generated during the transformation of the current version resource object based on the transformation rules is exposed to the outside under the control of the execution engine. After the detection results are classified, the classified detection results are saved to the corresponding detection result collection components in the backend storage.

[0014] As a further improvement of the present invention, the access request includes resource object type, resource object version and request subject information initiating the access request;

[0015] The operation of retrieving the current version resource object of the system is performed by the API service.

[0016] As a further improvement of the present invention, the status information is classified in the form of evaluation indicators, events or logs, and is respectively saved to the corresponding detection result collection components deployed in the backend storage, wherein the detection result collection components include a monitor, an event collector or a log recorder.

[0017] As a further improvement to the present invention, it also includes:

[0018] Upon receiving a new access request, the detection result collection component invokes the detection results generated in response to the previous access request to perform updates only on the current version of resource objects in the resource access component that are incompatible with the new access request.

[0019] As a further improvement to the present invention, it also includes:

[0020] Filtering is performed on the identification information contained in the access request extracted from the access request;

[0021] The access request is processed by calling transformation rules from the rule base to extract the current version resource object that is incompatible with the access request;

[0022] The identification information includes one or a combination of several of the following: subject information carried in the access request, the IP address of the subject initiating the access request, a token, or access type information.

[0023] As a further improvement of the present invention, the modification of the attribute values ​​of the extended component includes:

[0024] Modify the Backend field and API version information contained in the configuration file describing the current version resource object to save the conversion rules formed between the modified extended component and the current version resource object to the rule base. The conversion rules include the association relationship between the same extended component and the current version resource object before and after the modification based on the Backend field and / or API version information.

[0025] As a further improvement of the present invention, it also includes: performing pre-detection on the current version resource object associated with the access request, the pre-detection including:

[0026] The current version of the resource object in the resource access component is compared with the conversion rules stored in the rule base, and the extended components corresponding to the current version of the resource object that is incompatible with the current system version are extracted.

[0027] Modify the property values ​​of the extended components corresponding to the resource objects that are incompatible with the current system version.

[0028] As a further improvement of the present invention, the pre-detection passively triggers a Webhook request when the system receives an access request initiated by the user. By determining whether the extended component can access the current version resource object associated with the extended component, it is determined whether the current version resource object associated with the extended component needs to be updated. If the extended component cannot access the current version resource object associated with the extended component, the attribute value of the extended component is modified to update the extended component.

[0029] As a further improvement of the present invention, the operation of modifying the attribute values ​​of the extended component is initiated and executed directly to the extended component by the administrator through the API service, based on the configuration file issued by the administrator.

[0030] or,

[0031] The parsing unit initiates and executes the request to the extended component;

[0032] The configuration file can be a JSON file, a YAML file, or an XML file.

[0033] As a further improvement to the present invention, it also includes:

[0034] Determine whether the extended component can access the current version of the resource object associated with the extended component.

[0035] If not, under the control of the execution engine, the detection results are exposed to trigger the administrator or parsing unit to perform transformation on the current version resource object in the resource access component by calling the transformation rules of the rule base, so as to form the current version resource object and perform the operation of modifying the attribute values ​​of the extended component;

[0036] If so, the current version resource object is directly used as the designated resource object to respond to the user's access request.

[0037] As a further improvement of the present invention, the system is a Kubernetes cluster, which includes a master node and at least one worker node managed by the master node;

[0038] The extended components are deployed on the master node and / or any one of the worker nodes.

[0039] As a further improvement of the present invention, the extension component includes at least one addon component and / or at least one LCM component;

[0040] The addon component and / or LCM component are deployed only on multiple worker nodes, and the addon component and / or LCM component are deployed in the form of plugins or scripts.

[0041] As a further improvement of the present invention, the conversion rules stored in the rule base are defined by a message structure, which is jointly described by system API version information, type, metadata, description information, obsolete resource object API version information, and obsolete resource object API version operation strategy.

[0042] Meanwhile, based on the same inventive concept, this invention also provides a resource object scheduling system, comprising:

[0043] Extended components, resource access components, and a resource object detection system; the resource object detection system includes: a rule base, a conversion unit, a parsing unit, and an API service;

[0044] The extended component receives user access requests for specified resource objects;

[0045] The parsing unit retrieves the current version resource object in the system and calls the conversion rules from the rule base to perform conversion on the current version resource object according to the conversion rules;

[0046] The conversion unit converts the current version resource object associated with the access request into a resource object compatible with the current version resource object, updates the resource object associated with the access request in the resource access component, and modifies the attribute values ​​of the extension component to update the extension component.

[0047] As a further improvement of the present invention, the rule base stores conversion rules, wherein the conversion rules include the association relationship between the same extended component before and after modification and the resource object based on the Backend field and / or API version information.

[0048] As a further improvement of the present invention, the resource object detection system further includes:

[0049] Results exposure unit, execution engine, API service, and test result collection component;

[0050] The API service performs the operation to modify the attribute values ​​of the extended component. This modification is initiated and executed directly by the administrator through the API service, using a configuration file.

[0051] or,

[0052] The parsing unit initiates and executes operations on the property values ​​of the extended component;

[0053] The configuration file can be a JSON file, a YAML file, or an XML file.

[0054] As a further improvement of the present invention, when a new access request is received, the detection result collection component calls the detection result generated in response to the previous access request, and the result exposure unit exposes the detection result to the outside under the control of the execution engine. The result exposure unit classifies the detection result in the form of evaluation indicators, events or logs, and saves them to the corresponding detection result collection component deployed in the backend storage. The detection result collection component includes a monitor, an event collector or a log recorder.

[0055] As a further improvement of the present invention, the extension component includes at least one addon component and / or at least one LCM component;

[0056] The addon components and / or LCM components are deployed in the form of plugins or scripts.

[0057] As a further improvement of the present invention, the parsing unit includes: a filtering unit and a decision unit;

[0058] The filtering unit performs filtering on the identification information contained in the access request extracted from the access request;

[0059] The decision-making unit calls the transformation rules from the rule base to extract the current version resource object that is incompatible with the access request;

[0060] The identification information includes one or a combination of several of the following: subject information carried in the access request, the IP address of the subject initiating the access request, a token, or access type information.

[0061] Furthermore, based on the same inventive concept, this invention also discloses a computer cluster, comprising:

[0062] Master node, at least one working node managed by the master node;

[0063] The computer cluster is deployed as a resource object scheduling system as disclosed in any of the above inventions;

[0064] The extended components are deployed on the master node and / or any one of the worker nodes;

[0065] The computer cluster is a Kubernetes cluster.

[0066] As a further improvement of the present invention, the computer cluster further includes: backend storage for deploying the detection result collection component;

[0067] The result exposure unit exposes the status information generated during the conversion of the current version resource object based on the conversion rules to the outside world under the control of the execution engine. The detection results are then classified in the form of evaluation indicators, events or logs and saved to the corresponding detection result collection components deployed in the backend storage.

[0068] The detection result collection component includes a monitor, an event collector, or a logger.

[0069] As a further improvement of the present invention, the resource object detection system, the extended component, and the resource access component are all deployed on the master node.

[0070] or,

[0071] The resource object detection system and the resource access component are both deployed on the master node, while the extended components are distributed across multiple worker nodes.

[0072] As a further improvement of the present invention

[0073] The extended component includes at least one addon component and / or at least one LCM component;

[0074] The addon components and / or LCM components are deployed in the form of plugins or scripts;

[0075] The backend storage includes distributed storage systems, disk arrays, portable electronic storage devices, or cloud storage.

[0076] Finally, based on the same inventive concept, the present invention also provides a computer-readable medium.

[0077] The computer-readable medium stores computer program instructions, which, when read and executed by a processor, perform the steps of the resource object scheduling method as described in any of the preceding inventions.

[0078] The processor includes a CPU, GPU, DSP, FPGA, or vCPU.

[0079] Compared with the prior art, the beneficial effects of the present invention are:

[0080] In this application, if the current version of a resource object is incompatible with a specified resource object, a conversion rule is invoked to perform a conversion on the current version of the resource object according to the conversion rule. This converts the current version of the resource object associated with the access request into a resource object compatible with the current version, updates the current version of the resource object associated with the access request in the resource access component, and modifies the attribute values ​​of the extended component. Therefore, this application solves the problem of the same resource object being unrecognizable and invoked due to system version changes, and ensures the smoothness of the resource object invocation process. It is therefore suitable for application scenarios where system versions change, and significantly improves the reliability and stability of the invocation process for the same resource object during system version changes. Attached Figure Description

[0081] Figure 1 This is an overall flowchart of a resource object scheduling method according to the present invention;

[0082] Figure 2 For operation Figure 1 The topology diagram of a resource object detection system of the present invention, which is a resource object scheduling method, is shown in a specific embodiment, wherein the operation of modifying the attribute value of the extended component is performed by the API service.

[0083] Figure 3 For operation Figure 1 The resource object scheduling method shown is illustrated in another specific embodiment of the resource object detection system of the present invention, wherein the operation of modifying the attribute value of the extended component is performed by the parsing unit.

[0084] Figure 4 For operation Figure 1 The topology of a resource object detection system according to the present invention, which is a resource object scheduling method, is shown in another specific embodiment, wherein multiple addon components (i.e., a specific concept of extended components) are deployed on the same working node.

[0085] Figure 5 For operation Figure 1 The diagram shows a resource object scheduling method and a resource object detection system of the present invention in another specific embodiment, wherein multiple addon components are deployed on multiple worker nodes.

[0086] Figure 6 For operation Figure 1 The topology diagram of a resource object detection system of the present invention, which is a resource object scheduling method, is shown in another specific embodiment, wherein an extension component containing multiple addon components is deployed on the master node.

[0087] Figure 7An example diagram showing how a resource access component can store several earlier version resource objects and several current version resource objects.

[0088] Figure 8 This is a schematic diagram illustrating how the result exposure unit exposes the test results.

[0089] Figure 9 This is a diagram illustrating how the parsing unit parses access requests to generate detection results.

[0090] Figure 10 A flowchart for pre-checking and upgrading addon components;

[0091] Figure 11 This is a sequence diagram for administrators to cyclically retrieve defined resource objects from the Kubernetes cluster and determine whether a resource object is in an obsolete state based on the transformation rules configured in the rule base or the original definition rules.

[0092] Figure 12 A flowchart for passively triggering a Webhook;

[0093] Figure 13 A flowchart for actively triggering the modification of attribute values ​​of a resource access object;

[0094] Figure 14 This is a topological diagram of a computer-readable medium according to the present invention. Detailed Implementation

[0095] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Equivalent changes or substitutions in function, method, or structure made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0096] In summary, the resource object scheduling method, resource object detection system, Kubernetes cluster (or simply "k8s cluster"), and the technical solutions contained in the computer-readable medium disclosed in this application aim to solve the technical problem of resource object invocation failure in computer cluster scenarios that respond to user access requests due to version information differences in system versions at different stages. The resource objects in this application can be understood as Jobs (tasks), image files (e.g., Qcow2 files, ISO files, etc.), virtual gateways, virtual IP addresses, controls (e.g., menus, navigation bars, etc.), and other resource objects (i.e., Objects).

[0097] In this application, a resource object refers to an entity or specific information. A resource object can be a piece of text, an image, a song, or a service, and it uses a Uniform Resource Identifier (URI) to point to a specific resource. Each resource object corresponds to a specific URI. To obtain this resource, one simply accesses the URI; therefore, the URI becomes the address or unique identifier of each resource object. Resource objects are invoked through a RESTful API in a system (e.g., a Kubernetes cluster). Therefore, different versions of the system may have different version information, resulting in differences in the API descriptions or definitions in the attribute fields corresponding to the version information. Therefore, the resource object type (i.e., Version) is typically used to characterize the descriptions of the same or different resource objects in different system versions.

[0098] For example, during the iterative update process based on the Kubernetes system version information, for the same resource object, for example, ClusterRoleBinding (cluster role binding) has two version information during the iterative upgrade process of the Kubernetes system, namely, rbac.authorization.k8s.io / v1beta1 and rbac.authorization.k8s.io / v1. Among them, "v1beta1" represents a pre-release version (or "prior version resource object"), and "v1" represents a stable version (or "current version resource object"). In this application, the modification of the attribute values of the resource object and the update of the extension component 11 (for example, addon component or LCM component) can be understood as an upgrade iteration (for example, upgrading from v1 to v2), or a downgrade iteration (for example, downgrading from v2 to v1). The addon component in this application performs lifecycle management on the core services and resource objects formed by the Kubernetes cluster, so as to provide deployment services for the containerized cloud platform. The LCM (LifeCycle Management) component in this application installs, deploys, upgrades or replaces nodes for the Kubernetes cluster, or is based on applications (for example, APP) encapsulated by various resource objects of the Kubernetes cluster, and is based on the application in various states such as being created, running, suspended, transferred to the background, paused, etc., and performs lifecycle management on each resource object formed by the Kubernetes cluster. Both the addon component and the LCM component can be regarded as specific instances of the extension component 11. Users can directly initiate an access request for one or more resource objects to a certain extension component 11, or users can also directly initiate an access request for one or more resource objects to the resource access component 12. More specifically, the addon component can be an ingress-controller addon component and run in the form of a Pod on the master node 1 or the worker node in the Kubernetes cluster.

[0099] Exemplarily, the inventions disclosed in the various specific embodiments disclosed in this application aim to update the version information of resource objects and addon components (that is, a subordinate concept of the extension component 11) when a computer system (or system) such as a Kubernetes cluster undergoes a change in version information, so as to meet the compatibility of the current version of the system with resource objects, so as to achieve that when the system (for example, Kubernetes cluster) receives an access request initiated by a user, reliable scheduling of resource objects is achieved through the extension component 11, so as to effectively respond to the access request initiated by the user.

[0100] Refer Figure 1 And Figure 2 As shown in the figure, the present invention first discloses a resource object scheduling method (hereinafter or simply referred to as "scheduling method"). This resource object scheduling method schedules the resource objects of the system, including: the extended component 11 receives an access request initiated by the user for the specified resource object 122, and retrieves the compatibility between the current version resource object 121 corresponding to the access request in the system and the specified resource object 122;

[0101] When the current version resource object 121 is not compatible with the specified resource object 122, a conversion rule is called to perform a conversion on the current version resource object 121 according to the conversion rule, so as to convert the current version resource object 121 associated with the access request into a resource object compatible with the current version resource object 121;

[0102] The current version resource object 121 associated with the response to the access request in the resource access component 12 is updated, and the attribute value of the extended component 11 is modified to update the extended component 11.

[0103] See Figure 7 As shown in the figure, in this application, the specified resource object 122 and the current version resource object 121 are independent concepts of each other only when any one or several of their attribute values are different, such as different version information, different types, or different names. Therefore, when the current version resource object 121 is compatible with the version of the specified resource object, there is no need to call the conversion rule, and the version information of the specified resource object 122 associated with a specific access request can be directly adopted as the current version resource object 121 already stored in the resource access component 12, and the resource object can be directly called through, for example, the addon component 11a to respond to the current access request initiated by the user. The extended component 11, such as the addon component 11a, will be created and applied after startup, and complete the operation of distributing the resource objects corresponding to the application.

[0104] The scheduling method further includes: loading the conversion rules formed between the current version resource objects 121 of different system versions, saving the conversion rules to the rule base 10, and when receiving an access request initiated by a user, cyclically calling the conversion rules from the rule base 10 according to the user's namespace to determine the compatibility between the extended component 11 and the current version resource object 121 corresponding to the access request. If the extended component 11 is incompatible with the current version resource object 121 corresponding to the access request, the conversion rules are called from the rule base 10 to convert the current version resource object 121. Since the system presents different version information during version upgrades or downgrades, by loading the conversion rules formed between the current version resource objects 121 of different system versions and saving the conversion rules to the rule base 10, the rules can be directly converted when a new access request is received, thereby avoiding the need for the parsing unit 30 and the conversion unit 20 to manage the resource objects, thus improving the response efficiency and speed to the next new access request.

[0105] Rule base 10 defines the obsolescence state of resource object versions in the Kubernetes cluster by creating a custom CRD resource, DeprecatedResource. This resource object serves as the rule base 10 containing transformation rules, allowing for the creation, modification, and deletion of these rule bases along with the resource objects contained in the native Kubernetes cluster. The applicant presents the following code as an example to illustrate the technical concepts underlying the transformation rules contained in rule base 10.

[0106]

[0107]

[0108] Combination Figure 2As shown, in this application, through the DeprecatedResource object, detailed information such as the version of the deprecated resource object, in which version it was set to the deprecated state, and the upgrade to the new version can be obtained. The conversion rules defined in the rule library 10 will guide the parsing unit 30 (i.e., Deprecated API GVK) and the conversion unit 20 to manage the resource object. And the meaning of management in this application is to call the conversion rules for the resource object, update the resource object, and at the same time modify one or more extension components 11 (such as addon components) associated with the access request initiated by the current user. And it can modify the attribute values (i.e., attribute fields) of the addon component 11 (i.e., a lower-level concept of the extension component 11), so as to forward the resource object with updated attribute values to the resource access component 12 to meet the subsequent access requests initiated by the user for the same extension component 11 after modifying the attribute values. The parsing unit 30 determines whether extension components 11 such as the addon component 11a access the resource object that has been in the deprecated state saved in the resource access component 12. If it is a resource object in the deprecated state, it is determined that the resource object is incompatible with the specified resource object for the current version resource object, and the resource object in the deprecated state needs to be converted. After converting the resource object, version information conversion processing such as upgrading or downgrading the addon component 11a that accesses the resource object is performed. For a resource object that is not in the deprecated state (i.e., the current version resource object is compatible with the specified resource object), the conversion of the resource object is not performed. The applicant shows the following code to briefly explain how the parsing unit 30 in the embodiment of the resource object scheduling method disclosed in this application determines whether the resource object is compatible with the current version resource object 121 and the specified resource object 122.

[0109]

[0110]

[0111] Refer to Figure 11 As shown, this application further discloses a specific implementation manner of an administrator cyclically obtaining the defined resource objects from the Kubernetes cluster and determining whether the resource object is a deprecated state resource object (Deprecated Resource) based on the conversion rules or the original definition rules configured in the rule library 10.

[0112] In Figure 11In this process, after receiving an access request from a user on the server side, API service 60 notifies conversion unit 20, which then triggers an operation to check and convert the version information of all existing resource objects in the cluster. Conversion unit 20 calls the interface of rule base 10 to load conversion rules defined in the cluster using CRD (CustomResource Define). Conversion unit 20 sends a rule query request to rule base 10, which returns the rules (i.e., the conversion rules). Then, the following loop session process is executed, as detailed below.

[0113] The conversion unit 20 initiates a resource object query request to the resource access component 12 to query the version information of the current version resource object 121 in the resource access component 12. After the query is completed, the conversion unit 20 returns the version information of the resource object to the conversion unit 20 to determine whether the conversion rule already invoked by the conversion unit 20 should be used to convert the current version resource object 121. If the version information of the current version resource object 121 is inconsistent with that of the specified resource object (i.e., incompatible), the current version resource object is converted to modify its version information (i.e., modify the identification information), thereby performing the conversion. The converted current version resource object 121 then returns the information that the version information of the resource object has been converted to the conversion unit 20. At this time, the conversion unit 20 needs to expose the conversion result to the result exposure unit 40, and the conversion unit 20 initiates a resource object query request to the result exposure unit 40 and returns the exposure detection result. The scheduling method further includes: exposing the status information generated during the transformation of the current version resource object 121 based on the transformation rules to the outside world under the control of the execution engine 50, so that the detection results are classified and then saved to the corresponding detection result collection component 80 in the backend storage 8. The detection results are exposed in the form of status information and classified in the form of evaluation indicators, events or logs. The transformation unit 20 can access the status information in the result exposure unit 40 through the execution engine 50, and after obtaining the status information, it returns the status information to the transformation unit 20 through the execution engine 50.

[0114] The access request includes the resource object type, resource object version, and the requesting body information; among them, the operation of retrieving the current version of resource object 121 is performed by API service 60. More specifically, API service 60 is implemented by APIserver deployed on master node 1, and API service 60 can directly establish a session with the administrator.

[0115] Status information is categorized into evaluation metrics, events, or logs, and stored in the corresponding detection result collection component 80 deployed in the backend storage 8. The detection result collection component 80 includes a monitor 401, an event collector 402, or a logger 403. Whether the status information is exposed as evaluation metrics, events, or logs depends on the exposure policy for exposing detection results in the configuration file issued by the administrator. In this application, the purpose of exposing detection results is to notify the Kubernetes cluster administrator so that the administrator is aware of the scheduling content performed on the resource objects and can audit the resource objects during the scheduling process.

[0116] Meanwhile, the resource object scheduling method disclosed in this application also includes: when a new access request is received, the detection result collection component 80 calls the detection result generated by the response to the previous access request to perform an update only on the current version resource object 121 in the resource access component 12 that is incompatible with the new access request, so as to reduce the computational overhead caused by re-performing the update on the objectively compatible current version resource object 121.

[0117] More preferably, the resource object scheduling method further includes: performing filtering on the identification information contained in the access request extracted from the access request; calling the transformation rules from the rule base 10 on the access request to extract the current version resource object 121 that is incompatible with the access request; wherein, the identification information includes one or a combination of the subject information carried by the access request, the IP of the subject that initiated the access request, the Token, or the access type information.

[0118] Modifying the property values of the extension component 11 includes: modifying the Backend field and API version information included in the configuration file describing the current version resource object 121, and saving the conversion rule formed between the modified extension component 11 and the current version resource object 121 to the rule library 10. The conversion rule includes the association relationships formed between the same extension component 11 before and after modification based on the Backend field and / or API version information and the current version resource object 121. For example, when the Addon component is an instance of the ingress-controller addon component, the Backend field includes property fields (i.e., property values) such as Path (path), Service Name (service name), and Service Port (service interface). For example, modifying the Addon component can be understood as modifying one property field, several property resources, or all property fields of Path, Service Name, or Service Port simultaneously. When the cluster is upgraded to k8s 1.22, the object definition with the version information of v1beta1 in the Kubernetes system will not exist. For the ingress-controller v1 supporting v1beta1, if the ingress-controller addon component is not upgraded to k8s 1.22, this component will not be able to obtain the resource object of v1beta1, resulting in abnormal operation. Therefore, before the upgrade, it is necessary to upgrade the version information of the ingress-controller addon component, which is used as an addon component, from v1 to the v2 version corresponding to the higher version ingress-controller addon component, so that the v2 version ingress-controller addon component can support resource objects of both v1beta1 and v1 versions simultaneously.

[0119] As shown in Figure 10 the following, in each of the present applications, the scheduling method further includes: performing a pre-detection on the current version resource object 121 associated with the access request, and the pre-detection includes:

[0120] Step 701) Detect the existing resource objects in the system, compare the current version resource object 121 in the resource access component 12 with the conversion rules saved in the rule library 10, and extract the extension component 11 (e.g., addon component) corresponding to the current version resource object 121 that is incompatible with the current system version;

[0121] Step 702) Modify the property values of the extension component 11 corresponding to the resource object that is incompatible with the current system version.

[0122] In the pre-testing phase, the addon component of the resource object corresponding to the obsolete phase detected in the previous pre-testing phase of the access request response is upgraded to support the addon component version compatible with the resource object in the upgraded Kubernetes version. The addon component needs to support the version information of the resource object before and after the upgrade, so as to ensure that the addon component can always work normally during the upgrade process.

[0123] When the system receives an access request initiated by a user, the pre-detection passively triggers a Webhook request. It determines whether the current version resource object 121 associated with the extension component 11 needs to be updated by judging whether the extension component 11 can access the current version resource object 121 associated with the extension component 11. If the extension component 11 cannot access the current version resource object 121 associated with the extension component, it modifies the attribute value of the extension component 11 to update the extension component 11.

[0124] For example, the reference Figure 2 The operation to modify the attribute values ​​of extended component 11 is initiated and executed directly to extended component 11 by the administrator through the API service 60, or, as shown in the example... Figure 3 As shown, the operation of modifying the attribute values ​​of extended component 11 is initiated and executed by parsing unit 30 to extended component 11. Configuration files include JSON files, YAML files, or XML files. The administrator distributes the configuration file to API service 60.

[0125] The scheduling method further includes: determining whether the extension component 11 can access the current version resource object 121 associated with the extension component 11; if not, exposing the detection result under the control of the execution engine 50 to trigger the administrator or the parsing unit 30 to perform conversion on the current version resource object 121 in the resource access component 12 by calling the conversion rules of the rule base 10, so as to form the current version resource object 121 and perform the operation of modifying the attribute value of the extension component 11; if yes, directly using the current version resource object 121 as the designated resource object 122 to respond to the access request initiated by the user.

[0126] For example, the system referred to in this application may be a Kubernetes cluster, which includes a master node 1 and at least one worker node managed by the master node 1; the extension component 11 is deployed on the master node 1 and / or any one of the worker nodes.

[0127] The extension component 11 includes at least one addon component 11a and / or at least one LCM component 11b. The addon component and / or LCM component are deployed only distributed across multiple worker nodes. The addon component and / or LCM component are deployed in the form of plugins or scripts. Both the addon component and LCM component can be dynamically inserted, and an addon component 11a can be split into multiple independent sub-addon components that detect different resource objects as needed.

[0128] The transformation rules stored in Rule Base 10 are defined through a message structure. This message structure is jointly described by system API version information (Version), type (i.e., Kind), metadata, description information, deprecated resource object API version information, and deprecated resource object API version operation strategy. The message structure is sent via Webhook to... Figure 2 The resource object detection system 14 shown has a message structure mainly consisting of the Ref parameter of an Object type object, which carries the Resource information of the resource object associated with the access request.

[0129] In summary, the resource object scheduling method disclosed in this application solves the problem that the same resource object (e.g., the same Job) cannot be identified and invoked due to changes in Kubernetes system version information, and ensures the smoothness of the resource object invocation process. Therefore, it is applicable to application scenarios where Kubernetes system version information changes (e.g., iterative upgrades or iterative downgrades), and significantly improves the reliability and stability of the invocation process of the same resource object in Kubernetes system during version information changes.

[0130] Combination Figures 2 to 9 As shown, this application also discloses the inventive ideas contained in several optional specific implementations of the resource object scheduling system. This application further discloses several specific implementations of a resource object scheduling system.

[0131] Exemplarily, a resource object scheduling system runs the steps of the resource object scheduling method disclosed in the foregoing embodiments. The resource object scheduling system includes: an extension component 11, a resource access component 12, and a resource object detection system 14; the resource object detection system 14 includes: a rule library 10, a conversion unit 20, an analysis unit 30, and an API service 60. The extension component 11 receives a user's access request for a specified resource object 122. The analysis unit 30 retrieves the current version of the resource object 121 in the system and calls the conversion rule from the rule library 10 to perform conversion on the current version of the resource object 121 according to the conversion rule. The conversion unit 20 converts the current version of the resource object 121 associated with the access request into a resource object compatible with the current version of the resource object 121, updates the resource object associated with the response to the access request in the resource access component 12, and modifies the attribute value of the extension component 11 to update the extension component 11.

[0132] The extension component 11 includes at least one addon component and / or at least one LCM component. The addon component and / or the LCM component are deployed in the form of a plug-in or a script. Figure 2 The extension component 11, the resource access component 12, the ETCD component 13, and the resource object detection system 14 in [the system] are deployed on the server side of the Kubernetes cluster, and the user发起对指定资源对象的访问请求,并对指定资源对象进行调度。

[0133] The resource object detection system 14 exists in the form of a system service deployed on the master node 1 of the Kubernetes cluster. The resource object detection system 14 serves as the Webhook Provider of the Kubernetes cluster. After the addon component accesses the resource, the access request is sent to the resource version detection system to determine whether the version of the accessed resource object is in a discarded state, and the resource object being in a discarded state may be due to the iterative upgrade of the Kubernetes cluster or may also be due to the iterative downgrade of the Kubernetes cluster.

[0134] See Figure 12 The specific process of the passively triggered Webhook shown. The Webhook mechanism intercepts all requests sent to the kube-apiserver (i.e., the resource object access component 12) and sends the request event to the registered Webhook Provider for operations such as auditing the request. Such as Figure 2 and Figure 3 It should be noted that there seems to be an incomplete sentence in the translation of line . Please check and correct it if necessary.The computer logic running in each component or module in [the system] responds to the request from the resource access component 12, so it can be understood as being triggered passively. The specific process of this passively triggered Webhook specifically includes the following steps 711 to 715. At the same time, the method of passively triggering the Webhook can also more easily detect the extension component 11 associated with the resource object accessing the abandoned API, guiding the compatibility detection of the extension component 11 during the upgrade process of the Kubernetes system.

[0135] Step 711) The extension component 11 accesses the resource object of the resource access component 12;

[0136] Step 712) The resource access component 12 forwards the access request to the parsing unit 30 in the form of a Webhook;

[0137] Step 713) The parsing unit 30 executes the judgment logic. For example, the parsing unit 30 calls the conversion rule from the rule library 10 to judge whether the extension component 11 is compatible with the current version resource object 121. If so, jump to execute Step 714). If not, jump to execute Step 715).

[0138] Step 714) Respond to this access request;

[0139] Step 715) The parsing unit 30 feeds back the parsing result to the result exposure unit 40, and the result exposure unit 40 classifies and exposes the detection result. After this step, jump to execute the process of actively triggering and modifying the property value of the resource access object as Figure 13 shown.

[0140] Refer Figure 13 as shown, actively triggering and modifying the property value of the resource access object includes the following steps.

[0141] Step 720) Pre-configure the conversion rules in the rule library 10. It should be noted that Step 720) can be omitted. And if the conversion rules need to be pre-configured in advance, then the operation of actively triggering and modifying the property value of the resource access object starts from Step 721). The pre-configured conversion rules can be implemented by the administrator injecting a pre-configured file in xml format or JSON format that reflects the conversion rules into the rule library 10 through the API service 60. The pre-configured file can be in xml format or JSON format for the subsequent parsing tasks executed by the parsing unit 30 and the conversion processing of the resource object version executed by the conversion unit 20 to update the resource object.

[0142] Step 721) The request execution engine 50 triggers the conversion of the current version resource object 121 that is incompatible with the access request.

[0143] Step 722) Execution engine 50 forwards the current version resource object 121 conversion request to conversion unit 20.

[0144] Step 723) The conversion unit 20 pulls conversion rules from the rule base 10 and obtains incompatible current version resource objects 121 from the resource access component 12, so as to perform conversion on the incompatible current version resource objects 121 according to the conversion rules.

[0145] Step 724) Update the current version resource object in resource access component 12 with the converted current version resource object.

[0146] Step 725) The conversion result of the current version resource object is sent to the execution engine 50, and the execution engine 50 forwards it to the result exposure unit 40.

[0147] Step 726) The parsing unit 30 feeds back the parsing results to the result exposure unit 40, and the result exposure unit 40 classifies the detection results and exposes them.

[0148] At the same time, participants Figure 2 , Figure 3 As shown, the resource object scheduling system also includes an ETCD component 13 deployed on the master node 1 or logically independent of the master node 1. The ETCD component 13 is an open-source distributed unified key-value storage database used for shared configuration, service discovery and scheduling coordination of distributed systems or computer clusters. In this application, it can also be used to store record files formed during the update process of resource objects or the metadata corresponding to the resources.

[0149] For example, the reference Figure 2 As shown, several addon components can be deployed in extension component 11, for example, addon components 11a to 11z; or refer to... Figure 4 As shown, extension component 11 may also include at least one addon component (e.g., addon component 11a) and at least one LCM component (e.g., LCM component 11b) simultaneously deployed on worker node 2; or refer to Figure 5 As shown, the extension component 11 may also include multiple addon components 11a deployed on worker node 2 and multiple LCM components 11b deployed on worker node 3, or the extension component 11 may be deployed directly on master node 1.

[0150] The rule base 10 stores transformation rules, which include the association between the same extended component 11 before and after modification and the resource object based on the Backend field and / or API version information.

[0151] The resource object detection system 14 also includes: a result exposure unit 40, an execution engine 50, an API service 60, and a detection result collection component 80; the API service 60 performs operations to modify the attribute values ​​of the extension component 11, wherein the operation to modify the attribute values ​​of the extension component 11 is initiated and executed directly to the extension component 11 by the administrator through the API service 60, or the parsing unit 30 initiates and executes the operation to modify the attribute values ​​of the extension component 11; the configuration file includes a JSON file, a YAML file, or an XML file.

[0152] Upon receiving a new access request, the self-detection result collection component 80 calls the detection results generated in response to the previous access request. The result exposure unit 40 exposes the detection results to the outside world under the control of the execution engine. The result exposure unit 40 classifies the detection results in the form of evaluation indicators, events or logs, and saves them to the corresponding detection result collection component 80 deployed in the backend storage 8. The detection result collection component 80 includes a monitor 401, an event collector 402 or a log recorder 403.

[0153] Combination Figure 13 and Figure 9 As shown, in this application, the passive triggering of the Webhook and the exposure of the results by the result exposure unit 40 after classification are specifically implemented by the parsing and classification logic contained in the parsing unit 30. Specifically, the parsing unit 30 includes a filtering unit 301 and a decision unit 302. The filtering unit 301 performs filtering on the identification information contained in the access request extracted from the access request; the decision unit 301 calls the transformation rules from the rule base 10 to extract the current version resource object that is incompatible with the access request; wherein, the identification information includes one or a combination of the following: the subject information carried by the access request (e.g., username), the IP of the subject initiating the access request (e.g., the IP of the client where the user initiating the access request is located), the token (e.g., the token carried by the access request), or the access type information (e.g., GET request, POST request, PUT request, or DELETE request). By authenticating the identification information, it is ensured that access requests initiated by other users (e.g., illegal users) that are unrelated to or have no authority over this access request are prevented from competing for the same resource object in an unordered manner. The filtering module 30 mainly filters resource objects, filtering out resource types that do not need to be considered, thereby effectively reducing the number of access requests.

[0154] Based on the aforementioned specific implementation methods, this application also discloses a computer cluster.

[0155] A computer cluster includes: a master node 1, and at least one worker node managed by the master node 1 (e.g., Figure 4 Working node 2 or Figure 5 The computer cluster is deployed as a resource object scheduling system as disclosed in any specific implementation. The extension component 11 is deployed on master node 1 and / or any one of the worker nodes (e.g., worker node 2 or worker node 3); the computer cluster is a Kubernetes cluster.

[0156] The computer cluster also includes: a backend storage 8 for deploying the detection result collection component 80; the result exposure unit 40 exposes the status information generated during the transformation of the current version resource object based on the transformation rules to the outside world under the control of the execution engine 50, so that the detection results are classified in the form of evaluation metrics 41 (e.g., Metrics), events 42 (e.g., Kubernetes events), or logs 43 (e.g., logs), and saved to the corresponding detection result collection component 80 deployed in the backend storage 8 respectively; wherein, the detection result collection component 80 includes a monitor 401 (e.g., Prometheus), an event collector 402, or a logger 403, and the aforementioned monitor 402, event collector 402, and logger 403 are all subordinate concepts of the detection result collection component 80. The external exposure of detection results is to allow administrators to log in to the master node 1 to view the monitoring results of the system response to users' scheduling of system resource objects. For example, the evaluation metric 41 supports open-source system monitoring and alarm systems such as Prometheus. Meanwhile, evaluation metrics 41, events 42, and logs 43 can all be written to and saved to the ETCD component 13 after each access request has completed the scheduling of the resource object.

[0157] Exemplarily, as an optional implementation, the reference Figure 6 As shown, the resource object detection system 14, the extension component 11, and the resource access component 12 can all be deployed on the master node 1. Alternatively, as an example, as another optional implementation, refer to... Figure 5 As shown, the resource object detection system 14 and resource access component 12 can both be deployed on the master node 1, while the extension component 11 can be distributed and deployed on worker nodes 2 and 3. Each worker node deploys the same type of extension component 11. For example, in Figure 5 In this configuration, worker node 2 deploys one or more addon components 11a, and worker node 3 deploys one or more LCM components 11b. Access requests initiated by the system from addon components 11a and LCM components 11b are forwarded to resource access components 12 located on master node 1. This simplifies the deployment of extension components 11 on each worker node, facilitates the deployment of the corresponding number of extension components 11 in a single worker node according to actual needs, and simplifies the subsequent management of extension components 11.

[0158] The expansion component 11 includes at least one addon component 11a and / or at least one LCM component 11b; the addon component and / or the LCM component are deployed in the form of a plugin or a script. The backend storage 8 includes a distributed storage system, a disk array, a removable electronic storage device, or cloud storage.

[0159] See Figure 14 As shown, based on the inventive concept embodied in the resource object scheduling method, resource object scheduling system, or computer cluster disclosed in the foregoing specific embodiments, the present application also discloses a computer-readable medium 900. When computer program instructions 901 stored in the computer-readable medium 900 are read and executed by a processor 902, the steps in a resource object scheduling method disclosed in any of the above specific embodiments are executed. The processor 902 includes a CPU, a GPU, a DSP, an FPGA, or a vCPU. Optionally, the computer-readable medium 900 can be configured as a server, and the server runs on a physical device for building a private cloud, a hybrid cloud, or a public cloud. At the same time, for the same technical means or implementation processes respectively included in this embodiment and the foregoing embodiments, reference can be made to the foregoing description, and details will not be repeated herein.

[0160] The series of detailed descriptions listed above are only specific descriptions of the feasible implementation manners of the present invention, and they are not intended to limit the protection scope of the present invention. Any equivalent implementation manners or modifications made without departing from the technical spirit of the present invention should be included in the protection scope of the present invention.

[0161] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and the present invention can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention. Therefore, from any perspective, the embodiments should be regarded as exemplary and non-restrictive. The scope of the present invention is defined by the appended claims rather than the above description. Therefore, all changes falling within the meaning and scope of the equivalent elements of the claims are intended to be included in the present invention. Any reference signs in the claims should not be regarded as limiting the claimed rights.

[0162] In addition, it should be understood that although this specification is described according to embodiments, not every embodiment only includes an independent technical solution. This narrative manner of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A resource object scheduling method for scheduling resource objects in a system. Its features are, include: The extended component receives a user's access request for a specified resource object and searches the system for the compatibility between the current version resource object corresponding to the access request and the specified resource object. If the current version resource object is incompatible with the specified resource object, the conversion rule is invoked to perform a conversion on the current version resource object according to the conversion rule, so as to convert the current version resource object associated with the access request into a resource object compatible with the current version resource object; Update the current version resource object associated with the access request in the resource access component, and modify the attribute values ​​of the extended component to update the extended component; The extended component includes at least one addon component and / or at least one LCM component; The addon component and / or LCM component are deployed only on multiple worker nodes, and the addon component and / or LCM component are deployed in the form of plugins or scripts.

2. The resource object scheduling method according to claim 1, characterized in that, Also includes: The system loads the conversion rules formed between current version resource objects of different system versions and saves the conversion rules to the rule base. When a user initiates an access request, the system calls the conversion rules from the rule base in a loop according to the user's namespace to determine the compatibility between the extended component and the current version resource object corresponding to the access request. When the extended component is incompatible with the current version resource object corresponding to the access request, the system calls the conversion rules to convert the current version resource object.

3. The resource object scheduling method according to claim 2, characterized in that, Also includes: The status information generated during the transformation of the current version resource object based on the transformation rules is exposed to the outside under the control of the execution engine. After the detection results are classified, the classified detection results are saved to the corresponding detection result collection components in the backend storage.

4. The resource object scheduling method according to claim 2, characterized in that, The access request includes the resource object type, resource object version, and the requesting body information that initiated the access request; The operation of retrieving the current version resource object of the system is performed by the API service.

5. The resource object scheduling method according to claim 3, characterized in that, The status information is categorized through evaluation metrics, events, or logs, and is stored in the corresponding detection result collection components deployed in the backend storage. The detection result collection components include monitors, event collectors, or log recorders.

6. The resource object scheduling method according to claim 5, characterized in that, Also includes: Upon receiving a new access request, the detection result collection component invokes the detection results generated in response to the previous access request to perform updates only on the current version of resource objects in the resource access component that are incompatible with the new access request.

7. The resource object scheduling method according to claim 2, characterized in that, Also includes: Filtering is performed on the identification information contained in the access request extracted from the access request; The access request is processed by calling transformation rules from the rule base to extract the current version resource object that is incompatible with the access request; The identification information includes one or a combination of several of the following: subject information carried in the access request, the IP address of the subject initiating the access request, a token, or access type information.

8. The resource object scheduling method according to claim 2, characterized in that, The modification of the extended component's attribute values ​​includes: Modify the Backend field and API version information contained in the configuration file describing the current version resource object to save the conversion rules formed between the modified extended component and the current version resource object to the rule base. The conversion rules include the association relationship between the same extended component and the current version resource object before and after the modification based on the Backend field and / or API version information.

9. The resource object scheduling method according to claim 2, characterized in that, Also includes: Perform pre-checks on the current version resource object associated with the access request, the pre-checks including: The current version of the resource object in the resource access component is compared with the conversion rules stored in the rule base, and the extended components corresponding to the current version of the resource object that is incompatible with the current system version are extracted. Modify the property values ​​of the extended components corresponding to the resource objects that are incompatible with the current system version.

10. The resource object scheduling method according to claim 9, characterized in that, The pre-detection mechanism passively triggers a Webhook request when the system receives an access request initiated by a user. It determines whether the extended component can access the current version resource object associated with the extended component to decide whether the current version resource object associated with the extended component needs to be updated. If the extended component cannot access the current version resource object associated with the extended component, it modifies the attribute value of the extended component to update the extended component.

11. The resource object scheduling method according to claim 10, characterized in that, Modifying the property values ​​of extended components is initiated and executed directly by the administrator through the API service, using a configuration file. or, The parsing unit initiates and executes the request to the extended component; The configuration file can be a JSON file, a YAML file, or an XML file.

12. The resource object scheduling method according to claim 9, characterized in that, Also includes: Determine whether the extended component can access the current version of the resource object associated with the extended component. If not, under the control of the execution engine, the detection results are exposed to trigger the administrator or parsing unit to perform transformation on the current version resource object in the resource access component by calling the transformation rules of the rule base, so as to form the current version resource object and perform the operation of modifying the attribute values ​​of the extended component; If so, the current version resource object is directly used as the designated resource object to respond to the user's access request.

13. The resource object scheduling method according to claim 2, characterized in that, The system is a Kubernetes cluster, which includes a master node and at least one worker node managed by the master node. The extended components are deployed on the master node and / or any one of the worker nodes.

14. The resource object scheduling method according to claim 2, characterized in that, The conversion rules stored in the rule base are defined through a message structure, which is jointly described by system API version information, type, metadata, description information, obsolete resource object API version information, and obsolete resource object API version operation strategy.

15. A resource object scheduling system, characterized in that, include: Extended components, resource access components, and resource object detection system; The resource object detection system includes: a rule base, a conversion unit, a parsing unit, and an API service; The extended component receives user access requests for specified resource objects; The parsing unit retrieves the current version resource object in the system and calls the conversion rules from the rule base to perform conversion on the current version resource object according to the conversion rules; The conversion unit converts the current version resource object associated with the access request into a resource object compatible with the current version resource object, updates the resource object associated with the access request in the resource access component, and modifies the attribute values ​​of the extension component to update the extension component. The extended component includes at least one addon component and / or at least one LCM component; The addon components and / or LCM components are deployed in the form of plugins or scripts.

16. The resource object scheduling system according to claim 15, characterized in that, The rule base stores conversion rules, wherein the conversion rules include the association between the same extended component before and after modification and the resource object based on the Backend field and / or API version information.

17. The resource object scheduling system according to claim 15, characterized in that, The resource object detection system also includes: Results exposure unit, execution engine, API service, and test result collection component; The API service performs the operation to modify the attribute values ​​of the extended component. This modification is initiated and executed directly by the administrator through the API service, using a configuration file. or, The parsing unit initiates and executes operations on the property values ​​of the extended component; The configuration file can be a JSON file, a YAML file, or an XML file.

18. The resource object scheduling system according to claim 17, characterized in that, Upon receiving a new access request, the detection result collection component invokes the detection result generated in response to the previous access request. Under the control of the execution engine, the result exposure unit exposes the detection result to the outside world. The result exposure unit classifies the detection result in the form of evaluation indicators, events, or logs, and saves them to the corresponding detection result collection component deployed in the backend storage. The detection result collection component includes a monitor, an event collector, or a log recorder.

19. The resource object scheduling system according to claim 15, characterized in that, The analysis unit includes: a filtering unit and a decision unit; The filtering unit performs filtering on the identification information contained in the access request extracted from the access request; The decision-making unit calls the transformation rules from the rule base to extract the current version resource object that is incompatible with the access request; The identification information includes one or a combination of several of the following: subject information carried in the access request, the IP address of the subject initiating the access request, a token, or access type information.

20. A computer cluster, characterized in that, include: Master node, at least one working node managed by the master node; The computer cluster is deployed with the resource object scheduling system as described in claim 17 or 18; The extended components are deployed on the master node and / or any one of the worker nodes; The computer cluster is a Kubernetes cluster; The extended component includes at least one addon component and / or at least one LCM component; The addon components and / or LCM components are deployed in the form of plugins or scripts.

21. The computer cluster according to claim 20, characterized in that, The computer cluster also includes: backend storage for deploying the test result collection components; The result exposure unit exposes the status information generated during the conversion of the current version resource object based on the conversion rules to the outside world under the control of the execution engine. The detection results are then classified in the form of evaluation indicators, events or logs and saved to the corresponding detection result collection components deployed in the backend storage. The detection result collection component includes a monitor, an event collector, or a logger.

22. The computer cluster according to claim 20, characterized in that, The resource object detection system, the extended component, and the resource access component are all deployed on the master node. or, The resource object detection system and the resource access component are both deployed on the master node, while the extended components are distributed across multiple worker nodes.

23. The computer cluster according to claim 21, characterized in that, The backend storage includes distributed storage systems, disk arrays, portable electronic storage devices, or cloud storage.

24. A computer-readable medium, characterized in that, The computer-readable medium stores computer program instructions, which, when read and executed by a processor, perform the steps of the resource object scheduling method as described in any one of claims 1 to 14. The processor includes a CPU, GPU, DSP, FPGA, or vCPU.

Images