Resource deployment management method and system

Abstract

The invention discloses a resource deployment management method and system, and the method comprises the steps: obtaining a resource deployment request submitted by a user, and the resource deployment request comprises configuration data; calling an access controller to perform global verification on the resource deployment request; if the resource deployment request passes the global verification, generating a deployment instruction based on the configuration data; a deployment instruction is sent to the resource deployment platform, so that the resource deployment platform deploys a corresponding operation unit, and the operation unit is injected into the auxiliary container meeting the requirement condition of the configuration data. According to the scheme, all the resource deployment requests are uniformly managed through the access controller, the corresponding deployment instructions can be generated for deployment only after the resource deployment requests pass the global verification, and compared with a traditional scheme, the number of access control assemblies in the system is remarkably reduced, and the resource deployment efficiency is improved. And meanwhile, the global verification can avoid the problem of resource deployment conflict possibly caused by separate realization of different functions in the traditional scheme.

Description

TECHNICAL FIELD

[0001] The present application relates to resource deployment technology, and more particularly, to a resource deployment management method and system. BACKGROUND

[0002] In a Kubernetes (K8s) environment, a PaaS platform usually needs to inject multiple Sidecar containers for a workload (such as a Pod) to support functions such as security, log collection, and call tracking.

[0003] A traditional Sidecar injection method uses independent Webhook injection, that is, a Mutating Admission Webhook is implemented for each function (such as log and security). This method causes the K8s cluster to need to maintain multiple Webhook controllers, increasing the cost and management complexity. SUMMARY

[0004] Therefore, the present application provides the following technical solutions:

[0005] The first aspect of the present application provides a resource deployment management method, comprising:

[0006] obtaining a resource deployment request submitted by a user, wherein the resource deployment request includes configuration data;

[0007] calling an admission controller to perform global verification on the resource deployment request, wherein the global verification includes verification of the implementation logic of the resource deployment request and cross-verification with an existing deployment;

[0008] if the resource deployment request passes the global verification, generating a deployment instruction based on the configuration data;

[0009] sending the deployment instruction to a resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, wherein the running unit has injected an auxiliary container that meets the requirement conditions of the configuration data.

[0010] In one possible implementation, the calling of the admission controller to perform global verification on the resource deployment request comprises:

[0011] filtering the resource deployment request based on basic condition data of the resource deployment platform to determine a resource deployment request that meets the basic condition data, wherein the basic condition data is used to ensure that the processed resource deployment request is a resource deployment request that is executable on the current platform;

[0012] extracting resource configuration data from the resource deployment request that meets the basic condition data;

[0013] checking whether the resource configuration data meets rule requirements;

[0014] checking whether the resource configuration data conflicts with existing deployments.

[0015] In one possible implementation, the checking whether the configuration data of the resource deployment request meets rule requirements comprises:

[0016] the field checking based on the configuration data comprises: determining whether the configuration parameters in the configuration data conform to regular rules; the resource quota total checking based on the configuration data comprises: whether the total resource requests of multiple auxiliary containers exceed the configured total resource amount;

[0017] the dependency relationship checking based on the configuration data comprises: whether there is a dependency between auxiliary containers but the related configuration cannot complete the dependency implementation.

[0018] In one possible implementation, the checking whether the configuration data of the resource deployment request conflicts with existing deployments comprises:

[0019] the port conflict checking based on the configuration data comprises: whether auxiliary containers of different functions attempt to bind to the same port;

[0020] the storage volume mounting conflict checking based on the configuration data comprises: whether multiple auxiliary containers attempt to mount the same host path.

[0021] In one possible implementation, the method further comprises:

[0022] if the global checking fails, determining the failure cause and the corresponding correction method;

[0023] if the correction method does not require modifying the running program, adjusting the configuration data so that the resource deployment request passes the global checking;

[0024] if the correction method requires modifying the running program, returning the failure cause carrying the correction method, so that the user side adjusts the resource deployment request based on the correction method;

[0025] the failure cause and the correction suggestion are determined based on the checking items and the checking logic of the global checking.

[0026] In one possible implementation, the configuration data in the resource deployment request is determined by a user based on an interactive page that only exposes configurable fields.

[0027] The interactive page that only exposes configurable fields refers to the interactive page in which only optional function items and corresponding parameter filling items are exposed.

[0028] In a possible implementation, the deployment instruction is generated based on the configuration data, including:

[0029] An auxiliary container image version currently used by the resource deployment platform is obtained, and the user is prohibited from overriding;

[0030] The configuration data is converted into a configuration field of an auxiliary container to be injected;

[0031] A threshold parameter of the auxiliary container to be injected is determined according to the performance configuration of the running unit, and the threshold parameter at least includes a minimum resource parameter required for starting the auxiliary container to be injected and a maximum resource parameter allowed to be used;

[0032] Configuration content in a target configuration language is obtained based at least on the auxiliary container image version, the configuration field and the threshold parameter, and the target configuration language is a configuration language supported by the resource deployment platform.

