K8S cluster traffic management method and system, computer equipment and computer program product

Abstract

The invention relates to the technical field of traffic management of service grid and cluster cooperation, in particular to a K8S cluster traffic management method and system, computer equipment and a computer program product. A delay risk is predicted through a strategy engine, a traffic forwarding rule and a protocol unloading strategy are generated, an eBPF program deployed on a working node only performs kernel mode lightweight protocol identification and unloads complex analysis to a user mode process, traffic kernel mode straight-through forwarding is realized in combination with a triple mapping structure, full analysis and user mode switching is avoided, and the traffic forwarding efficiency is improved. And the end-to-end delay is reduced to a sub-millisecond level, so that the resource consumption is effectively reduced.

Description

Technical Field

[0001] This application relates to the field of traffic governance technology for service mesh and cluster collaboration, and in particular to a K8S cluster traffic management method, system, computer equipment and computer program product. Background Technology

[0002] As microservices scale, Kubernetes (K8S, container orchestration platform) clusters commonly employ service meshes (such as Istio 1.18) for traffic governance. Existing solutions rely on sidecar proxies (such as Envoy) to perform full parsing of protocols like HTTP / 2 and gRPC in user space. This involves multiple context switches: kernel interception → user-space unpacking → protocol parsing → policy execution → user-space packet encapsulation → kernel forwarding, resulting in end-to-end latency as high as 20–50ms. Some solutions attempt to introduce eBPF for traffic hijacking, still keeping protocol parsing and governance logic entirely within the sidecar, failing to overcome the latency bottleneck. Other solutions perform full parsing in eBPF, leading to kernel stability risks and functional deficiencies (such as the inability to support HPACK dynamic table updates and gRPC method-level circuit breaking). The fundamental contradiction lies in this: reducing latency requires simplifying or bypassing user-space parsing, but this inevitably sacrifices core governance functions such as route matching and method-level circuit breaking; conversely, ensuring governance integrity requires accepting high latency. Existing technologies cannot achieve an engineering-feasible balance between these two aspects. Summary of the Invention

[0003] To address the technical problems mentioned in the background, this application provides a K8S cluster traffic management method, system, computer equipment, and computer program product to solve the technical problems mentioned in the background where latency optimization and governance functions are difficult to balance, and static strategies cannot adapt to dynamic clusters.

[0004] In the first aspect, this application proposes a K8S cluster traffic management and latency optimization method, which is executed collaboratively by the processors of all nodes in the K8S cluster, wherein the nodes of the K8S cluster include the control plane and worker nodes. The method includes the following steps: S1: Using the policy engine deployed in the control plane, the latency metrics, topology relationships, and instance status data of services within the K8S cluster are collected to predict service latency risks and generate traffic forwarding rules and protocol offloading policies; wherein, the traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags; the protocol offloading policy is used to indicate whether to perform lightweight identification and metadata interception on the protocol; S2: The eBPF program deployed on the worker node responds to the traffic forwarding rules, intercepts traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and, according to the protocol offloading policy, only performs basic protocol frame type identification operations, extracts metadata containing key protocol semantic fields, and does not perform complete protocol parsing. S3: The metadata is transmitted to the user-space process through a zero-copy path, and the user-space process performs complete protocol parsing and governance decision calculation, and writes the decision result into the kernel-space triple mapping structure; S4. Based on the aforementioned triple mapping structure, the eBPF program directly executes traffic scheduling actions in the kernel mode to obtain matching traffic; S5. The user-space process collects the actual end-to-end delay of the traffic after scheduling in step S4, compares the actual end-to-end delay with the predicted delay value corresponding to the predicted delay risk in step S1, obtains the comparison result deviation, and dynamically adjusts the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

[0005] In one possible implementation of the first aspect, the triple mapping structure in step S3 includes: a first mapping for associating service identifiers with backend instance addresses, a second mapping for recording the real-time latency and health status of each instance, and a third mapping for caching traffic scheduling parameters generated based on the decision results.

