Traffic forwarding method based on service grid system, service grid system and product

Abstract

The embodiment of the invention discloses a traffic forwarding method based on a service grid system, the service grid system and a product, and belongs to the technical field of cloud. In the embodiment of the invention, a first network protocol table configured on a first network protocol table component not only comprises a first sidecar network protocol rule corresponding to a first sidecar component, but also comprises a first extension rule. Whether to skip the first sidecar network protocol rule may be determined by executing the first extension rule. On the basis, operation and maintenance personnel can control whether the exit flow of the first application component bypasses the first sidecar component or not through the first extension rule newly added in the first network protocol table, and the first sidecar network protocol rule does not need to be backed up and deleted. Therefore, the traffic is controlled to bypass the sidecar component for service access under the condition that the sidecar network protocol rule configured for the sidecar component does not need to be backed up and deleted, so that the problem caused when the sidecar network protocol rule is backed up and deleted is avoided.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of cloud technology, and in particular, to a traffic forwarding method, a service mesh system, and a product based on a service mesh system. Background Art

[0002] In a service mesh system, a pod of a node includes not only an application (APP) component but also a sidecar component. The core business function of the service provided by the node is deployed in the application component, and the edge function of the service is deployed in the sidecar component. In this scenario, when problems such as large latency or large resource occupation occur in the traffic of the service mesh system, in order to determine whether the problem is caused by the automatically added mesh data plane using the sidecar component, the traffic can be controlled to bypass the sidecar component for service access. If the foregoing problem disappears after the traffic bypasses the sidecar component, the traffic can be further controlled to access the service through the sidecar component to analyze in detail the cause of the problem.

[0003] In the related art, when it is necessary to control the traffic to bypass the sidecar component for service access, the user can first back up the sidecar network protocol rules configured for the sidecar component in the pod, and then delete the sidecar network protocol rules from the pod. In this way, the traffic will not be diverted to the sidecar component. Subsequently, when it is necessary to control the traffic to access the service through the sidecar component, the user restores the backed-up sidecar network protocol rules to the pod to divert the traffic to the sidecar component. Since the sidecar network protocol rules include many rules, and the backup and deletion are performed one by one, a certain time window is required for backing up and deleting the sidecar network protocol rules. In this way, it is easy to cause new traffic to be processed by incomplete sidecar protocol rules during the process of deleting the sidecar network protocol rules, resulting in misprocessing of the traffic. Summary of the Invention

[0004] The embodiments of the present application provide a traffic forwarding method, a service mesh system, and a product based on a service mesh system, which can control the traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rules configured for the sidecar component. The technical solution is as follows:

[0005] In a first aspect, a traffic forwarding method based on a service mesh system is provided. The service mesh system includes multiple nodes, and a first node among the multiple nodes includes a first pod. The first pod includes a first application component, a first sidecar component, and a first network protocol table component. The first network protocol table component is configured with a first network protocol table, and the first network protocol table includes a first extended rule and a first sidecar network protocol rule corresponding to the first sidecar component.

[0006] In this method, a first network protocol table component receives a first service access request from a first application component, where the first service access request is used to access a target service; the first network protocol table component executes a first extension rule to obtain a first interception result, and the first interception result is used to indicate whether to skip a first sidecar network protocol rule; in response to the first interception result indicating to skip the first sidecar network protocol rule, the first network protocol table component forwards the first service access request to a second node among multiple nodes, and the second node is used to provide the target service.

[0007] Among them, in response to the first interception result indicating to skip the first sidecar network protocol rule, the first network protocol table component forwarding the first service access request to a second node among multiple nodes can be understood as: the first network protocol table component does not execute the first sidecar network protocol rule and forwards the first service access request to a second node among multiple nodes.

[0008] In an embodiment of the present application, the first network protocol table configured on the first network protocol table component not only includes a first sidecar network protocol rule corresponding to a first sidecar component, but also includes a first extension rule. By executing the first extension rule, it can be determined whether to skip the first sidecar network protocol rule, that is, whether the egress traffic of the first application component bypasses the first sidecar component. Based on this, the operation and maintenance personnel can control whether the egress traffic of the first application component bypasses the first sidecar component through the first extension rule newly added to the first network protocol table, without backing up and deleting the first sidecar network protocol rule. Therefore, the embodiment of the present application provides a method for controlling traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rule configured for the sidecar component, so as to avoid the problems caused by backing up and deleting the sidecar network protocol rule.

[0009] Based on the method provided in the first aspect, in a possible implementation manner, the first network protocol table includes an egress switching table, and the egress switching table includes a first extension rule and a first sidecar network protocol rule.

[0010] In an embodiment of the present application, a first extension rule can be newly added to the egress switching table to implement the method provided in the embodiment of the present application.

[0011] Based on the method provided in the first aspect, in a possible implementation manner, the first extension rule is the first rule in the egress switching table.

[0012] Since the first network protocol table component executes each rule in the first network protocol table one by one, in order to ensure that the first network protocol table component executes the first extended rule before executing the first sidecar network protocol rule, the first extended rule is set as the first rule in the egress exchange table. Additionally, in the scenario where the operation and maintenance personnel update the rule in the first sidecar network protocol rule, the first extended rule always remains as the first rule in the egress exchange table.

[0013] Based on the method provided in the first aspect, in a possible implementation, the first extended rule includes the identifier of the first kernel program, and the first kernel program is used to skip the first sidecar network protocol rule; wherein, when the first kernel program is in the enabled state, the first interception result indicates skipping the first sidecar network protocol rule, and when the first kernel program is in the disabled state, the first interception result indicates not skipping the first sidecar network protocol rule.

[0014] When the user backs up and deletes the sidecar network protocol rules, since the sidecar network protocol rules are located in the kernel, it is also necessary to lock the sidecar network protocol rules. Correspondingly, new traffic is also locked when passing through the locked sidecar network protocol rules, which makes the traffic unable to access the service continuously, and thus causes problems with the performance of the service mesh system. Through the above implementation, when the operation and maintenance personnel need to control the traffic to bypass the sidecar component, they only need to control the first kernel program to be in the enabled state, without modifying the rules in the first network protocol table, thereby avoiding problems with the performance of the service mesh system due to modifying the first network protocol table.

[0015] Based on the method provided in the first aspect, in a possible implementation, the first node further includes a first daemon component. In this scenario, in response to the first sidecar interception configuration instruction triggered by the user, the first daemon component sets the first kernel program to be in the enabled state or the disabled state based on the first sidecar interception configuration instruction.

[0016] In the scenario where the first extended rule includes the identifier of the first kernel program, the operation and maintenance personnel can turn on or turn off the first kernel program through the first daemon component, thereby controlling the egress traffic to bypass or not bypass the sidecar component.

[0017] Based on the method provided in the first aspect, in a possible implementation, in response to the creation of the first pod, the first daemon component adds the first extended rule to the first network protocol table.

[0018] Through the above method, the first extended rule can be added to the first network protocol table when creating the first pod, so that there is no need to operate on the first network protocol table in subsequent operations.

[0019] Based on the method provided in the first aspect, in a possible implementation, after the first network protocol table component executes the first extension rule and obtains the first interception result, in response to the first interception result indicating not to skip the first sidecar network protocol rule, after the first network protocol table component executes the first sidecar network protocol rule, it forwards the first service access request to the first sidecar component, and the first sidecar component processes the first service access request to obtain a second service access request; the first network protocol table component receives the second service access request from the first sidecar component; the first network protocol table component forwards the second service access request to the second node.

[0020] By executing the first extension rule, it is also possible to control the egress traffic from not bypassing the sidecar component, that is, to control the sidecar component to intercept the egress traffic of the application component.

[0021] Based on the method provided in the first aspect, in a possible implementation, the process of the first network protocol table component forwarding the first service access request to the second node among multiple nodes can be as follows: the first network protocol table component forwards the first service access request to the first proxy component; the first proxy component processes the first service access request to obtain a third service access request; the first proxy component forwards the third service access request to the second node.

[0022] The destination address carried in the service access request generated by the first application component is the address of the target service. Since the egress traffic of the first application component in the first pod bypasses the first sidecar component, the destination address carried in the first service access request received by the first proxy component is still the address of the target service. At this time, the first proxy component needs to process the first service access request to convert the destination address in the first service access request into the address of a certain pod in the node that can provide the target service, so as to obtain the third service access request.

[0023] Based on the method provided in the first aspect, in a possible implementation, the first node further includes a first kernel-mode four-layer component, and the first kernel-mode four-layer component is in a closed state.

[0024] The above method of intercepting traffic by the sidecar component and the method of not intercepting traffic by the sidecar component but processing traffic by the proxy component can be applied to the scenario where the first kernel-mode four-layer component is in a closed state.

[0025] Based on the method provided in the first aspect, in a possible implementation, the first node further includes a first kernel-mode four-layer component, and the first kernel-mode four-layer component is in an enabled state. The implementation process of the first network protocol table component receiving the first service access request from the first application component can be as follows: the first kernel-mode four-layer component receives the fourth service access request from the first application component; the first kernel-mode four-layer component processes the fourth service access request to obtain the first service access request; the first kernel-mode four-layer component sends the first service access request to the first network protocol table component.

[0026] When the first kernel-mode four-layer component in the first node is in an enabled state, all egress traffic in the first application component will first be intercepted by the first kernel-mode four-layer component. Therefore, when the first kernel-mode four-layer component receives the fourth service access request from the first application component, after performing four-layer traffic governance on the fourth service access request, it sends the governed first service access request to the first network protocol table component, so that the first network protocol table component can determine whether to bypass the first sidecar component by executing the first extended rule.

[0027] Based on the method provided in the first aspect, in a possible implementation, the first node further includes a first daemon component. In this scenario, in response to the first four-layer interception configuration instruction triggered by the user, the first daemon component sets the first kernel-mode four-layer component to be in an enabled state or a disabled state based on the first four-layer interception configuration instruction.

[0028] In the embodiments of the present application, the operation and maintenance personnel can set the enabled or disabled state of the first kernel-mode four-layer component through the first daemon component to control whether the first kernel-mode four-layer component intercepts traffic.

[0029] In a second aspect, a traffic forwarding method based on a service mesh system is provided. The service mesh system includes multiple nodes, and the second node among the multiple nodes includes a second pod. The second pod includes a second application component, a second sidecar component, and a second network protocol table component. The second network protocol table component is configured with a second network protocol table, and the second network protocol table includes a second extended rule and a second sidecar network protocol rule corresponding to the second sidecar component.

[0030] In this method, the second network protocol table component receives a service access request from the first node among the multiple nodes. The service access request is used to access a target service; the second network protocol table component executes the second extended rule to obtain a second interception result, and the second interception result is used to indicate whether to skip the second sidecar network protocol rule; in response to the second interception result indicating to skip the second sidecar network protocol rule, the second network protocol table component forwards the service access request to the second application component, and the second application component is used to provide the target service.

[0031] Among them, in response to the second interception result indicating to skip the second sidecar network protocol rule, the second network protocol table component forwards the service access request to the second application component, which can be understood as: the second network protocol table component does not execute the second sidecar network protocol rule and forwards the service access request to the second application component.

