Method, device and equipment for flow control based on network policy, and medium

Abstract

The invention relates to the technical field of cloud monitoring, can be applied to the technical field of medical network environment construction, and discloses a method, a device, equipment and a medium for flow control based on a network policy, and the method comprises the following steps: in an operation environment without using a container arrangement platform, allocating labels for network resources in advance; converting a network strategy based on category-free inter-domain routing in a cloud native network into a network strategy based on a label according to the label corresponding to the network resource; and deploying the label-based network strategy to a production environment so as to control the flow of network resources in the production environment through the label-based network strategy. Through the logic abstraction capability of the label, the complexity of the network strategy can be reduced, the issuing number of the network strategy is greatly reduced, and the effective time of the network strategy is prolonged.

Description

Technical Field

[0001] The present invention relates to the field of cloud monitoring technology, which can be applied to the field of medical network monitoring technology, and in particular to a method, device, equipment and medium for flow control based on network strategy. Background Art

[0002] The rapid development of cloud-native applications has brought new demands for network connectivity and access. Cloud-native networks based on eBPF technology provide highly flexible, scalable, and secure solutions to meet the network and security requirements of cloud-native applications.

[0003] In hybrid clouds or complex network environments that do not rely on container clusters, related technologies usually use classless inter-domain routing to generate network policies for traffic control to explicitly allow or restrict network communications across environments. However, when multiple network policies based on classless inter-domain routing are applied in a cloud-native network, the magnitude of network policies will expand rapidly, and it is necessary to quickly respond to changes in network topology or deal with emergencies, which will increase the number of network policies issued concurrently, triggering multiple updates to the same memory area, resulting in spin lock requisition, making the policy effective for a longer time, and affecting the traffic control effect of the network policy. Summary of the invention

[0004] The present invention provides a method, device, computer equipment and medium for flow control based on network policy, so as to solve the technical problem in the related technology that an increase in the number of network policies issued concurrently leads to the requisition of spin locks, prolongs the policy effectiveness time and affects the flow control effect of the network policy.

[0005] In a first aspect, a method for performing traffic control based on a network policy is provided, comprising:

[0006] In an operating environment that does not use a container orchestration platform, pre-assign labels to network resources;

[0007] Converting a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to the label corresponding to the network resource;

[0008] The tag-based network policy is deployed in a production environment to control the traffic of network resources in the production environment through the tag-based network policy.

[0009] In a second aspect, a device for performing flow control based on a network policy is provided, comprising:

[0010] An allocation module for pre-allocating labels for network resources in an operating environment that does not use a container orchestration platform;

[0011] A conversion module, configured to convert a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to a label corresponding to the network resource;

[0012] A control module is used to deploy the label-based network policy into a production environment so as to control the flow of network resources in the production environment through the label-based network policy.

[0013] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned method for performing traffic control based on network policies when executing the computer program.

[0014] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned method for performing traffic control based on network policy are implemented.

[0015] In the scheme implemented by the above-mentioned method, device, computer equipment and storage medium for flow control based on network policy, labels can be pre-assigned to network resources through the client in an operating environment that does not use a container orchestration platform; the network policy based on classless inter-domain routing in the cloud native network is converted into a label-based network policy according to the label corresponding to the network resource; the label-based network policy is deployed to the production environment, so that the server controls the flow of network resources in the production environment through the label-based network policy. In the present invention, by converting the network policy based on classless inter-domain routing in the cloud native network into a label-based network policy, network resources can be managed in a refined manner and fine-grained flow control of network resources can be achieved. In an operating environment that does not use a container orchestration platform, it is often necessary to frequently adjust the network policy. Through the logical abstraction capability of the label, the complexity of the network policy can be reduced, the number of network policies issued can be greatly reduced, and the effective time of the network policy can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0017] Figure 1 is a schematic diagram of an application environment of a method for performing flow control based on network policy in one embodiment of the present invention;

[0018] Figure 2 is a flow chart of a method for performing flow control based on network policy in one embodiment of the present invention;

[0019] Figure 3 yes Figure 1 A schematic flow chart of a specific implementation of step S10;

[0020] Figure 4 yes Figure 1 A schematic flow chart of a specific implementation of step S20;

[0021] Figure 5 is a flow chart of a method for performing flow control based on network policy in another embodiment of the present invention;

[0022] Figure 6 is a structural schematic diagram of a device for performing flow control based on a network policy in one embodiment of the present invention;