[0006] In one possible implementation of the first aspect, when the eBPF program performs traffic scheduling in step S4, the selection priority of each instance is calculated using the following comprehensive weighting formula:

[0007] in, For traffic scheduling parameters; This represents the instance's current average response latency. The number of idle connections for the instance; These are the first and second weight coefficients that are dynamically adjusted by the strategy engine.

[0008] In one possible implementation of the first aspect, step S4 further includes: The matched traffic is injected into the network namespace of the target instance via the zero-copy path to avoid passing through the user-space proxy.

[0009] In one possible implementation of the first aspect, after the eBPF program directly executes the traffic scheduling action in the kernel mode based on the triple mapping structure to obtain the matching traffic, it further includes: The user-space process dynamically updates the traffic scheduling parameters in the third mapping based on the changes in the instance state in the second mapping, thereby updating the triple mapping structure; The following incremental synchronization formula is used during the update process of the triple mapping structure:

[0010] in, Indicates the first 24-hour service To the example The delay weight is used to dynamically update the traffic scheduling parameters, wherein... The higher the value, the better for the instance. The higher the proportion of traffic received; and These are constants that the strategy engine dynamically configures based on the scenario. For the example Real-time latency, For the example The state of health.

[0011] In one possible implementation of the first aspect, step S5 further includes: If the deviation of the comparison result exceeds the preset deviation threshold or the integrity of the governance function is detected to be lower than the preset lower limit threshold, the traffic forwarding rules and protocol offloading strategy are dynamically adjusted, and the standard sidecar proxy path is switched when the fallback conditions are met.

[0012] In one possible implementation of the first aspect, the process of generating the protocol offloading strategy in step S1 employs an integer linear programming (ILP) model, the objective function of which is expressed by the following formula:

[0013] Among them, w i Let L be the topological weight of the i-th service in the service call chain. i The predicted latency for the i-th service under the protocol offloading policy; The constraints of the integer linear programming (ILP) model are expressed by the following resource constraint formula:

[0014] Among them, C i The computing resources consumed by performing the protocol unloading on the i-th service, C total θ1 represents the total computing resources available for protocol offloading, and θ1 represents the upper limit threshold for computing resource utilization. The constraints of the integer linear programming (ILP) model can also be expressed by the following governance function constraint formula:

[0015] Among them, the θ2 represents the percentage of governance functions that can still be executed normally after the protocol is uninstalled, and θ2 is the preset lower limit threshold for the integrity of the governance functions.

[0016] Secondly, this application also proposes a collaborative system for a K8S cluster, wherein the nodes of the K8S cluster include a control plane and worker nodes; The policy engine deployed in the control plane is configured to collect latency metrics, topology relationships, and instance status data of services within the K8S cluster to predict service latency risks and generate traffic forwarding rules and protocol offloading policies. The traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags. The protocol offloading policies are used to indicate whether to perform lightweight identification and metadata interception on the protocol. The eBPF program deployed on the worker node is configured to respond to the traffic forwarding rule, intercept traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and, according to the protocol offloading policy, only perform basic protocol frame type identification operations, extract metadata containing key protocol semantic fields, and do not perform complete protocol parsing. The user-space process is configured to receive the metadata transmitted through a zero-copy path, perform complete protocol parsing and governance decision calculation, and write the decision results into the kernel-space triple mapping structure. The eBPF program is configured to directly execute traffic scheduling actions in the kernel space based on the triple mapping structure to obtain matching traffic; The user-space process collects the actual end-to-end latency of the scheduled traffic, compares the actual end-to-end latency with the predicted latency value corresponding to the latency risk, obtains the comparison result deviation, and dynamically adjusts the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

[0017] Thirdly, this application also proposes a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer device being located in a node of the K8S cluster; the processor executing the computer program implements the steps of the method described above.

[0018] Fourthly, this application also proposes a computer program product, including a computer program that, when run by a computer device, causes the steps of the method described in the first aspect to be performed.