[0032] In the embodiment of the present application, the second network protocol table configured on the second network protocol table component not only includes the second sidecar network protocol rule corresponding to the second sidecar component, but also includes a second extension rule. By executing the second extension rule, it can be determined whether to skip the second sidecar network protocol rule, that is, whether the incoming traffic of the second application component bypasses the second sidecar component. Based on this, the operation and maintenance personnel can control whether the incoming traffic of the second application component bypasses the second sidecar component through the second extension rule newly added to the second network protocol table, without backing up and deleting the second sidecar network protocol rule. Therefore, the embodiment of the present application provides a method for controlling traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rule configured for the sidecar component, so as to avoid the problems caused by backing up and deleting the sidecar network protocol rule.

[0033] Based on the method provided in the first aspect, in a possible implementation manner, the second network protocol table includes an ingress switching table, and the ingress switching table includes a second extension rule and a second sidecar network protocol rule.

[0034] In the embodiment of the present application, a second extension rule can be added to the ingress switching table to implement the method provided in the embodiment of the present application.

[0035] Based on the method provided in the first aspect, in a possible implementation manner, the second extension rule is the first rule in the ingress switching table.

[0036] Since the second network protocol table component executes each rule one by one when executing the rules in the second network protocol table, in order to ensure that the second network protocol table component executes the second extension rule before executing the second sidecar network protocol rule, the second extension rule is set as the first rule in the ingress switching table. In addition, in the scenario where the operation and maintenance personnel update the rule in the second sidecar network protocol rule, the second extension rule always remains the first rule in the ingress switching table.

[0037] Based on the method provided in the first aspect, in a possible implementation manner, the second extension rule includes an identifier of a second kernel program, and the second kernel program is used to skip the second sidecar network protocol rule; wherein, when the second kernel program is in an enabled state, the second interception result indicates to skip the second sidecar network protocol rule, and when the second kernel program is in a disabled state, the second interception result indicates not to skip the second sidecar network protocol rule.

[0038] When the user backs up and deletes the sidecar network protocol rules, since the sidecar network protocol rules are located in the kernel, it is also necessary to lock the sidecar network protocol rules. Correspondingly, when the new traffic passes through the locked sidecar network protocol rules, it is also locked accordingly, so that the traffic cannot continue to access the service, which in turn leads to performance problems in the service mesh system. Through the above implementation method, when the operation and maintenance personnel need to control the traffic to bypass the sidecar component, they only need to control the second kernel program to be in the enabled state, without modifying the rules in the second network protocol table, thus avoiding performance problems in the service mesh system caused by modifying the second network protocol table.

[0039] Based on the method provided in the first aspect, in a possible implementation, the second node further includes a second daemon component. In this scenario, in response to the second sidecar interception configuration instruction triggered by the user, the second daemon component sets the second kernel program to be in the enabled state or the disabled state based on the second sidecar interception configuration instruction.

[0040] In the scenario where the second extended rule includes the identifier of the second kernel program, the operation and maintenance personnel can turn on or turn off the second kernel program through the second daemon component, so as to control the ingress traffic to bypass or not bypass the sidecar component.

[0041] Based on the method provided in the first aspect, in a possible implementation, in response to the creation of the second pod, the second daemon component adds a second extended rule to the second network protocol table.

[0042] Through the above method, a second extended rule can be added to the second network protocol table when creating the second pod, so that there is no need to operate on the second network protocol table in subsequent operations.

[0043] Based on the method provided in the first aspect, in a possible implementation, after the second network protocol table component executes the second extended rule and obtains the second interception result, in response to the second interception result indicating not to skip the second sidecar network protocol rule, the second network protocol table component forwards the service access request to the second sidecar component after executing the second sidecar network protocol rule, and the second sidecar component processes the service access request; the second network protocol table component receives the service access request processed by the second sidecar component and forwards the received service access request to the second application component.

[0044] By executing the second extended rule, it is also possible to control the traffic not to bypass the sidecar component, that is, to control the sidecar component to intercept the ingress traffic of the application component.

[0045] Based on the method provided in the first aspect, in a possible implementation, the second node further includes a second kernel-mode four-layer component, and the second kernel-mode four-layer component is in the closed state.

[0046] The above - mentioned methods of intercepting traffic by the side - car component and the methods of not intercepting traffic by the side - car component can be applied to the scenario where the first kernel - mode layer - 4 component is in the closed state.

[0047] Based on the method provided in the first aspect, in a possible implementation, the second node further includes a second kernel - mode layer - 4 component, and the second kernel - mode layer - 4 component is in the open state; the implementation process of the second network protocol table component receiving a service access request from the first node among multiple nodes can be: the second kernel - mode layer - 4 component receives the service access request; the second kernel - mode layer - 4 component sends the service access request to the second network protocol table component based on the destination address of the service access request.

[0048] When the second kernel - mode layer - 4 component in the second node is in the open state, all incoming traffic in the second application component will first be intercepted by the second kernel - mode layer - 4 component. Therefore, after receiving the service access request from the first node, the second kernel - mode layer - 4 component can send the service access request to the second network protocol table component according to the destination address of the service access request.

[0049] Based on the method provided in the first aspect, in a possible implementation, the second node further includes a second daemon component. In this scenario, in response to the second layer - 4 interception configuration instruction triggered by the user, the second daemon component sets the second kernel - mode layer - 4 component to be in the open state or the closed state based on the second layer - 4 interception configuration instruction.

[0050] In the embodiments of the present application, the operation and maintenance personnel can set the open or closed state of the first kernel - mode layer - 4 component through the first daemon component to control whether the first kernel - mode layer - 4 component intercepts traffic.

[0051] In a third aspect, a service mesh system is provided, and the service mesh system has the function of implementing the traffic forwarding method behavior in the above - mentioned first aspect. The service mesh system includes at least one component, and this at least one component is used to implement the traffic forwarding method provided in the above - mentioned first aspect.

[0052] In a fourth aspect, a service mesh system is provided, and the service mesh system has the function of implementing the traffic forwarding method behavior in the above - mentioned second aspect. The service mesh system includes at least one component, and this at least one component is used to implement the traffic forwarding method provided in the above - mentioned second aspect.

[0053] In a fifth aspect, a computing device cluster is provided, and the computing device cluster includes at least one computing device, and each computing device includes a processor and a memory;

[0054] The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the traffic forwarding method provided in the first aspect above, or executes the traffic forwarding method provided in the second aspect above.

[0055] In a sixth aspect, there is provided a computer program product comprising instructions which, when run on a computing device cluster, cause the computing device cluster to execute the traffic forwarding method provided in the first aspect above, or execute the traffic forwarding method provided in the second aspect above.

[0056] In a seventh aspect, there is provided a computer-readable storage medium comprising computer program instructions which, when executed by a computing device cluster, cause the computing device cluster to execute the traffic forwarding method provided in the first aspect above, or execute the traffic forwarding method provided in the second aspect above.

[0057] The technical effects obtained by the corresponding technical means in the third to seventh aspects above are similar to those obtained by the corresponding technical means in the first or second aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 is a schematic diagram of the architecture of a service mesh system provided by an embodiment of the present application;

[0059] Figure 2 is a traffic forwarding flowchart of a system provided by an embodiment of the present application based on Figure 1 the system shown;

[0060] Figure 3 is a schematic diagram of the architecture of another service mesh system provided by an embodiment of the present application;

[0061] Figure 4 is a traffic forwarding flowchart of a system provided by an embodiment of the present application based on Figure 3 the system shown;

[0062] Figure 5 is a schematic diagram of the architecture of another service mesh system provided by an embodiment of the present application;

[0063] Figure 6 is a traffic forwarding method flowchart of a service mesh system provided by an embodiment of the present application;

[0064] Figure 7 is another traffic forwarding method flowchart of a service mesh system provided by an embodiment of the present application;

[0065] Figure 8It is a schematic diagram of the relationship between components in a certain state provided by an embodiment of the present application;

[0066] Figure 9 It is a flowchart of traffic forwarding in a certain state provided by an embodiment of the present application;

[0067] Figure 10 It is a schematic diagram of the relationship between components in a second state provided by an embodiment of the present application;

[0068] Figure 11 It is a flowchart of traffic forwarding in a second state provided by an embodiment of the present application;

[0069] Figure 12 It is a schematic diagram of the relationship between components in a third state provided by an embodiment of the present application;

[0070] Figure 13 It is a schematic diagram of the structure of a service mesh system provided by an embodiment of the present application;

[0071] Figure 14 It is a schematic diagram of the structure of another service mesh system provided by an embodiment of the present application;

[0072] Figure 15 It is a schematic diagram of the structure of a computing device provided by an embodiment of the present application;

[0073] Figure 16 It is a schematic diagram of the architecture of a computing device cluster provided by an embodiment of the present application;

[0074] Figure 17 It is a schematic diagram of the architecture of another computing device cluster provided by an embodiment of the present application. Detailed implementation manners

[0075] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0076] Before explaining the embodiments of the present application, the application scenarios of the embodiments of the present application will be explained first.

[0077] Through service mesh technology, the non-functional service governance logic in a distributed application with a microservices architecture can be separated from the business processes to a sidecar process outside the business processes, so as to provide connection, security, traffic control, gray release, and observation capabilities between services in a non-invasive manner, thereby realizing the lightweighting of business processes and the infrastructureization of service governance.

[0078] Figure 1 It is a schematic diagram of the architecture of a service mesh system provided by an embodiment of the present application. As Figure 1As shown in the figure, the service mesh system includes Node 1 and Node 2. Among them, Node 1 includes Pod 1 and Proxy Component 1. Pod 1 includes Application Component 1, Sidecar Component 1, and Network Protocol Table Component 1. Node 2 includes Pod 2 and Proxy Component 2. Pod 2 includes Application Component 2, Sidecar Component 2, and Network Protocol Table Component 2. Application Component 1 and Application Component 2 are used to provide services. Sidecar Component 1 and Sidecar Component 2 are used for service governance of traffic, such as performing routing processing, traffic limiting, and security authentication, etc.

[0079] Among them, Network Protocol Table 1 is also configured in Network Protocol Table Component 1, and Network Protocol Table 2 is also configured in Network Protocol Table Component 2. The network protocol table is also called iptables. Network Protocol Table 1 includes Sidecar Network Protocol Rule 1 configured for Sidecar Component 1, and Network Protocol Table 2 includes Sidecar Network Protocol Rule 2 configured for Sidecar Component 2. The sidecar network protocol rule is also called mesh iptables.

[0080] Figure 2 is a traffic forwarding flowchart of a system provided by an embodiment of the present application based on Figure 1 as shown in the figure. As Figure 2 shown in the figure, a pod including a sidecar component can also be called a pod injected with a sidecar component. As Figure 1 and Figure 2 shown in the figure, the traffic forwarding process includes the following steps.

[0081] (1) When Application Component 1 needs to access the service provided by Application Component 2, Application Component 1 generates a service access request, which is used to access the target service, and the target service is the service provided by Application Component 2.

[0082] (2) When the Network Protocol Table Component 1 in Pod 1 intercepts an outbound service access request, it processes the service access request in sequence according to the rules in Network Protocol Table 1. Since Network Protocol Table 1 includes Sidecar Network Protocol Rule 1 configured for Sidecar Component 1, after the Network Protocol Table Component 1 processes the service access request in sequence according to the rules in Network Protocol Table 1, it forwards the service access request to Sidecar Component 1, and Sidecar Component 1 continues to process the service access request.

[0083] (3) After Sidecar Component 1 processes the service access request, it determines that Pod 2 in Node 2 provides the target service. Therefore, Sidecar Component 1 can also establish a pod connection between Pod 1 and Pod 2. This pod connection is exemplarily a transmission control protocol (TCP) connection between Sidecar Component 1 and Sidecar Component 2, and forwards the service access request to Network Protocol Table Component 1 to continue the processing.