[0033] In a possible implementation, the deployment instruction is sent to the resource deployment platform, including:

[0034] The deployment instruction is submitted through an interface service of the resource deployment platform, so that the extension of a function corresponding to the resource deployment request is realized without updating a version of the resource deployment platform.

[0035] In a possible implementation, wherein:

[0036] The image version of the auxiliary container is uniformly managed by the resource deployment platform, including that the upgrade of the image version of the auxiliary container is controlled and implemented by the resource deployment platform;

[0037] The image version of the auxiliary container is invisible to the user, after the user submits the resource deployment request, the resource deployment platform performs a deployment operation based on the resource deployment request submitted by the user, and determines the latest deployed image version as the latest image version after the deployment is completed.

[0038] The second aspect of the present application provides a resource deployment management system, including:

[0039] A request obtaining module is configured to obtain a resource deployment request submitted by a user, and the resource deployment request includes configuration data;

[0040] A global verification module is configured to call an admission controller to perform global verification on the resource deployment request, and the global verification includes verification on implementation logic of the resource deployment request and cross-verification with a current existing deployment;

[0041] generate a deployment instruction based on the configuration data if the resource deployment request passes the global check;

[0042] send the deployment instruction to the resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, the running unit having injected an auxiliary container meeting a requirement condition of the configuration data.

[0043] According to the above technical solution, the embodiment of the present application discloses a resource deployment management method and system, including: obtaining a resource deployment request submitted by a user, the resource deployment request including configuration data; calling an admission controller to perform global check on the resource deployment request, the global check including check on implementation logic of the resource deployment request and cross check with current existing deployment; generating a deployment instruction based on the configuration data if the resource deployment request passes the global check; sending the deployment instruction to the resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, the running unit having injected an auxiliary container meeting a requirement condition of the configuration data. The above solution uniformly manages all resource deployment requests through the admission controller, performs global check on the resource deployment request, and only after passing the global check, a corresponding deployment instruction can be generated for deployment. Compared with the traditional solution in which different functions need to be respectively matched with corresponding controllers, the present solution significantly reduces the number of admission control components in the system, reduces the operation and maintenance complexity, and the global check can avoid the deployment resource conflict problem that may exist in the traditional solution in which different functions are respectively implemented. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only embodiments of the present application, and those skilled in the art can obtain other drawings according to the provided drawings without creative labor.

[0045] Figure 1 Flowchart of a resource deployment management method disclosed by the embodiment of the present application;

[0046] Figure 2 Flowchart of global check on a resource deployment request disclosed by the embodiment of the present application;

[0047] Figure 3 Flowchart of generating a deployment instruction disclosed by the embodiment of the present application;

[0048] Figure 4 Implementation flowchart of a unified Sidecar injection system disclosed by the embodiment of the present application;

[0049] Figure 5 A structural schematic diagram of a resource deployment management system disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0050] For the sake of citation and clarity, the following technical terms used in the specification, abbreviations or acronyms are summarized as follows:

[0051] Kubernetes: also known as K8s, Kubernetes is an open source container orchestration engine developed by Google, which supports automated deployment, large-scale scalability and application container management.

[0052] PaaS platform: the abbreviation of Platform as a Service, which means platform as a service. PaaS platform is one of the three service modes of cloud computing, which provides a complete cloud platform for users to develop, run and manage applications without managing the underlying infrastructure.

[0053] Pod: Pod is the smallest deployable and manageable unit in Kubernetes, which is composed of one or more containers sharing storage and network resources, representing a process running in the cluster.

[0054] Webhook: network hook.

[0055] Mutating Admission Webhook: the Chinese translation is‌Modifying Admission Webhook‌, which is a native webhook inside K8s that can be used to modify the configuration. It can change the environment after the container is started, configure, etc., and finally achieve some functions other than the original expected functions of the main container, such as security-related configuration, log collection configuration, injection of environment variables, injection of storage volumes, etc.

[0056] Sidecar container: Sidecar container is a side container in container orchestration that shares resources (such as network and storage) with the main container, and is usually used to provide functions such as log collection, monitoring, service agent, etc.

[0057] admission controller: admission controller.

[0058] CDR, the abbreviation of Custom Resource Definition, is a mechanism used by Kubernetes to extend the native API, allowing users to create and manage non-standard resource types.

[0059] YAML: YAML Ain't Markup Language, a data-centric serialization format, aims to provide a human-readable syntax structure while supporting complex data types (such as nested maps, lists, and mixed types). YAML is the configuration language supported by k8s, which contains all the configurations that users ultimately expect when deploying applications.

[0060] The technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor belong to the scope of protection of the present application.

[0061] Figure 1 A flowchart of a resource deployment management method disclosed in an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the resource deployment management method can include the following steps. Figure 1

[0062] Step 101: Obtain a resource deployment request submitted by a user, wherein the resource deployment request includes configuration data.