[0019] The K8S cluster traffic management method, system, computer equipment, and computer program products provided in this application predict latency risks and generate traffic forwarding rules and protocol offloading policies through a policy engine. eBPF only performs lightweight protocol identification in kernel mode, offloading complex parsing to user mode. Combined with a triple mapping structure, it realizes direct forwarding of traffic in kernel mode, avoiding full parsing and user mode switching, reducing end-to-end latency to sub-millisecond level, and effectively reducing resource consumption. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the main process of a K8S cluster traffic management method provided in this application; Figure 2 This is a schematic diagram of an embodiment in which data interaction exists between different parts of all nodes in the K8S cluster provided in this application; Figure 3 This is a schematic diagram of an embodiment of a K8S cluster traffic management method provided in this application; Figure 4 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0028] To address the aforementioned technical issues, in a first aspect, this application provides a method for K8S cluster traffic management and latency optimization, which is executed collaboratively by the processors of all nodes in the K8S cluster, wherein the nodes of the K8S cluster include a control plane and worker nodes; The method includes the following steps S1 to S5: Step S1: Using the policy engine deployed in the control plane, collect latency metrics, topology relationships, and instance status data of services within the K8S cluster to predict service latency risks and generate traffic forwarding rules and protocol offloading policies; wherein, the traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags; the protocol offloading policy is used to indicate whether to perform lightweight identification and metadata interception on the protocol; It should be noted that the control plane can be understood as the management and control components of the Kubernetes cluster (such as APIServer and Scheduler), which are responsible for global policy decisions, configuration distribution, and state coordination.

[0029] As an example, this application deploys a dynamic policy engine in the K8S control plane. This engine can collect P99 latency metrics, inter-Pod communication topology, and network link status data of all services in the cluster in real time, and predict service paths with high latency risk through machine learning models.

[0030] For example, the strategy engine in this application embodiment may include a three-layer progressive decision-making mechanism: First layer: Identify critical paths based on service dependency graphs, and mark services with P99 latency > 50ms as red sensitivity level; The second layer uses an LSTM model to predict latency fluctuations over the next 30 seconds. When the predicted value exceeds a threshold, a strategy is generated. The third layer: Combines GPU-accelerated integer programming algorithms to calculate the optimal protocol offloading combination scheme.

[0031] As an example, the dynamic policy generation process of this application (i.e., the process of generating traffic forwarding rules and protocol offloading policies) may include: collecting real-time metrics (request throughput, error rate, response time quantiles) reported by the Envoy proxy; constructing a service call chain topology graph and identifying bottleneck nodes in high-frequency call paths; calling a pre-trained latency prediction model, inputting topology relationships, resource utilization, and historical latency trends, and outputting the probability distribution of high-latency risk paths; generating avoidance policies based on risk probabilities, the policies including a list of alternative service instances, traffic weight allocation, and a protocol offloading whitelist.

[0032] The engine generates traffic forwarding rules and protocol offloading policies based on eBPF. The rules include, but are not limited to, the IP address, port number, protocol type, and latency sensitivity label of the target service. The policies are distributed to the node agent components through custom resource definitions (CRDs).

[0033] Step S2: The eBPF program deployed on the worker node responds to the traffic forwarding rules, intercepts traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and performs only the identification operation of the basic protocol frame type according to the protocol offloading policy, extracting metadata containing key fields of protocol semantics, without performing complete protocol parsing.

[0034] It should be noted that worker nodes can be worker nodes (Nodes) running application containers in a Kubernetes cluster, such as... Figure 2 As shown, a Pod and the daemon process and eBPF program of this invention are deployed on it, which are responsible for executing the traffic governance rules issued by the control plane; The relationship between the control plane and the worker nodes is as follows: the control plane issues policies to each worker node through custom resources, and the worker nodes execute specific traffic interception and latency optimization.

[0035] As an example, this application can pre-deploy a lightweight daemon process on each Kubernetes worker node to monitor rules issued by the policy engine. When a new rule is detected, the daemon process compiles the eBPF program into kernel executable bytecode and injects it into the node kernel's network protocol stack via the BPF_PROG_LOAD system call. The injected eBPF program includes a traffic classifier and a minimal protocol identification module: the traffic classifier matches target traffic based on 5-tuple hashes; the protocol identification module only identifies basic application layer frame types and does not perform complete protocol parsing or decoding.