[0084] (4) The network protocol table component 1 forwards the service access request to pod 2 through the pod connection between pod 1 and pod 2. In other words, the destination address carried in the service access request sent by the network protocol table component 1 is the address of pod 2.

[0085] (5) When the network protocol table component 2 in pod 2 intercepts the incoming service access request, it processes the service access request sequentially according to the rules in the network protocol table 2. Since the network protocol table 2 includes the sidecar network protocol rule 2 configured for the sidecar component 2, after the network protocol table component 2 processes the service access request sequentially according to the rules in the network protocol table 2, it forwards the service access request to the sidecar component 2, and the sidecar component 2 continues to process the service access request.

[0086] (6) After the sidecar component 2 processes the service access request, it creates a TCP connection between the sidecar component 2 and the application component 2 and forwards the service access request to the network protocol table component 2 for continued processing.

[0087] (7) The network protocol table component 2 forwards the service access request to the application component 2 through the TCP connection between the sidecar component 2 and the application component 2, thus completing the access to the target service.

[0088] In Figure 1 and Figure 2 In the forwarding process shown, the traffic between node 1 and node 2 can skip the processing of the proxy component 1.

[0089] In addition, in Figure 1 and Figure 2 In the process shown, if problems such as increased traffic delay and increased traffic occupying node resources occur. During the process of the operation and maintenance personnel helping the customer to locate the cause of the problem, it is necessary to first determine whether the problem is caused by the automatic increase of the mesh data plane due to the use of the sidecar component. In some scenarios, during the operation of the service mesh system, the traffic in the specified pod can be dynamically bypassed the sidecar component for service access. If the service access is successful and the problem disappears at this time, it is necessary to further control the traffic in the pod to continue the service access through the sidecar component to continue to analyze and locate the detailed problem. In other words, it is necessary to dynamically control the traffic to bypass or not bypass the sidecar component during the operation of the service mesh system.

[0090] Figure 3 is the schematic diagram of the architecture of another service mesh system provided by the embodiment of the present application. Figure 4 is a traffic forwarding flow chart of a system provided by the embodiment of the present application based on Figure 3 shown. As Figure 3 shown, in Figure 1Based on the service mesh system shown, Node 1 further includes Controller 1, and Node 2 further includes Controller 2. As Figure 3 and Figure 4 shown, the process of traffic dynamically bypassing the sidecar component for service access includes the following steps.

[0091] (1) When Controller 1 receives a configuration command to bypass the mesh interception from the operation and maintenance personnel, Controller 1 backs up and deletes the sidecar network protocol rule 1 configured for the sidecar component 1 in the network protocol table 1 of Pod 1.

[0092] (2) When Controller 2 receives a configuration command to bypass the mesh interception from the operation and maintenance personnel, Controller 2 backs up and deletes the sidecar network protocol rule 2 configured for the sidecar component 2 in the network protocol table 2 of Pod 2.

[0093] (3) When Application Component 1 needs to access the service provided by Application Component 2, Application Component 1 generates a service access request, which is used to access the target service, that is, the service provided by Application Component 2.

[0094] (4) When the network protocol table component 1 in Pod 1 intercepts an outbound service access request, that is, intercepts outbound traffic, it processes the service access request sequentially according to the rules in the network protocol table 1. Since the network protocol table 1 does not include the sidecar network protocol rule 1 configured for the sidecar component 1, after the network protocol table component 1 processes the service access request sequentially according to other rules in the network protocol table 1, it forwards the service access request to the proxy component 1, and the proxy component 1 continues to process the service access request.

[0095] (5) After the proxy component 1 processes the service access request, it determines that a certain pod in Node 2 provides the target service. Therefore, the proxy component 1 can also establish a node connection between Node 1 and Node 2, and forward the service access request (that is, outbound traffic) to Node 2 through this node connection.

[0096] (6) When the network protocol table component 2 in Pod 2 intercepts an inbound service access request, that is, intercepts inbound traffic, it processes the service access request sequentially according to the rules in the network protocol table 2. Since the network protocol table 2 does not include the sidecar network protocol rule 2 configured for the sidecar component 2, after the network protocol table component 2 processes the service access request sequentially according to other rules in the network protocol table 2, it directly forwards the service access request to Application Component 2, thus completing the access to the target service.

[0097] When traffic dynamic bypass of the sidecar component for service access is not required, Node 1 can restore the sidecar network protocol rule 1 in the network protocol table 1, and Node 2 can restore the sidecar network protocol rule 2 in the network protocol table 2, so that traffic can perform service access according to the Figure 1 and Figure 2 shown process.

[0098] Since the sidecar network protocol rules include many rules, that is, the scale of the sidecar network protocol rules is large, it takes a certain time window to back up and delete the sidecar network protocol rules. In this way, it is easy to cause that during the process of deleting the sidecar network protocol rules, new service access requests are processed by incomplete sidecar network protocol rules, resulting in traffic being misprocessed. In addition, when restoring the backed-up sidecar network protocol rules, it is also necessary to ensure the order of insertion of different rules, and this operation is likely to cause traffic chaos.

[0099] Based on this, the embodiments of the present application provide a method for traffic forwarding based on a service mesh system, a service mesh system and related products, which can control traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rules configured for the sidecar component, so as to avoid the problems caused by backing up and deleting the sidecar network protocol rules.

[0100] The service mesh system, the method for traffic forwarding based on the service mesh system and related products provided by the embodiments of the present application will be explained below.

[0101] Figure 5 is a schematic diagram of the architecture of another service mesh system provided by the embodiments of the present application. As Figure 5 shown, the service mesh system includes multiple nodes, Figure 5 Taking the first node 10 and the second node 20 as examples for illustration.

[0102] Among them, the first node 10 includes at least one first pod 101, a first daemon component 102, a first kernel-mode four-layer component 103, and a first proxy component 104. At least one of the first pods 101 includes a first pod 101 injected with a sidecar component and / or a first pod 101 not injected with a sidecar component. That is, in the embodiments of the present application, pods injected with sidecar components and pods not injected with sidecar components can be compatible on the same node. For the first pod 101 injected with a sidecar component, the first pod 101 includes a first application component 1011, a first sidecar component 1012, and a first network protocol table component 1013. For the first pod 101 not injected with a sidecar component, the first pod 101 includes a first application component 1011 and a first network protocol table component 1013.

[0103] Similar to the first node 10, the second node 20 includes at least one second pod 201, a second guardian component 202, a second kernel-mode four-layer component 203, and a second proxy component 204. The at least one second pod 201 includes a second pod 201 injected with a sidecar component and / or a second pod 201 without a sidecar component injected. That is, in the embodiments of the present application, pods injected with sidecar components and pods without sidecar components injected can be compatible on the same node. For the second pod 201 injected with a sidecar component, the second pod 201 includes a second application component 2011, a second sidecar component 2012, and a second network protocol table component 2013. For the second pod 201 without a sidecar component injected, the second pod 201 includes a second application component 2011 and a second network protocol table component 2013.

[0104] Since the composition of the second node 20 is basically the same as that of the first node 10, the functions of each component in the first node 10 will be described below by taking the first node as an example. For the functions of each component in the second node 20, reference can be made to the first node 10, and no further explanation will be given here.

[0105] At least one first pod 101 in the first node 10 is used to provide the same service, that is, the services implemented by each first application component 1011 in the at least one first pod 101 are the same. A pod can be understood as the basic unit in a service mesh system, and components in the same pod share storage resources, network resources, etc.

[0106] The first sidecar component 1012 in the first pod 101 is used to perform service governance on the outbound traffic and inbound traffic of the first application component 1011, such as performing routing selection, traffic limiting, and security authentication. The first network protocol table component 1013 in the first pod 101 is used to filter the outbound traffic and inbound traffic of the first application component 1011 according to the rules in the preset first network protocol table. When the first sidecar component 1012 is injected into the first pod 101, the first network protocol table configured on the first network protocol table component 1013 includes the first sidecar network protocol rules corresponding to the first sidecar component 1012. When the first sidecar component 1012 is not injected into the first pod 101, the first network protocol table configured on the first network protocol table component 1013 does not include the first sidecar network protocol rules corresponding to the first sidecar component 1012.

[0107] The first guardian component 102 is used to enable the functions of certain components in the first node in response to operations of users such as operation and maintenance personnel. The detailed functions of the first guardian component 102 will be described in detail in subsequent embodiments and will not be elaborated here. The first kernel-mode layer-4 component 103 is used to perform layer-4 traffic governance on the outbound traffic and inbound traffic of the first application component 1011, such as layer-4 load balancing, security encryption, etc.

[0108] The first proxy component 104 is used to perform node-level traffic processing on the outbound traffic and inbound traffic of the first application component 1011.

[0109] In addition, in a scenario where layer 4 (L4) and layer 7 (L7) are separated, as Figure 5 shown, the service mesh system may further include a layer-7 cluster component 30, and the layer-7 cluster component 30 is used to perform layer-7 traffic governance on the traffic between nodes.

[0110] In the embodiments of the present application, the service mesh system may be a service mesh system based on Kubernetes, and Kubernetes is also referred to as k8s or kube. In this scenario, the first guardian component 102 may also be referred to as the first Kmesh Daemon 102, the first kernel-mode layer-4 component 103 may also be referred to as the first Kmesh L4 103, and the first proxy component 104 may also be referred to as the first kube-proxy 104. The layer-7 cluster component 30 may also be referred to as the Kmesh L7 cluster.

[0111] Optionally, the service mesh system may also be a service mesh system based on other technologies, which will not be exemplified one by one here.

[0112] In addition, Figure 5 the components and the corresponding quantities in Figure 1 are used for illustrative purposes. The service mesh system provided in the embodiments of the present application may include more or fewer components compared to

[0113] Figure 6 is a flowchart of a traffic forwarding method based on a service mesh system provided in the embodiments of the present application. This method is exemplarily applied to Figure 5 the first node shown in Figure 6 As shown in

[0114] Step 601: The first network protocol table component receives a first service access request from the first application component, and the first service access request is used to access a target service.

[0115] As Figure 5As shown, when the first application component generates a service access request for accessing a target service, the first network protocol table component in the first pod will intercept the service access request, and judge the service access request according to the rules in the pre-configured first network protocol table, so as to continue forwarding the service access request that meets the rules in the first network protocol table, and filter out the service access request that does not meet the rules in the first network protocol table.

[0116] In the embodiment of the present application, a first extension rule is extended in the first network protocol table, and it can be determined whether to skip the first sidecar network protocol rule by executing the first extension rule. That is, when it is determined by executing the first extension rule to skip the first sidecar network protocol rule, the first network protocol table component does not filter the service access request according to the first sidecar network protocol rule, so as to bypass the interception of the egress traffic by the first sidecar component. When it is determined by executing the first extension rule not to skip the first sidecar network protocol rule, the first network protocol table component filters the service access request according to the first sidecar network protocol rule, so as to intercept the egress traffic through the first sidecar component and perform service governance.

[0117] Based on this, when the operation and maintenance personnel need to control the traffic to bypass the sidecar component, they only need to configure the extension rule in the network protocol table, without backing up and deleting the sidecar network protocol rule, which can ensure the atomicity of enabling all the original sidecar network protocol rules when controlling the traffic to bypass the sidecar component.