[0063] The resource deployment request can be a resource deployment request corresponding to a certain function, such as a log collection function, a monitoring function, a call tracking function, etc. The configuration data in the resource deployment request includes various types of configuration data, such as configuration data of a Pod to be built, configuration data of a Sidecar container to be injected, configuration data of an existing container of an application that applies to build a Pod, etc. In subsequent implementations, different configuration data has different functions, which will be described later.

[0064] Step 102: Call an admission controller to globally verify the resource deployment request, wherein the global verification includes verification of the implementation logic of the resource deployment request and cross-verification with the existing deployment.

[0065] The present application can be applied to cloud middleware, and can also be applied to cloud computing service platforms (such as PaaS platforms), container orchestration engine management platforms (such as k8s platforms), etc. In the implementation of the present application, all resource deployment requests submitted by users are intercepted by a unique admission controller in the system and are uniformly managed. That is, the single admission controller acts as a "gateway" for auxiliary container injection management, and can implement the logic of all auxiliary container injections.

[0066] ​The unique admission controller can realize that the number of injected auxiliary containers is not limited, and the types can also be different, such as auxiliary containers of injection log function class, security class auxiliary containers, monitoring class auxiliary containers, etc. The auxiliary container described herein can be a Sidecar container.

[0067] If the resource deployment request is legal and compliant, a Pod, that is, a running unit, is usually constructed based on the resource deployment request, and the required Sidecar container, that is, the auxiliary container, is injected in the Pod. After the auxiliary container deployment injection is successful, the corresponding Pod can realize the function corresponding to the configuration data.

[0068] The resource deployment request is globally checked, including checking the configuration data therein. The checking operation is used to determine whether the configuration data in the configuration data meets the rule requirements and whether there is a resource conflict with the existing deployment. If the global check passes, a deployment instruction that can be recognized by the resource deployment platform and contains the configuration data is generated based on the configuration data. The specific checking implementation will be described in detail in the embodiments below, and will not be described too much here. In the traditional implementation, each function needs to be independently deployed with a Webhook. The Webhook only checks the implementation logic of the function corresponding to itself and does not consider other functions. The implementation logic of the function corresponding to itself may be correct, but the configuration item of the Webhook of the other function is modified, causing subsequent errors. For example, storage area 1 is originally allocated to function 1, and then function 2 also wants to use storage area 1. The two Webhooks independently check the functions corresponding to themselves and are not problematic, but they will cause subsequent data overlap and data disorder problems, affecting the use of the function.

[0069] Step 103: If the resource deployment request passes the global check, a deployment instruction is generated based on the configuration data.

[0070] In this application, after obtaining the resource deployment request, the related processing of generating the deployment instruction is not directly performed, but the configuration data in the resource deployment request is first globally checked. Only when the global check passes, it is ensured that the configuration data meets the related rule requirements and will not cause a resource conflict with the existing deployment, so as to ensure the normal implementation of the subsequent related function, and then the operation of generating the deployment instruction is performed.

[0071] Step 104: The deployment instruction is sent to the resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, and the running unit has injected an auxiliary container that meets the requirement condition of the configuration data.

[0072] After obtaining the deployment instruction, the deployment instruction is sent to a resource deployment platform. Since the execution subject of the scheme, such as a cloud middleware, has implemented the injection logic of the Sidecar container, the Sidecar container injection request or the Pod creation request that meets the condition can be obtained based on the set condition and requirement. Therefore, the resource deployment platform can no longer perform other identification or judgment logic after receiving the deployment instruction, and directly executes the deployment instruction to implement the deployment work corresponding to the resource deployment request, to obtain a newly created Pod, and the Sidecar container is injected into the Pod, that is, the configuration data and the auxiliary container to be injected are met.

[0073] In the traditional scheme, multiple auxiliary containers need multiple Mutating Admission Webhook to respectively correspond to the injection management of the Sidecar container, so that the number of Webhook components in the system is too large. The scheme can implement a single Webhook (corresponding to an admission controller) and a multi-Sidecar injection mechanism. Specifically, a single Webhook (admission controller) supports multiple Sidecar container injections through plug-in design. The plug-in design makes different types of Sidecar containers can be turned off or turned on, and the k8s function can be extended without changing the main version of the container orchestration engine platform (k8s).

[0074] The resource deployment management method described in the embodiment only deploys a single admission controller to manage all resource deployment requests, that is, to manage the injection logic of all auxiliary containers. The scheme supports dynamic plug-in architecture and allows the platform system to load different Sidecar injection rules on demand. This implementation significantly reduces the number of admission control components in the system, reduces the operation and maintenance complexity, and improves the system control ability. In addition, global verification can avoid the deployment resource conflict that may exist in the traditional scheme of different functions being implemented separately, and ensure that each function on the platform can be normally implemented after the resource deployment is completed.

[0075] Figure 2 The embodiment of the application discloses a flowchart for globally verifying a resource deployment request. As shown in Figure 2 The calling of the admission controller to globally verify the resource deployment request can include:

[0076] Step 201: Filtering the resource deployment request based on the basic condition data of the resource deployment platform to determine the resource deployment request that meets the basic condition data.