[0036] For example, for HTTP / 2 traffic, only the frame type field in the frame header can be detected, and the first few bytes can be truncated when a HEADERS frame is identified. For gRPC traffic, only the preamble magic byte or the traffic direction can be detected to identify whether it is gRPC communication. Furthermore, eBPF programs do not perform complex operations such as HPACK / Huffman decoding, Protobuf deserialization, or method ID mapping; as an example, the captured frame header data can be passed to the user-space acceleration daemon through a circular buffer or the AF_XDP zero-copy channel.

[0037] Step S3: The metadata is transmitted to the user-space process through a zero-copy path, and the user-space process performs complete protocol parsing, governance decision calculation, and writes the decision result into the kernel-space triple mapping structure; Understandably, kernel mode refers to the privileged mode when the CPU runs the operating system kernel code, which has the ability to access all system resources; during the process of a worker node running a business container, its operating system kernel is the so-called "kernel mode".

[0038] In this embodiment, after receiving tuple data, the user-space acceleration daemon performs complete protocol parsing, method name identification, and policy calculation. For the aforementioned HTTP / 2 traffic, complete HEADERS decoding and method mapping can be performed; for gRPC traffic, Protobuf deserialization and method ID mapping can be performed. The generated tuple data (target service name, API endpoint, message type, QoS tag) can be compressed into a 16-byte fixed-length structure and written into the kernel-space triple mapping structure via eBPF MAP to support subsequent rapid governance and forwarding.

[0039] As an example, the triple mapping structure of this application may include: a first mapping for associating service identifiers with backend instance addresses, a second mapping for recording the real-time latency and health status of each instance, and a third mapping for caching traffic scheduling parameters generated based on the decision results.

[0040] Step S4: Based on the triple mapping structure, the eBPF program directly executes traffic scheduling actions in the kernel mode to obtain the matching traffic; As an example, this application can be based on a triple mapping structure written into the kernel, where subsequent traffic matching is directly managed by a kernel-mode eBPF program. The eBPF program can make load balancing, circuit breaking, and routing decisions based on the traffic scheduling parameters (latency weight, circuit breaker flag, protocol offload flag) in the triple mapping, and use the bpf_redirect_map function to directly route traffic to the target Pod's virtual network interface through the AF_XDP zero-copy channel, completely avoiding user-mode-kernel mode switching and the involvement of user-mode agents.

[0041] Step S5: Collect the actual end-to-end delay of the traffic after scheduling in step S4, compare the actual end-to-end delay with the predicted delay value corresponding to the predicted delay risk in step S1, obtain the comparison result deviation, and dynamically adjust the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

[0042] It is understood that the daemon process in this application can continuously monitor the end-to-end latency of the governance traffic and report the actual latency and prediction deviation to the policy engine every 100 milliseconds. The policy engine can dynamically adjust the load balancing weights, circuit breaker thresholds, and protocol offloading granularity in the eBPF program based on reinforcement learning models (such as the PPO algorithm).

[0043] As an example, if the deviation of the comparison result exceeds a preset deviation threshold or the integrity of the governance function is detected to be lower than a preset lower limit threshold, the traffic forwarding rules and protocol offloading strategy are dynamically adjusted, and the standard sidecar proxy path is switched when the fallback conditions are met.

[0044] For example, when protocol offloading is detected causing governance function failure or latency to rise to 90% of the Sidecar mode level, traffic can be automatically switched to the standard Envoy proxy path and an alarm can be triggered. The governance function missing rate is calculated by comparing the governance decisions of the protocol offloading path and the standard Sidecar proxy path for the same batch of traffic in real time. A fallback is triggered when the missing rate is >5%. The governance function missing rate is calculated by comparing the governance decisions of the protocol offloading path and the standard Envoy proxy path for the same batch of traffic in real time: when the offloading path cannot execute a function (such as circuit breaking, routing, retry, or timeout control) from the predefined governance rule set, it is considered missing. The missing rate is the proportion of missing functions to the total number of functions. Once any trigger condition is met, traffic is automatically switched to the standard Envoy proxy path, and an alarm is triggered.