[0118] In some embodiments, the first network protocol table includes multiple tables. Exemplarily, the first network protocol table includes a postrouting table for filtering the egress traffic of the first application component. In the embodiment of the present application, a first extension rule can be added to the postrouting table to implement the method provided by the embodiment of the present application. In other words, the first network protocol table includes a postrouting table, and the postrouting table includes a first extension rule and a first sidecar network protocol rule.

[0119] In this scenario, the first extension rule is the first rule in the postrouting table. Since the first network protocol table component executes each rule one by one when executing the rules in the first network protocol table, in order to ensure that the first network protocol table component executes the first extension rule before executing the first sidecar network protocol rule, the first extension rule is set as the first rule in the postrouting table.

[0120] In addition, when the operation and maintenance personnel update the rule in the first sidecar network protocol rule, the first extension rule always remains the first rule in the postrouting table.

[0121] Optionally, the first extension rule can also be set in other tables in the first network protocol table, as long as it is ensured that the first network protocol table component executes the first extension rule before executing the first sidecar network protocol rule. Examples are not given one by one here.

[0122] In addition, when the user backs up and deletes the sidecar network protocol rules, since the sidecar network protocol rules are located in the kernel, it is also necessary to lock the sidecar network protocol rules. Correspondingly, new traffic is also locked when processed by the locked sidecar network protocol rules, so that the traffic cannot continue to access the service, which in turn leads to performance problems in the service mesh system.

[0123] Based on this, in order to prevent operators from operating on the first network protocol table when they need to control traffic to bypass the sidecar component, in some embodiments, the first extension rule includes an identifier of a first kernel program, and the first kernel program is used to skip the first sidecar network protocol rule; wherein, when the first kernel program is in the on state, the first interception result indicates skipping the first sidecar network protocol rule, and when the first kernel program is in the off state, the first interception result indicates not skipping the first sidecar network protocol rule.

[0124] In this way, when operators need to control traffic to bypass the sidecar component, they only need to control the first kernel program to be in the on state, without modifying the rules in the first network protocol table, thus avoiding performance problems in the service mesh system caused by modifying the first network protocol table.

[0125] In the scenario where the first extension rule includes an identifier of a first kernel program, operators can Figure 5 enable or disable the first kernel program through the first daemon component in. Based on this, in some embodiments, in response to a first sidecar interception configuration instruction triggered by the user, the first daemon component sets the first kernel program to be in the on state or the off state based on the first sidecar interception configuration instruction.

[0126] Exemplarily, when the first sidecar interception configuration instruction indicates that the first sidecar component does not intercept the egress traffic of the first application component, the first daemon component sets the first kernel program to the on state, so that the egress traffic of the first application component does not undergo service governance through the first sidecar component. Another example is that when the first sidecar interception configuration instruction indicates that the first sidecar component intercepts the egress traffic of the first application component, the first daemon component sets the first kernel program to the off state, so that all the egress traffic of the first application component undergoes service governance through the first sidecar component.

[0127] Optionally, the first daemon component is provided with a user interaction interface through which an operation and maintenance personnel can trigger a first sidecar interception configuration instruction in a preset operation. The preset operation can be a voice operation, a keyboard input, a mouse selection, etc., and will not be enumerated here one by one.

[0128] In addition, in a scenario where the first extension rule includes an identifier of a first kernel program, the operation and maintenance personnel can add the first extension rule to the first network protocol table during system initialization. Based on this, in some embodiments, in response to creating the first pod, the first daemon component adds the first extension rule to the first network protocol table of the first pod.

[0129] In the above manner, the first extension rule can be added to the first network protocol table when creating the first pod, so that there is no need to operate on the first network protocol table in subsequent operations. For example, add the first extension rule to the egress exchange table in the first network protocol table.

[0130] Optionally, the first extension rule can be a specific indication message, and the first network protocol table component can directly determine whether to skip the first sidecar network protocol rule through the first extension rule. In this scenario, when the operation and maintenance personnel need to control the traffic to bypass the sidecar component, the first extension rule is temporarily added to the first network protocol table to implement the traffic forwarding method provided by the embodiments of the present application.

[0131] Step 602: The first network protocol table component executes the first extension rule to obtain a first interception result, and the first interception result is used to indicate whether to skip the first sidecar network protocol rule.

[0132] Based on step 601, it can be known that the first network protocol table component first executes the first extension rule. After executing the first extension rule, it determines whether to continue executing the first sidecar network protocol rule based on the first interception result obtained by executing the first extension rule.

[0133] For the manner of obtaining the first interception result, reference can be made to the implementation manner of the first extension rule in step 601, which will not be elaborated here.

[0134] Step 603: In response to the first interception result indicating to skip the first sidecar network protocol rule, the first network protocol table component forwards the first service access request to a second node among multiple nodes, and the second node is used to provide a target service.

[0135] When the first interception result indicates skipping the first sidecar network protocol rule, the first network protocol table component does not send the first service access request to the first sidecar component, but sends the first service access request to the second node for providing the target service, so that the egress traffic of the first application component in the first pod can bypass the interception of the first sidecar component.

[0136] In some embodiments, the implementation manner in which the first network protocol table component forwards the first service access request to the second node among multiple nodes may be: the first network protocol table component forwards the first service access request to the first proxy component; the first proxy component processes the first service access request to obtain a third service access request; the first proxy component forwards the third service access request to the second node.

[0137] It should be noted that the destination address carried in the service access request generated by the first application component is the address of the target service. Since the egress traffic of the first application component in the first pod bypasses the first sidecar component, the destination address carried in the first service access request received by the first proxy component is still the address of the target service. At this time, the first proxy component needs to process the first service access request to convert the destination address in the first service access request into the address of a certain pod in the node that can provide the target service, so as to obtain the third service access request.

[0138] In addition, in step 602, after the first network protocol table component executes the first extension rule and obtains the first interception result, in response to the first interception result indicating not to skip the first sidecar network protocol rule, after the first network protocol table component executes the first sidecar network protocol rule, it forwards the first service access request to the first sidecar component, and the first sidecar component processes the first service access request to obtain a second service access request; the first network protocol table component receives the second service access request from the first sidecar component; the first network protocol table component forwards the second service access request to the second node.

[0139] Among them, the first sidecar component processes the first service access request to obtain the second service access request, which can be understood as: the first sidecar component processes the first service access request to convert the destination address in the first service access request into the address of a certain pod in the node that can provide the target service, so as to obtain the second service access request.

[0140] By executing the first extension rule, the traffic can also be controlled not to bypass the sidecar component, that is, to control the sidecar component to intercept the egress traffic of the application component.

[0141] In this scenario, the implementation method for the first network protocol table component to forward the second service access request to the second node can be as follows: The first network protocol table component forwards the second service access request to the first proxy component; when the first proxy component receives the second service access request, since the destination address in the second service access request is already the address of a certain pod in the node that can provide the target service, the first proxy component does not need to process the second service access request, but forwards the second service access request to the second node according to the destination address in the second service access request.

[0142] The above implementation method can be applied to the scenario where the node does not include a kernel-mode four-layer component. Optionally, in some other embodiments, the first node further includes a first kernel-mode four-layer component. In this scenario, the above implementation method is applied when the first kernel-mode four-layer component is in the closed state.

[0143] Optionally, when the first kernel-mode four-layer component is in the open state, the implementation method for the first network protocol table component to receive the service access request from the first application component can be as follows: The first kernel-mode four-layer component receives the fourth service access request, the first kernel-mode four-layer component processes the fourth service access request to obtain the first service access request, and the first kernel-mode four-layer component sends the first service access request to the first network protocol table component.

[0144] Among them, the first kernel-mode four-layer component processes the fourth service access request, that is, performs four-layer traffic governance, to obtain the first service access request, which can be understood as: The first kernel-mode four-layer component processes the fourth service access request to convert the destination address in the fourth service access request into the address of a certain pod in the node that can provide the target service, so as to obtain the first service access request.

[0145] In this scenario, the implementation method for the first network protocol table component to forward the first service access request to the second node can be as follows: The first network protocol table component forwards the first service access request to the first proxy component; when the first proxy component receives the first service access request, since the destination address in the first service access request is already the address of a certain pod in the node that can provide the target service, the first proxy component does not need to process the first service access request, but forwards the first service access request to the second node according to the destination address in the first service access request.

[0146] When the first kernel-mode four-layer component in the first node is in the enabled state, all egress traffic in the first application component will first be intercepted by the first kernel-mode four-layer component. Therefore, when the first kernel-mode four-layer component receives a fourth service access request from the first application component, after performing four-layer traffic governance on the fourth service access request, it sends the governed first service access request to the first network protocol table component, so that the first network protocol table component can determine whether to bypass the first sidecar component through the above steps 601-603.

[0147] It should be noted that the mechanism of the first proxy component and the aforementioned first kernel-mode four-layer component for selecting pods in the second node that can provide the target service from the service mesh system is different. The embodiments of the present application do not elaborate on how the first proxy component and the first kernel-mode four-layer component select pods in the second node that can provide the target service from the service mesh system.

[0148] In addition, in the embodiments of the present application, the operation and maintenance personnel can also set the on or off state of the first kernel-mode four-layer component through the first daemon component. Based on this, in some embodiments, in response to a first four-layer interception configuration instruction triggered by the user, the first daemon component sets the first kernel-mode four-layer component to the on state or the off state based on the first four-layer interception configuration instruction.

[0149] Exemplarily, when the first four-layer interception configuration instruction instructs the first kernel-mode four-layer component to intercept the egress traffic of the first application component, the first daemon component sets the first kernel-mode four-layer component to the on state, so that the egress traffic of the first application component undergoes four-layer traffic governance through the first kernel-mode four-layer component. Another example is that when the first four-layer interception configuration instruction instructs the first kernel-mode four-layer component not to intercept the egress traffic of the first application component, the first daemon component sets the first kernel-mode four-layer component to the off state, so that the egress traffic of the first application component does not undergo four-layer traffic governance through the first kernel-mode four-layer component.

[0150] Optionally, the first daemon component provides a user interface, and the operation and maintenance personnel can trigger the first four-layer interception configuration instruction through a preset operation on the user interface. The preset operation can be a voice operation, a keyboard input, a mouse selection, etc., and will not be exemplified one by one here.

[0151] In addition, the above is described by taking the first pod in the first node injected with the first sidecar component as an example. Optionally, for the first pod in the first node without the injection of the sidecar component, three scenarios are respectively exemplified below.

[0152] Scenario 1: The first kernel-mode four-layer component included in the first node is in the on state, and the first interception result indicates skipping the sidecar network protocol rule.

[0153] For the first pod without an injected sidecar component in the first node, when the first application component in the first pod generates a service access request, since the first kernel-mode layer-4 component is in the enabled state, the service access request is also intercepted by the first kernel-mode layer-4 component. Therefore, when the first kernel-mode layer-4 component receives the service access request from the first application component, after processing the service access request, it sends the processed service access request to the first network protocol table component. Since the first sidecar component is not injected into the first pod, the first network protocol table does not include the first sidecar network protocol rule corresponding to the first sidecar component. In this scenario, after filtering the received service access request according to other rules in the first network protocol table, the first network protocol table component forwards the service access request to the second node through the proxy component.

[0154] For the first pod with an injected sidecar component in the first node, when the first application component in the first pod generates a service access request, since the first kernel-mode layer-4 component is in the enabled state, the service access request is also intercepted by the first kernel-mode layer-4 component. Therefore, when the first kernel-mode layer-4 component receives the service access request from the first application component, after processing the service access request, it sends the processed service access request to the first network protocol table component. Since the first sidecar component is injected into the first pod, the first network protocol table includes the first sidecar network protocol rule corresponding to the first sidecar component. In this scenario, after executing the first extended rule and skipping the first sidecar network protocol rule, the first network protocol table component also forwards the service access request to the second node through the proxy component.