[0023] Figure 7 is a schematic diagram of a structure of a computer device in one embodiment of the present invention;

[0024] Figure 8 It is another structural schematic diagram of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] The method for flow control based on network policy provided by the embodiment of the present invention can be applied in the following aspects: Figure 1In the application environment, in which, in the operating environment where the container orchestration platform is not used, labels are pre-assigned to network resources; the network policy based on classless inter-domain routing in the cloud native network is converted into a label-based network policy according to the label corresponding to the network resource; the label-based network policy is deployed to the production environment, so that the server controls the traffic of network resources in the production environment through the label-based network policy. In the present invention, by converting the network policy based on classless inter-domain routing in the cloud native network into a label-based network policy, the network resources can be finely managed to achieve fine-grained traffic control of network resources. In the operating environment where the container orchestration platform is not used, the network policy often needs to be adjusted frequently. Through the logical abstraction capability of the label, the complexity of the network policy can be reduced, the number of network policies issued can be greatly reduced, and the effective time of the network policy can be increased. Among them, the client can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0027] See also Figure 2 As shown, Figure 2 A flow chart of a method for performing flow control based on network policy provided in an embodiment of the present invention includes the following steps:

[0028] S10: In an operating environment that does not use a container orchestration platform, pre-assign labels to network resources.

[0029] The method for flow control based on network policy provided by the present invention can be applied to scenarios of microservice architecture isolation, including process isolation, thread isolation, cluster isolation, etc. Specifically, the legal access path between microservices can be clarified through network policy. For example, only the order service is allowed to communicate with the payment service, and direct calls of other services are blocked. Then metadata tags are added to each service, such as service name, environment type, version number, etc., to form a digital identity. The network policy can accurately identify the traffic subject based on these tags, further limit the source of the service receiving traffic and constrain the connection actively initiated by the service. When the service instance is expanded or reduced or the version is upgraded, the network policy is automatically updated synchronously. The whole process forms a special isolation structure between microservices through refined traffic control, which controls security risks to the smallest unit while ensuring business connectivity.

[0030] In this embodiment, the operating environment that does not use the container orchestration platform is a computing environment that uses the container orchestration platform as a container orchestration and management environment. This type of environment may include container technology or may not use containers at all. The core is that functions such as resource scheduling, service discovery, and network policies do not rely on the architecture and components of the container orchestration platform. Correspondingly, in the operating environment that does not use the container orchestration platform, network resources can be physical / virtual network devices that build the network architecture, such as switches and routers, host network configurations, such as bridges and routing tables, and network security resources, such as firewalls and security groups.

[0031] Among them, a tag is a key-value pair attached to a network resource, which is used to represent resource attributes, classifications, or association policies. Here, network resources may include but are not limited to services, containers, or network interfaces. As an implementation method, the tag field of the network resource can be directly defined in the template in a predefined manner to ensure that the preset tag is automatically attached when the resource is created, and then the tag value is dynamically generated through the template variable to assign tags to the network resource. As another implementation method, a tool can be used to reserve a tag placeholder in the configuration file, and the tag configuration file is generated by rendering the tag variables (such as environment type, service level) passed in during deployment to achieve flexible configuration of tags. Here, tags can be divided into global tags and resource-level tags. In order to ensure cross-platform compatibility, a set format can be used to store tag metadata to standardize the tag configuration file. The tag configuration file is then synchronized to the cloud platform through a script so that the cloud platform assigns tags to network resources according to the tag configuration file.

[0032] It should be noted that, considering the feasibility of using labels for network resources, labels can be automatically generated according to set rules when services are deployed or expanded to ensure that the allocation of labels is synchronized with the life cycle (creation, update, and destruction) of network resources in real time to avoid management failures due to delays.

[0033] In a specific implementation scenario, in an operating environment that does not use a container orchestration platform, the network resource types that need to be assigned labels are determined, and for different network resource types, metadata is automatically attached as labels when the network resources are started. Specifically, Figure 3 As shown, in step S10, that is, in an operating environment where a container orchestration platform is not used, labels are pre-allocated to network resources, including the following steps:

[0034] S11: Use a template engine to define the tag metadata as a tag variable and write it into a service configuration file, so that when the service is deployed, the tag configuration file is generated by the tag variable.

[0035] S12: In an operating environment that does not use a container orchestration platform, synchronize the tag configuration file to the cloud platform through a script, so that the cloud platform assigns tags to network resources according to the tag configuration file.

