CN116232687B

CN116232687B - Automatic front-end admission management method and system based on Kubernetes

Info

Publication number: CN116232687B
Application number: CN202310017554.1A
Authority: CN
Inventors: 钟毅翔; 张海伟; 朱晓曦; 方敏伟; 秦榛
Original assignee: Zhiji Automobile Technology Co Ltd
Current assignee: Zhiji Automobile Technology Co Ltd
Priority date: 2023-01-06
Filing date: 2023-01-06
Publication date: 2025-11-11
Anticipated expiration: 2043-01-06
Also published as: CN116232687A

Abstract

This invention discloses an automated pre-approval management method and system based on Kubernetes. The method includes: intercepting all requests to the Kube-Apiserver; pre-approving the requests and parsing the information messages of the requests; obtaining fields that need to be audited based on the information messages; using static and dynamic admission mechanisms to check the fields that need to be audited to manage whether the request is approved or needs to be modified; summarizing and storing the information of the requests based on the check results; and sending the approved requests to the Kube-Apiserver to execute the subsequent corresponding resource creation process. This invention can effectively reduce the performance anxiety of the Kube-Apiserver; at the same time, by using static and dynamic admission mechanisms to check all requests during the request management process, it can intercept or warn against requests that do not conform to the admission rules, thereby achieving the interception of illegal and erroneous requests and timely warning of suspicious requests, preventing adverse effects caused by human error.

Description

Automatic front-end admission management method and system based on Kubernetes

Technical Field

The invention relates to the technical field of computer data processing, in particular to an automatic front-end admission management method and system based on Kubernetes.

Background

With the popularization of cloud source generation concepts and the high-speed development of cloud computing technologies, container technologies are rapidly accepted by large enterprises by virtue of the technical characteristics of quick and efficient release, safe isolation of resources, unified multi-environment version and the like, and more companies begin to migrate services from the traditional host environment into the container environment.

Based on the light weight of the containers, the containers are used for carrying the service, and the number of the containers is generally large, so that an efficient and convenient distributed cluster management scheme is needed. In many schemes, kubernetes becomes the preferred scheme for managing container clouds for many enterprises at present by virtue of the advanced design concept, the strong expandability, the efficient arrangement efficiency and other technical characteristics.

However, in the real service data processing process, the wrong Kubernetes request may bring unpredictable serious influence to the cluster or the service, such as mistakenly modifying the number of Pods (in the Kubernetes scheme, the container group provides service to the outside in the form of Pod objects and carries the basic unit of application service), deleting the core component providing the service due to misoperation, or after knowing the global component of the cluster, including the access mode of CSI (channel state information), CNI (container network interface), CRI (container runtime interface), coreDNS (DNS server/repeater), ingress Controller (admission manager), carrying out malicious attack on the core component. The current common solution is to record all request information into a local log file by using Kube-APISERVER components to open an audit function. But only recording information, only recording and tracing the request, and not intercepting illegal and wrong requests and timely early warning of suspicious requests.

The prior art is therefore still in need of further development.

Disclosure of Invention

Aiming at the technical problems, the invention provides an automatic preposed admission management method and system based on Kubernetes, which can realize interception and early warning of error requests.

In a first aspect of the present invention, an automated front-end admission management method based on Kubernetes is provided, including:

intercepting all requests to Kube-APISERVER (a component providing API SERVER in a Kubernetes scheme is an entry for all requests to call), leading the requests and analyzing information messages of the requests;

Acquiring a field to be audited based on the information message, and checking the field to be audited by utilizing a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified;

and summarizing and storing the information of the request according to the checking result, and sending the admitted request to Kube-APISERVER to execute the subsequent corresponding resource creation flow.

In some embodiments, the pre-forwarding the request and parsing the information message of the request includes:

All requests to Kube-APISERVER are forwarded to an admission front-end processor, and the admission front-end processor analyzes information messages of the requests, wherein the admission front-end processor exists outside the Kubernetes cluster.

In some embodiments, the checking the field to be audited using a static admission mechanism and a dynamic admission mechanism to manage whether the request is admitted or needs modification includes:

And checking the mirror image download address, the service exposure port number and the request address in the request by using a static access mechanism, determining the request corresponding to the mirror image download address, the service exposure port number and the request address which conform to the static access mechanism as a quasi-access request, and intercepting or sending out a notification needing modification for the request corresponding to the mirror image download address, the service exposure port number and the request address which do not conform to the static access mechanism.

In some embodiments, the checking the field to be audited using a static admission mechanism and a dynamic admission mechanism to manage whether the request is admitted or needs modification further includes:

And checking the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the request by utilizing a dynamic admission mechanism, determining the request with the request resource number not exceeding the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the Kubernetes system as an admission request, and intercepting or sending a notification needing modification to the request with the request resource number not exceeding the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the Kubernetes system.

In some embodiments, the static admission mechanism is manually configured by a user, and the dynamic admission mechanism dynamically checks the condition of the requested resource application according to the monitoring data of the current Kubernetes cluster, and pre-warns or modifies the number and the size of the resource applications according to the resource state of the current Kubernetes cluster.

In a second aspect of the present invention, there is provided an automated pre-admission management system based on Kubernetes, comprising:

the admission front end processor is configured to acquire all intercepted requests to Kube-APISERVER, analyze information messages of the requests and send the information messages to the rule server;

The rule server is configured to acquire the field to be audited based on the information message, check the field to be audited by utilizing a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified, send the admitted request to Kube-APISERVER to execute a subsequent corresponding resource creation flow, summarize the information of the request according to the check result and generate the summarized information of the request to an audit report system for storage.

In some embodiments, the rule server comprises a static rule module configured to check the mirror download address, the service exposure port number and the request address in the request by using a static admission mechanism, determine the request corresponding to the mirror download address, the service exposure port number and the request address conforming to the static admission mechanism as a quasi-admission request, intercept the request corresponding to the mirror download address, the service exposure port number and the request address not conforming to the static admission mechanism, or send out a notification that modification is needed.

In some embodiments, the rule server comprises a dynamic rule module configured to check a single container resource usage limit, a resource copy number, a resource elastic capacity expansion number limit in the request by using a dynamic admission mechanism, determine the request with the number of requested resources not exceeding the single container resource usage limit, the resource copy number, the resource elastic capacity expansion number limit in the Kubernetes system as a admitted request, intercept or issue a notification that needs modification for the request with the number of requested resources not exceeding the single container resource usage limit, the resource copy number, the resource elastic capacity expansion number limit in the Kubernetes system.

In a third aspect of the present invention, there is provided an electronic apparatus comprising:

And at least one memory communicatively coupled to the processor, wherein the memory stores program instructions executable by the processor, the processor invoking the program instructions capable of performing the method according to the first aspect of the embodiments of the invention.

In a fourth aspect of the invention, a computer-readable storage medium is provided, on which a computer program is stored which, when run by a computer, performs the method according to the first aspect of the embodiment of the invention.

The invention intercepts all requests to Kube-APISERVER and preposes the requests, can effectively reduce the performance anxiety of Kube-APISERVER, and simultaneously, utilizes a static admittance mechanism and a dynamic admittance mechanism to check all requests in the process of managing the requests, intercepts or early-warns the requests which do not accord with admittance rules, realizes the interception of illegal and wrong requests and the timely early-warning of suspicious requests, and prevents the adverse effects caused by human misoperation.

Drawings

Fig. 1 is a schematic working diagram of an automatic front-end admission management system based on Kubernetes according to an embodiment of the present invention;

fig. 2 is a flow chart of an automatic front-end admission management method based on Kubernetes in an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The Kubernetes audit log is a structured log of configurable policies generated by Kube-APISERVER that records all access events to Kube-APISERVER. The audit log provides another cluster observation dimension except for the Metrics (a java library capable of providing code running insight function), and changes to the cluster state can be traced back, the running condition of the cluster can be known, abnormal problems can be eliminated, potential performance risks of the cluster can be found and the like by checking and analyzing the audit log. The audit log includes 3 parts of metadata (metadata), request content (requestObject), and response content (responseObject). By default, audit logs do not record what is in requestObject or responseObject, and mainly record metadata (metadata) information that contains the context information of the request, such as who initiated the request, where the request originated, what the accessed resource is, what is specifically operating, etc., through which information an administrator can be helped to have a better control over the current state of the cluster.

