A Kubernetes resource inspection method, system and device

Abstract

The application provides a Kubernetes resource inspection method, system and device, the method comprises the following steps: submitting a CRD creation request to a Kubernetes API Server, initializing the corresponding CRD in the inspection management, and deploying the inspection core management controller; creating a business workload according to the CRD creation request, and setting an IP pool controller corresponding to the CRD to listen to the CR resource; submitting a request for creating an inspection task CR to the Kubernetes API Server; the inspection core management controller obtains the inspection task request through the long connection with the Kubernetes API Server, and performs the inspection on the inspection task CR. The scheme can ensure that there is only one same type of inspection Pod running on each Node, and the execution of the inspection is monitored during the running process, and after the running is completed, the inspection Pod can be recycled and the resources are released, thereby effectively reducing the occupation of the cluster resources.

Description

Technical Field

[0001] This invention relates to the field of container orchestration in the cloud-native system, and in particular to a Kubernetes resource inspection method, system and device. Background Technology

[0002] After upgrading basic software, such as Kubelet, or creating the corresponding virtual device for Macvlan on the selected node, it is often necessary to perform verification checks on each node. The usual practice is to have a resident management Pod on the corresponding node to perform periodic inspections of different resources. These checks usually only need to be performed once in a long period of time, or triggered temporarily when needed. In this case, when there are many resources to be inspected, the resident management Pod will consume a lot of CPU, memory, or network resources.

[0003] Therefore, how to reduce the number of resource inspections in cloud-native systems and the cluster resources consumed by inspections is an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the present invention provides a Kubernetes resource inspection method, system, and device to reduce the number of resource inspections and the cluster resources consumed during inspections. Specifically, the present invention provides the following technical solutions:

[0005] On one hand, the present invention provides a Kubernetes resource inspection method, the method comprising:

[0006] Step 1: Submit a CRD creation request to the Kubernetes API Server to initialize the corresponding CRD in the inspection management and deploy the inspection core management controller; the inspection core management controller is used to listen to inspection tasks (CRs).

[0007] Step 2: Create the business workload according to the CRD creation request, and set the IPPool controller corresponding to the CRD to listen to the CR resource to complete the creation of the target inspection resource;

[0008] Step 3: Submit a request to the Kubernetes API Server to create an inspection task (CR). Once the inspection task (CR) is created, it will be in a waiting-for-scheduling state.

[0009] Step 4: The inspection core management controller obtains inspection task requests by establishing a long connection with the Kubernetes API Server and executes the inspection of the inspection task CR.

[0010] Preferably, in step 2, the creation of the target inspection resource can be achieved by submitting a CRD creation request corresponding to the business workload to the Kubernetes APIServer, deploying the management controller corresponding to the business workload, and having the management controller listen to the CR resource (e.g., IPPool instance) corresponding to the business workload and create the workload to complete the creation of the target inspection resource.

[0011] Preferably, in step 1, the inspection core management controller establishes a long connection with the Kubernetes API Server through InCluster mode.

[0012] Preferably, in step 2, when a virtual network creation request is received, the IPPool controller will verify whether the IP subnet is valid and at the same time verify whether the virtual network to be created already exists, so as to ensure that the corresponding virtual network is created on the corresponding Node node.

[0013] Preferably, in step 2, the IPPool controller corresponding to the CRD shares the network protocol stack with the host machine.

[0014] Preferably, in step 3, the information of the inspection task CR includes: image definition, command corresponding to container execution, concurrency parameters, timeout, and number of retries.

[0015] Preferably, in step 4, performing the inspection of the inspection task CR specifically includes:

[0016] Step 401: Obtain information about the inspection task CR instance;

[0017] Step 402: Determine if the inspection task CR instance has a management tag. If it does not exist, complete the management tag and update the tag of the inspection task CR instance, then proceed to the next step. If it exists, proceed directly to the next step.

[0018] Step 403: Determine whether the inspection task CR instance has been completed. If it has been completed, summarize the inspection results, release resources, and complete the inspection; otherwise, proceed to the next step.

[0019] Step 404: Determine whether the start time of the inspection task CR instance has been set. If not, set the start time to the current time. If it has been set, proceed to the next step.

[0020] Step 405: Determine whether the Phase has been set in the CR instance of the inspection task. If not, set the Phase status to running; if it has been set, proceed to the next step.

[0021] Step 406: Obtain all inspection Pod instances managed by the inspection task CR instance;

[0022] Step 407: Obtain the mapping table of Nodes and Inspection Pods corresponding to all Inspection Pods managed by the Inspection Task CR instance;

[0023] Step 408: Obtain a list of all Nodes in the cluster as a candidate Node list;

[0024] Step 409: Based on the status of the inspection Pod instance, filter and classify all inspection Pod instances managed by the obtained inspection task CR instance, and add the corresponding inspection Pod to the inspection Pod list of the corresponding type.

[0025] The types of the inspection Pod list include failed, active, and succeeded classes;

[0026] Step 410: Traverse all Nodes in the candidate Node list and filter out the WaitingForRunPod Node list based on the matching of Nodes with the corresponding matching items in the inspection Pod list, so as to use it as the new Node list for inspection Pod scheduling, and at the same time obtain the inspection Pod instances that need to be cleaned up.

[0027] Step 411: Determine the Phase in the CR instance status of the inspection task. If the corresponding status of the Phase is PhaseFailed, update the rescheduling delay, re-enter the queue, and wait for the next processing; otherwise, proceed to the next step.

[0028] Step 412: Determine the status of the Phase corresponding to the Spec in the CR instance of the inspection task. If the status of the Phase corresponding to the Spec is Paused, and the Phase status in the CR instance of the inspection task is PhaseRunning or PhasePaushed, then update the rescheduling delay, re-enter the queue, and wait for the next processing; otherwise, proceed to the next step.

[0029] Step 413: Determine the state of the Phase corresponding to the Spec in the CR instance of the inspection task. If the state of the Phase corresponding to the Spec is not Paused, and the Phase state in the CR instance of the inspection task is PhasePaushed, then update the rescheduling delay, re-enter the queue, and wait for the next processing; otherwise, proceed to the next step.