[0036] For step S11, the tag metadata is the metadata content that needs to be defined as a tag, such as the application name, environment type, version number, etc. These tag metadata usually exist in the form of key-value pairs. Specifically in the template file, placeholders are reserved for the tag metadata that needs to be written dynamically. These placeholders will be replaced by the actual tag variable values ​​later. The tag metadata is associated with the variables in the template engine so that the template engine knows the data that needs to replace the placeholders. Usually in the configuration or related files of the template engine, there is usually a special area to define these variables. Further in the application or build script, the rendering method of the template engine is called, and the tag variables and template files are passed in as parameters. The template engine will replace the placeholders in the template file with actual content according to the value of the tag variable to generate the final service configuration file.

[0037] For step S12, the script is configured with access credentials of the cloud platform, such as access keys, tokens, etc., which can usually be passed through environment variables and configuration files to ensure that the script has sufficient permissions to access the cloud platform. By reading the tag configuration file, the identification of the network resources and the corresponding tag information can be accurately extracted from the file, and then according to the resource identification rules of the cloud platform, the resource identification in the tag configuration file is matched with the actual network resources of the cloud platform to ensure that the target network resources that need to be assigned tags can be accurately found. The tag assignment function of the cloud platform is called by the script, and the extracted tag information is passed to the cloud platform to instruct the assignment of tags to the corresponding network resources.

[0038] S20: Converting a network policy based on classless inter-domain routing in the cloud native network into a network policy based on a label according to the label corresponding to the network resource.

[0039] In this embodiment, classless inter-domain routing is a method used to represent an IP address and its routing prefix, which combines the IP address and the subnet mask. For example, 192.168.1.0 / 24, where / 24 indicates that the first 24 bits in the subnet mask are network bits and the last 8 bits are host bits. This representation method can more flexibly divide the network address space and achieve efficient management of networks of different sizes. The network policy based on classless inter-domain routing is to define network access rules based on the IP address range represented by the classless inter-domain routing. By specifying conditions such as the source IP address range, the destination IP address range, and the type of network traffic allowed or denied, the network communication between different workloads, containers or services in the cloud native environment is controlled.

[0040] Usually, in the control plane of the cloud native network, the network policy controller centrally configures the network policy based on classless inter-domain routing. Specifically, the network policy in the entire cloud native network can be defined, modified, and deployed in a unified interface or configuration file to ensure the consistency and manageability of the policy.

[0041] However, considering that in the process of interaction between different environments, a large number of network policies based on classless inter-domain routing need to be defined for various network entities in different environments to ensure the security and correctness of network communication. As the number of network resources in different environments increases, more network policies need to be formulated, resulting in exponential expansion of network policies. This embodiment can convert the classless inter-domain routing based on cloud native networks into label-based network policies. The label-based network policies can label network resources according to various attributes, such as application name, functional role, environment type, etc., thereby achieving more fine-grained access control than classless inter-domain routing. It can accurately allow a microservice to communicate only with other microservices with specific labels, rather than just controlling based on IP address ranges. In other words, the policy based on classless inter-domain routing needs to continuously adjust the classless inter-domain routing range to adapt to these changes, while the label-based policy only needs to assign corresponding labels to resources. No matter how the IP address of the resource changes, the network policy can be automatically applied according to the label, which greatly improves the dynamic adaptability of the policy.

[0042] Specifically, in an operating environment that does not use a container orchestration platform, a network policy based on classless inter-domain routing can determine the IP range allowed for traffic control, for example, a network policy that allows traffic from 10.0.0.0 / 8. When converting to a label-based network policy, the allowed IP range needs to be mapped to a network resource with a specific label, where the label is metadata used to identify the network resource, such as the environment, application, etc. In an actual application scenario, if all servers in the IP range allowed based on classless inter-domain routing are labeled "internal network", the corresponding network policy is set to allow traffic with the "internal network" label.

[0043] It is understandable that by establishing a mapping relationship, the classless inter-domain routing segment can be mapped to a specific label, so that when formulating network policies, it can be based on labels instead of specific IP addresses, which improves flexibility and maintainability. Specifically, Figure 4 As shown, in step S20, that is, converting the network policy based on classless inter-domain routing in the cloud native network into a label-based network policy according to the label corresponding to the network resource, includes the following steps:

[0044] S21: By analyzing the network policy based on classless inter-domain routing in the cloud native network, resource service information corresponding to the classless inter-domain routing segment is obtained.

[0045] S22: Establishing a mapping relationship between the classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment.

