A cloud-edge collaborative message redundancy elimination method, device and medium for KubeEdge

Abstract

This invention discloses a method, device, and medium for eliminating message redundancy in cloud-edge collaboration for KubeEdge. By pre-marking the data before the patch operation, creating a pre-marked record with the state of Intent, and then performing the actual patch operation, the system receives confirmation information from the API Server containing the updated resource version number. The marked record's state is updated to Confirmed, and the updated resource version number returned by the API Server is entered. Watch events sent to edge nodes are monitored and intercepted. Through its internally maintained update record (PatchRecord) state machine, unnecessary duplicate messages triggered by the patch operation are accurately identified and intercepted. This significantly reduces cloud-edge network bandwidth consumption, reduces redundant message transmission between the cloud and edge, lowers network bandwidth consumption, and improves the overall efficiency and resource utilization of the KubeEdge system.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge collaborative caching technology, and specifically to a method, device, and medium for eliminating cloud-edge collaborative message redundancy for KubeEdge. Background Technology

[0002] In the KubeEdge edge computing architecture (an open-source cloud-native edge computing platform), when the cloud controller performs a Patch operation on a Pod (the smallest scheduling unit in Kubernetes, typically referring to one or more container groups) or Node (defined as a node in Kubernetes), it triggers update events from the Watch mechanism. These update events are captured by the DownstreamController (the component responsible for issuing instructions from the cloud to the edge) and sent to the corresponding edge nodes via the cloud-edge messaging channel. However, this mechanism has the following key issues:

[0003] Problem 1: Cloud-edge message duplication issue;

[0004] After the patch operation is completed, the cloud-based Kubernetes API Server (Kubernetes: an open-source container orchestration system; API Server: the sole entry point for cluster resource operations) generates a corresponding update event. The downstream controller's `syncPod` (function that synchronizes Pods to the edge) and `syncEdgeNodes` (function that synchronizes Nodes to the edge) modules capture these events and convert them into cloud-edge messages, which are then sent to the edge. Simultaneously, the `syncController` (component that synchronizes cloud-edge resources via ACK) module detects the resource version inconsistency and triggers the update event again. This results in the same resource update being sent twice to the edge nodes, causing redundant transmission of cloud-edge messages.

[0005] Question 2: Waste of bandwidth in cloud-edge networks;

[0006] In edge computing scenarios, cloud-edge network bandwidth is a precious and limited resource. Especially in large-scale edge node deployment environments, the repeated transmission of messages for each Pod or Node can accumulate into significant bandwidth waste. For example, if there are 1,000 edge nodes, each with 10 Pods, and each Pod's update message is transmitted repeatedly, it will generate 10,000 unnecessary network messages.

[0007] Question 3: The processing burden on edge nodes;

[0008] Edge nodes need to process these repetitive update messages, including message parsing, resource updates, and state synchronization. This not only wastes computing resources but also carries the risk of state inconsistency due to repeated processing. Summary of the Invention

[0009] The technical problem this invention aims to solve is that the same resource update is processed by multiple modules, generating duplicate messages. This lack of event source identification and filtering mechanisms leads to unnecessary duplicate message consumption of cloud-edge bandwidth. The goal is to provide a method, device, and medium for eliminating message redundancy in cloud-edge collaboration for KubeEdge. This is achieved by pre-marking the update before the patch operation and intelligently matching and filtering during update event distribution. The system introduces a core intelligent management component called RetryPatchMarker into the cloud-edge collaborative architecture. Through its internally maintained PatchRecord state machine, it accurately identifies and intercepts unnecessary duplicate messages triggered by patch operations, thereby significantly reducing cloud-edge network bandwidth consumption, reducing redundant message transmission between the cloud and edge, and improving the overall efficiency and resource utilization of the KubeEdge system.

[0010] This invention is achieved through the following technical solution:

[0011] The first aspect of this invention provides a method for eliminating redundancy in cloud-edge collaborative messages for KubeEdge, comprising the following specific steps:

[0012] Create a pre-tagged record with the status of Intent. The pre-tagged record contains resource identification information. In the current status, the resource version number of the resource identification information is empty.

[0013] Perform the actual patch operation and receive confirmation information from the API Server, including the updated resource version number;

[0014] Update the status of the pre-marked record to Confirmed, and fill in the updated resource version number returned by the API Server;

[0015] Listen for and intercept Watch events sent to edge nodes, and extract resource identification information and event resource version number from the events;