[0045] The technical advantages of this application's embodiments are as follows: by predicting latency risks through a policy engine and generating traffic forwarding rules and protocol offloading policies, eBPF only performs lightweight protocol identification in kernel mode, offloading complex parsing to user mode. Combined with a triple mapping structure, it achieves direct forwarding of traffic in kernel mode, avoiding full parsing and user mode switching, reducing end-to-end latency to sub-millisecond level, and effectively reducing resource consumption.

[0046] In one embodiment, the process of generating the protocol offloading strategy in step S1 of the foregoing embodiments can be performed using an integer linear programming (ILP) model. The objective function of the integer linear programming (ILP) model can be expressed by the following formula:

[0047] Among them, w i Let L be the topological weight of the i-th service in the service call chain. i The predicted latency for the i-th service under the protocol offloading policy; The constraints of the integer linear programming (ILP) model are expressed by the following resource constraint formula:

[0048] Among them, C i The computing resources consumed by performing the protocol unloading on the i-th service, C total θ1 represents the total computing resources available for protocol offloading, and θ1 is the upper limit threshold for computing resource utilization. This constraint prevents protocol offloading from excessively consuming GPU resources, which could lead to policy solution timeouts or other business performance degradation.

[0049] The constraints of the integer linear programming (ILP) model can also be expressed by the following governance function constraint formula:

[0050] Among them, the θ2 represents the percentage of governance functions that can still function normally after protocol uninstallation, and θ2 is a preset lower limit threshold for the integrity of the governance functions. This constraint ensures that protocol uninstallation does not lead to the loss of core governance capabilities (circuit breaking, routing, etc.). This application's embodiment uses an integer linear programming (ILP) model to address the problem of GPU overload or governance capability collapse caused by unconstrained policy optimization. This embodiment significantly shortens policy solution time by parallelizing the branch and bound tree nodes of the ILP on the GPU. This optimization process enables the policy engine to generate the protocol offloading combination scheme with the minimum global prediction latency, while ensuring resource control and uninterrupted governance functionality.

[0051] In one embodiment, the triple mapping structure in step S3 of the foregoing embodiments may include: a first mapping for associating service identifiers with backend instance addresses, a second mapping for recording the real-time latency and health status of each instance, and a third mapping for caching traffic scheduling parameters generated based on the decision results. In a specific implementation, the triple mapping structure can consist of three levels of eBPF MAPs, and its specific implementation is as follows: Level 1 MAP (ServiceMap): The mapping between storage service names and backend Pod instances.

[0052]

[0053] in Indicates the first A service name, This is a list of instance IPs for this service.

[0054] The second-level MAP (HealthMap) records the real-time health status and latency information of each Pod instance.

[0055]

[0056] in for Real-time latency of the instance The health score is calculated based on the request success rate and error rate. The latency data in the health map is calculated by the node daemon process in real time from the average response latency within the last 100 milliseconds. The health score is generated by calculating the request success rate and error rate within the same period using a normalization formula.

[0057] The third-level MAP (PolicyMap) stores dynamic traffic governance parameters calculated by the policy engine, such as weight, routing priority, and circuit breaker status.

[0058]

[0059] in Indicates the delay weight. Indicates the circuit breaker flag (0 / 1). This indicates the protocol unloading flag.

[0060] Correspondingly, the user-space process writes the governance decision results (load balancing weight, circuit breaker status, routing priority, etc.) into the PolicyMap, which can be directly queried and used by the eBPF program in kernel space.

[0061] Furthermore, in some embodiments, the zero-copy path of step S4 relies on a triple mapping mechanism: The first-level MAP stores the mapping table from storage names to backend Pod IPs. The second-level MAP records the health status of Pods and their real-time latency. The third-level MAP maintains the governance policy cache for connection sessions.

[0062] Accordingly, in step S4, when the eBPF program performs traffic scheduling, it uses the following comprehensive weighting formula to calculate the selection priority of each instance:

[0063] Among them, among them, These are traffic scheduling parameters, which are the basic parameters for instance comprehensive selection weight and load balancing decisions. The larger the value, the higher the proportion of traffic received by the instance. This represents the instance's current average response latency, for example, the instance's average response latency (in milliseconds) over the last 100ms, collected in real time by HealthMap. This is the number of idle connections for the instance, i.e., the number of network connections that the instance is currently not occupied (unit: number), which is counted by the node daemon. The first weighting coefficient and the second weighting coefficient are dynamically adjusted by the strategy engine. The first weighting coefficient is used to control latency sensitivity, and the second weighting coefficient is used to control load balancing.

[0064] It is understandable that traditional algorithms allocate traffic based solely on the number of currently active requests for an instance, which may lead to instances with low latency but few idle connections being over-allocated traffic (causing a new increase in latency); while the solution in the above embodiments of this application... Introducing a resource capacity dimension ensures that traffic allocation prioritizes low-latency instances. It also takes into account the idle resources of the instance. This prevents low-latency instances with few idle connections from being over-allocated traffic, thus preventing service unavailability due to connection exhaustion. It also provides a more reasonable initial value for subsequent dynamic weight adjustments.

[0065] Furthermore, for step S4, based on the triple mapping structure, the eBPF program directly executes traffic scheduling actions in kernel mode to obtain matching traffic. This matching traffic is then directly injected into the target instance's network namespace via a zero-copy path (taking the AF_XDP socket as an example), thus completely avoiding the user-space proxy program (e.g., Envoy Sidecar). The governance action uses the bpf_redirect_map function to directly route traffic to the target Pod's virtual network interface, skipping the programmatic proxy forwarding chain and achieving zero-switch between user mode and kernel mode.

[0066] Furthermore, the multi-layered mapping zero-copy traffic governance data structure aims to achieve rapid kernel-level association and synchronous updates between service identifiers, health status, and policy decisions. Synchronization between the three mapping layers is accomplished through a bidirectional triggered incremental update mechanism.

[0067] In some embodiments, when Health status of a certain instance Decline or delay When the increase exceeds the threshold, a synchronization event is triggered; After the daemon process captures the event, it calculates a new latency weight. That is, after step S4 in the aforementioned embodiment, it may also include the user-space process dynamically updating the traffic scheduling parameters in the third mapping based on the changes in the instance state in the second mapping, so as to update the triple mapping structure. The update process of the triple mapping structure can be achieved using the following incremental synchronization formula:

[0068] in, Indicates the first 24-hour service To the example The delay weight is used to dynamically update the traffic scheduling parameters, wherein... The higher the value, the better for the instance. The higher the proportion of traffic received; and These are constants that the strategy engine dynamically configures based on the scenario. For the example Real-time latency, For the example The state of health.

[0069] If there are changes in the weights or circuit breaker flags in the PolicyMap, the traffic scheduling weights in the ServiceMap are updated through synchronization events. The overall synchronization cycle is controlled within ≤100ms, and concurrent consistency is ensured through the eBPFringbuffer communication channel and the RCU (Read-Copy-Update) mechanism. This embodiment can solve the technical problem of policy lag caused by static updates of triple mapping, which leads to traffic misscheduling and latency fluctuations, by using the above incremental synchronization formula. It can upgrade the "triple mapping structure" in S4 from a static data container to a dynamic governance engine, and achieve sub-millisecond policy hot updates.

[0070] Secondly, this application also proposes a collaborative system for a K8S cluster, wherein a policy engine deployed in the control plane is configured to collect latency metrics, topology relationships, and instance status data of services within the K8S cluster to predict service latency risks and generate traffic forwarding rules and protocol offloading policies; wherein the traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags; and the protocol offloading policies are used to indicate whether to perform lightweight identification and metadata interception on the protocol. The eBPF program deployed on the worker node is configured to respond to the traffic forwarding rule, intercept traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and, according to the protocol offloading policy, only perform basic protocol frame type identification operations, extract metadata containing key protocol semantic fields, and do not perform complete protocol parsing. The user-space process is configured to receive the metadata transmitted through a zero-copy path, perform complete protocol parsing and governance decision calculation, and write the decision results into the kernel-space triple mapping structure. The eBPF program is configured to directly execute traffic scheduling actions in the kernel space based on the triple mapping structure to obtain matching traffic; The user-space process collects the actual end-to-end latency of the scheduled traffic, compares the actual end-to-end latency with the predicted latency value corresponding to the latency risk, obtains the comparison result deviation, and dynamically adjusts the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