[0046] S23: Convert a network policy based on classless inter-domain routing in the cloud native network into a network policy based on a label by using a mapping relationship between the classless inter-domain routing segment and at least one label.

[0047] Specifically, in the process of implementing step S21, the network policy based on classless inter-domain routing in the cloud native network can be parsed to extract the classless inter-domain routing segment of the network policy; according to the classless inter-domain routing segment of the network policy, the network resources corresponding to the classless inter-domain routing segment are queried; the network resources corresponding to the classless inter-domain routing segment are associated with the business service to obtain the resource service information corresponding to the classless inter-domain routing segment.

[0048] In this embodiment, the network policy based on classless inter-domain routing in the cloud native network can be obtained through the configuration file of the network device. It can be understood that in the configuration information of the network policy, the source IP address range and the target IP address range can be specified, and this information can appear in the form of a classless inter-domain routing segment. Accordingly, in the process of extracting the classless inter-domain routing segment of the network policy, the source IP address range can be determined by searching the configuration file for keywords related to the source IP. For example, in the firewall configuration file, there will be a network policy similar to "access-list 101permit ip 192.168.1.0 / 24any", where "192.168.1.0 / 24" is the source IP address range, identifying the network address as 192.168.1.0, the subnet mask as 255.255.255.0, and the actual IP address range from 192.168.1.0 to 192.168.1.255. Similarly, the target IP address range is determined by searching the configuration file for keywords related to the target IP.

[0049] It should be noted that after locating the keyword, since the classless inter-domain routing is usually expressed in a set format, the classless inter-domain routing segment of the network policy can be accurately extracted from the configuration file according to the set format, considering that the network policy may define multiple source / destination IP address ranges in a list form. If there are multiple classless inter-domain routing segments, they need to be extracted and recorded one by one.

[0050] Furthermore, the extracted classless inter-domain routing segment needs to be format-validated to ensure that it complies with the set format specification. For example, the IP address part must be a legal IP address and the mask length must be within a reasonable range.

[0051] Specifically, in the process of implementing step S22, the resource attribute label of the classless inter-domain routing segment can be determined according to the resource service information corresponding to the classless inter-domain routing segment; based on the resource attribute label of the classless inter-domain routing segment, a mapping relationship between the classless inter-domain routing segment and at least one label is established, and the mapping relationship here supports bidirectional query.

[0052] In this embodiment, the resource service information corresponding to the classless inter-domain routing segment can be used to determine the function, application or business service provided by the resource service corresponding to the classless inter-domain routing, for example, whether the resource service is used for a user authentication system or a data storage service. Further, the resource attribute label is determined according to the resource service information corresponding to the classless inter-domain routing segment. Here, the resource attribute label can be determined according to the business function of the resource service. For example, if a resource service is an order management system, a label such as "order processing" can be assigned to indicate its role in the business process. The label can also be set according to the technology stack or technical features used by the resource service. If the resource service is based on a microservice architecture, a label such as "microservice" can be added. The label can also be determined according to the environment or region where the resource service is located. For example, if the resource service is deployed in the East China Data Center in the production environment, labels such as "production environment" and "East China region" can be set. Finally, the classless inter-domain routing segment is associated with the corresponding resource attribute label. For example, for a user authentication resource service corresponding to a classless inter-domain routing segment, a mapping relationship is established with the "user authentication" label according to the function label strategy.

[0053] It is understandable that after the mapping relationship is established, in order to ensure that the correspondence between the classless inter-domain routing segment and the label is accurate, the mapping relationship needs to be verified. Specifically, it can be verified by checking whether the actual network traffic of the resource service is consistent with the set label and the expected situation of the classless inter-domain routing segment, or by querying the configuration information of the relevant tools or platforms.

[0054] In actual application scenarios, based on the established mapping relationship between the classless inter-domain routing segment and at least one label, the classless inter-domain routing segment in the network policy can be replaced with the corresponding label. For example, if a classless inter-domain routing segment "192.168.1.0 / 24" is mapped to the label "backend service", in the network policy, all rules whose source or destination is the classless inter-domain routing segment are replaced with the source or destination being the "backend service" label.

[0055] It should be noted that for complex rules that contain multiple classless inter-domain routing segments, each classless inter-domain routing segment can be replaced with a corresponding label according to the mapping relationship and adjusted according to the logical relationship. For example, if the policy allows traffic from "192.168.1.0 / 24" or "192.168.2.0 / 24" to access a service, and these two classless inter-domain routing segments are mapped to the "Service A" and "Service B" labels respectively, then the converted network policy should allow traffic from the "Service A" or "Service B" labels to access the service.