However, the access controller of Kubernetes is that after the resources are created and authenticated, kube-APISERVER intercepts data before the data is written into etcd (a high-availability Key/Value storage system), and then performs relevant inspection on the resources, which can be said to be the last defense line of the request before the cluster is affected, so that the access and audit can be said to be two important means for guaranteeing the normal operation of Kubernetes.

However, in the prior art, the related check only has a recording function, and cannot intercept illegal and error requests and timely early warn suspicious requests. The invention utilizes the independent admission front end processor to complete the admission processing of all requests, and some admission control mechanisms exist in the prior art, but the admission control mechanisms are not independently used, and the scheduling of flow and the scheduling of resources are realized only by combining with the preset rules, so that the invention can not prevent human error operation, can not relieve the operation pressure of Kube-APISERVER, and increases the operation pressure to a certain extent.

Based on the above, as shown in fig. 1, the invention provides an automatic front-end access management system based on Kubernetes, which comprises an access front-end processor and a rule server, wherein the access front-end processor exists outside a Kubernetes cluster and is isolated from the Kubernetes cluster, and as the access service intercepts requests before Kube-APISERVER, the performance anxiety of Kube-APISERVER can be effectively reduced, and even if the access front-end processor abnormally affects the later-stage service, the access front-end processor can be bypassed in a degradation mode and the like, so that the cluster is not affected. The rule server is used for examining all requests, giving different response management to the requests with different risk levels, and intercepting illegal and wrong requests and timely early warning suspicious requests even if adverse effects are generated due to human misoperation. In one embodiment:

The admission front end processor is configured to acquire all the intercepted requests to Kube-APISERVER, analyze the information message of the requests and send the information message to the rule server.

The rule server is configured to obtain a field to be audited based on the information message, check the field to be audited by using a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified, send the admitted request to Kube-APISERVER to execute a subsequent corresponding resource creation process (such as a Controller and an execution list Schedule in fig. 1, respectively control different pod and Node), collect the information of the request according to the checking result, and send the collected information of the request to an audit report system for storage.

It should be appreciated that the admission front-end processor includes a class proxy server that can be loaded with Kubernetes TLS certificates, and in the Kubernetes architecture, the front-end processor can intercept all requests to Kube-APISERVER and then parse the corresponding request information messages. The request message is a standard structure body, and contains elements such as a request type (requestKind), request resource configuration information (name/spec), request source account information (userInfo) and the like. The method comprises the steps of splitting request information, intercepting fields needing to be audited, and then sending the fields needing to be audited to a rule server for auditing.

When the fields needing to be audited are sent to the rule server, the request object can be recombined by combining the source IP acquired by the admission front end processor. For the admission and interception of requests, the requests with known IP can be intercepted in batches, and the access to the Kubernetes cluster is intercepted by directly rejecting the IP address. Therefore, when the method is specifically executed, the request objects can be recombined according to the IP source of the request, the request objects consistent with each other can be sent to the rule server in batches for auditing the request, and the auditing pressure can be effectively reduced.

In the rule server, two checking mechanisms are adopted to perform checking on the request, namely a static admittance mechanism and a dynamic admittance mechanism, wherein the two mechanisms respectively correspond to a static rule and a dynamic rule. The two rule types support three management modes, namely a reject request, a modify request and an early warning request, and correspond to the requests with different risk levels.

The invention mainly aims to prevent adverse effects caused by human misoperation, and checks the intercepted request by using the two checking rules. As will be appreciated by the background, the above-described requests include various types of requests, namely all requests to Kube-APISERVER. Therefore, the static admittance mechanism is mainly used for checking rules of artificial behaviors, can be manually configured by a user or an administrator, has various specific configuration contents, and can be formulated according to different project requirements. By way of example, the static admission mechanism described above may formulate rules that meet corporate security baselines, such as directly denying access to the cluster by sensitive IP addresses, defining port ranges after container release, and mirror pull addresses, etc.