[0030] Step 414: Determine if the status of the inspection task CR instance is failed. If it is failed, clean up the inspection Pod corresponding to the inspection task CR instance, re-enter the queue, or continue the inspection process. If it is not failed, clean up the inspection Pod corresponding to the Delete Pod list and release cluster resources when the Delete Pod list is not empty. Otherwise, proceed to the next step.

[0031] Step 415: If the DeletionTimestamp of the inspection task CR instance is not set and the WaitingForRunPod Node list is not empty, then perform inspection Pod scheduling.

[0032] Step 416: The inspection Pod runs on the corresponding Node to execute inspection commands and monitors the inspection Pod. Based on the obtained inspection task CR instance, the status processing of the corresponding inspection task CR instance is performed during monitoring.

[0033] Step 417: Obtain the execution status of the inspection task Pod and the inspection task CR instance to which the inspection task Pod belongs, and send the obtained inspection task CR instance information to step 401, and perform the corresponding operation in step 401.

[0034] Preferably, in step 410, the matching process includes:

[0035] Step 4101: If a matching item exists, match each matching sub-item one by one; when the conditions of all matching sub-items are met, add the corresponding Node to the Desired Node list; if the conditions of any matching sub-item are not met, and the DeletionTimestamp of the inspection Pod has been set, add the Node to the Delete Pod list in preparation for cleaning up the corresponding inspection Pod.

[0036] Step 4102: If no matching item exists, initialize the inspection Pod instance and match each matching sub-item one by one. When the conditions of all matching sub-items are met, add the corresponding Node to the WaitingForRunPod Node list.

[0037] Preferably, the matching sub-item includes any combination of the following sub-items:

[0038] Matching sub-item 1: Host matching processing; Matching sub-item 2: NodeSelector matching processing; Matching sub-item 3: NodeTaints matching processing; Matching sub-item 4: Node Unschedulable matching processing; Matching sub-item 5: Matching based on the number of Pods already scheduled on the current Node.

[0039] Preferably, step 414 further includes: if the inspection task CR instance status is determined to be failed, then the following processing strategies are set: FailFast, TypePause, Continue, with the corresponding processing strategies as follows:

[0040] FailFast: This interrupts the processing of the current inspection task CR instance. If the inspection task CR instance meets the timeout condition, the inspection Pod corresponding to the inspection task CR instance is cleaned up and resources are released.

[0041] TypePause: This pauses the processing of the current inspection task CR instance, updates the rescheduling delay, and re-enters the queue to wait for the next processing.

[0042] Continue: This means continuing the processing of the current inspection task CR instance until all inspection Pods have finished running.

[0043] Preferably, in step 415, the Pod scheduling process for inspection specifically includes:

[0044] If the number of inspection Pods currently in an active state exceeds the concurrency parameter, a threshold exceeding event is reported, and the current processing is interrupted; or

[0045] If the number of inspection Pods currently in the active state is less than or equal to the concurrency parameter, then calculate the actual concurrency value; and create inspection Pods concurrently based on the actual concurrency value.

[0046] Preferably, the calculation of the actual concurrency value is performed in the following manner:

[0047] batchSize = min(parallelism-active, waiting)

[0048] Where waiting is the length of the WaitingForRunPod Node list, parallelism is the set concurrency value, active is the length of the inspection Pod list associated with the active type, and the function min is to take the minimum value among the parameter values.

[0049] Furthermore, this invention also provides a Kubernetes resource inspection system, the system comprising:

[0050] The deployment module is used to send CRD creation requests to the Kubernetes API Server, initialize the corresponding CRD in the inspection management, and deploy the inspection core management controller in the cluster.

[0051] The core management controller is used to monitor inspection tasks (CR).

[0052] The inspection resource creation module is used to create business workloads based on CRD creation requests and set up the IPPool controller corresponding to the CRD to listen to the CR resource in order to complete the creation of the target inspection resource.

[0053] The inspection task creation module is used to submit a request to the Kubernetes API Server to create an inspection task (CR), and to create the inspection task CR. Once the inspection task CR is created, it enters a waiting-for-scheduling state.

[0054] The inspection module is used to obtain inspection task requests by invoking the inspection core management controller to establish a long connection with the Kubernetes API Server, and to perform inspections on the inspection tasks CR.

[0055] Preferably, the inspection module includes:

[0056] The inspection task CR event access unit is used to obtain information about the inspection task CR instance;

[0057] The judgment unit determines whether the inspection task CR instance has a management tag. If not, it notifies the processing unit to complete the management tag and update the tag of the inspection task CR instance. It also determines whether the inspection task CR instance has been completed, whether the start time of the inspection task CR instance has been set, and whether the start time has been set to the current time. Furthermore, it determines whether the Phase in the inspection task CR instance has been set, and whether the Phase status has been set to running. Finally, it determines the status corresponding to the Phase in the status of the inspection task CR instance, and the status of the Phase corresponding to the Spec in the inspection task CR instance.

[0058] The processing unit retrieves all inspection Pod instances managed by the inspection task CR instance, the mapping table between Nodes and inspection Pods corresponding to all inspection Pods managed by the inspection task CR instance, and a list of all Nodes in the cluster as a candidate Node list; based on the status of the inspection Pod instances, it filters and categorizes all inspection Pod instances managed by the inspection task CR instance, and adds the corresponding inspection Pods to the corresponding type of inspection Pod list; and

[0059] Iterate through all Nodes in the candidate Node list and, based on the matching of Nodes with corresponding items in the inspection Pod list, filter out the WaitingForRunPod Node list to serve as the new Node list for inspection Pod scheduling. Simultaneously, obtain the inspection Pod instances that need to be cleaned up.