[0016] Perform resource version matching checks on the extracted resource identifier information and event resource version number, and assign matching count values ​​to the corresponding pre-marked records based on the matching count;

[0017] The message delivery decision is determined based on the matching count assigned to the pre-marked records and its preset threshold:

[0018] If the resource version matches but the matching count has not reached the threshold: skip the process, keep the record, and do not send out the event;

[0019] If the resource version matches and the match count reaches the threshold: skip the process, delete the record, and do not send out the event.

[0020] If the resource version does not match: skip the process and the event is sent normally.

[0021] Furthermore, the step of performing a resource version matching check on the extracted resource identifier information and event resource version number specifically includes:

[0022] S1. Initialize the retry counter attempt to the initial value and obtain the preset maximum number of retries;

[0023] S2. Determine whether the current retry counter value is less than the maximum number of retries;

[0024] If so, proceed to step S3;

[0025] If not, proceed to step S6;

[0026] S3. Call the matching decision method checkAndSkip, and combine it with the current retry counter value to return two boolean values:

[0027] The first Boolean value, skip, indicates whether the current event should be skipped.

[0028] The second Boolean value, shouldRetry, indicates whether a retry is recommended.

[0029] S4. Determine whether the second Boolean value is true;

[0030] If the second Boolean value is false, the first Boolean value is returned directly as the final decision result, and the process ends.

[0031] If the second Boolean value is true, proceed to step S5;

[0032] Step S5: Increment the value of the retry counter by 1, wait for a preset short time interval, and then return to step S2 to continue the next round of loop judgment;

[0033] Step S6: When the number of retries reaches the maximum number of retries, execute the last core matching logic call and use the first boolean value returned by it as the final decision result, and the process ends.

[0034] Furthermore, the matching decision method checkAndSkip specifically includes:

[0035] S31. Obtain the resource identifier, event resource version, and current attempt count;

[0036] S32. Based on the resource identifier and in conjunction with the patch record mapping, obtain the historical update record linked list corresponding to the resource identifier;

[0037] S33. Perform a non-empty check on the updated record list;

[0038] S34. Traverse the verified record list and filter out valid pre-marked records;

[0039] S35. Determine the record status based on the status field of the record linked list, where the record status includes:

[0040] The Confirmed status has been verified.

[0041] Intent or Pending status;

[0042] S36. After traversing all records in the record list, determine the final return result based on whether a valid state is matched, and whether it is necessary to skip the current event or trigger a retry mechanism.

[0043] Furthermore, the step of performing a non-empty check on the updated record list specifically includes determining whether the obtained record list exists and is not empty:

[0044] If the linked list is nil or empty, the current resource identifier does not have a pre-marked or updated record, the current event is not triggered by a known Patch operation, and the third result set is returned directly without skipping the event delivery and without retrying.

[0045] If the linked list is not empty, proceed to step S33.

[0046] Furthermore, the step of traversing the verified record list and filtering valid pre-marked records specifically includes:

[0047] For each pre-marked record encountered, check if its ExpiryTime field is earlier than the current time:

[0048] If it is earlier than the current time, the currently pre-marked record is invalid and should be deleted.

[0049] If it is not earlier than the current time, the currently pre-marked record is valid.

[0050] Furthermore, if the recorded status is determined to be "Confirmed", then the following operations are performed:

[0051] Determine if the ResourceVersion field of the current record is exactly equal to the input parameter eventRV;

[0052] If they are equal, it is determined that the resource version is an exact match, and the following actions are taken:

[0053] Increment the MatchedCount count of the current record by 1;

[0054] Update the current record's expiry time (ExpiryTime) to the current time plus the maximum record retention time (maxRecordAge);

[0055] Determine whether the updated MatchedCount is greater than or equal to the preset threshold maxMatchCount;

[0056] If so, mark the current record as pending deletion so that it can be removed after the traversal is complete;

[0057] If not, retain the current record and continue processing;

[0058] Return the first result set, which contains true and false values ​​to indicate that a matching record has been found, and the current event should be skipped without retrying.

[0059] If they are not equal, it is determined that the resource version is mismatched, and the process continues to traverse the next record.

[0060] Furthermore, if the recorded status is determined to be either an Intent or a Pending status, the following operations are performed:

[0061] If the current record's status is Intent, then update it to Pending;

[0062] Increment the match attempt count (MatchAttempts) for the current record by 1;

[0063] Determine if the current record is within the valid waiting time window and if the current MatchAttempts value is less than the maximum number of retries minus 1;