[0056] In actual application scenarios, classless inter-domain routing segments use variable-length subnet masks to allocate IP addresses more flexibly, allowing multiple consecutive address blocks to be aggregated into a larger supernet or subdivided into smaller subnets. In this case, the classless inter-domain routing segment will have multiple segment inclusion relationships. For example, a larger classless inter-domain routing segment contains multiple smaller subnets. Processing label mapping relationships may be more complicated because hierarchical relationships need to be processed.

[0057] Correspondingly, after establishing a mapping relationship between a classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment, when a multi-segment inclusion relationship exists in the classless inter-domain routing segment, the label of the classless inter-domain routing segment is adjusted according to the hierarchical relationship of the classless inter-domain routing segment to adjust the mapping relationship accordingly. Here, the multi-segment inclusion relationship is that the IP address range of a classless inter-domain routing segment covers the IP address range of at least one smaller classless inter-domain routing segment.

[0058] Specifically, all involved classless inter-domain routing segments can be sorted out, and by comparing the network addresses and masks of the classless inter-domain routing segments, it can be determined which classless inter-domain routing segments are included in other classless inter-domain routing segments. For example, a classless inter-domain routing segment 192.168.1.0 / 24 contains two child classless inter-domain routing segments 192.168.1.0 / 25 and 192.168.1.128 / 25. Then, according to the hierarchical relationship of the classless inter-domain routing segments, the classless inter-domain routing segments are constructed into a hierarchical tree structure, where the classless inter-domain routing segments at the upper level are the parent with a wider range, and the included classless inter-domain routing segments are the children. Further check the label status currently assigned to each classless inter-domain routing segment to determine whether there are labels that do not match the hierarchical relationship, or whether there are labels that need to be adjusted according to the new hierarchical relationship. For the parent classless inter-domain routing segment at the upper level of the hierarchy, a more general and broader label is usually assigned to represent the entire range it contains. The label of the child classless inter-domain routing segment needs to be refined based on the parent label to reflect its difference from other child classless inter-domain routing segments of the same level. Finally, according to the adjusted label of the classless inter-domain routing segment, the mapping relationship related to these classless inter-domain routing segments in the network policy is updated.

[0059] In actual application scenarios, as the network scale continues to expand, the original network needs to be expanded and new subnets or network segments need to be added. During the expansion process, if the allocation of classless inter-domain routing in the existing network is not carefully considered, the allocated classless inter-domain routing segment may partially overlap with the original classless inter-domain routing segment. At this time, the classless inter-domain routing segment will have multiple overlapping segments. For example, the enterprise initially used the 192.168.1.0 / 24 network segment, and later, as the business grew, the 192.168.1.128 / 25 network segment was allocated when the network was expanded, which overlapped with the original network segment.

[0060] Correspondingly, after establishing a mapping relationship between a classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment, when there are multiple overlapping relationships between the classless inter-domain routing segments, the label of the classless inter-domain routing segment is adjusted according to the usage priority of the classless inter-domain routing segment to adjust the mapping relationship accordingly. Here, the multiple overlapping relationships refer to the overlap between the IP address range of one classless inter-domain routing segment and the IP address range of another classless inter-domain routing segment.

[0061] Specifically, all involved classless inter-domain routing segments can be sorted out, and the overlapping classless inter-domain routing segments can be found by comparing the network addresses and subnet masks of the classless inter-domain routing segments. For example, 192.168.1.0 / 24 and 192.168.1.128 / 25 have overlapping parts. Then, according to the actual needs and business logic of the network, the use priority of each classless inter-domain routing segment is determined, which can be based on various factors, such as the importance of the business, the characteristics of network traffic, and security requirements. For example, the classless inter-domain routing segment used for the core business system may have a higher priority, while the classless inter-domain routing segment used for testing or temporary functions has a lower priority. Further check the label assigned to each current classless inter-domain routing segment to determine the naming rules and meaning of the label and the corresponding relationship between the label and the classless inter-domain routing segment. For the classless inter-domain routing segment with a higher use priority, assign a label that can highlight its importance and uniqueness. This label should be able to clearly reflect the key role or special purpose of the classless inter-domain routing segment in the network, for example, "core business-production network". For classless inter-domain routing segments with lower priorities that overlap with high-priority classless inter-domain routing segments, their labels need to be adjusted to indicate their subordinate or secondary status. Some modifiers can be added to the original labels to reflect their relationship with the high-priority classless inter-domain routing segments and their own characteristics, such as "auxiliary-test network". If label conflicts or ambiguities are found during the label adjustment process, different classless inter-domain routing segments can be distinguished by adding more descriptive information or specific identifiers to ensure that each label can uniquely identify a classless inter-domain routing segment and its priority. Finally, according to the adjusted labels of the classless inter-domain routing segments, the mapping relationships related to these classless inter-domain routing segments in the network policy are updated.