[0155] Therefore, in the embodiment of the present application, in the scenario of separation between L4 and L7, when the first kernel-mode layer-4 component included in the first node is in the enabled state and the first interception result indicates skipping the sidecar network protocol rule, regardless of whether the pod in the first node has an injected sidecar component or not, four-layer traffic governance is performed on the egress traffic of the application component in the pod, achieving compatibility between pods with sidecar components and pods without sidecar components in the scenario of separation between L4 and L7.

[0156] Scenario 2: The first kernel-mode layer-4 component included in the first node is in the disabled state and the first interception result indicates skipping the sidecar network protocol rule.

[0157] For the first pod in the first node without an injected sidecar component, when the first application component in the first pod generates a service access request, since the first kernel-mode layer-4 component is in the closed state, the service access request is intercepted by the first network protocol table component. Since the first sidecar component is not injected into the first pod, the first network protocol table does not include the first sidecar network protocol rule corresponding to the first sidecar component. In this scenario, after filtering the service access request according to other rules in the first network protocol table, the first network protocol table component forwards the service access request to the first proxy component for the first proxy component to process the service access request.

[0158] For the first pod in the first node with an injected sidecar component. When the first application component in the first pod generates a service access request, since the first kernel-mode layer-4 component is in the closed state, the service access request is also intercepted by the first network protocol table component. Since the first sidecar component is injected into the first pod, the first network protocol table includes the first sidecar network protocol rule corresponding to the first sidecar component. In this scenario, after executing the first extension rule and skipping the first sidecar network protocol rule, the first network protocol table component forwards the service access request to the first proxy component for the first proxy component to process the service access request.

[0159] Therefore, in the embodiment of the present application, in the scenario of L4 and L7 separation, when the first kernel-mode layer-4 component is in the closed state and the first interception result indicates skipping the sidecar network protocol rule, whether it is a pod with an injected sidecar component or a pod without an injected sidecar component in the first node, the egress traffic of the application component in the pod will be processed by the first proxy component, achieving compatibility between pods with sidecar components and pods without sidecar components in the L4 and L7 separation scenario.

[0160] Scenario 3: The first kernel-mode layer-4 component included in the first node is in the closed state and the first interception result indicates not skipping the sidecar network protocol rule.

[0161] For the first pod in the first node without an injected sidecar component. Since the first sidecar component is not injected into the first pod, the first network protocol table does not include the first sidecar network protocol rule corresponding to the first sidecar component. In this scenario, after filtering the service access request according to other rules in the first network protocol table, the first network protocol table component forwards the service access request to the first proxy component for the first proxy component to process the service access request.

[0162] Regarding the first pod in the first node into which the sidecar component is injected. Since the first sidecar component is injected into the first pod, the first network protocol table includes the first sidecar network protocol rules corresponding to the first sidecar component. In this scenario, after filtering the service access request according to the first sidecar network protocol rules in the first network protocol table, the first network protocol table component forwards the service access request to the first sidecar component for the first sidecar component to process the service access request.

[0163] Therefore, in the embodiment of the present application, in the scenario where L4 and L7 are separated, when the first kernel-mode layer-4 component included in the first node is in the closed state and the first interception result indicates not to skip the sidecar network protocol rules, for the pod in the first node into which the sidecar component is injected and the pod without the injected sidecar component, the egress traffic of the application components in the pod can be processed in different ways, realizing the compatibility between the pod with the sidecar component and the pod without the sidecar component in the scenario where L4 and L7 are separated.

[0164] It should be noted that in the scenario where the first node includes the first kernel-mode layer-4 component, considering that users will not require the first sidecar component and the first kernel-mode layer-4 component to process traffic simultaneously, for the scenario where the first interception result indicates not to skip the first sidecar network protocol rules, the first kernel-mode layer-4 component is in the closed state.

[0165] In summary, in the embodiment of the present application, the first network protocol table configured on the first network protocol table component not only includes the first sidecar network protocol rules corresponding to the first sidecar component, but also includes the first extension rule. By executing the first extension rule, it can be determined whether to skip the first sidecar network protocol rules, that is, whether the egress traffic of the first application component bypasses the first sidecar component. Based on this, the operation and maintenance personnel can control whether the egress traffic of the first application component bypasses the first sidecar component through the first extension rule newly added to the first network protocol table, without backing up and deleting the first sidecar network protocol rules. Therefore, the embodiment of the present application provides a method for controlling traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rules configured for the sidecar component, so as to avoid the problems caused by backing up and deleting the sidecar network protocol rules.

[0166] Figure 7 It is a flowchart of another traffic forwarding method based on the service mesh system provided by the embodiment of the present application. This method is exemplarily applied to Figure 5 the second node shown in Figure 7 As shown in, this method includes the following steps.

[0167] Step 701: The second network protocol table component receives a service access request from the first node among multiple nodes, and this service access request is used to access the target service.

[0168] Based on Figure 6 As can be seen from the illustrated embodiments, in a scenario where the second node includes a second kernel-mode four-layer component, if the second kernel-mode four-layer component is in an enabled state, correspondingly, the second kernel-mode four-layer component will first intercept the incoming traffic of the second node.

[0169] Based on this, in some embodiments, when the second kernel-mode four-layer component is in an enabled state, the implementation manner of step 701 may be: the second kernel-mode four-layer component receives a service access request; the second kernel-mode four-layer component sends the service access request to the second network protocol table component based on the destination address of the service access request.

[0170] Exemplarily, the destination address carried in the service access request intercepted by the second kernel-mode four-layer component is the address of a certain pod in the second node. Therefore, the second kernel-mode four-layer component can directly route the service access request to the second network protocol included in the pod based on the destination address.

[0171] Optionally, if the second kernel-mode four-layer component is in a disabled state, since the destination address carried in the service access request is the address of a certain pod in the second node, the incoming traffic of the second node directly enters the second network protocol table component of the pod. In other words, the second network protocol table component directly receives the service access request from the first node.

[0172] In addition, in some embodiments, the second daemon component in the second node can also set the state of the second four-layer kernel-mode component in response to an operation by an operation and maintenance personnel. Exemplarily, in response to a second four-layer interception configuration instruction triggered by a user, the second daemon component sets the second kernel-mode four-layer component to be in an enabled state or a disabled state based on the second four-layer interception configuration instruction. The specific implementation manner can refer to Figure 6 the relevant content in the embodiments, which will not be elaborated here.

[0173] Step 702: The second network protocol table component executes the second extended rule to obtain a second interception result, and the second interception result is used to indicate whether to skip the second sidecar network protocol rule.

[0174] The implementation manner of step 702 can refer to Figure 6 step 602 in the embodiments, which will not be elaborated here.

[0175] In some embodiments, the second network protocol table includes an ingress swap table, and the ingress swap table includes a second extended rule and a second sidecar network protocol rule. Exemplarily, the second extended rule is the first rule in the ingress swap table.

[0176] In addition, in some embodiments, the second extension rule includes an identifier of a second kernel program, and the second kernel program is used to skip the second sidecar network protocol rule; wherein, when the second kernel program is in the enabled state, the second interception result indicates skipping the second sidecar network protocol rule, and when the second kernel program is in the disabled state, the second interception result indicates not skipping the second sidecar network protocol rule.

[0177] In addition, in some embodiments, the second node further includes a second daemon component. In this scenario, in response to a second sidecar interception configuration instruction triggered by a user, the second daemon component sets the second kernel program to be in the enabled state or the disabled state based on the second sidecar interception configuration instruction.

[0178] In addition, in some embodiments, in response to creating a second pod, the second daemon component adds a second extension rule to the second network protocol table of the second pod.

[0179] The implementation manner of the above second extension rule can also refer to Figure 6 the implementation manner of the first extension rule in the embodiments, which will not be elaborated here.

[0180] Step 703: In response to the second interception result indicating skipping the second sidecar network protocol rule, the second network protocol table component forwards the service access request to the second application component, and the second application component is used to provide the target service.

[0181] When the second interception result indicates skipping the second sidecar network protocol rule, it means that the ingress traffic of the second application component does not need to go through the second sidecar component for service governance. Therefore, the second network protocol table component can directly forward the service access request to the second application component, and the second application component performs the business processing corresponding to the target service on the service access request.

[0182] Optionally, in response to the second interception result indicating executing the second sidecar network protocol rule, the second network protocol table component executes the second sidecar network protocol rule on the service access request; after the second network protocol table component executes the second sidecar network protocol rule, it forwards the service access request to the second sidecar component, and the second sidecar component processes the service access request; the second network protocol table component receives the service access request processed by the second sidecar component and forwards the received service access request to the second application component.

[0183] When the second interception result indicates not skipping the second sidecar network protocol rule, it means that the ingress traffic of the second application component needs to go through the second sidecar component for service governance. Therefore, before the second network protocol table component forwards the service access request to the second application component, it needs to first forward the service access request to the second sidecar component, and the second sidecar component performs service governance on the service access request.

[0184] In an embodiment of the present application, the second network protocol table configured on the second network protocol table component includes not only the second sidecar network protocol rules corresponding to the second sidecar component, but also second extension rules. By executing the second extension rules, it can be determined whether to skip the second sidecar network protocol rules, that is, whether the ingress traffic of the second application component bypasses the second sidecar component. Based on this, the operation and maintenance personnel can control whether the ingress traffic of the second application component bypasses the second sidecar component by adding the second extension rules to the second network protocol table, without backing up and deleting the second sidecar network protocol rules. Therefore, the embodiment of the present application provides a method for controlling traffic to bypass the sidecar component for service access without backing up and deleting the sidecar network protocol rules configured for the sidecar component, so as to avoid the problems caused when backing up and deleting the sidecar network protocol rules.

[0185] It should be noted that Figure 6 and Figure 7 take the first node and the second node as examples respectively to illustrate how to set the interception methods for the egress traffic and ingress traffic of the application component. Optionally, the functions of the above-mentioned second node can also be implemented on the first node. In other words, the second extension rules can also be extended on the first node to set the interception method for the ingress traffic of the first application component through the second extension rules. The functions of the above-mentioned first node can also be implemented on the second node. In other words, the first extension rules can also be extended on the second node to set the interception method for the egress traffic of the second application component through the first extension rules. Examples are not given one by one here.

[0186] In addition, based on Figure 6 and Figure 7 the embodiments shown, in a scenario where the extension rules include the identifier of the kernel-mode program and the node includes a kernel-mode four-layer component, the forwarding path of the traffic can be changed by controlling the opening and closing of the kernel-mode program and the kernel-mode four-layer component, so as to implement the traffic forwarding method based on the service mesh system provided by the embodiment of the present application.

[0187] Among them, the kernel-mode programs indicated by the identifiers of the extended rules can be in an enabled or disabled state, and the four-layer kernel-mode components can be in an enabled or disabled state. Considering that the kernel-mode program is in the disabled state (i.e., traffic needs to be intercepted by the sidecar component) and the four-layer kernel-mode component is in the enabled state (i.e., traffic needs to be intercepted by the four-layer kernel-mode component), this scenario is not allowed. Therefore, the operation and maintenance personnel can set three states: "kernel-mode program is in the enabled state + four-layer kernel-mode component is in the enabled state", "kernel-mode program is in the enabled state + four-layer kernel-mode component is in the disabled state", and "kernel-mode program is in the disabled state + four-layer kernel-mode component is in the disabled state" to achieve traffic forwarding in three different states. The following is an example description of these three states respectively.