[0060] The system determines whether the inspection task CR instance status is failed. If it is, the corresponding inspection Pod is cleaned up, re-entered into the queue, or continues inspection. If it is not failed, and the Delete Pod list is not empty, the corresponding inspection Pod is cleaned up to release cluster resources. If the DeletionTimestamp of the inspection task CR instance is not set, and the WaitingForRunPod Node list is not empty, inspection Pod scheduling is performed. The inspection Pod runs on the corresponding Node to execute inspection commands and is monitored. Based on the obtained inspection task CR instance, the system performs status processing for the corresponding inspection task CR instance.

[0061] Determine if the status of the inspection task CR instance is completed; if so, release resources.

[0062] In another aspect, the present invention also provides a Kubernetes resource inspection device, the device including a processor and a storage device, the storage device storing instructions that can be read by the processor; the processor is used to call the instructions in the storage device to execute the Kubernetes resource inspection method as described above.

[0063] Compared with existing technologies, this solution receives and creates business workloads; creates a core management controller (CRD); deploys a core management controller (Operator); creates a core management controller (CR); and deploys a core management controller (Operator). After receiving inspection requests, the solution ensures that only one inspection Pod of the same type runs on each Node within the set Node range. During operation, the solution monitors the inspection execution status and ensures that the inspection Pod is recycled and resources are released after operation, effectively reducing the occupation of cluster resources. Attached Figure Description

[0064] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a flowchart illustrating the inspection execution process according to an embodiment of the present invention.

[0066] Figure 2 This is a schematic diagram illustrating the execution steps of an embodiment of the present invention. Detailed Implementation

[0067] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0068] Those skilled in the art should understand that the following specific embodiments or implementation methods are a series of optimized configurations listed to further explain the specific content of the invention. These configuration methods can be combined or used in conjunction with each other, unless the invention explicitly states that some or a specific embodiment or implementation method cannot be associated with or used in conjunction with other embodiments or implementation methods. Furthermore, the following specific embodiments or implementation methods are merely optimized configurations and are not intended to limit the scope of protection of the invention.

[0069] Example 1:

[0070] In a specific embodiment, such as Figure 1 , 2 As shown, a flowchart of a Kubernetes resource inspection method provided in an embodiment of this application is illustrated. The specific steps of this method can be implemented in the following manner:

[0071] Step 1: Submit a CRD (Custom Resource Definition) creation request to the Kubernetes API Server to initialize the inspection and management of the corresponding CRD. The Kubernetes API Server is a component in Kubernetes used to receive requests related to resource creation, updating, and deletion.

[0072] After the CRD initialization is completed, the inspection core management controller is deployed in the Kubernetes cluster. Specifically, at the execution level, the computer program corresponding to each inspection core management controller is deployed in the cluster.

[0073] After the program corresponding to the inspection core management controller starts, preferably, it establishes a long connection with the Kubernetes API Server through InCluster mode and listens (i.e. executes the Watch function) for the CR (Custom Resource) corresponding to the inspection task.

[0074] At this time, the inspection core management controller is in a ready state, waiting to receive and process inspection requests.

[0075] Step 2, create target inspection resources. Create business workloads based on the CRD creation request. In one specific implementation, such as... Figure 1 As shown, here we define a custom type of business workload instance IPPool.

[0076] In a more preferred approach, the IPPool here can be a custom CR (Network Controller). The CR can define key elements such as network name, network type, subnet segment, subnet mask, gateway, and whether IPv6 is supported. An example of a CR in this case is as follows:

[0077] apiVersion: network.tiduyun.com / v1alpha1

[0078] kind: IPPool

[0079] metadata:

[0080] name: network1

[0081] spec:

[0082] type: macvlan

[0083] network: 192.168.0.0

[0084] gateway: 192.168.0.1

[0085] interface: eth0

[0086] mask: 255.255.255.0

[0087] The IPPool controller is a corresponding CRD implementation. It listens to the CR resources corresponding to the IPPool and ensures that the corresponding virtual network is created on the corresponding Node. When it receives a virtual network creation request, the IPPool controller will verify whether the IP subnet is valid and whether the virtual network to be created already exists.

[0088] Here, we will explain the specific implementation of the IPPool for business workloads using one particular method:

[0089] The IPPool controller runs an instance in InCluster mode on each Node in the Kubernetes cluster. It establishes a long connection with the Kubernetes API Server and listens for the CR resources corresponding to the IPPool. When it receives a change event for the CR resource corresponding to the IPPool, each IPPool controller instance will perform the following branching processing according to the event type (e.g., creation or deletion) (the following branches are based on the CR instance network1): [Creation Branch] When the change event type for the CR resource corresponding to the IPPool is creation, it will process the request through the Docker standard network API using the REST (i.e., via HTTP) interface as follows: [Creation Sub-branch 1] Check if the virtual device network1 exists. If it exists, the processing flow is stopped; otherwise, proceed to [Creation Sub-branch 2]; [Creation Sub-branch 2] Verify the validity of network, gateway, and mask in the spec, and whether the interface exists; [Creation Sub-branch 3] Execute creation. [Delete Branch] When the change event type for the CR resource corresponding to the IPPool is deletion, it will check if the virtual device network1 exists. If it exists, the processing flow is stopped; otherwise, the deletion operation will be performed. Through the above-described configuration steps, the IPPool controller can achieve a one-to-one correspondence with the CRD, ensuring the creation of the corresponding virtual network on the corresponding node, and verifying the IP subnet and whether the virtual network already exists during the process.

[0090] It should be noted that the corresponding IPPool controller shares the network protocol stack with the host machine. In a more preferred embodiment, an example of creating a virtual device corresponding to the IPPool can be as follows:

[0091] docker network create -d macvlan --subnet=192.168.0.0 / 23 --gateway=192.168.0.1 -o parent=eth0 network1

[0092] The example above creates a virtual network named network1 with a network type of macvlan. Within the selected Node range, each Node will have this virtual network.

[0093] At this point, the target inspection resources have been created.

[0094] Step 3: Submit a request to the Kubernetes API Server to create a CR (Crew Inspection) task.