[0077] The basic condition data is used to ensure that the processed resource deployment request is a resource deployment request that is executable on the current platform. Specifically, considering that the entire resource deployment platform can include multiple Pods, the types or functions of these Pods are different, some types of Pods allow users to inject Sidecar containers, and some types of Pods do not allow users to inject Sidecar containers. Therefore, after obtaining the resource deployment request, it can be first judged whether the resource deployment request meets the set condition, and only in the case of meeting the condition, the subsequent processing logic will be performed, if it does not meet the condition, the resource deployment request can be directly rejected, and the corresponding prompt information is returned.

[0078] In one implementation, the resource deployment request meeting the set condition can include that the type of the running unit applied to be created by the resource deployment request belongs to a running unit type that allows injection of a Sidecar container.

[0079] For example, for platform management type Pods, users are not allowed to inject Sidecar containers, and for extended function type Pods, users are allowed to inject Sidecar containers; therefore, when the type of the Pod applied to be created by the resource deployment request is a platform management type Pod, it is considered that the resource deployment request does not meet the set condition, and the resource deployment request is not responded or discarded, and only when the type of the Pod applied to be created by the resource deployment request is a Pod that allows injection of a Sidecar container, it is considered that the resource deployment request meets the set condition.

[0080] Step 202: Extract resource configuration data from the resource deployment request meeting the basic condition data.

[0081] Step 203: Verify whether the resource configuration data meets the rule requirement.

[0082] Specifically, verifying whether the resource configuration data meets the rule requirement can include, but is not limited to, the following aspects: performing field verification based on the configuration data, including: determining whether the configuration parameters in the configuration data meet the regular rules, thereby the system performs strong verification (such as regular matching, enumeration value limitation) on the input fields in the configuration data to prevent incorrect configuration; performing resource quota total amount verification based on the configuration data, including: whether the total amount of resource requests of multiple auxiliary containers exceeds the configured total amount of resources; performing dependency relationship verification based on the configuration data, including: whether there is a dependency between auxiliary containers but the related configuration cannot complete the dependency implementation.

[0083] Step 204: Verify whether the resource configuration data has a resource conflict with an existing deployment.

[0084] Specifically, it can include but is not limited to the following aspects: based on the configuration data, the port conflict checking includes: whether different functions of the auxiliary container attempt to bind at the same port; based on the configuration data, the storage volume mounting conflict checking includes: whether multiple auxiliary containers attempt to mount the same host path.

[0085] The execution order of steps 203 and 204 is not fixed, and they can be executed simultaneously or sequentially.

[0086] Specifically, in the verification scenario, platform joint verification can be performed to prevent incorrect configuration, and the user is prompted to modify before sending the deployment instruction. Among them:

[0087] For port conflict checking, since the port in the Pod is unique, if the port has been used by the sidecar container, other sidecar containers will use it, and the program will report an error when starting, so only one sidecar container can use one port. For example: the security Sidecar (such as Istio Proxy) occupies 15090 (Prometheus indicator port) by default, and the monitoring Sidecar (such as custom indicator collector) also attempts to bind 15090.

[0088] For resource quota total amount checking, the corresponding scenario is that the total resource request of multiple Sidecars exceeds the Pod limit, such as the log Sidecar applying for 0.5 core CPU + 512MiB memory; the security Sidecar applying for 1 core CPU + 1GiB memory; and the total limit of the Pod is only 1 core CPU.

[0089] For dependency relationship checking, the corresponding scenario is that there is a dependency between Sidecars but the configuration is contradictory, such as the call chain tracking Sidecar (such as Jaeger) depending on the mTLS (Mutual Transport Layer Security. Two-way Transport Layer Security) function of the security Sidecar (Istio); and the user has turned off the mTLS configuration of the security Sidecar.

[0090] For storage volume mounting conflict checking, the corresponding scenario is that multiple Sidecars attempt to mount the same host path. Different Sidecars attempt to mount the same host path, and the volume mounted behind will overwrite the content mounted in front, causing some content to be invisible or some content to be overwritten. The sidecar container will fail to start or the written content will pollute the original content and cause the running to go wrong. For example, the log Sidecar mounts / var / log to the container / logs; the audit Sidecar also attempts to mount / var / log to / audit-logs.

[0091] After any of the above verification operations fails, corresponding failure information can be returned to prompt the user, the failure information including failure causes and correction suggestions, so as to facilitate the user to make corresponding adjustments and modifications and then reapply for a resource deployment meeting the requirements.

[0092] In the implementation, the configuration data in the resource deployment request is subjected to the verification operation, which can avoid problems such as subsequent Sidecar container (auxiliary container) injection failure or injection function running error caused by some inappropriate configurations in the configuration data, and can return failure information after the verification fails, wherein the correction suggestions carried in the failure information can help the user quickly locate the problem and timely adjust the configuration data.