[0064] If so, set the internal retry flag shouldRetry to true.

[0065] If not, then keep shouldRetry as false;

[0066] Return a second result set containing the false value and the value of the shouldRetry flag to indicate that no Confirmed match was found at present, and to suggest to the caller whether to retry later based on the shouldRetry flag.

[0067] Furthermore, if multiple records in the linked list are traversed and neither the first nor the second result set is returned, the following judgment is performed on the currently traversed record:

[0068] If the record's status is Confirmed, and the record matches the event view eventRV to be processed;

[0069] If no record is found that is in the Intent / Pending state and requires waiting;

[0070] Then execute the third result set, which indicates that the event should be skipped and no retry is required.

[0071] A second aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements a cloud-edge collaborative message redundancy elimination method for KubeEdge.

[0072] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for eliminating cloud-edge collaborative message redundancy for KubeEdge.

[0073] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0074] 1. Pre-labeling mechanism: Record the intent before the Patch operation is executed, and establish the "operation-event" association;

[0075] 2. Precise resource version matching: Accurately identify the source of an event by using the Kubernetes resource version number;

[0076] 3. Match count threshold: Set a configurable threshold for the number of matches, providing a flexible filtering strategy;

[0077] 4. Instant record cleanup: Records are deleted immediately upon reaching the matching threshold to prevent memory leaks;

[0078] 5. Dual interception point design: Interception is carried out simultaneously in the downstream controller and the synchronization controller to ensure no omissions;

[0079] 6. State Machine Management: Track the entire lifecycle of a patch through Intent / Pending / Confirmed states;

[0080] 7. Concurrency safety design: Ensure data consistency in a multi-coroutine environment through read-write locks;

[0081] 8. Automatic cleanup mechanism: Background coroutines periodically clean up expired records to ensure system stability. Attached Figure Description

[0082] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0083] Figure 1 This is a flowchart of the existing patch operation and event dispatch process in KubeEdge in this embodiment of the invention;

[0084] Figure 2 This is the cloud-edge message deduplication system architecture based on pre-labeling in this embodiment of the invention;

[0085] Figure 3 This is a complete flowchart of the Patch operation in this embodiment of the invention;

[0086] Figure 4 This is a complete flowchart of the Patch operation in this embodiment of the invention;

[0087] Figure 5 This is a flowchart of the checkAndSkip algorithm in an embodiment of the present invention. Detailed Implementation

[0088] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0089] In this embodiment, KubeEdge is an open-source edge computing platform that extends Kubernetes' native container orchestration capabilities to edge computing environments. Cloud-edge messaging refers to communication messages transmitted over the network between the cloud control plane and edge nodes.

[0090] Resource Version (RV): In Kubernetes, each resource object has a unique resource version identifier to identify its version. Each update changes the resource version. Pre-marking: Before executing a patch operation, the intent of the patch operation is recorded so that events triggered by that operation can be identified later. syncController: The controller component in KubeEdge responsible for synchronizing resource state between the cloud and the edge. Redundant Distribution: The same resource update event is sent multiple times to edge nodes, causing unnecessary network transmission.

[0091] KubeEdge is a CNCF (Cloud Native Computing Foundation) incubation project designed to extend Kubernetes' container orchestration capabilities to edge computing environments. In the KubeEdge architecture, cloud-edge communication is a core component, primarily including:

[0092] 1. Cloud Core: Runs in the cloud and includes modules such as EdgeController (which manages metadata for edge nodes and other resources) and DeviceController (which manages edge devices);

[0093] 2. Edge Core: Runs on edge nodes, including modules such as EdgeHub (edge ​​hub, responsible for communication with the cloud) and MetaManager (edge ​​metadata manager);

[0094] 3. Message Bus: Responsible for message transmission between the cloud and the edge, supporting protocols such as WebSocket (a full-duplex communication protocol) and QUIC (a low-latency transmission protocol based on UDP);

[0095] In the standard KubeEdge workflow, the resource synchronization process is as follows:

[0096] 1. Changes occur to resources in the cloud-based Kubernetes API Server (CRUD operations).

[0097] 2. EdgeController captures these change events through the Watch mechanism;

[0098] 3. The event is converted into a cloud-edge message format;

[0099] 4. Send the message to the corresponding edge node via the message bus;

[0100] 5. Edge nodes receive and apply these updates, keeping them in sync with the cloud.

[0101] Based on the above, in the unoptimized KubeEdge, patch operations and event dispatching are two independent processes, such as... Figure 1 As shown, the main operating procedures include:

[0102] 1. Patch operation triggering phase:

[0103] The cloud controller calls the Kubernetes API to execute Pod / Node patch operations;

[0104] The API Server performs updates, modifies resource objects, and updates resource versions.

[0105] Return the updated result to the caller;

[0106] 2. Event capture phase:

[0107] The EdgeController (the core cloud component in the KubeEdge architecture, responsible for metadata synchronization and communication control between the Kubernetes (K8s) cloud and edge nodes (EdgeCore). It acts as a bridge between the K8s API Server and edge nodes, enabling key cloud-edge collaboration functions) uses a Watch mechanism to capture update events through its podManager / nodeManager.

[0108] The syncPod / syncEdgeNodes method handles these events;

[0109] Convert events into cloud-edge message format;

[0110] Send to edge nodes via the message layer;

[0111] 3. Synchronous detection phase:

[0112] The syncController periodically checks ObjectSync / ClusterObjectSync (a Kubernetes custom resource used to record the synchronization status of cloud-edge resources).

[0113] resource;

[0114] Compare the differences in resource versions between the cloud and the edge;

[0115] If a version inconsistency is detected, an update event is triggered.

[0116] It is then sent again to the edge node through the message layer.

[0117] Therefore, existing technologies lack a mechanism to distinguish whether an event is directly triggered by a user action or indirectly triggered by a patch operation. This leads to: the same resource update being processed by multiple modules, generating duplicate messages; a lack of mechanisms for identifying and filtering the source of events; and unnecessary duplicate messages consuming cloud-edge bandwidth.

[0118] In existing technologies, after a patch operation is completed, the API Server generates an update event. The EdgeController's Watch mechanism captures this event, and the syncPod / syncEdgeNodes module processes and distributes it. Subsequently, the syncController checks the resource version and finds that the cloud resource version is newer than the edge version, triggering a synchronization operation and distributing the update again. Since the same resource update is processed by two independent mechanisms, two identical update messages are generated, leading to wasted cloud-edge network bandwidth and reduced message transmission efficiency. Edge nodes repeatedly receiving the same update messages require repeated processing of the same resource updates, resulting in wasted computing resources and potentially introducing state inconsistency risks. In large-scale edge computing environments, the large number of nodes amplifies the accumulation of duplicate messages on each node, reducing overall system efficiency and limiting scalability.

[0119] As a possible implementation, to address the aforementioned problems, this embodiment provides a method for eliminating message redundancy in KubeEdge cloud-edge collaboration. It aims to solve the problem in cloud-edge collaboration architectures such as KubeEdge where redundant update events triggered by patch operations on Pod or Node resources lead to redundant messages consuming cloud-edge network bandwidth. This is achieved by pre-marking the update events before execution and intelligently matching and filtering them during update event distribution. The system introduces a core intelligent management component called RetryPatchMarker into the cloud-edge collaboration architecture. Through its internally maintained PatchRecord state machine, it accurately identifies and intercepts unnecessary duplicate messages triggered by patch operations, thereby significantly reducing cloud-edge network bandwidth consumption. Figure 2 As shown:

[0120] This system architecture primarily runs within the CloudCore component of KubeEdge. When the Cloud Controller needs to perform a patch operation on a Pod or Node resource, it first calls the Kubernetes API Server (Kubernetes is an open-source container orchestration system; the API Server is the sole entry point for cluster resource operations). After the API Server performs the update and generates a new resource version (Resource Version, RV, a field in Kubernetes used to identify resource version numbers), it triggers the standard Kubernetes Watch mechanism, generating an update event.

[0121] The key improvement of this invention lies in the introduction of the centralized RetryPatchMarker component. This component internally maintains a map, where the key is the resource name and the value is a linked list of update records corresponding to that resource. Each update record (PatchRecord) contains key information such as status and resource version (RV).

[0122] The workflow is as follows:

[0123] 1. Pre-marking: Before the Controller initiates the actual patch operation to the API Server, it first calls the RecordPatchIntent method of RetryPatchMarker to create a record with the status of Intent. At this time, the resource version is empty.

[0124] 2. Record the results: After the patch operation is completed, call the RecordPatchResult method to update the corresponding record status to Confirmed and fill in the new resource version number returned from the API Server.

[0125] 3. Event interception: Before receiving a Watch event and preparing to send a message to the edge node, multiple modules within CloudCore that may send events (such as the Downstream Controller responsible for Pod synchronization, the Sync Controller responsible for state synchronization, etc.) will act as event dispatch interceptors and uniformly call the ShouldSkip method of RetryPatchMarker to make a judgment.