[0188] State 1: The kernel-mode program is in the enabled state + the four-layer kernel-mode component is in the enabled state.

[0189] In State 1, based on the relevant content of step 603, the implementation method for the first network protocol table component to receive the first service access request from the first application component can be as follows: the first four-layer kernel-mode component receives the fourth service access request from the first application component, and the destination address carried in the fourth service access request is the address of the target service; the first four-layer kernel-mode component processes the fourth service access request to obtain the first service access request, and the destination address carried in the first service access request is the address of the destination pod, and the destination pod is the pod in the second node; the first four-layer kernel-mode component sends the first service access request to the first network protocol table component.

[0190] Correspondingly, the implementation method for the first network protocol table component to forward the first service access request to the second node among multiple nodes in step 603 can be: the first network protocol table component forwards the first service access request to the first proxy component; in response to the destination address in the first service access request already being the address of the destination pod, the first proxy component does not process the first service access request, but forwards the first service access request to the second node, as if the first network protocol table component skips the first proxy component to forward the service access request.

[0191] Figure 8 It is a schematic diagram of the relationship between components in State 1 provided by an embodiment of the present application. Figure 9 It is a traffic forwarding flowchart in State 1 provided by an embodiment of the present application. As Figure 8 and Figure 9 shown, when the kernel-mode program indicated by the extended rule is in the enabled state and the four-layer kernel-mode component is in the enabled state, the forwarding path of the service access request generated by the first application component is the forwarding path shown in the following steps.

[0192] (1) The guardian components (also known as kmesh Daemon) in the first node and the second node monitor the pods created by their respective nodes. When the first node creates the first pod, it inserts (or injects) a first extended rule before the sidecar network protocol rule corresponding to the sidecar component in the POSTROUTING (export routing table). The first extended rule is an eBPF kernel program entry, such as iptables bpf xxx.o, which is used to point to the first kernel program. When the second node creates the second pod, it inserts a second extended rule before the sidecar network protocol rule corresponding to the sidecar component in the PREROUTING (import routing table). The second extended rule is also an eBPF kernel program entry, such as iptables bpf xxx.o, which is used to point to the second kernel program.

[0193] (2) By default, the guardian component on each node sets the kernel-level four-layer component (also known as kmesh L4) of the corresponding node to the default mode of intercepting all mesh traffic, that is, the kernel-level four-layer component is set to the enabled state by default.

[0194] (3) When the first application component (APP) in the first pod injected with the first sidecar component accesses a service, the service access request generated by the first application component is first intercepted by the first kernel-level four-layer component, and the first kernel-level four-layer component performs the L4 traffic governance function on the service access request. Such as L4 load balancing, to convert the destination address in the service access request to the address of a pod on the second node.

[0195] The first kernel-level four-layer component calls the first network protocol table component in the pod. At this time, the first network protocol table component will first execute the first rule in the export routing table, that is, the first extended rule. Among them, the first extended rule points to the first kernel program, and the execution logic of the first kernel program is to skip all sidecar network protocol rules.

[0196] (4) As Figure 8 and Figure 9 shown, after the first network protocol table component filters the service access request, it can also return the service access request to the first kernel-level four-layer component, and the first kernel-level four-layer component performs other service governance on the service access request, such as traffic limiting, security encryption, etc. At this time, after the first kernel-level four-layer component processes the service access request, it forwards the service access request through the subsequent step (6) or steps (7) and (8).

[0197] Optionally, after the first network protocol table component executes the first extended rule, it skips the first sidecar network protocol rule and directly forwards the service access request to the second node through the first proxy component.

[0198] (5) Service access requests generated by application components in the ordinary pod injected with non-sidecar components in the first node will be directly intercepted by the first kernel-mode four-layer component. When the first kernel-mode four-layer component calls the first network protocol table component in the ordinary pod, since there is no sidecar network protocol rule corresponding to the sidecar component in the ordinary pod, the first kernel-mode four-layer component directly performs the L4 traffic governance function on the service access request. Its subsequent processing is the same as that in (4).

[0199] (6) The first kernel-mode four-layer component can directly access the second kernel-mode four-layer component of the target node (i.e., the second node) through the fast path.

[0200] (7) When L7 processing of the service access request is required, an independent seven-layer cluster component (also called the kmesh L7 elastic cluster) will be called to continue the L7 traffic governance of the service access request.

[0201] (8) After the seven-layer cluster component completes the L7 traffic governance, it will create a connection between the seven-layer cluster component and the second kernel-mode four-layer component to call the second kernel-mode four-layer component of the target node.

[0202] (9) Since the inbound second kernel-mode four-layer component has interception enabled, the second kernel-mode four-layer component will send the service access request to the pod injected with the sidecar component or other ordinary pods in the second node according to the destination address of the intercepted service access request.

[0203] (10) Since a second extended rule is inserted into the ingress switching table of the second node, and the second extended rule points to the second kernel program, the execution logic of the second kernel program also skips the subsequent sidecar network protocol rules. Therefore, the final service access request does not enter the second sidecar component but is directly sent to the second application component.

[0204] Among them, as Figure 9 shown, after filtering the service access request, the second network protocol table component can also return the service access request to the second kernel-mode four-layer component, and the second kernel-mode four-layer component performs other service governance on the service access request, such as traffic limiting, security encryption, etc. At this time, after processing the service access request, the second kernel-mode four-layer component forwards the service access request to the second pod including the second sidecar component on the second node.

[0205] Based on Figure 8 and Figure 9In the solution shown, the daemon component controls the current interception method as follows: only skip the traffic interception logic of the sidecar component, but not skip the traffic interception logic of the kernel-mode four-layer component itself. Among them, the daemon component only needs to control the kernel-mode four-layer component to be in the enabled state and the kernel program indicated by the extended rule to be in the enabled state at the same time, so that all egress traffic can be forwarded through the kernel-mode four-layer component.

[0206] In addition, in Figure 8 and Figure 9 In the solution shown, it is possible to allow the egress traffic of the pod with the sidecar component injected and the egress traffic of the pod without the sidecar component injected to behave the same in the processing behavior of the kernel-mode four-layer component, which can provide better compatibility.

[0207] State two: The kernel-mode program is in the enabled state + the kernel-mode four-layer component is in the disabled state.

[0208] In state two, based on Figure 6 Regarding the relevant content of step 603 in

[0209] Figure 10 It is a schematic diagram of the relationship between various components in state two provided by an embodiment of the present application. Figure 11 It is a traffic forwarding flow chart in state two provided by an embodiment of the present application. As Figure 10 and Figure 11 shown, when the kernel-mode program indicated by the extended rule is in the enabled state and the kernel-mode four-layer component is in the disabled state, the forwarding path of the service access request generated by the first application component is the forwarding path shown in the following steps.

[0210] (1) When the daemon component on each node receives the bypass all mesh interception command issued by the administrator, it will issue a close interception command to its respective kernel-mode four-layer component, that is, set the kernel-mode four-layer component on the corresponding node to the disabled state.

[0211] (2) When the first application component (APP) in the first pod with the first sidecar component injected accesses the service, since the first kernel-mode four-layer component is in the disabled state, the service access request generated by the first application component is intercepted by the first network protocol table component and the service access request is processed according to the rules in the first network protocol table.

[0212] (3) At this time, the first network protocol table component will first execute the first rule in the egress exchange table, that is, the first extended rule. Among them, the first extended rule points to the first kernel program, and the execution logic of the first kernel program is to skip all sidecar network protocol rules. Since the first kernel program is in the enabled state, after the first network protocol table component executes the first extended rule, it skips all sidecar network protocol rules and sends the service access request to the first proxy component, and the first proxy component processes the service access request.

[0213] (4) Similarly, the traffic sent by the pod injected without the sidecar component enters the first proxy component because the first kernel-mode four-layer component is closed and there is no default sidecar network protocol rule.

[0214] (5) The service access request sent by the first node enters the second network protocol table component of the pod in the second node.

[0215] (6) The second network protocol table component executes the rules in the second network protocol table. For the pod injected with the sidecar component, since the second extended rule is inserted in the ingress exchange table, the second extended rule points to the second kernel program, and the execution logic of the second kernel program is to skip all sidecar network protocol rules, and the second kernel program is in the enabled state. Therefore, after the second network protocol table component executes the second extended rule, it sends the service access request to the second application component. For the pod without the sidecar component injected, the second network protocol table component directly forwards the service access request to the second application component.

[0216] Based on Figure 10 and Figure 11 The solution shown, the daemon component controls the current interception method as: not only skipping the interception of the kernel-mode four-layer component itself, but also skipping the interception of the sidecar component. Among them, the daemon component only needs to control the kernel-mode four-layer component to be in the closed state and the kernel program indicated by the extended rule to be in the enabled state at the same time, so that all egress traffic originally intercepted by the kernel-mode four-layer component can be forwarded only by the proxy component calling the iptables rules of k8s. At this time, the egress traffic of the pod injected with the sidecar component and the egress traffic of the pod without the sidecar component injected behave the same in the processing behavior of the proxy component, which can not only provide better compatibility, but also quickly help locate whether problems such as egress traffic delay are caused by the introduction of the sidecar component.

[0217] Status three: The kernel-mode program is in the closed state + the kernel-mode four-layer component is in the closed state.

[0218] In State 3, based on the relevant content of Step 603, after the first network protocol table component executes the first extension rule and obtains the first interception result, and in response to the first interception result indicating not to skip the first sidecar network protocol rule, after the first network protocol table component executes the first sidecar network protocol rule, it forwards the first service access request to the first sidecar component. The first sidecar component processes the first service access request to obtain a second service access request. The destination address carried in the second service access request is the address of the destination pod, and the destination pod is a pod in the second node. The first network protocol table component receives the second service access request from the first sidecar component. The first network protocol table component forwards the second service access request to the first proxy component. In response to the destination address in the second service access request being the address of the destination pod, the first proxy component does not process the second service request but directly forwards the second service access request to the second node, seemingly as if the first network protocol table component skips the first proxy component in the first node to forward the service access request.

[0219] Figure 12 It is a schematic diagram of the relationship between components in State 3 provided by an embodiment of the present application. As Figure 12 shown, when the kernel-mode program indicated by the extension rule is in the closed state and the kernel-mode four-layer component is in the closed state, the forwarding path of the service access request generated by the first application component is the forwarding path shown in the following steps.

[0220] (1) When the daemon component on each node receives the interception command issued by the administrator to only bypass the sidecar component, it will issue a shutdown interception command to its respective kernel-mode four-layer component, that is, set its respective kernel-mode four-layer component to the closed state, and at the same time set the kernel program indicated by the extension rule to the closed state, that is, not to skip the sidecar network protocol rule. At this time, all sidecar network protocol rules after the extension rule will take effect again.

[0221] (2) When the first application component (APP) in the first pod injected with the first sidecar component accesses the service, since the first kernel-mode four-layer component is in the closed state, the service access request generated by the first application component is intercepted by the first network protocol table component and processed according to the rules in the first network protocol table.

[0222] (3) At this time, the first network protocol table component will first execute the first rule in the egress exchange table, that is, the first extended rule. Among them, the first extended rule points to the first kernel program, and the execution logic of the first kernel program is to skip all sidecar network protocol rules. Since the first kernel program is in the closed state, after the first network protocol table component executes the first extended rule, it will continue to execute the subsequent first sidecar network protocol rules, and after executing the first sidecar network protocol rules, it will send the service access request to the first sidecar component, and the first sidecar component performs service governance on the service access request.