[0093] In one implementation, the resource deployment management method can further include: if the global verification fails, determining failure causes and a corresponding correction method; if the correction method does not need to modify the running program, adjusting the configuration data to make the resource deployment request pass the global verification; if the correction method needs to modify the running program, returning failure causes with the correction method to make the user side adjust the resource deployment request based on the correction method; and the failure causes and correction suggestions are determined based on the verification items and verification logic of the global verification.

[0094] For example, the global verification fails, there is a port conflict problem, and the port A required to be bound by the current resource deployment request has been bound by other auxiliary containers, and then the platform can automatically configure another port, such as port B, for the resource deployment request to avoid that the A port already used by other auxiliary containers is allocated to other auxiliary containers again.

[0095] For another example, the global verification fails, and there is a situation that the dependency relationship verification cannot be implemented, such as the implementation of function A corresponding to the current resource deployment request needs the execution result of function B, but the platform does not have or does not enable function B, and then the current resource deployment request cannot implement function A even if it is deployed. The implementation of function B needs to modify the running program, and in this case, the platform cannot solve the problem, and then needs to return failure causes with correction methods, such as function A needs to be implemented based on function B, and it is suggested that the user deploys function B first.

[0096] After the global verification fails, the embodiments of the present application can handle the failure causes respectively, for the failure problems that can be solved by the platform, the configuration data is automatically adjusted to ensure the success of the resource deployment, and for the failure problems that cannot be solved by the platform, the failure causes and correction methods are returned to the user to facilitate the user to make corrections based on the correction methods.

[0097] In one implementation, the configuration data in the resource deployment request is determined based on an interactive page with only configurable fields exposed for user input. The interactive page with only configurable fields exposed refers to the interactive page with only optional function items and corresponding parameter filling items. The interactive page with only configurable fields exposed can be a UI form, a CDR page, etc. The UI form is a visual interface with tables, and can be implemented on a platform web.

[0098] The configuration language that can be recognized or supported by the resource deployment platform is fixed. Therefore, when applying for resource deployment, the supported configuration language of the resource deployment platform must be submitted to ensure that the resource deployment platform can accurately recognize and execute the corresponding deployment instructions. The configuration language supported by the resource deployment platform is, for example, YAML.

[0099] In one implementation, the configurable fields can be exposed through a UI form or a CRD, and the user does not need to directly write YAML. For example, the user selects a function (such as "security agent") through the form, and the platform automatically generates a compliant YAML to avoid manual filling errors, thereby realizing form-based configuration and strong verification. This implementation has a low user threshold, and the user does not need to master the YAML language. The user only needs to check the desired function and fill in the corresponding parameters, and the rest of the work is automatically completed by the platform.

[0100] Figure 3 A flowchart for generating a deployment instruction is disclosed in the embodiments of the present application. Referring to FIG. 3, Figure 3 As shown in FIG. 3, generating a deployment instruction based on the configuration data can include:

[0101] Step 301: Obtain the current version of the auxiliary container image used by the resource deployment platform, and set it to be prohibited from being overwritten by the user.

[0102] In the implementation of the present application, the version of the auxiliary container image (Sidecar image version) is uniformly managed by the system platform, and the user only needs to select a function (such as "enable log collection") without specifying the version. At the same time, even if the user specifies the desired version of the auxiliary container image in the resource deployment request, since the platform sets the version of the auxiliary container image to prohibit the user from overwriting, the implementation will not be executed according to the version of the auxiliary container image specified by the user, but will use the version of the auxiliary container image currently used by the resource deployment platform. In the implementation, the upgrade of the version of the auxiliary container image is controlled and implemented by the resource deployment platform. The platform can automatically roll over the version of the Sidecar container image through a version controller, and the user has no perception. In this way, the version of the auxiliary container is hidden and automatically upgraded.

[0103] That is, the mirror image version of the auxiliary container is invisible to the user, and after the user submits a resource deployment request, the resource deployment platform performs deployment operations based on the resource deployment request submitted by the user, and determines the latest deployed mirror image version as the latest mirror image version after deployment is completed. The mirror image version of the auxiliary container is uniformly managed by the platform, and is easier to upgrade and maintain.

[0104] Step 302: converting the configuration data into the configuration field of the auxiliary container to be injected.

[0105] Since the configuration language supported by the resource deployment platform is fixed, and the configuration data input by the user carried in the resource deployment request may not be consistent with the configuration language supported by the resource deployment platform, or cannot be accurately recognized by the resource deployment platform, the configuration data needs to be converted into the configuration field of the auxiliary container to be injected, that is, the standard configuration resource that can be recognized by the resource deployment platform.

[0106] Step 303: determining the threshold parameter of the auxiliary container to be injected according to the performance configuration of the running unit.

[0107] The threshold parameter at least includes the minimum resource parameter required for starting the auxiliary container to be injected and the maximum resource parameter allowed to use.