[0126] 4. Intelligent Matching and Decision-Making: The ShouldSkip method executes the core matching logic. It searches for matching records in the RetryPatchMarker based on the resource name and version number carried by the event. If a record with a Confirmed status and an identical resource version number is found, the MatchedCount for that record is incremented by 1. If the MatchedCount reaches a preset threshold (e.g., 2 times), the event is determined to be a duplicate event triggered by the current Patch operation and should be filtered out.

[0127] 5. Message delivery decision: The ShouldSkip method returns a boolean value. If true, the message delivery is skipped; if false, the message is allowed to be delivered normally to the edge node.

[0128] This architecture ensures that only non-repeating, necessary update messages consume cloud-edge network bandwidth, thereby achieving the optimization goal.

[0129] like Figure 3 As shown, a complete process from the initiation of a Patch operation to the eventual triggering of message delivery is presented, clearly depicting how RetryPatchMarker intervenes and manages this lifecycle, specifically including:

[0130] 1. Pre-marking (RecordPatchIntent): When a controller (such as DownstreamController) decides to patch a resource (such as a Pod), it first calls the RetryPatchMarker.RecordPatchIntent(resource) method. This method immediately creates a new PatchRecord for the resource within the RetryPatchMarker, sets its state to Intent, and then inserts this record at the head of the linked list corresponding to the resource. This pre-marking step is the starting point of the entire method; it announces that a patch operation for this resource is about to occur.

[0131] 2. Patch Execution and Recording Results (RecordPatchResult): The controller then calls the Kubernetes APIServer to perform the actual patch operation. Upon successful processing by the APIServer, it returns an updated resource object containing the new resource version number (newRV). The controller then calls RetryPatchMarker.RecordPatchResult(resource, newRV). This method searches for the latest Intent or Pending status record for the resource, updates its status to Confirmed, and populates the ResourceVersion field with newRV. If no suitable record is found (possibly because it has been cleaned up), a new Confirmed status record is created.

[0132] 3. Event Capture and Smart Matching (ShouldSkip): Patch operations increment the resource version on the API Server and trigger Watch events. Event handling modules in CloudCore (such as syncPod or syncController) capture these events. Before converting these events into messages and sending them to edge nodes, the `RetryPatchMarker.ShouldSkip(resource, eventRV)` method is called for judgment. This method executes the core matching logic: searching the resource's record list for a record with a `Confirmed` status and whose `ResourceVersion` exactly matches the `eventRV` carried by the event. If found, a match count and threshold judgment are performed.

[0133] 4. Decision-making and Action:

[0134] Matching but not reaching the threshold: ShouldSkip returns true, but the record is retained. The event is skipped and not sent. This handles the first event after the Patch operation.

[0135] If a match is found and the threshold is reached: ShouldSkip returns true and the record is immediately deleted (because its mission has been completed, preventing memory leaks). The event is skipped. This handles subsequent duplicate events that might be triggered by a synchronization controller, etc.

[0136] Not matched: ShouldSkip returns false, and the event is sent normally. This indicates that the update was not triggered by the previous Patch operation, but may have been caused by other operations (such as a direct Update), and needs to be synchronized to the edge.

[0137] As described above, the `ShouldSkip` method, which handles event capturing and intelligent matching, includes a possible retry mechanism to handle the rare occurrence of a small time difference between the completion of the `Patch` operation and the arrival of the `Watch` event (i.e., the `RecordPatchResult` call is slightly later than the `ShouldSkip` call). Its internal logic is as follows: Figure 4 As shown, the ShouldSkip method does not simply call checkAndSkip once, but includes a lightweight retry loop to enhance robustness in concurrent environments.

[0138] 1. Initialization and Loop Condition Check: At the start of the method, the retry counter `attempt` is initialized to 0. As long as `attempt` is less than the maximum number of retries (`maxRetries`, e.g., 5 times), the loop will continue.

[0139] 2. Calling the core matching logic: In each loop, the internal checkAndSkip method is called, passing in the current attempt value. The checkAndSkip method performs the specific record matching work and returns two boolean values: skip (whether to skip at present) and shouldRetry (whether to suggest retrying).