The dynamic admission mechanism is mainly used for dynamically checking the resource application condition according to the multi-dimensional monitoring data of the current Kubernetes cluster, and carrying out early warning or modification on the quantity, the size and the like of the resource application according to the actual condition of the Kubernetes cluster. For example, the upper and lower limits of the number of resource copies and the number of elastic expansion of the resource may be checked for a single container resource usage upper and lower limit. It can be understood that whether the resource application of the Kubernetes cluster in the request is reasonable is checked, whether the Kubernetes cluster can meet the resource application, if not, interception or early warning is carried out, and if so, the request is treated as an admission request.

The static admittance mechanism effectively meets the inspection of manual operation conforming to the project baseline of the company, intercepts some error events of manual operation by using a static rule, and the dynamic admittance mechanism effectively meets the inspection of the quantity of resources of the Kubernetes cluster except the manual operation, and can meet the requirement that whether the current resource data is requested according to the Kubernetes cluster, namely, the events of some manual operation cannot be intercepted by using the static rule, and the interception is realized by using the dynamic rule according to the current situation.

The rule server is also used for tracing the subsequent audit and optimizing the related flow, such as log recording, and analyzing the basis after the fault occurs. For example, the rule server collects the requested information according to the checking result and generates the collected requested information to the audit report system for storage.

After the rule server processes the request, the processed request object is copied in the memory, the rule server sends the admitted request to Kube-APISERVER to execute the subsequent corresponding resource creation flow, one copy of the request is sent to the audit report system together with the original request object for subsequent operation audit and tracing, and the user can periodically optimize the corresponding rule and flow according to the data in the audit report system.

In summary, the method intercepts all requests of Kube-APISERVER and preposes the requests, can effectively reduce performance anxiety of Kube-APISERVER, can check all requests by utilizing a static admittance mechanism and a dynamic admittance mechanism in the request management process, can prevent adverse effects caused by human misoperation, intercepts or early warns requests which do not accord with admittance rules, and can intercept illegal and wrong requests and timely early warn suspicious requests.

Still further, the rule server includes a static rule module and a dynamic rule module. The static rule module executes the static admittance mechanism, and the dynamic rule module executes the dynamic admittance mechanism. Wherein the static admission mechanism is manually configured by a user, e.g. providing a manual configuration interface, by which parameter values or constraints are entered. The code of the management rule can be written by the user, and the automatic admission judgment can be realized through the code. The field information of the request is used for checking the usage rules in the present invention, which can be implemented by setting the admission rules of the fields or automatically checking the codes of the fields. The dynamic admission mechanism mainly detects whether the resource application is reasonable or not, for example, the condition of the requested resource application is dynamically checked according to the monitoring data of the current Kubernetes cluster, and the quantity and the size of the resource application are early-warned or modified according to the resource state of the current Kubernetes cluster.

In some embodiments, the static rule module is configured to check the image download address, the service exposure port number and the request address in the request by using a static admission mechanism, determine the request corresponding to the image download address, the service exposure port number and the request address conforming to the static admission mechanism as a admitted request, intercept the request corresponding to the image download address, the service exposure port number and the request address not conforming to the static admission mechanism or send out a notification that modification is needed. For example, in a Kubernetes-based automated pre-admission management system, the static rules module is responsible for auditing the necessary fields at the time of resource creation, including the mirror download address, service exposure port number, request source address. The static rule comprises admittance, intercepts the two filtering actions, and a user can freely combine the two filtering actions with the audit field so as to realize preliminary audit and prevention of the resource creation request.