[0062] S30: Deploy the tag-based network policy to a production environment to control the traffic of network resources in the production environment through the tag-based network policy.

[0063] In this embodiment, the tag-based network policy can be distributed to various network devices and related systems using a network management tool or a policy orchestration platform to ensure that the network policy can be accurately transmitted to the target device, correctly loaded and effective on the target device.

[0064] Understandably, in order to reduce risks, deployment is usually carried out in a gradual manner. Policy deployment and verification can be carried out in some non-critical network areas or test environments first, and then observed for a period of time to ensure that the implementation of network policies will not have a negative impact on the business. After confirmation, the deployment scope can be gradually expanded until it covers the entire production environment.

[0065] In practical applications, the process of flow control based on network policies can be applied to the scenario of setting up a medical network environment. Considering that there are many businesses in the medical scenario, such as electronic medical record systems, medical image transmission, remote medical consultations, and data transmission of medical Internet of Things devices. These businesses have different requirements for network bandwidth, latency, and reliability. For example, remote medical consultations require real-time, high-definition audio and video transmission, and have high requirements for bandwidth and low latency. Specifically, detailed network policies can be formulated based on different businesses combined with network equipment performance and network topology. For example, a higher priority and fixed bandwidth can be assigned to remote medical consultations to ensure smooth video, and a suitable transmission rate and priority can be set for the medical image transmission system to ensure fast and accurate transmission of image data, while avoiding occupying too much bandwidth and affecting other businesses.

[0066] Considering the feasibility of implementing tag-based network policies, a comprehensive functional test can be performed on the deployed tag-based network policies to check whether the network policies can fully control the traffic as expected by simulating various network traffic scenarios. For example, try to access servers with different tags from clients with different tags to verify whether only traffic that complies with the network policies can pass through and traffic that does not comply with the network policies is correctly blocked. Figure 5 As shown, after step S30, the method further includes the following steps:

[0067] S40: Obtain a policy deployment time point and a policy effective time point of the tag-based network policy.

[0068] S50: Compare the policy deployment time with the policy effective time point to obtain the effective delay time of the network policy.

[0069] S60: If the effective delay time exceeds the set time, the tag-based network policy is checked.

[0070] Among them, the policy deployment time point is the time point when the network policy is submitted to the control end, which is equivalent to the time point when the policy is applied to the system. Specifically, you can find records or fields related to network policy deployment in the detailed information page of the network policy. The time displayed in this field is the policy deployment time point. The policy effective time is the time point when the control end first monitors the traffic operation event record, which is equivalent to the time point when the policy actually starts to affect the traffic. Specifically, you can check the change record of the policy status or related operation logs, combined with the network force monitoring data to determine the policy effective time point. For example, observe whether the network traffic is correctly controlled and adjusted according to the network policy from a certain point in time. This time point can be used as the policy effective time point.

[0071] Furthermore, after obtaining the policy deployment time and effective time, subtract the deployment time from the effective time, and the time difference is the effective delay of the network policy. The calculated effective delay is recorded and analyzed in combination with factors such as the network environment and policy complexity. If the effective delay is found to be too long, further investigation is required, such as network equipment performance issues, policy configuration errors, etc., and appropriate measures are taken to optimize it.

[0072] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.

[0073] In one embodiment, a device for performing flow control based on a network policy is provided, and the device for performing flow control based on a network policy corresponds one-to-one to the method for performing flow control based on a network policy in the above embodiment. Figure 6 As shown, the device for performing flow control based on network policy includes a switching module 101, a configuration module 102 and a broadcast module 103. Each functional module is described in detail as follows:

[0074] The allocation module 101 is used to pre-allocate labels to network resources in an operating environment that does not use a container orchestration platform;

[0075] A conversion module 102, configured to convert a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to a label corresponding to the network resource;

[0076] The control module 103 is used to deploy the label-based network policy into the production environment, so as to control the traffic of the network resources in the production environment through the label-based network policy.

[0077] In one embodiment, the allocation module 101 is specifically configured to:

[0078] Use a template engine to define the tag metadata as a tag variable and write it into a service configuration file, so that when the service is deployed, the tag configuration file is generated by the tag variable;

[0079] In an operating environment that does not use a container orchestration platform, the tag configuration file is synchronized to the cloud platform through a script, so that the cloud platform assigns tags to network resources according to the tag configuration file.

[0080] In one embodiment, the conversion module 102 is specifically configured to:

[0081] By analyzing the network policy based on classless inter-domain routing in the cloud native network, the resource service information corresponding to the classless inter-domain routing segment is obtained;

[0082] Establishing a mapping relationship between the classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment;

[0083] By utilizing the mapping relationship between the classless inter-domain routing segment and at least one label, a network policy based on classless inter-domain routing in a cloud native network is converted into a network policy based on a label.

[0084] In one embodiment, the conversion module 102 is further configured to:

[0085] By parsing the network policy based on classless inter-domain routing in the cloud native network, the classless inter-domain routing segment of the network policy is extracted;

[0086] According to the classless inter-domain routing segment of the network policy, querying the network resources corresponding to the classless inter-domain routing segment;

[0087] The network resources corresponding to the classless inter-domain routing segment are associated with the business service to obtain resource service information corresponding to the classless inter-domain routing segment.

[0088] In one embodiment, the conversion module 102 is further configured to:

[0089] Determining a resource attribute tag of the classless inter-domain routing segment according to the resource service information corresponding to the classless inter-domain routing segment;

[0090] According to the resource attribute label of the classless inter-domain routing segment, a mapping relationship between the classless inter-domain routing segment and at least one label is established, and the mapping relationship supports bidirectional query.

[0091] In one embodiment, the conversion module 102 is further configured to:

[0092] After establishing a mapping relationship between a classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment, when the classless inter-domain routing segment has a multi-segment inclusion relationship, adjusting the label of the classless inter-domain routing segment according to the hierarchical relationship of the classless inter-domain routing segment to adjust the mapping relationship accordingly, the multi-segment inclusion relationship being that an IP address range of one classless inter-domain routing segment covers an IP address range of at least one smaller classless inter-domain routing segment;

[0093] When there are multiple overlapping relationships among the classless inter-domain routing segments, the labels of the classless inter-domain routing segments are adjusted according to the usage priority of the classless inter-domain routing segments to adjust the mapping relationship accordingly, and the multiple overlapping relationships are that the IP address range of one classless inter-domain routing segment overlaps with the IP address range of another classless inter-domain routing segment.

[0094] In one embodiment, the device further comprises:

[0095] An acquisition module, used for acquiring a policy deployment time point and a policy effective time point of the tag-based network policy after deploying the tag-based network policy to the production environment so as to control the traffic of network resources in the production environment through the tag-based network policy, wherein the policy deployment time point is the time point when the network policy is submitted to the control end, and the policy effective time is the time point when the control end first monitors the traffic operation event record;

[0096] A comparison module, used to compare the policy deployment time with the policy effective time point to obtain the effective delay time of the network policy;

[0097] The checking module is used to check the label-based network policy if the effectiveness delay time exceeds the set time.

[0098] The present invention provides a device for flow control based on network policy. By converting the network policy based on classless inter-domain routing in the cloud native network into a network policy based on labels, network resources can be managed in a refined manner to achieve fine-grained flow control of network resources. In an operating environment where a container orchestration platform is not used, it is often necessary to frequently adjust the network policy. The logical abstraction capability of labels can reduce the complexity of the network policy, greatly reduce the number of network policies issued, and increase the effective time of the network policy.

[0099] For the specific definition of the device for flow control based on network policy, please refer to the definition of the intelligent question and answer method above, which will not be repeated here. Each module in the above-mentioned device for flow control based on network policy can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0100] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 7As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, the functions or steps on the service side of a method for flow control based on network policy are implemented.

[0101] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, the client-side functions or steps of a method for flow control based on network policy are implemented.

[0102] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0103] In an operating environment that does not use a container orchestration platform, pre-assign labels to network resources;

[0104] Converting a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to the label corresponding to the network resource;

[0105] The tag-based network policy is deployed in a production environment to control the traffic of network resources in the production environment through the tag-based network policy.

[0106] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0107] In an operating environment that does not use a container orchestration platform, pre-assign labels to network resources;

[0108] Converting a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to the label corresponding to the network resource;

[0109] The tag-based network policy is deployed in a production environment to control the traffic of network resources in the production environment through the tag-based network policy.