[0140] 3. Retry Decision: The `shouldRetry` returned by the `checkAndSkip` method is typically true when it finds a record with a status of Intent or Pending, indicating that a Patch operation has been marked but may not yet be completed (i.e., `RecordPatchResult` has not been called), and the time elapsed since the record was created is still within a reasonable waiting window. If `shouldRetry` is false, the current skip result is returned immediately, ending the process. If it is true, the attempt count is incremented, and a short time interval (`retryInterval`, e.g., 150 milliseconds) is waited before proceeding to the next iteration of the loop.

[0141] 4. Exit the loop: When the maximum number of retries is reached, regardless of the value of shouldRetry, a final checkAndSkip call will be made, and the skip value returned by it will be used as the final decision, thereby avoiding indefinite waiting.

[0142] The checkAndSkip method is the core matching decision engine in this embodiment. See the flowchart below. Figure 5As shown, its logical complexity is the highest, directly determining the accuracy of message deduplication and system efficiency. This method takes the resource name, event resource version, and current attempt count as input. By traversing the historical update records of the resource, it performs a series of precise state checks and version matching, and finally outputs two boolean values: foundMatch (whether a match is found and should be skipped) and shouldRetry (whether to suggest the caller to retry later).

[0143] 1. Algorithm Startup and Initial Checks

[0144] The node "checkAndSkip start": The algorithm begins execution, with the input parameters being the resource identifier, the event resource version (eventRV), and the current number of attempts (attempt).

[0145] The node "Get Resource Record List": Based on the input resource identifier, the algorithm retrieves the linked list of historical update records corresponding to the resource from the patchRecords mapping managed internally by RetryPatchMarker.

[0146] Determine if the record list exists and is not empty: This is the first key decision point.

[0147] No: If the list is nil or empty, it means there are no pre-tagged or updated records for this resource in the system. The algorithm proceeds directly down the "No" path, executing "Return (false, false)". This means the current event was not triggered by a known Patch operation, should not be skipped, and does not need to be retried.

[0148] Yes: If the list is not empty, the core processing loop is entered, and the process points to "traversing each record".

[0149] 2. Record traversal and expiration filtering

[0150] The node "Traverse each record": The algorithm begins by sequentially traversing the linked list of records. It typically starts with the latest record.

[0151] Determine if a record has expired: For the record currently being iterated over, check if its ExpiryTime field is earlier than the current time.

[0152] Yes: The record has expired. The algorithm follows the "Yes" path and executes "Skip and continue to the next record". This record is ignored, and the process returns to the "Traverse each record" node to process the next record. This implements a mechanism to automatically clean up expired data.

[0153] No: Record is valid. The process proceeds to the core "Record Status Judgment" node.

[0154] 3. Core Status Judgment and Handling

[0155] The "Record Status Judgment" node is the watershed of the algorithm. Based on the recorded Status field value, the process is divided into two clear processing directions:

[0156] Option 1: Status is Confirmed.

[0157] Determine if "Resource version exact match?": Compare the ResourceVersion field of the current record with the input parameter eventRV to see if they are exactly equal.

[0158] Match successful: The algorithm continues down the "Yes" path, executing "MatchedCount + 1 to refresh expiration time". This operation includes:

[0159] 1. Increment the MatchedCount (number of successful matches) of the record by 1.

[0160] 2. Update the recorded ExpiryTime to "current time + maxRecordAge" to extend its validity period.

[0161] Then, determine "MatchedCount >= threshold?" (Here, the threshold is maxMatchCount).

[0162] Yes: "Mark the record for immediate deletion". This record will be removed after the traversal is complete, implementing an immediate cleanup strategy.

[0163] No: "Continue processing", keep the record.

[0164] Regardless of whether the record is deleted, the event will ultimately return "(true, false)". This indicates that a match has been found, the current event should be skipped, and no retry is necessary.

[0165] Match failed: The algorithm follows the "No" path and executes "Continue to the next record". The process returns to the "Traverse each record" node and checks the next record in the linked list.

[0166] Option 2: Status is Intent or Pending

[0167] The algorithm executes the following: "If the record is intent, change it to pending." If the record state is Intent, then update it to Pending.

[0168] Next, execute "MatchAttempts+1 to set the shouldRetry flag", which includes:

[0169] 1. Increment the recorded MatchAttempts (number of match attempts) by 1.

[0170] 2. Judgment: If the record is still within a reasonable waiting time window (e.g., it has not exceeded maxRetries*retryInterval since its creation), and the current attempt value is less than the maximum number of retries minus 1, then set the internal shouldRetry flag to true.