[0108] The running unit is also called a Pod, and the specification of the running unit is determined based on the specification of the existing container resource of the current application. For example, if the current application has 10 containers, the total CPU of the 10 containers is 100 cores, and the maximum CPU resource allowed to use for the auxiliary container to be injected is not more than 10% of the total resource, then the maximum CPU resource allowed to use for the auxiliary container to be injected can be determined as 100x10%=10 cores.

[0109] Step 304: obtaining the configuration content of the target configuration language based on at least the auxiliary container mirror image version, the configuration field and the threshold parameter, the target configuration language being the configuration language supported by the resource deployment platform.

[0110] The above describes the process of generating a deployment instruction, which facilitates better understanding and implementation of the technical solutions of the present application by those skilled in the art.

[0111] In one implementation, the sending of the deployment instruction to the resource deployment platform can include submitting the deployment instruction through the interface service of the resource deployment platform, so as to realize the extension of the function corresponding to the resource deployment request without updating the version of the resource deployment platform. Thus, a dynamic plug-in architecture is realized, allowing the platform to load different Sidecar injection rules (such as logs, security, monitoring) on demand.

[0112] Figure 4 ​The implementation process diagram of the unified Sidecar injection system disclosed in the embodiments of the present application can be combined with Figure 4 The following specific implementation introduction is understood.

[0113] 1. User submits a resource deployment request

[0114] Input method: form submission (UI interface): the user checks the function modules (such as log collection, security agent) and fills in the necessary parameters (such as log storage path, security level).

[0115] 2. Webhook (admission controller) intercepts the request

[0116] Trigger condition: the Kubernetes API Server calls the pre-registered MutatingWebhook (modifiable admission control) when creating / updating a Pod.

[0117] Key operations:

[0118] Request filtering: filter the Pods that need to be injected with Sidecar according to Namespace / Labels / Annotations.

[0119] Context extraction: analyze the resource configuration (CPU / memory / port required for the Pod to run), existing container list, Volume declaration (such as what type of disk, how much disk space, and which path to mount) of the Pod, etc.

[0120] Request forwarding: pass the extracted context to the configuration center for rule matching.

[0121] 3. Query the configuration center rules

[0122] Configuration center data structure:

[0123] json

[0124] {

[0125] "sidecars":{

[0126] "istio-proxy": {

[0127] "image": "istio / proxyv2:1.18",

[0128] "required_ports": [15090, 15020],

[0129] "conflict_checks": ["ports", "env.ENV"]

[0130] },

[0131] "fluent-bit": {

[0132] "image": "fluent / fluent-bit:2.1",

[0133] "volume_mounts": [" / var / log"]

[0134] }

[0135] }

[0136] }

[0137] Validation logic:

[0138] Version control: Automatically select the current platform approved Sidecar image version.

[0139] Field validation: Ensure user input parameters meet regular rules (e.g. log path needs to match ^ / var / log / [a-z0-9_]+$).

[0140] 4、Detect Sidecar resource conflicts

[0141] Conflict detection types:

[0142]

[0143] Dynamic adjustment example:

[0144] Python

[0145] # If the security Sidecar (15090) conflicts with the monitoring Sidecar port

[0146] if conflict_detected(sidecar1.ports, sidecar2.ports):

[0147] sidecar2.ports = find_available_port(pod.spec.ports) # Automatically reassign

[0148] 5、Generate standardized Sidecar configuration

[0149] Configuration generation rules:

[0150] Image version lock: Get the current stable version image from the configuration center (e.g. istio / proxyv2:1.18), prohibit user override.

[0151] Resource quotas: Automatically calculate the Sidecar's default Request (minimum resources required when the container starts) / Limit (maximum resources allowed for the container to use, such as 10% of the total CPU) based on the Pod specification.

[0152] Output example:

[0153] yaml

[0154] - name: istio-proxy

[0155] image: istio / proxyv2:1.18

[0156] ports:

[0157] - containerPort: 15090

[0158] resources:

[0159] requests: {cpu: "0.1", memory: "128Mi"}

[0160] 6. Inject into the Pod and return a response.

[0161] Injection operation:

[0162] Patch (Patch stands for Mutating Admission Webhook, meaning modification) generation: Generates a JSON Patch description of the Sidecar addition / modification operation:

[0163] json [

[0165] { "op": "add", "path": " / spec / containers / -", "value": { / * Sidecar configuration* / }} ]

[0167] Atomic injection: Submitting changes via the Patch interface of the K8s API Server.

[0168] Response handling:

[0169] Success: Returns a 200 status code and the complete YAML of the injected Pod.

[0170] Failure: Returns 4xx / 5xx status codes and structured errors (e.g., {"error": "CPU_LIMIT_EXCEEDED","detail": "Total requests 1.5 cores > Limit 1 core"}).

[0171] 7. Abnormal processing flow (corresponding to Figure 3 the 5th block in the method)

[0172] Typical exceptions and processing:

[0173]

[0174] In summary, the present application can realize the following technical contents:

[0175] Unified admission control webhook: unique entry, replacing traditional multi-webhook solution;

[0176] Sidecar configuration center: centralized management of image version, form field, and verification rule;