[0071] Terminology Explanation: K8S (Kubernetes): Container Orchestration Platform AF_XDP: is a socket address family (AddressFamily) in the Linux network subsystem used for high-performance packet processing. Its full name is AddressFamilyeXpressDataPath. It is a user-space interface provided by the Linux kernel for XDP (eXpressDataPath) to implement a zero-copy packet sending and receiving mechanism.

[0072] eBPF ringbuffer communication channel: is a high-performance, low-latency data transmission mechanism between user space and kernel space in the Linux eBPF subsystem; BPF: Berkeley Packet Filter / Extended Berkeley Packet Filter BPf_PROG_LOAD: eBPF program loading system call, a system call interface provided by the Linux kernel, used to inject compiled eBPF bytecode into the kernel; Ring buffer: A high-performance data transfer mechanism in the Linux eBPF subsystem, used for asynchronous data exchange between kernel-mode eBPF programs and user-mode processes; Zero-Copy: Zero-copy technology; Sidecar: The traditional traffic governance carrier of service mesh, deployed in the same Pod as the business container, responsible for the entire process of traffic interception, parsing, and forwarding.

[0073] Thirdly, embodiments of the present invention provide a computer device, such as... Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device in this embodiment is located in a node of the K8S cluster; the computer device in this embodiment includes: at least one processor 10, a memory 11, and a computer program 12 stored in the memory 11 and executable on the at least one processor 10. When the processor 10 executes the computer program 12, it implements the steps of the various embodiments of the K8S cluster traffic management method supporting service mesh in the foregoing method embodiments of this application.

[0074] Those skilled in the art will understand that Figure 4 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0075] Furthermore, this application also provides a computer program product comprising a computer program corresponding to the computer device mentioned in the foregoing method embodiments, wherein the computer program, when run by the computer device, causes the steps of any of the methods described in the foregoing method embodiments to be executed.

[0076] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for managing traffic in a Kubernetes cluster, characterized in that, It is executed collaboratively by the processors of all nodes in the K8S cluster, which includes the control plane and worker nodes; The method includes the following steps: The policy engine deployed in the control plane collects latency metrics, topology relationships, and instance status data of services within the K8S cluster to predict service latency risks and generate traffic forwarding rules and protocol offloading policies. The traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags. The protocol offloading policies are used to indicate whether to perform lightweight identification and metadata interception on protocols. The eBPF program deployed on the worker node responds to the traffic forwarding rules, intercepts traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and performs only the basic protocol frame type identification operation according to the protocol offloading policy, extracting metadata containing key protocol semantic fields without performing complete protocol parsing. The metadata is transmitted to the user-space process through a zero-copy path, where the user-space process performs complete protocol parsing and governance decision calculation, and writes the decision results into the kernel-space triple mapping structure. Based on the aforementioned triple mapping structure, the eBPF program directly executes traffic scheduling actions in the kernel mode to obtain matching traffic; The user-space process collects the actual end-to-end latency of the scheduled traffic, compares the actual end-to-end latency with the predicted latency value corresponding to the latency risk, obtains the comparison result deviation, and dynamically adjusts the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

2. The method according to claim 1, characterized in that, The triple mapping structure includes: a first mapping for associating service identifiers with backend instance addresses, a second mapping for recording the real-time latency and health status of each instance, and a third mapping for caching traffic scheduling parameters generated based on the decision results.