[0171] The algorithm then executes a "return (false, true)" statement. This indicates that no Confirmed match was found, but suggests that the caller (the ShouldSkip method) retry later. This mechanism provides fault tolerance to handle the extremely short time lag between the completion of the Patch operation and the arrival of the event.

[0172] 4. End of traversal and return of results

[0173] If, after traversing all records in the linked list, no "return (true, false)" or "return (false, true)" is triggered on any record, then it means:

[0174] 1. No Confirmed record was found that matches eventRV.

[0175] 2. No records were found that were in the Intent / Pending state and required waiting.

[0176] At this point, the algorithm will execute "return (false, false)". This indicates that the event should not be skipped and there is no need to retry.

[0177] 5. End point of the process

[0178] All possible execution paths will eventually converge at the "end" node, completing this checkAndSkip call.

[0179] In some possible implementations, the problem of duplicate messages caused by patch operations in KubeEdge is fundamentally solved by introducing a pre-label-based intelligent filtering mechanism. Its advantages can be derived through the following logical chain:

[0180] First-level advantages (direct effects):

[0181] By identifying Patch operations through pre-labeling, the source of events can be accurately distinguished;

[0182] Filtering duplicate events by matching counts can reduce the transmission of duplicate messages;

[0183] The dual interception point design ensures comprehensive coverage of all event paths.

[0184] Second-level advantages (system effects):

[0185] Reducing duplicate message transmissions can lower cloud-edge network bandwidth consumption (estimated to reduce update messages by 30%-50%).

[0186] Avoiding redundant processing at edge nodes can save edge computing resources;

[0187] Cleaning up matching records in a timely manner can prevent memory leaks and improve system stability.

[0188] Third-level advantages (business value):

[0189] Reducing network bandwidth consumption can reduce operating costs, making it particularly suitable for large-scale edge deployments;

[0190] Improving message transmission efficiency can enhance system response speed and real-time performance;

[0191] Reducing edge processing load can improve the availability and reliability of edge nodes;

[0192] The transparent implementation allows for compatibility with the existing Kubernetes ecosystem without requiring modifications to existing business logic.

[0193] Fourth-level advantages (technical advantages):

[0194] Accurate event source identification can avoid false filtering and missed filtering;

[0195] Configurable filtering policies can adapt to different business scenarios and network environments;

[0196] A robust fault-tolerance mechanism can handle edge cases such as network latency and concurrent operations;

[0197] Detailed monitoring and statistics can provide observability of the system's operating status.

[0198] Specifically, in large-scale edge computing scenarios, assuming 1000 edge nodes, each running an average of 50 Pods, and each Pod generating 10 updates per day, this invention can reduce the number of messages by: 1000 nodes × 50 Pods / node × 10 updates / day × 50% deduplication rate = 250,000 messages / day. Assuming each message is 1KB, this saves approximately 250MB of network traffic per day, significantly reducing cloud-edge communication costs.

[0199] In some possible implementations, the method of this embodiment has good scalability and can support deduplication of more resource types (such as ConfigMap, Secret, etc.) in the future, adaptive parameter adjustment based on machine learning, collaborative filtering in distributed deployment scenarios, integration with Quality of Service (QoS) policies, and cross-cloud deduplication in multi-cloud edge scenarios. This method can significantly improve cloud-edge communication efficiency and reduce operating costs without changing the core architecture of KubeEdge, providing key technical support for large-scale edge computing deployments.

[0200] As one possible implementation, this embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements a cloud-edge collaborative message redundancy elimination method for KubeEdge.

[0201] As one possible implementation, this embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a cloud-edge collaborative message redundancy elimination method for KubeEdge.

[0202] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for eliminating message redundancy in cloud-edge collaboration for KubeEdge, characterized in that, The specific steps include the following: Create a pre-tagged record with the status of Intent. The pre-tagged record contains resource identification information. In the current status, the resource version number of the resource identification information is empty. Perform the actual patch operation and receive confirmation information from the API Server, including the updated resource version number; Update the status of the pre-marked record to Confirmed, and fill in the updated resource version number returned by the API Server; Listen for and intercept Watch events sent to edge nodes, and extract resource identification information and event resource version number from the events; Perform resource version matching checks on the extracted resource identifier information and event resource version number, and assign matching count values ​​to the corresponding pre-marked records based on the matching count; The message delivery decision is determined based on the matching count assigned to the pre-marked records and its preset threshold: If the resource version matches but the matching count has not reached the threshold: skip the process, keep the record, and do not send out the event; If the resource version matches and the match count reaches the threshold: skip the process, delete the record, and do not send out the event. If the resource version does not match: skip the process and the event is sent normally.

2. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 1, characterized in that, The process of performing a resource version matching check on the extracted resource identifier information and the event resource version number specifically includes: S1. Initialize the retry counter attempt to the initial value and obtain the preset maximum number of retries; S2. Determine whether the current retry counter value is less than the maximum number of retries; If so, proceed to step S3; If not, proceed to step S6; S3. Call the matching decision method checkAndSkip, and combine it with the current retry counter value to return two boolean values: The first Boolean value, skip, indicates whether the current event should be skipped. The second Boolean value, shouldRetry, indicates whether a retry is recommended. S4. Determine whether the second Boolean value is true; If the second Boolean value is false, the first Boolean value is returned directly as the final decision result, and the process ends. If the second Boolean value is true, proceed to step S5; Step S5: Increment the value of the retry counter by 1, wait for a preset short time interval, and then return to step S2 to continue the next round of loop judgment; Step S6: When the number of retries reaches the maximum number of retries, execute the last core matching logic call and use the first boolean value returned by it as the final decision result, and the process ends.

3. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 2, characterized in that, The matching decision method checkAndSkip specifically includes: S31. Obtain the resource identifier, event resource version, and current attempt count; S32. Based on the resource identifier and in conjunction with the patch record mapping, obtain the historical update record linked list corresponding to the resource identifier; S33. Perform a non-empty check on the updated record list; S34. Traverse the verified record list and filter out valid pre-marked records; S35. Determine the record status based on the status field of the record linked list, where the record status includes: The Confirmed status has been verified. Intent or Pending status; S36. After traversing all records in the record list, determine the final return result based on whether a valid state is matched, and whether it is necessary to skip the current event or trigger a retry mechanism.

4. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 3, characterized in that, The step of performing a non-empty check on the updated record list specifically includes determining whether the obtained record list exists and is not empty: If the linked list is nil or empty, the current resource identifier does not have a pre-marked or updated record, the current event is not triggered by a known Patch operation, and the third result set is returned directly without skipping the event delivery and without retrying. If the linked list is not empty, proceed to step S33.

5. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 3, characterized in that, The step of traversing the verified record list and filtering valid pre-marked records specifically includes: For each pre-marked record encountered, check if its ExpiryTime field is earlier than the current time: If it is earlier than the current time, the currently pre-marked record is invalid and should be deleted. If it is not earlier than the current time, the currently pre-marked record is valid.

6. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 3, characterized in that, If the record status is determined to be "Confirmed", then perform the following operations: Determine if the ResourceVersion field of the current record is exactly equal to the input parameter eventRV; If they are equal, it is determined that the resource version is an exact match, and the following actions are taken: Increment the MatchedCount count of the current record by 1; Update the current record's expiry time (ExpiryTime) to the current time plus the maximum record retention time (maxRecordAge); Determine whether the updated MatchedCount is greater than or equal to the preset threshold maxMatchCount; If so, mark the current record as pending deletion so that it can be removed after the traversal is complete; If not, retain the current record and continue processing; Return the first result set, which contains true and false values ​​to indicate that a matching record has been found, and the current event should be skipped without retrying. If they are not equal, it is determined that the resource version is mismatched, and the process continues to traverse the next record.

7. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 6, characterized in that, If the recorded status is determined to be either Intent or Pending, then the following operations are performed: If the current record's status is Intent, then update it to Pending; Increment the match attempt count (MatchAttempts) for the current record by 1; Determine if the current record is within the valid waiting time window and if the current MatchAttempts value is less than the maximum number of retries minus 1; If so, set the internal retry flag shouldRetry to true. If not, then keep shouldRetry as false; Return a second result set containing the false value and the value of the shouldRetry flag to indicate that no Confirmed match was found at present, and to suggest to the caller whether to retry later based on the shouldRetry flag.

8. The cloud-edge collaborative message redundancy elimination method for KubeEdge according to claim 7, characterized in that, If multiple records in the linked list are traversed and neither the first nor the second result set is returned, then for the currently traversed record, the following condition is checked: If the record's status is Confirmed, and the record matches the event view eventRV to be processed; If no record is found that is in the Intent / Pending state and requires waiting; Then execute the third result set, which indicates that the event should be skipped and no retry is required.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the cloud-edge collaborative message redundancy elimination method for KubeEdge as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the cloud-edge collaborative message redundancy elimination method for KubeEdge as described in any one of claims 1 to 8.

Images