[0110] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0111] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0112] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0113] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for flow control based on network strategy, characterized in that: include: In an operating environment that does not use a container orchestration platform, pre-assign labels to network resources; Converting a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to the label corresponding to the network resource; The tag-based network policy is deployed in a production environment to control the traffic of network resources in the production environment through the tag-based network policy.

2. The method for flow control based on network policy according to claim 1, characterized in that: In the operating environment where the container orchestration platform is not used, pre-allocating labels for network resources includes: Using a template engine, define the tag metadata as a tag variable and write it into a service configuration file, so that when the service is deployed, the tag configuration file is generated by the tag variable; In an operating environment that does not use a container orchestration platform, the tag configuration file is synchronized to the cloud platform through a script, so that the cloud platform assigns tags to network resources according to the tag configuration file.

3. The method for flow control based on network policy according to claim 1, characterized in that: The converting the network policy based on classless inter-domain routing in the cloud native network into a network policy based on a label according to the label corresponding to the network resource includes: By analyzing the network policy based on classless inter-domain routing in the cloud native network, the resource service information corresponding to the classless inter-domain routing segment is obtained; Establishing a mapping relationship between the classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment; By utilizing the mapping relationship between the classless inter-domain routing segment and at least one label, a network policy based on classless inter-domain routing in a cloud native network is converted into a network policy based on a label.

4. The method for flow control based on network policy as claimed in claim 3, characterized in that: The method of obtaining resource service information corresponding to the classless inter-domain routing segment by analyzing the network policy based on classless inter-domain routing in the cloud native network includes: By parsing the network policy based on classless inter-domain routing in the cloud native network, the classless inter-domain routing segment of the network policy is extracted; According to the classless inter-domain routing segment of the network policy, querying the network resources corresponding to the classless inter-domain routing segment; The network resources corresponding to the classless inter-domain routing segment are associated with the business service to obtain resource service information corresponding to the classless inter-domain routing segment.

5. The method for flow control based on network policy as claimed in claim 3, characterized in that: The establishing a mapping relationship between the classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment includes: Determining a resource attribute tag of the classless inter-domain routing segment according to the resource service information corresponding to the classless inter-domain routing segment; According to the resource attribute label of the classless inter-domain routing segment, a mapping relationship between the classless inter-domain routing segment and at least one label is established, and the mapping relationship supports bidirectional query.

6. The method for flow control based on network policy as claimed in claim 3, characterized in that: After establishing a mapping relationship between a classless inter-domain routing segment and at least one label according to the resource service information corresponding to the classless inter-domain routing segment, the method further includes: When the classless inter-domain routing segment has a multi-segment inclusion relationship, adjusting the label of the classless inter-domain routing segment according to the hierarchical relationship of the classless inter-domain routing segment to adjust the mapping relationship accordingly, and the multi-segment inclusion relationship is that the IP address range of one classless inter-domain routing segment covers the IP address range of at least one smaller classless inter-domain routing segment; When there are multiple overlapping relationships among the classless inter-domain routing segments, the labels of the classless inter-domain routing segments are adjusted according to the usage priority of the classless inter-domain routing segments to adjust the mapping relationship accordingly, and the multiple overlapping relationships are that the IP address range of one classless inter-domain routing segment overlaps with the IP address range of another classless inter-domain routing segment.

7. The method for performing flow control based on network policy according to any one of claims 1 to 6, characterized in that: After deploying the label-based network policy to the production environment to control the traffic of network resources in the production environment through the label-based network policy, the method further includes: Obtain the policy deployment time point and policy effective time point of the tag-based network policy, where the policy deployment time point is the time point when the network policy is submitted to the control end, and the policy effective time is the time point when the control end first monitors the traffic operation event record; Compare the policy deployment time with the policy effective time point to obtain the effective delay time of the network policy; If the effective delay time exceeds the set time, the tag-based network policy is checked.

8. A device for flow control based on network strategy, characterized in that: include: An allocation module for pre-allocating labels for network resources in an operating environment that does not use a container orchestration platform; A conversion module, configured to convert a network policy based on classless inter-domain routing in a cloud native network into a network policy based on a label according to a label corresponding to the network resource; A control module is used to deploy the label-based network policy into a production environment so as to control the flow of network resources in the production environment through the label-based network policy.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method for performing traffic control based on network policy as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for performing traffic control based on network policy as claimed in any one of claims 1 to 7 are implemented.

Images