[0223] (4) After the first sidecar component completes traffic governance, it re-creates a connection and resends the service access request to the first network protocol table component.

[0224] (5) The first network protocol table component sends the service access request to the target node by skipping the first proxy component of the first node.

[0225] (6) Since the first kernel state four-layer component is closed, the traffic sent by the ordinary pod injected by the non-sidecar component on the first node will be forwarded by the first network protocol table component in the ordinary pod to the first proxy component, and the first proxy component forwards the traffic by executing the iptables rules of k8s.

[0226] (7) The first proxy component is responsible for forwarding the traffic in the pod injected by the non-sidecar component to the target node.

[0227] (8) The second kernel state four-layer component on the target node is also closed, and the ingress traffic will enter the pod injected with the sidecar component or enter the ordinary pod according to the address of the target pod.

[0228] When the ingress traffic enters the pod injected with the sidecar component, since the second extended rule is inserted in the ingress exchange table, the second extended rule points to the second kernel program, and the execution logic of the second kernel program is to skip all sidecar network protocol rules, and the second kernel program is in the closed state. Therefore, after the second network protocol table component executes the second extended rule, it continues to execute the second sidecar network protocol rules and sends the ingress service access request to the second sidecar component.

[0229] (9) After the second sidecar component processes the service access request, it forwards the processed service access request to the second network protocol table component.

[0230] (10) The second network protocol table component finally forwards the service access request to the second application component.

[0231] Based on Figure 12In the solution shown, the daemon component controls the current interception method as follows: only skip the traffic interception logic of the kernel-mode four-layer component itself, and at the same time restore the traffic interception logic of the sidecar component. Among them, the daemon component only needs to control the kernel-mode four-layer component to be in the closed state and the kernel program indicated by the extended rule to be in the closed state at the same time, so that all outgoing traffic originally intercepted by the kernel-mode four-layer component can be forwarded only after being intercepted by the sidecar component.

[0232] This can further compare the interception performance of the sidecar component and the kernel-mode four-layer component, or locate and delimit problems with the traffic. Figure 12 In the solution shown, it is also not necessary to dynamically modify the network protocol rules in the network protocol table. And, Figure 12 in the solution shown, it also supports deploying pods with sidecar components injected and pods without sidecar components injected on the same node.

[0233] In summary, compare Figure 3 and Figure 4 the solution of backing up and deleting the sidecar network protocol rules shown. Figures 8 to 12 In the solution shown, two extended rules are inserted when creating the pod, and these two extended rules will not be modified during the operation of the pod. During the operation of the pod, the interception mode is dynamically switched through the command interaction between the daemon component and the kernel-mode four-layer component and the kernel program. In this way, regardless of the scale of the original sidecar network protocol rules, Figures 8 to 12 the solution shown will not cause the time window problem caused by backing up and deleting the sidecar network protocol.

[0234] The following explains the related devices and equipment provided in the embodiments of the present application.

[0235] The embodiments of the present application also provide a service mesh system, as Figure 13 shown. The first node in the service mesh system 1300 includes a first pod, the first pod includes a first application component 1301, a first sidecar component 1302, and a first network protocol table component 1303. The first network protocol table component 1303 is configured with a first network protocol table, and the first network protocol table includes a first extended rule and a first sidecar network protocol rule corresponding to the first sidecar component.

[0236] Among them, the first network protocol table component 1303 is used to:

[0237] Receive a first service access request from the first application component, and the first service access request is used to access a target service; the specific implementation method can refer to Figure 6 step 601 in the embodiment.

[0238] Execute the first extension rule to obtain a first interception result, which is used to indicate whether to skip the first sidecar network protocol rule; the specific implementation method can refer to Figure 6 Step 602 in the embodiment.

[0239] In response to the first interception result indicating to skip the first sidecar network protocol rule, forward the first service access request to a second node among multiple nodes, and the second node is used to provide the target service. The specific implementation method can refer to Figure 6 Step 603 in the embodiment.

[0240] Optionally, the first network protocol table includes an egress exchange table, and the egress exchange table includes the first extension rule and the first sidecar network protocol rule.

[0241] Optionally, the first extension rule is the first rule in the egress exchange table.

[0242] Optionally, the first extension rule includes an identifier of a first kernel program, and the first kernel program is used to skip the first sidecar network protocol rule;

[0243] Wherein, when the first kernel program is in the on state, the first interception result indicates to skip the first sidecar network protocol rule, and when the first kernel program is in the off state, the first interception result indicates not to skip the first sidecar network protocol rule.

[0244] Optionally, the first node further includes a first daemon component 1304, and the first daemon component 1304 is used for:

[0245] In response to a first sidecar interception configuration instruction triggered by a user, set the first kernel program to be in the on state or the off state based on the first sidecar interception configuration instruction.

[0246] Optionally, the first node further includes a first daemon component 1304, and the first daemon component 1304 is used for:

[0247] In response to creating the first pod, add the first extension rule to the first network protocol table.

[0248] Optionally, the first network protocol table component 1303 is further used for:

[0249] In response to the first interception result indicating not to skip the first sidecar network protocol rule, after executing the first sidecar network protocol rule, forward the first service access request to the first sidecar component, and the first sidecar component processes the first service access request to obtain a second service access request; receive the second service access request from the first sidecar component; forward the second service access request to the second node.

[0250] Optionally, the first network protocol table component is configured to: forward the first service access request to the first proxy component; the first proxy component is configured to: process the first service access request to obtain a third service access request; and forward the third service access request to the second node.

[0251] Optionally, the first node further includes a first kernel-mode layer-4 component 1305, and the first kernel-mode layer-4 component is in a closed state.

[0252] Optionally, the first node further includes a first kernel-mode layer-4 component, and the first kernel-mode layer-4 component is in an open state;

[0253] The first kernel-mode layer-4 component 1305 is configured to: receive a fourth service access request from the first application component; process the fourth service access request to obtain a first service access request; and send the first service access request to the first network protocol table component.

[0254] Optionally, the first node further includes a first daemon component; the first daemon component is configured to: in response to a first layer-4 interception configuration instruction triggered by a user, set the first kernel-mode layer-4 component to be in an open state or a closed state based on the first layer-4 interception configuration instruction.

[0255] The embodiment of the present application further provides another service mesh system, as Figure 14 shown, the service mesh system includes multiple nodes, and a second node among the multiple nodes includes a second pod, the second pod includes a second application component 1401, a second sidecar component 1402, and a second network protocol table component 1403, the second network protocol table component 1403 is configured with a second network protocol table, and the second network protocol table includes a second extended rule and a second sidecar network protocol rule corresponding to the second sidecar component;

[0256] The second network protocol table component 1403 is configured to:

[0257] receive a service access request from a first node among the multiple nodes, the service access request is used to access a target service; the specific implementation manner may refer to Figure 7 step 701 in the embodiment.

[0258] execute the second extended rule to obtain a second interception result, the second interception result is used to indicate whether to skip the second sidecar network protocol rule; the specific implementation manner may refer to Figure 7 step 702 in the embodiment.

[0259] in response to the second interception result indicating to skip the second sidecar network protocol rule, forward the service access request to the second application component, and the second application component is used to provide the target service. The specific implementation manner may refer to Figure 7 step 703 in the embodiment.

[0260] Optionally, the second network protocol table includes an ingress switching table, and the ingress switching table includes a second extension rule and a second sidecar network protocol rule.

[0261] Optionally, the second extension rule is the first rule in the ingress switching table.

[0262] Optionally, the second extension rule includes an identifier of a second kernel program, and the second kernel program is used to skip the second sidecar network protocol rule;

[0263] Wherein, when the second kernel program is in the on state, the second interception result indicates skipping the second sidecar network protocol rule, and when the second kernel program is in the off state, the second interception result indicates not skipping the second sidecar network protocol rule.

[0264] Optionally, the second node further includes a second daemon component 1404;

[0265] The second daemon component 1404 is configured to: in response to a second sidecar interception configuration instruction triggered by a user, set the second kernel program to be in the on state or the off state based on the second sidecar interception configuration instruction.

[0266] Optionally, the second daemon component 1404 is further configured to: in response to the creation of a second pod, add a second extension rule to the second network protocol table.

[0267] Optionally, the second network protocol table component is further configured to: in response to the second interception result indicating not skipping the second sidecar network protocol rule, after executing the second sidecar network protocol rule, forward the service access request to the second sidecar component, and the second sidecar component processes the service access request; receive the service access request processed by the second sidecar component, and forward the received service access request to the second application component.

[0268] Optionally, the second node further includes a second kernel-mode four-layer component 1405, and the second kernel-mode four-layer component is in the off state.

[0269] Optionally, the second node further includes a second kernel-mode four-layer component 1405, and the second kernel-mode four-layer component is in the on state;

[0270] The second kernel-mode four-layer component is configured to: receive a service access request; and send the service access request to the second network protocol table component based on the destination address of the service access request.

[0271] Optionally, the second node further includes a second daemon component; the second daemon component is configured to: in response to a second four-layer interception configuration instruction triggered by a user, set the second kernel-mode four-layer component to be in the on state or the off state based on the second four-layer interception configuration instruction.

[0272] Among them, the first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305, as well as the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405 can all be implemented by software or by hardware. Exemplarily, next, taking the first application component 1301 as an example, the implementation manner of the first application component 1301 will be introduced. Similarly, the implementation manners of the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305, as well as the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405 can refer to the implementation manner of the first application component 1301.

[0273] As an example of a software functional unit, the first application component 1301 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above computing instance may be one or more. For example, the first application component 1301 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Among them, generally, one region may include multiple AZs.

[0274] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Among them, generally, one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is achieved through the communication gateway.

[0275] As an example of a hardware functional unit, the first application component 1301 may include at least one computing device, such as a server. Alternatively, the first application component 1301 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above PLD may be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0276] The multiple computing devices included in the first application component 1301 may be distributed in the same region or in different regions. The multiple computing devices included in the first application component 1301 may be distributed in the same availability zone (AZ) or in different AZs. Similarly, the multiple computing devices included in the first application component 1301 may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Among them, the multiple computing devices may be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0277] It should be noted that in other embodiments, the first application component 1301 may be used to execute any step in the method provided in the embodiments of the present application, and any other component may also be used to execute any step in the method provided in the embodiments of the present application. The steps to be implemented by the first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305, as well as the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405 can be specified as needed. The first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305, as well as the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405 respectively implement different steps in the method provided in the embodiments of the present application to implement all functions of the service mesh system.

[0278] The embodiments of the present application also provide a computing device 1500. As Figure 15As shown, the computing device 1500 includes: a bus 1502, a processor 1504, a memory 1506, and a communication interface 1508. The processor 1504, the memory 1506, and the communication interface 1508 communicate with each other via the bus 1502. The computing device 1500 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1500.

[0279] The bus 1502 can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 15 only one line is shown in the figure, but it does not mean that there is only one bus or one type of bus. The bus 1504 can include a path for transmitting information between various components of the computing device 1500 (for example, the memory 1506, the processor 1504, and the communication interface 1508).

[0280] The processor 1504 can include any one or more of processors such as a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Micro Processor (MP), or a Digital Signal Processor (DSP).

[0281] The memory 1506 can include volatile memory, such as Random Access Memory (RAM). The processor 1504 can also include non-volatile memory, such as Read-Only Memory (ROM), flash memory, a Hard Disk Drive (HDD), or a Solid State Drive (SSD).