[0177] Dynamic injection engine: intelligently handle port / resource conflicts to ensure Pod schedulability;

[0178] Main technical points include:

[0179] Single-webhook multi-sidecar dynamic injection mechanism: traditional solutions require multiple webhooks, and the present application realizes single-webhook support for multiple sidecar injections through plug-in design.

[0180] Formalized configuration and strong verification: users select functions (such as "security agent") through forms, and the platform automatically generates compliant YAML to avoid manual filling errors.

[0181] Sidecar version black box and automatic upgrade: users cannot modify the sidecar image version, and the platform realizes seamless upgrade through version control.

[0182] Conflict detection and optimized scheduling: unified webhook detects resource conflicts (such as port occupation) between sidecars and automatically adjusts injection strategies.

[0183] Technical effects that can be achieved: reduce operation and maintenance costs: reduce the number of webhook components and improve cluster stability; improve user experience: form-based configuration is more user-friendly than manual YAML, reducing errors; enhance platform control: hide the version, and the platform can forcibly update security to avoid vulnerabilities.

[0184] For each method embodiment described above, for the sake of simple description, it is expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0185] The method is described in detail in the embodiments of the present application disclosed above, and the method of the present application can be implemented in various forms of devices, so the present application also discloses a device, and specific embodiments are given below to be described in detail.

[0186] Figure 5 A structural schematic diagram of a resource deployment management system disclosed in an embodiment of the present application is shown in FIG. 1. Figure 5 As shown in FIG. 1, the resource deployment management system 50 can include:

[0187] The request obtaining module 501 is configured to obtain a resource deployment request submitted by a user, wherein the resource deployment request includes configuration data.

[0188] The global verification module 502 is configured to call an admission controller to perform global verification on the resource deployment request, wherein the global verification includes verification of implementation logic of the resource deployment request and cross-verification with existing deployments.

[0189] The instruction generation module 503 is configured to generate a deployment instruction based on the configuration data if the resource deployment request passes the global verification.

[0190] The instruction sending module 504 is configured to send the deployment instruction to the resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, wherein the running unit has injected an auxiliary container meeting the requirement condition of the configuration data.

[0191] The resource deployment management system described in the embodiment only deploys a single admission controller to manage all resource deployment requests, that is, to manage the injection logic of all auxiliary containers; the scheme supports a dynamic plug-in architecture, allowing the platform system to load different Sidecar injection rules on demand; this implementation significantly reduces the number of admission control components in the system, reduces the operation and maintenance complexity, and improves the system control capability. In addition, global verification can avoid the deployment resource conflict that may exist in the traditional scheme where different functions are implemented separately, and ensure that each function on the platform can be normally implemented after the resource deployment is completed.

[0192] The specific implementation of the resource deployment management system and each module included therein, and other possible implementations can be found in the corresponding part of the method embodiment, which will not be repeated here.

[0193] Any one of the resource deployment management systems in the above embodiments includes a processor and a memory, and the request interception module, the instruction generation module, the instruction sending module, etc. in the above embodiments are stored in the memory as program modules, and the corresponding functions are realized by the processor executing the above program modules stored in the memory.

[0194] The processor includes a core, and the core calls the corresponding program modules in the memory. The core can be set to one or more, and the processing of the revisit data is realized by adjusting the core parameters.

[0195] The memory can include non-permanent memory in a computer readable medium, random access memory (RAM) and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM), and the memory includes at least one memory chip.

[0196] In an exemplary embodiment, a computer readable storage medium directly loadable into the internal memory of a computer is also provided, which contains software codes. After the computer program is loaded and executed by the computer, the steps shown in any one of the above resource deployment management method embodiments can be realized.

[0197] In an exemplary embodiment, a computer program product directly loadable into the internal memory of a computer is also provided, which contains software codes. After the computer program is loaded and executed by the computer, the steps shown in any one of the above resource deployment management method embodiments can be realized.

[0198] Each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The same or similar parts between each embodiment can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant part can be referred to the method part.

[0199] It is also to be noted that, as used in the specification and the appended claims, the singular forms "a," "an" and "the" include plural referents unless otherwise indicated. Furthermore, to the extent that the terms "including," "includes," "having," "has," "with," or "contains" are used in either the detailed description and the claims, such terms are intended to be inclusive in a manner similar to the term "comprising" as an open transition term without precluding any additional or other elements.

[0200] The embodiments disclosed herein can each be implemented as a method, apparatus, or article of manufacture using programming instructions. The embodiments disclosed herein can be implemented using software, firmware, hardware, or a combination thereof. The embodiments disclosed herein can be implemented in a computer system that includes one or more processors that are configured with instructions that, once implemented in hardware, cause the computer system to carry out the steps described herein. The instructions can be stored on a computer readable medium, such as a floppy disk, a hard disk, a CD-ROM, a DVD, a memory, a solid state drive, or a magnetic tape. The instructions can also be downloaded from the Internet. The instructions can be implemented in a plurality of programming languages.