[0095] In a more preferred embodiment, the specific definition of the inspection task CR may include: image definition, command corresponding to container execution, concurrency parameters, timeout, number of retries, etc. In specific implementation, the type of the inspection task CR can be defined as InspectionJob type. That is, in a specific runtime environment or programming language environment, the computer program representation of the inspection task CR can use InspectionJob. In this embodiment, InspectionJob can also be used instead of the inspection task CR to facilitate a detailed explanation of this solution.

[0096] Once the inspection task (CR) is created, it will be in a waiting-for-scheduling state.

[0097] Step 4, as described in Step 1, the inspection core management controller is in a ready state, waiting to receive and process inspection requests. After the inspection task (CR) corresponding to Step 3 is created, the inspection core management controller obtains the inspection task request through a long connection with the Kubernetes API Server. This step corresponds to... Figure 1 The inspection process in the process.

[0098] In a more preferred embodiment, refer to Figure 1 As shown, the inspection process includes the following stages:

[0099] Step 401: The inspection task CR event access unit obtains detailed instance information of the inspection task CR based on the event information obtained from the Kubernetes API Server.

[0100] Step 402: The judgment unit determines whether the inspection task CR instance has a management tag. The management tag includes: name and UID, etc. If it does not exist, the inspection core management controller will complete the tag, update the instance tag configuration of the inspection task CR, and proceed to the next step. If it exists, proceed directly to the next step.

[0101] Step 403: Judgment Unit. This unit determines whether the inspection task CR instance has been completed. In a more preferred embodiment, this judgment can be considered complete if any condition in the status condition list (i.e., the Conditions list) is met. These conditions are: 1. Completed (Complete == True), or 2. Failed (Failed == True). If the inspection task CR instance status is completed, the inspection results are summarized and resources are released. If the instance status is incomplete, proceed to the next step.

[0102] Step 404: Judgment Unit: Determine whether the start time in the CR instance status of the inspection task has been set. If not, set it to the current time; if it has been set, proceed to the next step.

[0103] Step 405: Judgment Unit: Determine whether the Phase flag in the instance status of the inspection task CR has been set. If not, set the Phase flag to Running, i.e., in operation; if it has been set, proceed to the next step.

[0104] Step 406: Processing unit, obtain all inspection Pod instances managed by the inspection task CR instance.

[0105] Step 407: Processing unit, obtains the mapping table of Node and Inspection Pod corresponding to all Inspection Pods managed by the Inspection Task CR instance. In a more preferred embodiment, the key in the mapping table can be set to NodeName and the value can be set to the Inspection Pod instance. It should be noted that the mapping table is empty for the first created Inspection Task CR instance.

[0106] Step 408: Processing unit, obtain the Node list. This step will obtain all Nodes in the cluster, and the obtained Node list will be used as the candidate Node list for the next step of filtering.

[0107] Step 409: The processing unit filters and classifies all inspection Pod instances managed by the obtained inspection task CR instance. In a more preferred embodiment, the classification categories can be set to three categories, including: active, failed, and succeeded.

[0108] If the status of an inspected Pod is "Succeeded", it is classified into the "succeeded" category and added to the list of inspected Pods associated with the "succeeded" type. If the status of an inspected Pod is "Failed", it is classified into the "failed" category and added to the list of inspected Pods associated with the "failed" type. If the "DeletionTimestamp" attribute (i.e., the deletion marker timestamp) of an inspected Pod is defined, if the number of restarts exceeds the limit under the current judgment branch, it is classified into the "failed" category and added to the list of inspected Pods associated with the "failed" type; otherwise, it is classified into the "active" category and added to the list of inspected Pods associated with the "active" type.

[0109] Step 410: Processing Unit. Process the candidate Node list, traverse all candidate Nodes, attempt to obtain the corresponding matching item in the mapping table between the Node and the inspection Pod based on the NodeName, and perform matching processing to achieve: filtering the association mapping table of existing inspection Pods and their corresponding Nodes, and using the Node list for scheduling new inspection Pods, i.e., the WaitingForRunPodNode list, and at the same time obtain the inspection Pod instances that need to be cleaned up.

[0110] In a more preferred embodiment, the matching process described above can be performed in the following manner:

[0111] Step 4101, [Branch Condition 1] If a match exists, then execute:

[0112] [Matching Sub-item 1] Host matching processing: If the Spec.NodeName in the currently matched inspection Pod is not specified or is consistent with the current NodeName, the current match is successful and the next matching item is processed; otherwise, the current processing is interrupted and the next candidate Node is processed.

[0113] [Matching Sub-item 2] NodeSelector matching, which matches Nodes based on the NodeSelectorLabels declared by the currently inspected Pod. If the current match is successful, the process continues to the next matching item; otherwise, the current process is interrupted, and the next candidate Node is processed. NodeSelector is a node label selector that filters corresponding Nodes based on the labels on the Node. Labels exist in a key / value format.

[0114] [Matching Sub-item 3] Node Taints matching: If the current match is successful, continue processing the next match; otherwise, interrupt the current processing and continue processing the next candidate Node. Taints are taints. If a Node has a taint set, the Pod will not be scheduled to the current Node unless the Pod defines that it tolerates the taint.

[0115] [Matching Sub-item 4] Node Unschedulable Matching: Based on the Pod's Spec.Tolerations and the Node's Spec.Unschedulable, if both of these metrics are false, the current match passes, and processing continues to the next match item; otherwise, the current processing is interrupted, and the next candidate Node is processed. Unschedulable means the Node is unschedulable, which will prevent new Pods from being scheduled to that node, but will not affect any Pods already on it. Tolerations means that Pods with tolerances set can be scheduled to tainted Nodes.

[0116] [Matching Sub-item 5] Inspect Pod Resources matching. If the number of Pods scheduled on the current Node exceeds the allowed value, the current match fails, the current processing is interrupted, and the process continues to the next candidate Node. If the CPU, memory, and storage resources required by the Pod exceed the resource limit that can be allocated on the current Node, the current processing is interrupted, and the process continues to the next candidate Node. If the above checks pass, the process continues to the next matching item. Resources include the following matching dimensions: 1. The number of Pods allowed to be scheduled on the Node; 2. Whether the CPU / memory resources required by the Pod exceed the value that can be allocated by the Node, etc.