3. The method according to claim 2, characterized in that, During the process of the eBPF program directly executing traffic scheduling actions in the kernel mode, the selection priority of each instance is calculated using the following comprehensive weighting formula: in, For traffic scheduling parameters; This represents the instance's current average response latency. The number of idle connections for the instance; These are the first and second weight coefficients that are dynamically adjusted by the strategy engine.

4. The method as described in claim 3, characterized in that, Based on the aforementioned triple mapping structure, after the eBPF program directly executes traffic scheduling actions in kernel mode to obtain the matching traffic, the process further includes: The matching traffic is injected into the network namespace of the target instance via the zero-copy path.

5. The method according to any one of claims 2 to 4, characterized in that, Based on the aforementioned triple mapping structure, after the eBPF program directly executes traffic scheduling actions in kernel mode to obtain the matching traffic, the process further includes: The user-space process dynamically updates the traffic scheduling parameters in the third mapping based on the changes in the instance state in the second mapping, thereby updating the triple mapping structure; The following incremental synchronization formula is used during the update process of the triple mapping structure: in, Indicates the first 24-hour service To the example The delay weight is used to dynamically update the traffic scheduling parameters, wherein... The higher the value, the better for the instance. The higher the proportion of traffic received; and These are constants that the strategy engine dynamically configures based on the scenario. For the example Real-time latency, For the example The state of health.

6. The method as described in claim 1, characterized in that, The step of dynamically adjusting the traffic forwarding rules and the protocol offloading strategy based on the deviation of the comparison results further includes: If the deviation of the comparison result exceeds the preset deviation threshold or the integrity of the governance function is detected to be lower than the preset lower limit threshold, the traffic forwarding rules and the protocol offloading strategy are dynamically adjusted, and the standard sidecar proxy path is switched when the fallback conditions are met.

7. The method according to claim 1, characterized in that, The process of generating the protocol offloading strategy employs an integer linear programming (ILP) model, the objective function of which is expressed by the following formula: Among them, w i Let L be the topological weight of the i-th service in the service call chain. i The predicted latency for the i-th service under the protocol offloading policy; The constraints of the integer linear programming (ILP) model are expressed by the following resource constraint formula: Among them, C i The computing resources consumed by performing the protocol unloading on the i-th service, C total θ1 represents the total computing resources available for protocol offloading, and θ1 represents the upper limit threshold for computing resource utilization. The constraints of the integer linear programming (ILP) model are expressed by the following governance function constraint formula: Among them, the θ2 represents the percentage of governance functions that can still be executed normally after the protocol is uninstalled, and θ2 is the preset lower limit threshold for the integrity of the governance functions.

8. A collaborative system for a Kubernetes cluster, characterized in that, The nodes of the K8S cluster include a control plane and worker nodes; The policy engine deployed in the control plane is configured to collect latency metrics, topology relationships, and instance status data of services within the K8S cluster to predict service latency risks and generate traffic forwarding rules and protocol offloading policies. The traffic forwarding rules include target service identifiers, protocol types, and latency sensitivity tags. The protocol offloading policies are used to indicate whether to perform lightweight identification and metadata interception on the protocol. The eBPF program deployed on the worker node is configured to respond to the traffic forwarding rule, intercept traffic matching the target service identifier and the protocol type at the IP layer of the network protocol stack, and, according to the protocol offloading policy, only perform basic protocol frame type identification operations, extract metadata containing key protocol semantic fields, and do not perform complete protocol parsing. The user-space process is configured to receive the metadata transmitted through a zero-copy path, perform complete protocol parsing and governance decision calculation, and write the decision results into the kernel-space triple mapping structure. The eBPF program is configured to directly execute traffic scheduling actions in the kernel space based on the triple mapping structure to obtain matching traffic; The user-space process collects the actual end-to-end latency of the scheduled traffic, compares the actual end-to-end latency with the predicted latency value corresponding to the latency risk, obtains the comparison result deviation, and dynamically adjusts the traffic forwarding rules and the protocol offloading strategy based on the comparison result deviation.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The computer device is located in a node of the K8S cluster; when the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, Includes a computer program, which, when run by a terminal device, causes the steps of the method as described in any one of claims 1 to 8 to be performed.

Images