[0282] The memory 1506 stores executable program codes, and the processor 1504 executes the executable program codes to implement the functions of the foregoing first application component 1301, first sidecar component 1302, first network protocol table component 1303, first daemon component 1304, and first kernel-mode four-layer component 1305, as well as the second application component 1401, second sidecar component 1402, second network protocol table component 1403, second daemon component 1404, and second kernel-mode four-layer component 1405, so as to implement the method provided by the embodiment of the present application. That is, the memory 1506 stores instructions for executing the method provided by the embodiment of the present application.

[0283] Alternatively, the memory 1506 stores executable codes, and the processor 1504 executes the executable codes to implement the functions of the foregoing service mesh system, so as to implement the method provided by the embodiment of the present application. That is, the memory 1506 stores instructions for executing the method provided by the embodiment of the present application.

[0284] The communication interface 1503 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1500 and other devices or a communication network.

[0285] The embodiment of the present application further provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0286] As Figure 16 shown, the computing device cluster includes at least one computing device 1500. The memory 1506 in one or more of the computing devices 1500 in the computing device cluster may store the same instructions for executing the method provided by the embodiment of the present application.

[0287] In some possible implementation manners, the memory 1506 of one or more of the computing devices 1500 in the computing device cluster may also store partial instructions for executing the method provided by the embodiment of the present application respectively. In other words, a combination of one or more computing devices 1500 may jointly execute the instructions for executing the method provided by the embodiment of the present application.

[0288] It should be noted that the memories 1506 in different computing devices 1500 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the service mesh system. That is to say, the instructions stored in the memories 1506 in different computing devices 1500 can implement one or more of the functions of the first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305, as well as the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405.

[0289] In some possible implementation manners, one or more computing devices in the computing device cluster can be connected through a network. Among them, the network can be a wide area network or a local area network, etc. Figure 17 A possible implementation manner is shown. As Figure 17 shown, two computing devices 1500A and 1500B are connected through a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation manner, the memory 1506 in the computing device 1500A stores instructions for executing the functions of the first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305. At the same time, the memory 1506 in the computing device 1500B stores instructions for executing the functions of the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405.

[0290] Figure 17 The connection manner between the computing device clusters shown can be considered because the method provided in this application requires access between different services. Therefore, it is considered that the functions implemented by the first application component 1301, the first sidecar component 1302, the first network protocol table component 1303, the first daemon component 1304, and the first kernel-mode four-layer component 1305 are executed by the computing device 1500A, and the functions implemented by the second application component 1401, the second sidecar component 1402, the second network protocol table component 1403, the second daemon component 1404, and the second kernel-mode four-layer component 1405 are executed by the computing device 1500B.

[0291] It should be understood that Figure 17 the functions of the computing device 1500A shown in

[0292] The embodiments of the present application also provide a computer program product containing instructions. The computer program product can be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, at least one computing device is caused to execute the traffic forwarding method provided by the embodiments of the present application.

[0293] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions that direct the computing device to execute the traffic forwarding method provided by the embodiments of the present application.

[0294] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or perform equivalent replacements for some of the technical features. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A traffic forwarding method based on a service mesh system, characterized in that, the service mesh system includes multiple nodes, a first node among the multiple nodes includes a first pod, the first pod includes a first application component, a first sidecar component and a first network protocol table component, the first network protocol table component is configured with a first network protocol table, the first network protocol table includes a first extension rule and a first sidecar network protocol rule corresponding to the first sidecar component; the method includes: the first network protocol table component receives a first service access request from the first application component, the first service access request is used to access a target service; the first network protocol table component executes the first extension rule to obtain a first interception result, the first interception result is used to indicate whether to skip the first sidecar network protocol rule; in response to the first interception result indicating to skip the first sidecar network protocol rule, the first network protocol table component forwards the first service access request to a second node among the multiple nodes, and the second node is used to provide the target service.

2. The method according to claim 1, characterized in that, the first network protocol table includes an egress exchange table, and the egress exchange table includes the first extension rule and the first sidecar network protocol rule.

3. The method according to claim 2, characterized in that, the first extension rule is the first rule in the egress exchange table.

4. The method according to any one of claims 1-3, characterized in that, the first extension rule includes an identifier of a first kernel program, and the first kernel program is used to skip the first sidecar network protocol rule; wherein, when the first kernel program is in an enabled state, the first interception result indicates to skip the first sidecar network protocol rule, and when the first kernel program is in a disabled state, the first interception result indicates not to skip the first sidecar network protocol rule.

5. The method according to claim 4, characterized in that, the first node further includes a first daemon component; the method further includes: in response to a first sidecar interception configuration instruction triggered by a user, the first daemon component sets the first kernel program to be in an enabled state or a disabled state based on the first sidecar interception configuration instruction.

6. The method according to claim 4 or 5, characterized in that, the method further includes: in response to creating the first pod, the first daemon component adds the first extension rule to the first network protocol table.

7. The method according to any one of claims 1-6, characterized in that, after the first network protocol table component executes the first extension rule to obtain a first interception result, the method further includes: in response to the first interception result indicating not to skip the first sidecar network protocol rule, after the first network protocol table component executes the first sidecar network protocol rule, it forwards the first service access request to the first sidecar component, and the first sidecar component processes the first service access request to obtain a second service access request; The first network protocol table component receives the second service access request from the first sidecar component; The first network protocol table component forwards the second service access request to the second node.

8. The method according to any one of claims 1-6, wherein, The first node further includes a first proxy component; The first network protocol table component forwards the first service access request to a second node among the multiple nodes, including: The first network protocol table component forwards the first service access request to the first proxy component; The first proxy component processes the first service access request to obtain a third service access request; The first proxy component forwards the third service access request to the second node.

9. The method according to claim 7 or 8, wherein, The first node further includes a first kernel-mode four-layer component, and the first kernel-mode four-layer component is in a closed state.

10. The method according to any one of claims 1-6, wherein, The first node further includes a first kernel-mode four-layer component, and the first kernel-mode four-layer component is in an open state; The first network protocol table component receives the first service access request from the first application component, including: The first kernel-mode four-layer component receives a fourth service access request from the first application component; The first kernel-mode four-layer component processes the fourth service access request to obtain the first service access request; The first kernel-mode four-layer component sends the first service access request to the first network protocol table component.

11. The method according to claim 9 or 10, wherein, The first node further includes a first daemon component; The method further includes: In response to a first four-layer interception configuration instruction triggered by a user, the first daemon component sets the first kernel-mode four-layer component to be in an open state or a closed state based on the first four-layer interception configuration instruction.

12. A traffic forwarding method based on a service mesh system, wherein, The service mesh system includes multiple nodes, a second node among the multiple nodes includes a second pod, the second pod includes a second application component, a second sidecar component, and a second network protocol table component, the second network protocol table component is configured with a second network protocol table, and the second network protocol table includes a second extended rule and a second sidecar network protocol rule corresponding to the second sidecar component; the method includes: The second network protocol table component receives a service access request from a first node among the multiple nodes, and the service access request is used to access a target service; The second network protocol table component executes the second extended rule to obtain a second interception result, and the second interception result is used to indicate whether to skip the second sidecar network protocol rule; In response to the second interception result indicating to skip the second sidecar network protocol rule, the second network protocol table component forwards the service access request to the second application component, and the second application component is used to provide the target service.

13. The method according to claim 12, wherein, The second network protocol table includes an ingress switching table, and the ingress switching table includes the second extended rule and the second sidecar network protocol rule.

14. The method according to claim 13, wherein, the second extended rule is the first rule in the ingress switching table.

15. The method according to any one of claims 12 - 14, wherein, the second extended rule includes an identifier of a second kernel program, and the second kernel program is used to skip the second sidecar network protocol rule; wherein, when the second kernel program is in an enabled state, the second interception result indicates skipping the second sidecar network protocol rule, and when the second kernel program is in a disabled state, the second interception result indicates not skipping the second sidecar network protocol rule.

16. The method according to claim 15, wherein, the second node further includes a second daemon component; the method further includes: In response to a second sidecar interception configuration instruction triggered by a user, the second daemon component sets the second kernel program to be in an enabled state or a disabled state based on the second sidecar interception configuration instruction.

17. The method according to claim 15 or 16, wherein, the method further includes: In response to creating the second pod, the second daemon component adds the second extended rule to the second network protocol table.

18. The method according to any one of claims 12 - 17, wherein, after the second network protocol table component executes the second extended rule to obtain a second interception result, the method further includes: In response to the second interception result indicating not skipping the second sidecar network protocol rule, after the second network protocol table component executes the second sidecar network protocol rule, it forwards the service access request to the second sidecar component, and the second sidecar component processes the service access request; The second network protocol table component receives the service access request processed by the second sidecar component and forwards the received service access request to the second application component.

19. The method according to any one of claims 12 - 18, wherein, the second node further includes a second kernel mode four - layer component, and the second kernel mode four - layer component is in a disabled state.

20. The method according to any one of claims 12 - 18, wherein, the second node further includes a second kernel mode four - layer component, and the second kernel mode four - layer component is in an enabled state; The second network protocol table component receives a service access request from a first node among the multiple nodes, including: The second kernel mode four - layer component receives the service access request; The second kernel mode four - layer component sends the service access request to the second network protocol table component based on the destination address of the service access request.

21. The method according to claim 19 or 20, wherein, the second node further includes a second daemon component; the method further includes: In response to a second four-layer interception configuration instruction triggered by a user, the second daemon component sets the second kernel-mode four-layer component to an on state or an off state based on the second four-layer interception configuration instruction.

22. A service mesh system, characterized in that the service mesh system includes a plurality of nodes, and a first node among the plurality of nodes includes a first pod, the first pod includes a first application component, a first sidecar component, and a first network protocol table component, the first network protocol table component is configured with a first network protocol table, and the first network protocol table includes a first extended rule and a first sidecar network protocol rule corresponding to the first sidecar component; the first network protocol table component is used for: receiving a first service access request from the first application component, the first service access request being used to access a target service; executing the first extended rule to obtain a first interception result, the first interception result being used to indicate whether to skip the first sidecar network protocol rule; in response to the first interception result indicating to skip the first sidecar network protocol rule, forwarding the first service access request to a second node among the plurality of nodes, and the second node is used to provide the target service.

23. A service mesh system, characterized in that the service mesh system includes a plurality of nodes, and a second node among the plurality of nodes includes a second pod, the second pod includes a second application component, a second sidecar component, and a second network protocol table component, the second network protocol table component is configured with a second network protocol table, and the second network protocol table includes a second extended rule and a second sidecar network protocol rule corresponding to the second sidecar component; the second network protocol table component is used for: receiving a service access request from a first node among the plurality of nodes, the service access request being used to access a target service; executing the second extended rule to obtain a second interception result, the second interception result being used to indicate whether to skip the second sidecar network protocol rule; in response to the second interception result indicating to skip the second sidecar network protocol rule, forwarding the service access request to the second application component, and the second application component is used to provide the target service.

24. A computing device cluster, characterized in that it includes at least one computing device, and each computing device includes a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1-11, or executes the method according to any one of claims 12-21.

25. A computer program product containing instructions, characterized in that when the instructions are run by a computing device cluster, the computing device cluster is caused to execute the method according to any one of claims 1-11, or execute the method according to any one of claims 12-21.

26. A computer-readable storage medium, characterized in that Comprising computer program instructions which, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method according to any one of claims 1-11, or to perform the method according to any one of claims 12-21.

Images