[0117] If the currently inspected Pod and the matched Node satisfy all the above matching sub-conditions, then the matched Node is added to the Desired Node list. In a more preferred implementation, the Desired Node list is an existing list of associated mappings between inspected Pods and Nodes obtained after further filtering the candidate Node list, where the key is NodeName and the value is the Pod instance. Subsequent inspection task status judgments are based on this list, such as whether the inspection task has been completed, etc. No further processing is performed on the Nodes in this list, i.e., this list is read-only.

[0118] If the current inspected Pod does not match any of the above sub-items, and the DeletionTimestamp (i.e., deletion identifier timestamp) of the inspected Pod is already set, it means that the current inspected Pod needs to be cleaned up. Then, the matched Node will be added to the Delete Pod list.

[0119] It should be noted that the order of matching sub-items 1-5 in step 4101 can be adjusted or modified individually based on actual logical needs or user habits. Furthermore, the order in this embodiment is set only for ease of description. Those skilled in the art will understand that the order cannot be interpreted as a limitation or restriction on the order of matching sub-item judgment. That is, any adjustment to the order of matching sub-items 1-5 should be considered as falling within the protection scope of this invention.

[0120] Step 4102, [Branch Condition 2]: If no matching item exists, initialize the inspection Pod instance structure and proceed to all matching sub-items under [Branch Condition 1]. If the current inspection Pod and the matched Node satisfy all the above matching sub-item conditions, add them to the WaitingForRunPod Node list. If the conditions are not met, continue with the next Node matching process. The worst case is that the final WaitingForRunPod Node list is empty, meaning there is no Node that meets the conditions for scheduling. More preferably, the obtained WaitingForRunPod Node list is used for scheduling the next inspection Pod. The inspection core control manager will allocate the corresponding Node to the newly created inspection Pod according to a certain scheduling algorithm.

[0121] The specific judgment for [branch condition 1] here is:

[0122] [Matching Sub-item 1] Host matching processing: If the Spec.NodeName in the currently matched inspection Pod is not specified or is consistent with the current NodeName, the current match is successful and the next matching item is processed; otherwise, the current processing is interrupted and the next candidate Node is processed.

[0123] [Matching Sub-item 2] NodeSelector matching, which matches Nodes based on the NodeSelectorLabels declared by the currently inspected Pod. If the current match is successful, the process continues to the next matching item; otherwise, the current process is interrupted, and the next candidate Node is processed. NodeSelector is a node label selector that filters corresponding Nodes based on the labels on the Node. Labels exist in a key / value format.

[0124] [Matching Sub-item 3] Node Taints matching: If the current match is successful, continue processing the next match; otherwise, interrupt the current processing and continue processing the next candidate Node. Taints are taints. If a Node has a taint set, the Pod will not be scheduled to the current Node unless the Pod defines that it tolerates the taint.

[0125] [Matching Sub-item 4] Node Unschedulable Matching: Based on the Pod's Spec.Tolerations and the Node's Spec.Unschedulable, if both of these metrics are false, the current match passes, and processing continues to the next match item; otherwise, the current processing is interrupted, and the next candidate Node is processed. Unschedulable means the Node is unschedulable, which will prevent new Pods from being scheduled to that node, but will not affect any Pods already on it. Tolerations means that Pods with tolerances set can be scheduled to tainted Nodes.

[0126] [Matching Sub-item 5] Inspect Pod Resources matching. If the number of Pods scheduled on the current Node exceeds the allowed value, the current match fails, the current processing is interrupted, and the process continues to the next candidate Node. If the CPU, memory, and storage resources required by the Pod exceed the resource limit that can be allocated on the current Node, the current processing is interrupted, and the process continues to the next candidate Node. If the above checks pass, the process continues to the next matching item. Resources include the following matching dimensions: 1. The number of Pods allowed to be scheduled on the Node; 2. Whether the CPU / memory resources required by the Pod exceed the value that can be allocated by the Node, etc.

[0127] It should be noted that the order of matching sub-items 1-5 in step 4102 can be adjusted or modified individually based on actual logical needs or user habits. Furthermore, the order in this embodiment is set only for ease of description. Those skilled in the art will understand that the order cannot be interpreted as a limitation or restriction on the order of matching sub-item judgment. That is, any adjustment to the order of matching sub-items 1-5 should be considered as falling within the protection scope of this invention.

[0128] In summary, after the above processing, the processing unit can complete the following data filtering:

[0129] The existing inspection Pods and their corresponding Nodes are filtered through an association mapping table; a list of Nodes that can be used for scheduling new inspection Pods, i.e., the WaitingForRunPod Node list; and inspection Pod instances that need to be cleaned up.

[0130] Step 411: Judgment Unit. If the Phase in the status corresponding to the Inspection Job instance (CR) is PhaseFailed, this may be due to concurrent processing conflicts or temporary unavailability of the status. Then, update the rescheduling delay, re-enter the queue, and wait for the next processing. Otherwise, proceed to the next judgment or processing unit. Here, Phase refers to a stage, used to identify different stages of the Pod's lifecycle. In a more preferred implementation, its enumeration values ​​can be set to: PhaseCompleted, PhaseRunning, PhasePaused, and PhaseFailed, etc.

[0131] Regarding the rescheduling delay, when the inspection task CR instance status is PhaseFailed, the inspection core control manager will attempt to retry after a certain delay, which is called the rescheduling delay.

[0132] Step 412: Judgment Unit. If the Phase corresponding to the Inspection Job instance Spec is Paused, and the Phase status is PhaseRunning or PhasePaushed, it means that the current inspection task is paused. In this case, update the rescheduling delay, re-enter the queue, and wait for the next processing. Otherwise, proceed to the next judgment or processing unit. Here, Spec stands for Specification.