The dynamic rule module is configured to check the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the request by utilizing a dynamic admission mechanism, determine the request with the request resource number not exceeding the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the Kubernetes system as an admission request, intercept or send out a notice needing modification to the request with the request resource number not exceeding the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the Kubernetes system. For example, the dynamic rule module is responsible for auditing specific resource requirements during resource creation, including upper and lower limits of single container resource use, resource copy number and upper and lower limits of resource elastic capacity expansion number. The dynamic rules include admittance, modification, and interception of these three actions. The module dynamically intercepts/adjusts the resource creation request according to the monitoring data transmitted in real time by the monitoring and the total capacity of the current cluster. When an abnormality occurs, for example, a user performs one-time service release, which involves release of a plurality of resources, but due to misoperation, the number of the resources is changed from 2 to 2000, but the total upper limit of the current cluster resources is insufficient to support such large capacity expansion, in order to avoid release failure, the request is determined as an abnormal request by an admission front end processor, and the admission front end processor modifies the capacity expansion number according to the residual capacity of the current cluster and notifies the user and an administrator to perform insufficient resource early warning. Wherein the early warning and the modification can be performed by means of a monitoring alarm system.

In the originated Kubernetes cluster Kube-APISERVER is the entry for all requests, and Kube-APISERVER requires that each piece of complete request information be duplicated and kept local after the audit function is opened, which may cause performance problems in general terms Kube-APISERVER because the complete request information contains all metadata (metadata) requested. The present invention can solve this problem by forwarding all requests to Kube-APISERVER to the admission front-end processor.

As shown in fig. 2, the present invention provides an automatic front-end admission management method based on Kubernetes, which includes:

step 210, intercepting all requests to Kube-APISERVER, leading the requests and analyzing the information messages of the requests.

And 220, acquiring a field to be audited based on the information message, and checking the field to be audited by utilizing a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified. The static access mechanism is configured manually by a user, the dynamic access mechanism dynamically checks the request resource application condition according to the monitoring data of the current Kubernetes cluster, and the number and the size of the resource applications are pre-warned or modified according to the resource state of the current Kubernetes cluster. Wherein the pre-warning may be alerted using the function of a pop-up window and the modification may provide a modification interface or directly modify the content of the request initially sent to Kube-APISERVER.

And 230, summarizing and storing the information of the request according to the checking result, and sending the admitted request to Kube-APISERVER to execute the subsequent corresponding resource creation flow. The information storage of the checking result is stored by an audit report system of the Kubernetes cluster, is consistent with the log storage position, and is different from the result which is processed by a rule server, namely, the result which is finished by executing the static admittance mechanism and the dynamic admittance mechanism.

In step 210, the pre-forwarding the request and parsing the information message of the request includes:

In step 220, the checking the field to be audited for managing whether the request is admitted or needs modification by using a static admission mechanism and a dynamic admission mechanism includes:

Further, the checking the field to be audited by using a static admission mechanism and a dynamic admission mechanism to manage whether the request is admitted or needs modification, and the method further includes:

The invention provides an automatic front-end admission management method based on Kubernetes, which can be combined with the content understanding of the automatic front-end admission management system based on the Kubernetes, and is not repeated.

The present invention also provides an electronic device including:

And at least one memory communicatively coupled to the processor, wherein the memory stores program instructions executable by the processor, the processor invoking the program instructions capable of performing the Kubernetes-based automated pre-admission management method described above.

The invention also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the automatic front-end admission management method based on the Kubernetes when being executed by a processor.

It is understood that the computer-readable storage medium may include any entity or device capable of carrying a computer program, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a software distribution medium, and so forth. The computer program comprises computer program code. The computer program code may be in the form of source code, object code, executable files, or in some intermediate form, among others. The computer readable storage medium may include any entity or device capable of carrying computer program code, a recording medium, a USB flash disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a software distribution medium, and so forth.

In some embodiments of the present invention, the apparatus may include a controller, which is a single-chip microcomputer chip, integrated with a processor, a memory, a communication module, etc. The processor may refer to a processor comprised by the controller. The Processor may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), off-the-shelf Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and additional implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The foregoing embodiments are merely for illustrating the technical solution of the present invention, but not for limiting the same, and although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that modifications may be made to the technical solution described in the foregoing embodiments or equivalents may be substituted for parts of the technical features thereof, and that such modifications or substitutions do not depart from the spirit and scope of the technical solution of the embodiments of the present invention in essence.