[0201] The above description of disclosed embodiments provides enough information to enable those with ordinary skill in the art to make and use the application. Various modifications to these embodiments will be readily apparent to those with ordinary skill in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Accordingly, the application is not to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A resource deployment management method characterized by comprising: The method comprises the following steps: obtaining a resource deployment request submitted by a user, wherein the resource deployment request comprises configuration data; calling an admission controller to perform global verification on the resource deployment request, wherein the global verification comprises verification of implementation logic of the resource deployment request and cross-verification with existing deployments; generating a deployment instruction based on the configuration data if the resource deployment request passes the global verification; sending the deployment instruction to a resource deployment platform so that the resource deployment platform deploys a corresponding running unit, wherein the running unit has injected an auxiliary container that meets the requirement conditions of the configuration data.

2. The resource deployment management method according to claim 1, characterized by, The step of calling the admission controller to perform global verification on the resource deployment request comprises the following steps: filtering the resource deployment request based on basic condition data of the resource deployment platform to determine a resource deployment request that meets the basic condition data, wherein the basic condition data is used to ensure that the processed resource deployment request is a resource deployment request that is executable on the current platform; extracting resource configuration data from the resource deployment request that meets the basic condition data; verifying whether the resource configuration data meets the rule requirements; verifying whether the resource configuration data has resource conflicts with existing deployments.

3. The resource deployment management method according to claim 2, characterized by, The step of verifying whether the configuration data of the resource deployment request meets the rule requirements comprises the following steps: performing field verification based on the configuration data, including determining whether the configuration parameters in the configuration data meet the regular rules; performing resource quota total amount verification based on the configuration data, including whether the total amount of resource requests of multiple auxiliary containers exceeds the configured total amount of resources; performing dependency relationship verification based on the configuration data, including whether there is a dependency between auxiliary containers but the related configuration cannot complete the dependency implementation.

4. The resource deployment management method according to claim 2, characterized by, The step of verifying whether the configuration data of the resource deployment request has resource conflicts with existing deployments comprises the following steps: performing port conflict verification based on the configuration data, including whether auxiliary containers of different functions attempt to bind to the same port; performing storage volume mounting conflict verification based on the configuration data, including whether multiple auxiliary containers attempt to mount the same host path.

5. The resource deployment management method of claim 1, wherein, The method further comprises the following steps: if the global verification fails, determining the failure reason and the corresponding correction method; if the correction method does not require modifying the running program, adjusting the configuration data so that the resource deployment request passes the global verification; if the correction method requires modifying the running program, returning the failure reason with the correction method so that the user side adjusts the resource deployment request based on the correction method; the failure reason and the correction suggestion are determined based on the verification items and verification logic of the global verification.

6. The resource deployment management method according to claim 1, characterized by, The configuration data in the resource deployment request is determined by a user based on an interactive page that only exposes configurable fields; wherein the interactive page that only exposes configurable fields refers to the interactive page that only has optional function items and corresponding parameter filling items.

7. The resource deployment management method of claim 1, wherein, The step of generating a deployment instruction based on the configuration data comprises the following steps: obtaining the auxiliary container image version currently used by the resource deployment platform and setting it to be prohibited from being overwritten by the user; converting the configuration data into configuration fields of the auxiliary container that needs to be injected; determining threshold parameters of the auxiliary container to be injected according to a performance configuration of the running unit, the threshold parameters at least including: a minimum resource parameter required for starting the auxiliary container to be injected and a maximum resource parameter allowed to be used; obtaining configuration content in a target configuration language based on at least the auxiliary container image version, the configuration field and the threshold parameters, the target configuration language being a configuration language supported by the resource deployment platform.

8. The resource deployment management method of claim 1, wherein, The sending of the deployment instruction to the resource deployment platform comprises: submitting the deployment instruction through an interface service of the resource deployment platform to realize the expansion of the function corresponding to the resource deployment request without updating the version of the resource deployment platform.

9. The resource deployment management method of claim 1, wherein, Wherein: the image version of the auxiliary container is uniformly managed by the resource deployment platform, including that the upgrade of the image version of the auxiliary container is controlled and implemented by the resource deployment platform; the image version of the auxiliary container is invisible to the user, and after the user submits a resource deployment request, the resource deployment platform performs a deployment operation based on the resource deployment request submitted by the user, and determines the latest image version as the latest image version after the deployment is completed.

10. A resource deployment management system, characterized by, including: a request obtaining module configured to obtain a resource deployment request submitted by a user, the resource deployment request including configuration data; a global verification module configured to call an admission controller to perform global verification on the resource deployment request, the global verification including verification of implementation logic of the resource deployment request and cross-verification with current existing deployment; an instruction generation module configured to generate a deployment instruction based on the configuration data if the resource deployment request passes the global verification; an instruction sending module configured to send the deployment instruction to the resource deployment platform, so that the resource deployment platform deploys a corresponding running unit, the running unit having injected an auxiliary container meeting the requirement condition of the configuration data.

Images