[0133] Step 413: Judgment Unit. If the Phase corresponding to the Inspection Job instance Spec is not Paused, and the Phase in the CR instance status is PhasePaushed, it means that the current inspection task continues, the rescheduling delay is updated, and the task re-enters the queue to wait for the next processing; otherwise, proceed to the next judgment or processing unit.

[0134] Step 414: The processing unit determines whether the inspection task (CR) instance status is failed. Based on the list of inspection Pods associated with the failed type obtained by the aforementioned processing unit, if the length of this list is greater than 0, it means that at least one inspection Pod has failed. In a more preferred embodiment, if there are failed Pod inspections, the following failure handling strategies can be set: FailFast, TypePause, Continue, with the branch conditions as follows:

[0135] [Branch Condition 1] If the failure handling policy is FailFast, which interrupts the processing of the current inspection task CR (i.e., InspectionJob) instance, and the inspection task CR (i.e., InspectionJob) instance meets the DeadlineExceeded condition (i.e., the time limit has been exceeded), then clean up the inspection Pod corresponding to the inspection task CR (i.e., InspectionJob) instance and release cluster resources.

[0136] [Branch Condition 2] If the failure handling policy is TypePause, that is, suspend the processing of the current inspection task CR (i.e., InspectionJob) instance, update the rescheduling delay, re-enter the queue, and wait for the next processing;

[0137] [Branch Condition 3] If the failure handling strategy is Continue, that is, continue processing the current inspection task CR (i.e., InspectionJob) instance until all inspection Pods have completed (successfully or failed).

[0138] In the processing unit, if the status of the InspectionJob instance is non-failure, and the corresponding Delete Pod list is not empty, the corresponding inspection Pod in the Delete Pod list is cleaned up to release cluster resources. If the corresponding Delete Pod list is empty, it means that there are no Pods that need to be cleaned up at the current time, so subsequent processing continues.

[0139] Step 415, Processing Unit: If the DeletionTimestamp of the Inspection Job (CR) instance is not set and the previously processed WaitingForRunPod Node list is not empty, perform inspection Pod scheduling processing. The branch conditions are as follows:

[0140] [Branch Condition 1] If the number of inspection Pods currently in the active state is greater than the concurrency parameter, report the threshold over-limit event and interrupt the current unit's processing logic.

[0141] [Branch Condition 2] If the number of inspection Pods currently processing the active state is less than the concurrency parameter (here, batchSize is calculated; if the number of inspection Pods equals the concurrency parameter, min(parallelism-active,waiting) will result in 0, which is meaningless), calculate the actual concurrency value. The algorithm is as follows:

[0142] Define the variable `waiting` as the length of the `WaitingForRunPod` node list;

[0143] Define the variable parallelism as the set concurrency value;

[0144] Define the variable `active` as the length of the inspection Pod list associated with the `active` type;

[0145] Define the variable batchSize as the calculated concurrent value;

[0146] The function min takes the minimum value among the parameter values, then:

[0147] batchSize = min(parallelism-active, waiting)

[0148] The inspection core management controller concurrently creates inspection Pods by starting threads or coroutines based on the calculated batchSize. The core configuration of the inspection Pod is Spec.Affinity. The inspection core management controller binds the inspection Pods to be created to the selected Nodes using Node Affinity, thereby achieving the goal of having only one inspection Pod of the same type running on each Node. At the same time, the inspection core management controller sets the Owner Reference of the inspection Pod to itself. After that, the inspection core management controller requests the Kubernetes API Server to create the inspection Pod.

[0149] Step 416: Processing Unit. The inspection Pod runs on the corresponding Node and executes the inspection command defined in the container, such as: docker network inspect network1 in this example. When the virtual network network1 does not exist, the return code of this instruction will be a non-zero integer, which means that the inspection has failed.

[0150] Furthermore, and more preferably, the processing unit monitors the inspection Pods. The inspection core management controller obtains the status of the inspection Pods through a long-lived connection with the Kubernetes API Server, retrieves the corresponding inspection task (CR) instance through the Owner Reference of the inspection Pod, submits it to the corresponding queue of the inspection task (CR) instance, and processes the status of the inspection task (CR) instance for the corresponding branch process. Here, the Owner Reference refers to the reference to the object to which the resource belongs, specifically the inspection task (CR) instance information to which the inspection Pod belongs.

[0151] Step 417: The processing unit determines whether the status of the inspection task (CR) instance is completed. In a more preferred embodiment, a variable `status` is defined here to express the status of the inspection task (CR) instance, and the status is determined.

[0152] The branching conditions are as follows:

[0153] [Branch Condition 1] If the Desired Node list is empty, it means that the inspection task Pod corresponding to the inspection task CR (i.e., InspectionJob) instance has been completed and the status is set to: PhaseCompleted;

[0154] [Branch Condition 2] Traverse the Desired Node list, get all inspection task Pods, and if the status of all inspection task Pods is completed, set the status to: PhaseCompleted;

[0155] [Branch Condition 3] If the list of inspection Pods associated with the failed type is not empty, it means that at least one inspection task Pod is in a failed state, and the status is set to: PhaseFailed;

[0156] [Processing Unit 1] If the status is: PhaseCompleted, update the status of the inspection task CR (i.e., InspectionJob) instance to: PhaseCompleted. The specific process here is as follows: The inspection core management controller requests the Kubernetes API Server to update the status of the current inspection task CR (i.e., InspectionJob) instance to completed, and at the same time summarizes the execution status of all inspection task Pods. After this step is completed, jump to step 401 and repeat step 401 and its subsequent steps. Since the status and attributes of the inspection task CR (i.e., InspectionJob) instance have been set in the current step, there will be selective execution of the processing unit or branch judgment corresponding to step 401 and its subsequent steps. This mainly corresponds to the Delete Pod list processing in step 414, that is, cleaning up the inspection task Pods, thereby achieving the effect of releasing resources.

[0157] [Processing Unit 2] If the status is: PhaseRunning (not yet completed, in progress), update the status of the inspection task CR (i.e., InspectionJob) instance to: PhaseRunning. The specific process here is: the inspection core management controller requests the Kubernetes API Server to update the status of the current inspection task CR (i.e., InspectionJob) instance to completed. After this step is completed, jump to step 401 and repeat the processing unit or branch judgment corresponding to step 401 and its subsequent steps.