Claims

1. An automatic front-end admission management method based on Kubernetes is characterized by comprising the following steps:

Intercepting all requests of Kube-APISERVER, and forwarding the requests to Kube-APISERVER to an admission front end processor, wherein the admission front end processor analyzes the information messages of the requests, and the admission front end processor exists outside a Kubernetes cluster;

Acquiring a field to be audited based on the information message, and checking the field to be audited by utilizing a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified; the dynamic admission mechanism can dynamically intercept or adjust a resource creation request according to monitoring data transmitted in real time and the total capacity of a current cluster, wherein the dynamic admission mechanism can dynamically check the resource application condition of the request according to the monitoring data of the current Kubernetes cluster and early warn or modify the quantity and the size of the resource application according to the resource state of the current Kubernetes cluster;

2. The Kubernetes-based automated front-end admission management method of claim 1, wherein the checking the field to be audited with a static admission mechanism and a dynamic admission mechanism to manage whether the request is admitted or needs modification comprises:

3. The Kubernetes-based automated front-end admission management method of claim 2, wherein the checking the field to be audited with a static admission mechanism and a dynamic admission mechanism to manage whether the request is admitted or needs modification further comprises:

And checking the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the request by utilizing a dynamic admission mechanism, and determining the request with the number of the requested resources not exceeding the single container resource use limit number, the resource copy number and the resource elastic capacity expansion quantity limit number in the Kubernetes system as an admission request.

4. The Kubernetes-based automated front-end admission management method of claim 1, wherein the static admission mechanism is manually configured by a user.

5. An automated front-end admission management system based on Kubernetes, comprising:

The access front end processor is configured to acquire all requests which are intercepted to Kube-APISERVER, analyze the information messages of the requests and send the information messages to the rule server, wherein the access front end processor is used for forwarding all requests to Kube-APISERVER to the access front end processor, analyzing the information messages of the requests by the access front end processor, and the access front end processor exists outside a Kubernetes cluster;

The rule server is configured to acquire a field to be audited based on the information message, check the field to be audited by utilizing a static admittance mechanism and a dynamic admittance mechanism to manage whether the request is admitted or needs to be modified, send the admitted request to the Kube-APISERVER to execute a subsequent corresponding resource creation flow, summarize the information of the request according to the check result and generate the summarized information of the request to an audit report system for storage, wherein:

The dynamic admission mechanism can dynamically intercept or adjust resource creation requests according to monitoring data transmitted in real time and the total capacity of the current cluster, wherein the dynamic admission mechanism can dynamically check the resource application condition of the requests according to the monitoring data of the current Kubernetes cluster and early warn or modify the quantity and the size of the resource applications according to the resource state of the current Kubernetes cluster.

6. The Kubernetes-based automated pre-admission management system of claim 5, wherein the rules server comprises a static rules module configured to examine the request for the image download address, the service exposure port number, and the request address using a static admission mechanism, determine the request corresponding to the image download address, the service exposure port number, and the request address that are compliant with the static admission mechanism as a admitted request, intercept the request corresponding to the image download address, the service exposure port number, and the request address that are not compliant with the static admission mechanism, or issue a notification that modification is required.

7. The Kubernetes-based automated pre-admission management system of claim 5, wherein the rules server comprises a dynamic rules module configured to examine individual container resource usage limits, resource copies, resource elastic capacity expansion amount limits in the request with a dynamic admission mechanism, and determine the request for which the number of requested resources does not exceed individual container resource usage limits, resource copies, resource elastic capacity expansion amount limits in the Kubernetes system as an admitted request.

8. The Kubernetes-based automated front-end admission management system of claim 5, wherein the static admission mechanism is manually configured by a user.

9. An electronic device, comprising:

And at least one memory communicatively coupled to the processor, wherein the memory stores program instructions executable by the processor, the processor invoking the program instructions capable of performing the method of any of claims 1-4.

10. A computer-readable storage medium, on which a computer program is stored, which, when being run by a computer, performs the method according to any one of claims 1 to 4.