[0158] [Processing Unit 3] If the status is: PhaseFailed (not yet completed, in progress), update the status of the inspection task CR (i.e., InspectionJob) instance to: PhaseFailed. The specific process here is: the inspection core management controller requests the Kubernetes API Server to update the status of the current inspection task CR (i.e., InspectionJob) instance to completed. After this step is completed, jump to step 401 and repeat the processing unit or branch judgment corresponding to step 401 and its subsequent steps.

[0159] Example 2

[0160] In yet another specific embodiment, the solution of the present invention can also be implemented through a Kubernetes resource inspection system. In a preferred embodiment, the system may be configured to include:

[0161] The deployment module is used to send CRD creation requests to the Kubernetes API Server, initialize the corresponding CRD in the inspection management, and deploy the inspection core management controller in the cluster.

[0162] The core management controller is used to monitor inspection tasks (CR).

[0163] The inspection resource creation module is used to create business workloads based on CRD creation requests and set up the IPPool controller corresponding to the CRD to listen to the CR resource in order to complete the creation of the target inspection resource.

[0164] The inspection task creation module is used to submit a request to the Kubernetes API Server to create an inspection task (CR), and to create the inspection task CR. Once the inspection task CR is created, it enters a waiting-for-scheduling state.

[0165] The inspection module is used to obtain inspection task requests by invoking the inspection core management controller to establish a long connection with the Kubernetes API Server, and to perform inspections on the inspection tasks CR.

[0166] In a more preferred embodiment, the inspection module includes:

[0167] The inspection task CR event access unit is used to obtain information about the inspection task CR instance;

[0168] The judgment unit determines whether the inspection task CR instance has a management tag. If not, it notifies the processing unit to complete the management tag and update the tag of the inspection task CR instance. It also determines whether the inspection task CR instance has been completed, whether the start time of the inspection task CR instance has been set, and whether the start time has been set to the current time. Furthermore, it determines whether the Phase in the inspection task CR instance has been set, and whether the Phase status has been set to running. Finally, it determines the status corresponding to the Phase in the status of the inspection task CR instance, and the status of the Phase corresponding to the Spec in the inspection task CR instance.

[0169] The processing unit retrieves all inspection Pod instances managed by the inspection task CR instance, the mapping table between Nodes and inspection Pods corresponding to all inspection Pods managed by the inspection task CR instance, and a list of all Nodes in the cluster as a candidate Node list; based on the status of the inspection Pod instances, it filters and categorizes all inspection Pod instances managed by the inspection task CR instance, and adds the corresponding inspection Pods to the corresponding type of inspection Pod list; and

[0170] Iterate through all Nodes in the candidate Node list and, based on the matching of Nodes with corresponding items in the inspection Pod list, filter out the WaitingForRunPod Node list to serve as the new Node list for inspection Pod scheduling. Simultaneously, obtain the inspection Pod instances that need to be cleaned up.

[0171] The system determines whether the inspection task CR instance status is failed. If it is, the corresponding inspection Pod is cleaned up, re-entered into the queue, or continues inspection. If it is not failed, and the Delete Pod list is not empty, the corresponding inspection Pod is cleaned up to release cluster resources. If the DeletionTimestamp of the inspection task CR instance is not set, and the WaitingForRunPod Node list is not empty, inspection Pod scheduling is performed. The inspection Pod runs on the corresponding Node to execute inspection commands and is monitored. Based on the obtained inspection task CR instance, the system performs status processing for the corresponding inspection task CR instance.

[0172] Determine if the status of the inspection task CR instance is completed; if so, release resources.

[0173] More preferably, the inspection core management controller establishes a long connection with the Kubernetes API Server through InCluster mode.

[0174] When the system receives a virtual network creation request, the IPPool controller will verify whether the IP subnet is valid and at the same time verify whether the virtual network to be created already exists, so as to ensure that the corresponding virtual network is created on the corresponding Node.

[0175] In a more preferred embodiment, the IPPool controller corresponding to the CRD shares the network protocol stack with the host machine.

[0176] To facilitate the monitoring and inspection of inspection tasks (CRs), the information of the inspection task CR includes: image definition, command corresponding to container execution, concurrency parameters, timeout, number of retries on failure, etc.

[0177] In another specific implementation, this solution can be implemented using a device, which may include corresponding modules that perform one or more steps in Embodiment 1, or the Kubernetes resource inspection system provided in Embodiment 2. Therefore, each or more steps of the various embodiments described above can be performed by corresponding modules, and the electronic device may include one or more of these modules. A module may be one or more hardware modules specifically configured to perform the corresponding step, or implemented by a processor configured to perform the corresponding step, or stored in a computer-readable medium for implementation by a processor, or implemented through some combination thereof.

[0178] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this solution includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which the embodiments of this solution pertain. The processor performs the various methods and processes described above. For example, the method embodiments of this solution can be implemented as software programs tangibly contained in a machine-readable medium, such as memory. In some embodiments, part or all of the software program can be loaded and / or installed via memory and / or a communication interface. When the software program is loaded into memory and executed by the processor, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, the processor can be configured to perform one of the methods described above by any other suitable means (e.g., by means of firmware).

[0179] The logic and / or steps represented in the flowchart or otherwise described herein may be specifically implemented in any readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0180] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0181] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A Kubernetes resource inspection method, characterized in that, The method includes: Step 1: Submit a CRD creation request to the Kubernetes API Server to initialize the corresponding CRD in the inspection management and deploy the inspection core management controller; the inspection core management controller is used to listen to inspection tasks (CRs). Step 2: Create the business workload according to the CRD creation request, and set the IPPool controller corresponding to the CRD to listen to the CR resource to complete the creation of the target inspection resource; Step 3: Submit a request to the Kubernetes API Server to create an inspection task (CR). Once the inspection task (CR) is created, it will be in a waiting-for-scheduling state. Step 4: The inspection core management controller obtains inspection task requests by establishing a long connection with the Kubernetes API Server and executes the inspection of the inspection task CR. The inspection of the inspection task CR in step 4 includes: Step 401: Obtain information about the inspection task CR instance; Step 402: Determine if the inspection task CR instance has a management tag. If not, complete the management tag. Step 403: Determine whether the inspection task CR instance has been completed. If it has been completed, summarize the inspection results, release resources, and complete the inspection. Otherwise, determine whether the start time of the inspection task CR instance has been set. If not, set the start time to the current time. If it has been set, determine whether the Phase in the inspection task CR instance has been set. If not, set the Phase status to running. If it has been set, proceed to the next step. Step 404: Obtain all inspection Pod instances managed by the inspection task CR instance; obtain the Node and Pod mapping table corresponding to all inspection Pods managed by the inspection task CR instance; obtain a list of all Nodes in the cluster as a candidate Node list. Step 405: Based on the status of the inspection Pod instances, filter and classify all the obtained inspection Pod instances, and add the corresponding inspection Pods to the inspection Pod list of the corresponding type. Step 406: Traverse the Nodes in the candidate Node list, and based on the matching process between the Nodes and the corresponding matching items in the inspection Pod list, filter out the WaitingForRunPod Node list as the new Node list for inspection Pod scheduling, and at the same time obtain the inspection Pod instances that need to be cleaned up. Step 407: Determine the Phase status in the CR instance of the inspection task. If it is PhaseFailed, update the rescheduling delay, re-enter the queue, and wait for the next processing. Otherwise, determine the Phase status corresponding to the Spec in the CR instance of the inspection task. If it is Paused, and the Phase status in the CR instance of the inspection task is PhaseRunning or PhasePaushed, update the rescheduling delay, re-enter the queue, and wait for the next processing. If the Phase status corresponding to the Spec is not Paused, and the Phase status in the CR instance of the inspection task is PhasePaushed, update the rescheduling delay, re-enter the queue, and wait for the next processing. Otherwise, proceed to the next step. Step 408: Determine if the status of the inspection task CR instance is failed. If it is failed, clean up the inspection Pod corresponding to the inspection task CR instance, re-enter the queue, or continue the inspection process. If it is not failed, clean up the inspection Pod corresponding to the Delete Pod list and release cluster resources when the Delete Pod list is not empty. Otherwise, proceed to the next step. Step 409: If the DeletionTimestamp of the inspection task CR instance is not set and the WaitingForRunPodNode list is not empty, then perform inspection Pod scheduling. Step 410: The inspection Pod runs on the corresponding Node to execute inspection commands and monitors the inspection Pod. Based on the obtained inspection task CR instance, the status processing of the corresponding inspection task CR instance is performed during monitoring. Step 411: Obtain the execution status of the inspection task Pod and the inspection task CR instance to which the inspection task Pod belongs, and send the obtained inspection task CR instance information to step 401, and execute step 401.

2. The method according to claim 1, characterized in that, In step 1, the inspection core management controller establishes a long connection with the Kubernetes API Server through InCluster mode.

3. The method according to claim 1, characterized in that, In step 2, when a virtual network creation request is received, the IPPool controller will verify whether the IP subnet is valid and at the same time verify whether the virtual network to be created already exists, so as to ensure that the corresponding virtual network is created on the corresponding Node.

4. The method according to claim 1, characterized in that, In step 2, the IPPool controller corresponding to the CRD shares the network protocol stack with the host machine.

5. The method according to claim 1, characterized in that, In step 3, the information of the inspection task CR includes: image definition, command corresponding to container execution, concurrency parameters, timeout, and number of retries for failure.

6. The method according to claim 1, characterized in that, In step 406, the matching process includes: Step 4061: If a matching item exists, match each matching sub-item one by one; when the conditions of all matching sub-items are met, add the corresponding Node to the Desired Node list; if the conditions of any matching sub-item are not met, and the DeletionTimestamp of the inspection Pod has been set, add the Node to the Delete Pod list in preparation for cleaning up the corresponding inspection Pod. Step 4062: If no matching item exists, initialize the inspection Pod instance and match each matching sub-item one by one. When the conditions of all matching sub-items are met, add the corresponding Node to the WaitingForRunPod Node list.

7. The method according to claim 1, characterized in that, Step 408 further includes: if the inspection task CR instance status is determined to be failed, then the following processing strategies are set: FailFast, TypePause, Continue, with the corresponding processing strategies as follows: FailFast: This interrupts the processing of the current inspection task CR instance. If the inspection task CR instance meets the timeout condition, the inspection Pod corresponding to the inspection task CR instance is cleaned up and resources are released. TypePause: This pauses the processing of the current inspection task CR instance, updates the rescheduling delay, and re-enters the queue to wait for the next processing. Continue: This means continuing the processing of the current inspection task CR instance until all inspection Pods have finished running.

8. A Kubernetes resource inspection system, characterized in that, The system is used to execute the Kubernetes resource inspection method according to claim 1, and the system includes: The deployment module is used to send CRD creation requests to the Kubernetes API Server, initialize the corresponding CRD in the inspection management, and deploy the inspection core management controller in the cluster. The core management controller is used to monitor inspection tasks (CR). The inspection resource creation module is used to create business workloads based on CRD creation requests and set up the IPPool controller corresponding to the CRD to listen to the CR resource in order to complete the creation of the target inspection resource. The inspection task creation module is used to submit a request to the Kubernetes API Server to create an inspection task (CR), and to create the inspection task CR. Once the inspection task CR is created, it enters a waiting-for-scheduling state. The inspection module is used to obtain inspection task requests by invoking the inspection core management controller to establish a long connection with the Kubernetes API Server, and to perform inspections on the inspection tasks CR.

9. A Kubernetes resource inspection device, characterized in that, The device includes a processor and a memory, the memory storing instructions that can be read by the processor; the processor is used to invoke the instructions in the memory to execute the Kubernetes resource inspection method as described in any one of claims 1-7.

Images