IPBlock rule issuing method and device, equipment and storage medium

Abstract

The embodiment of the invention provides an IPBlock rule issuing method and device, equipment and a storage medium, and the method can merge strategy rules according to application deployment unit information in strategy rule data after obtaining the to-be-issued strategy rule data, so as to generate merged rule data, and then apply the merged rule data to a target deployment unit. According to the IPBlock rule issuing method, the rules of the same content can be merged and the rules of the same application deployment unit can be merged by merging, issuing and updating a strategy mechanism, so that the creation and updating times of the strategy rules are reduced, the competition between execution locks is reduced, the rule issuing speed and efficiency are improved, and the overall time delay of rule issuing is shortened.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and particularly to an IPBlock rule distribution method, apparatus, device, and storage medium. Background Art

[0002] An Internet Protocol Address Block (IPBlock) is a rule field used to define a specific IP range in the network policies used by a container orchestration platform. IPBlock allows administrators to control the traffic inside and outside the cluster by specifying a Classless Inter-Domain Routing (CIDR) range.

[0003] In a network environment built based on Kubernetes (K8s), the container network and security platform (Cilium) and the Extended Berkeley Packet Filter (eBPF) technology can be applied to the control and management of network traffic. Among them, Cilium, as a container network and security platform based on eBPF, can provide efficient network policy management functions. However, when dealing with a large number of IPBlock type rules, Cilium has some performance bottlenecks. Especially when multiple Policies are created concurrently, the overall distribution speed of IPBlock type rules is limited.

[0004] Since Cilium needs to match and manage a large number of IP addresses when dealing with IPBlock type rules. And Cilium frequently uses a global read lock in the event processing flow and needs to wait for multiple coroutines to complete during the processing, which will increase the distribution delay of IPBlock type rules. In addition, when Cilium concurrently processes multiple Policy creation requests, it is in a serial manner, which limits the overall performance of the system, resulting in low distribution speed and efficiency of Cilium when dealing with a large number of IPBlock type rules. Summary of the Invention

[0005] In view of this, embodiments of this application provide an IPBlock rule distribution method, apparatus, device, and storage medium to solve the problem of low distribution speed and efficiency of Cilium when dealing with a large number of IPBlock type rules.

[0006] According to one aspect of this application, an IPBlock rule distribution method is provided. The method includes:

[0007] Obtain the policy rule data to be distributed, where the policy rule data includes policy rules and application deployment unit information of the policy rules;

[0008] Merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, where the merged rule data includes at least one of a first rule, a second rule, and a third rule; the first rule is a rule generated by merging policy rules corresponding to the same port in multiple deployment units; the second rule is a set of rules that merges multiple policy rules applied to the same deployment unit into the same batch operation; the third rule is the policy rule in the policy rule data that has not been merged;

[0009] Apply the merged rule data to the target deployment unit.

[0010] According to another aspect of the present application, there is provided an IPBlock rule distribution device, where the device includes:

[0011] A rule acquisition module, configured to obtain the policy rule data to be distributed, where the policy rule data includes policy rules and application deployment unit information of the policy rules;

[0012] A rule merging module, configured to merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, where the merged rule data includes at least one of a first rule, a second rule, and a third rule; the first rule is a rule generated by merging policy rules corresponding to the same port in multiple deployment units; the second rule is a set of rules that merges multiple policy rules applied to the same deployment unit into the same batch operation; the third rule is the policy rule in the policy rule data that has not been merged;

[0013] A rule application module, configured to apply the merged rule data to the target deployment unit.

[0014] According to yet another aspect of the present application, there is provided a computer device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, where when the processor executes the program, the above-mentioned IPBlock rule distribution method is implemented.

[0015] According to still another aspect of the present application, there is provided a storage medium, on which a computer program is stored, where when the program is executed by a processor, the above-mentioned IPBlock rule distribution method is implemented.

[0016] With the above technical solution, the embodiments of the present application provide an IPBlock rule distribution method, device, equipment and storage medium. After obtaining the policy rule data to be distributed, the method can merge the policy rules according to the application deployment unit information in the policy rule data to generate merged rule data, and then apply the merged rule data to the target deployment unit. Among them, the merged rule data includes at least one of a first rule, a second rule, and a third rule. The first rule is a rule generated by merging the policy rules corresponding to the same port of multiple deployment units. The second rule is a rule set obtained by merging multiple policy rules applied to the same deployment unit into the same batch operation. The third rule is the policy rule that has not been merged in the policy rule data. The method can reduce the number of creations and updates of policy rules, reduce the competition between execution locks, improve the speed and efficiency of rule distribution, and shorten the overall latency of rule distribution by merging and distributing the update policy mechanism, merging rules with the same content, and merging rules of the same application deployment unit.

[0017] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the following specifically describes the embodiments of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0019] Figure 1 It is a schematic diagram of the cloud computing platform structure provided by the embodiments of the present application;

[0020] Figure 2 It is a schematic diagram of the structure of the container orchestration platform provided by the embodiments of the present application;

[0021] Figure 3 It is a schematic diagram of the policy rule distribution process provided by the embodiments of the present application;

[0022] Figure 4 It is a schematic diagram of the IPBlock rule distribution method process provided by the embodiments of the present application;

[0023] Figure 5 It is a schematic diagram of the process for generating the first rule provided by the embodiments of the present application;

[0024] Figure 6 It is a schematic diagram of the process for generating the second rule provided by the embodiments of the present application;

[0025] Figure 7Schematic diagram of the API entry lock optimization process provided by the embodiments of this application;

[0026] Figure 8 Schematic diagram of the task sharding process provided by the embodiments of this application;

[0027] Figure 9 Schematic diagram of the structure of the IPBlock rule distribution device provided by the embodiments of this application;

[0028] Figure 10 Schematic diagram of the structure of the computer device provided by the embodiments of this application. Detailed implementation manners

[0029] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other.

[0030] In the embodiments of the present application, the cloud computing refers to a technology for providing computing resources through the Internet. For example, through cloud computing technology, computing resources such as servers, storage, databases, networks, and applications can be provided. Based on cloud computing technology, users do not need to deploy and maintain a complete set of hardware devices, but only need to rent resources from cloud service providers on demand and access and use these resources through the network.

[0031] As Figure 1 shown, cloud computing can rely on a cloud computing platform deployed in the Internet to implement corresponding services. A cloud computing platform is a combination of multiple electronic devices and service applications built relying on the Internet. Among them, the electronic devices are the infrastructure for providing computing resources and services such as servers, storage, networks, and applications. The service applications can include applications for providing cloud computing services and applications for maintaining the operation of the cloud computing platform. Through the cloud computing platform, flexible, efficient, and scalable computing resources and services can be provided to help users reduce costs, improve efficiency, and accelerate innovation.

[0032] The cloud computing platform can provide cloud computing services to users based on a specific application management and deployment method. In some embodiments, a cloud computing platform can be built based on a container orchestration platform. A container orchestration platform is a tool or a collection of tools for managing and automating the deployment, scaling, and operation of containerized applications. The container orchestration platform can achieve container distribution and scheduling by centrally managing a container cluster.

[0033] As Figure 2As shown below, taking the Kubernetes container orchestration platform as an example, the core components of Kubernetes include management (Master) components, node (Node) components, deployment units (Pod), service (Service) components, deployment (Deployment) components, stateful replica sets (StatefulSet) components, daemon sets (DaemonSet), job / cron job (Job / CronJob) components, etc. Among them, the Master components can include units such as the Application Programming Interface Server (API Server), Controller Manager, Scheduler, and distributed key-value store (etcd). The API Server can provide the RESTful API interface of the cluster and is the control center of the cluster. The Controller Manager manages the controllers in the cluster, such as the node controller and replica controller. The Scheduler is responsible for determining which node to schedule the Pod to run on. Etcd is a distributed key-value store used to store the status information of the cluster.

[0034] The Node components can include units such as the Kubelet service, Kubelet proxy (Kube-proxy), and Container Runtime. The Kubelet service can run on each node and is responsible for managing the life cycles of Pods and containers. The Kube-proxy, as a network proxy, is responsible for network forwarding and load balancing. The Container Runtime is responsible for running containers.

[0035] The Pod, as the smallest deployment unit of Kubernetes, can contain one or more containers. The containers within the Pod share the same network namespace and storage volume. The Service is used to define a logical collection of Pods, providing a stable network identity and load balancing. The Deployment is used to manage the deployment of stateless applications, supporting automatic scaling and rolling updates. The StatefulSet is used to manage stateful applications, such as databases, providing a stable network identity and storage volume. The DaemonSet is used to ensure that one Pod replica runs on each node and is often used to run log collectors or monitoring agents. The Job / CronJob can be used to run one-time tasks or scheduled tasks.

[0036] Among them, a container in a container orchestration platform is a lightweight, portable, and self - contained software runtime environment that packages an application and its dependencies together for efficient operation in different computing environments. Containers are the core components of a container orchestration platform, and the main task of a container orchestration platform is to manage and schedule these containers.

[0037] For example, container orchestration platforms such as Kubernetes and Docker Swarm can automatically deploy containerized applications and automatically scale the number of container instances up or down according to the application load. They can also provide load - balancing functions to evenly distribute traffic across multiple container instances to ensure the high availability and high performance of the application. At the same time, the container orchestration platform provides stable network access for containers through a service discovery mechanism. If a container fails, the container orchestration platform will automatically detect and restart the container, or schedule it to run on other healthy nodes to ensure the continuous operation of the application.

[0038] Containers in a container orchestration platform can be deployed in specific deployment units. For example, the smallest deployment unit in Kubernetes is a Pod, and a Pod can contain one or more containers. Containers within a Pod can share the same network namespace, communicate with each other through localhost, and share the same IP address.

[0039] The deployment unit can set ports to define the network communication interface of the deployment unit. For example, containers within a Pod can expose services through specified ports. The ports applied to the deployment unit can be called ContainerPorts, and each container can expose one or more ports through containerPort. The exposed ports can be used for communication between containers or for external access to container services. In a container orchestration platform, there are also Service Ports. A Service is a resource object in the container orchestration platform used to define a logical collection of deployment units. Therefore, a Service can forward traffic to the container ports of the backend deployment unit through a virtual IP and port.

[0040] To define resource behaviors and security rules, a container orchestration platform can also deploy policies. A policy is a set of rules, guidelines, or configurations used to define key functions such as the behavior of a system, access permissions, resource allocation, etc. For example, policies can include NetworkPolicy and PodSecurityPolicy. Among them, NetworkPolicy is used to define the network communication rules between Pods. Through policies, specific inbound (Ingress) and outbound (Egress) traffic can be allowed or denied. And traffic control is performed based on the label selector, namespace selector, or IP range of the Pod. PodSecurityPolicy is used to define the security policy of the Pod, such as runtime permissions, file system permissions, etc. In some embodiments, the policy used to control the inbound and outbound traffic of the Pod defined and issued through the NetworkPolicy resource can be referred to as a rule of the IPBlock type. IPBlock allows the management system to specify the IP address range (i.e., Classless Inter-Domain Routing, CIDR) that is allowed or denied, and can exclude specific subnets in combination with the except field.

[0041] As Figure 3 shown, the deployment process of the policy can include stages such as creation, distribution, and application. In the creation stage of the policy, an ipBlock rule can be specified by creating a NetworkPolicy resource file. For example, through a data serialization language (YAML Ain't Markup Language, YAML) file, traffic from a specific IP range can be defined while excluding certain subnets. That is, by defining ingress: - from: - ipBlock: cidr: 10.0.0.0 / 16; except: - 10.0.1.0 / 24, inbound traffic from the range 10.0.0.0 / 16 is allowed, but the subnet 10.0.1.0 / 24 is excluded. By defining egress: - to: - ipBlock: cidr: 192.168.1.0 / 24, outbound traffic to the range 192.168.1.0 / 24 is allowed.

[0042] After creating the ipBlock rule, the container orchestration platform can distribute the created ipBlock rule to the specified deployment unit. For example, when the container orchestration platform is a pod, the master component can set the target deployment unit for the created ipBlock rule, that is, set the IP address of the target pod for the application of the ipBlock rule. Then, according to the set IP address of the deployment unit, the ipBlock rule is sent to the specified deployment unit.

[0043] After sending the ipBlock rule to the target deployment unit, the issued ipBlock rule can be applied to the target deployment unit. For example, in order to apply NetworkPolicy, the kubectl command can be used to apply NetworkPolicy to the cluster. That is, by defining bash: kubectl apply -f networkpolicy.yaml, the ipBlock rule named "networkpolicy.yaml" is applied to the cluster.

[0044] In some embodiments, in a network environment built based on Kubernetes (K8s), the container network and security platform (Cilium) and the Extended Berkeley Packet Filter (eBPF) technology can be applied to the control and management of network traffic. Among them, Cilium, as a container network and security platform based on eBPF, can provide an efficient network policy management function.

[0045] Since Cilium needs to match and manage a large number of IP addresses when processing IPBlock type rules. And Cilium frequently uses a global read lock in the event processing flow and needs to wait for multiple coroutines to complete during the processing, which will increase the latency of issuing IPBlock type rules. Moreover, when Cilium concurrently processes multiple Policy creation requests, it is in a serial manner, which limits the overall performance of the system and results in low issuing speed and efficiency of Cilium when processing a large number of IPBlock type rules.

[0046] To solve the problem of low issuing speed and efficiency of Cilium when processing a large number of IPBlock type rules, some embodiments of this application provide an IPBlock rule issuing method. The method can be applied to a container orchestration platform and is specifically applied to a node device or an electronic device with data processing functions and management permissions in the container orchestration platform. For the sake of description, in the embodiments of this application, the container orchestration platform is used as the execution subject of the IPBlock rule issuing method. It should be understood that the method can also be applied to other types of execution subjects, such as servers, cloud computing network applications, mobile terminals, etc. As Figure 4 shown, the method includes:

[0047] S101. Obtain the policy rule data to be issued.

[0048] To issue rules of the IPBlock type, the container orchestration platform may first obtain the policy rule data to be issued. Among them, the policy rule data includes policy rules and the application deployment unit information of the policy rules. The policy rule is the content of the IPBlock type policy rule to be issued. The application deployment unit information is used to represent the specific deployment unit to which the IPBlock rule to be issued is to be applied.

[0049] For example, the policy rules in the policy rule data may include the YAML file corresponding to the specific policy rule, while the application deployment unit information may include the network IP address of the pod to which the policy rule is specifically applied. There is a preset association relationship between the policy rule and the application deployment unit information. The container orchestration platform may, according to this association relationship, issue and apply the corresponding policy rule to the specified pod according to the application deployment unit information.

[0050] To obtain the policy rule data to be issued, in some embodiments, when the container orchestration platform obtains the policy rule data to be issued, it may receive a policy issuance instruction input through the management system. After receiving the policy issuance instruction, the container orchestration platform may, in response to the policy issuance instruction, create a policy rule. For example, the administrator of the container orchestration platform may write a YAML file for the new rule according to the platform requirements and upload the YAML file to the container orchestration platform. The container orchestration platform may perform verification and trial operation on the written YAML file and, after passing the verification, create it as a policy rule.

[0051] After creating the policy rule, the associated deployment unit of the policy rule may be found, that is, when creating a Policy, by reading the Pods involved in the policy rule, all related Pods of the Policy are found. In some embodiments, the associated deployment unit may be the deployment unit IP address specifically defined in the policy rule. For example, when the created policy rule includes a YAML file with the following content, "ingress: - from: - ipBlock: cidr: 10.0.0.0 / 16; except: - 10.0.1.0 / 24; egress: - to: - ipBlock: cidr: 192.168.1.0 / 24", the Pods related to this policy rule include: 10.0.0.0 / 16; 10.0.1.0 / 24 and 192.168.1.0 / 24.

[0052] In some embodiments, the associated deployment unit may also include the IP addresses of other pods in addition to the deployment unit IP address specifically defined in the policy rule. For example, for the global policy rule applied to the entire container orchestration platform, its associated deployment unit is all the pods of the current container orchestration platform.

[0053] After finding the associated deployment unit of the policy rule, the container orchestration platform can extract the application deployment unit information of the associated deployment unit, where the application deployment unit information includes the application deployment unit IP and the application port. Then, an association relationship is established between the policy rule and the application deployment unit information to generate the policy rule data.

[0054] To adapt to the processing method of the IPBlock type policy rule, when establishing the association relationship between the policy rule and the application deployment unit information, according to the processing method requirements of Cilium, one Policy can correspond to one Pod IP and one application port to control the network traffic thereon. Therefore, the generated policy rule data can include multiple Policies, and each Policy is set with a corresponding Pod IP or application port to facilitate subsequent policy distribution and application.

[0055] S102. Merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data.

[0056] After obtaining the policy rule data to be distributed, the container orchestration platform can merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data. Among them, the merging of the policy rules can include merging the policy rules corresponding to multiple deployment units when multiple deployment units correspond to one policy rule, and merging the tasks of multiple policy rules when one deployment unit corresponds to multiple policy rules.

[0057] Therefore, the merged rule data includes at least one of a first rule, a second rule, and a third rule. The first rule is a rule generated by merging the policy rules corresponding to multiple deployment units with the same port.

[0058] As Figure 5 shown, in some embodiments, to generate the merged rule data including the first rule, after obtaining the policy rule data to be distributed, the container orchestration platform can read multiple policy rules from the policy rule data and identify the rule content of the policy rules. Then, according to the rule content, determine the policy rules to be merged among the multiple policy rules. The policy rules to be merged have the same rule content. Then, merge the multiple policy rules to be merged into one policy rule to generate the first rule.

[0059] For example, after obtaining the policy rule data to be distributed, the container orchestration platform can read each of the multiple policy rules included in the policy rule data, that is, read the YAML file corresponding to the policy rule to determine the specific rule content of the policy rule. By reading the YAML files corresponding to multiple policy rules, it can be identified whether the multiple policy rules are the same rule.

[0060] In some embodiments, when identifying the rule content of the policy rule, the container orchestration platform can determine the keyword fields defined in the policy rule based on the read content of the policy rule, such as the inbound field Ingress and the outbound field Egress, etc. If the number and content of the keyword fields included in two policy rules are the same, it can be determined that these two policy rules are the same policy rule.

[0061] After identifying the rule content of the policy rule, the container orchestration platform can determine multiple policy rules to be merged that are the same policy rule among multiple policy rules according to the rule content. For example, the policy rule data can include n policy rules, that is, P1, P2,..., Pn. By comparing the rule content, it can be determined that the rule content of P1, P3, and Pn is the same, only the corresponding pods are different. Therefore, it can be determined that P1, P3, and Pn are the policy rules to be merged.

[0062] After determining the policy rules to be merged, multiple said policy rules to be merged can be merged into one policy rule to generate a first rule. In some embodiments, when merging multiple policy rules to be merged, the multiple application deployment unit information of multiple said policy rules to be merged can be read respectively, and then according to the multiple application deployment unit information, a deployment unit set can be generated, and an association relationship between the deployment unit set and the first rule can be established to generate the merged rule data including the first rule.

[0063] For example, after determining the policy rule Policy to be merged, all relevant Pods when the policy rule to be merged is created can be searched respectively, and according to the application deployment unit information corresponding to multiple relevant pods, a deployment unit set can be generated, and by establishing an association relationship between the deployment unit set and the first rule, the Policy rule can be applied to these Pods to generate the merged rule data including the first rule.

[0064] By merging the Policies corresponding to the same port of multiple Pods into one Policy, the number of Policies can be reduced, thereby reducing the number and frequency of lock usage. Moreover, sharing one Policy for multiple Pods can reduce the number of Policy creations and updates, reduce lock contention, improve the efficiency of rule distribution, and reduce the overall latency.

[0065] The second rule is a rule set that merges multiple policy rules applied to the same deployment unit into the same batch operation. As Figure 6 shown, in some embodiments, to generate merged rule data including the second rule, when the container orchestration platform executes merging the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, it can read the application deployment unit information of the policy rules from the policy rule data, and extract multiple same-batch policy rules according to the application deployment unit information. Wherein, the application deployment unit information includes an application port and / or an application deployment unit IP. The multiple same-batch policy rules have the application deployment unit information characterizing the same deployment unit. Then, the multiple same-batch policy rules are merged into the same policy distribution task to generate the second rule.

[0066] After obtaining the policy rule data to be distributed, the container orchestration platform can read the application deployment unit information in the policy rule data to determine multiple policy rules applied to the same deployment unit. To further reduce the number of times of lock usage, the update operations of multiple Policies corresponding to one Pod can be merged into one batch operation. Therefore, the multiple policy rules applied to the same deployment unit determined according to the application deployment unit information are collectively referred to as same-batch policy rules.

[0067] For example, by reading the associated Pods corresponding to n policy rules P1, P2, ……, Pn in the policy rule data, determining the IP address or application port information of the Pods corresponding to the policy rules, so as to determine multiple policy rules applied to the same Pod, that is, P2, P4, Pn-1 are same-batch policy rules.

[0068] After determining multiple same-batch policy rules, the multiple same-batch policy rules can be merged into the same policy distribution task, thereby generating the second rule. Among them, the distribution task can be executed based on a specific distribution tool. For example, for the scenario where one Pod corresponds to multiple Policy rules, when distributing the policy rules, the update operations of multiple Policies corresponding to one Pod can be merged into one batch operation and sent to the Cilium CNI plugin at the same time, so that the Cilium CNI plugin can update these Policies at one time when processing. Among them, the Cilium CNI plugin is a plugin for open source container networks such as Kubernetes, and can implement high-performance and scalable network and security functions based on the eBPF technology.

[0069] It can be seen that in the scenario where a Pod corresponds to multiple Policy rules, when issuing policy rules, the update operations of multiple Policies corresponding to a Pod are merged into a batch operation to generate the second rule. And by issuing the second rule to network plug-ins such as Cilium CNI, the second rule in the same batch is updated once during processing and the lock is taken once, thereby reducing the number of lock usage, reducing the number of Policy creation and updates, reducing lock contention, and improving the efficiency of the rule taking effect.

[0070] After merging the situations where one policy rule in the policy rule data corresponds to multiple deployment units and the first deployment unit corresponds to multiple policy rules in the manner provided in the above embodiment, some policy rules in the policy rule data can be merged into the same policy rule or the same policy delivery task, thereby reducing the number of policies included in the policy rule data. As for the policy rules that are not merged in the policy rule data, the unmerged policy rules can be retained as the third rule in the merged rule data, that is, the third rule is the policy rule that is not merged in the policy rule data.

[0071] For example, for policy rule data including n policy rules, by comparing the rule content and application Pod information of policy rules P1, P2, ..., Pn respectively, it can be determined that the rule content of P1, P3, and Pn is the same, and they are policy rules to be merged. P2, P4, and Pn-1 are applied to the same Pod and are policy rules in the same batch. After merging P1, P3, and Pn into the first rule Pm, and merging P2, P4, and Pn-1 into the second rule Ps, the remaining policy rules P5, P6, ..., and Pn-2 do not participate in the merger and are the third rule. Therefore, the generated merged rule data can include Pm, Ps, P5, P6, ..., and Pn-2.

[0072] It should be noted that the merged rule data may include one or a combination of the first rule, the second rule, and the third rule. That is, when merging the policy rules in the policy rule data according to the application deployment unit information to generate the merged rule data, if there are policy rules to be merged with the same rule content in the policy rule data, after merging, the merged rule data including the first rule can be obtained. When there are batch policy rules applied to the same Pod in the policy rule data, after merging, the merged rule data including the second rule can be obtained. When the policy rule data contains both policy rules to be merged with the same rule content and batch policy rules applied to the same Pod, after merging, the merged rule data including the first rule and the second rule can be obtained. Similarly, when the policy rule data contains neither policy rules to be merged with the same rule content nor batch policy rules applied to the same Pod, after merging, the merged rule data including only the third rule can be obtained.

[0073] S103. Apply the merged rule data to the target deployment unit.

[0074] After generating the merged rule data by merging the policy rule data, the container orchestration platform can send down and apply the merged rule data to the target deployment unit. Among them, the target deployment unit is the application deployment unit corresponding to the policy rule in the merged rule data, that is, the application deployment unit applying the policy rule in the merged rule data.

[0075] In some embodiments, in order to be able to apply the policy rules in the merged rule data to the target deployment unit, the container orchestration platform can determine the target deployment unit according to the merged rule data. Among them, according to the different specific situations of the first rule, the second rule, and the third rule included in the merged rule data, the target deployment unit may include the deployment units in the deployment unit set corresponding to the first rule, and / or, the deployment unit corresponding to the second rule, and / or, the deployment unit corresponding to the third rule.

[0076] For example, when the merged rule data includes the first rule and the third rule, the container orchestration platform can determine the deployment unit set G(Pod) = [Pod11, Pod12,..., Pod1m] corresponding to the first rule by reading the first rule and the third rule in the merged rule data, so as to determine that the multiple deployment units Pod11, Pod12,..., Pod1m included in the deployment unit set are the target deployment units. And determine the deployment units [Pod31, Pod32,..., Pod3n] corresponding to the third rule, that is, determine that the deployment units Pod31, Pod32,..., Pod3n are the target deployment units from the application deployment unit information associated with the unmerged policy rules.

[0077] When the merged rule data includes a second rule and a third rule, the container orchestration platform can determine the deployment units [Pod21, Pod22, ……, Pod2p] corresponding to the second rule as the target deployment units by reading the second rule and the third rule in the merged rule data. And, determine the deployment units [Pod31, Pod32, ……, Pod3n] corresponding to the third rule as the target deployment units.

[0078] After determining the target deployment units, the container orchestration platform can distribute the merged rule data to the target deployment units according to the target deployment units. It can be seen that since the merged rule data is obtained by merging the policy rule data, the number of policy rules included in the merged rule data is less than that of the policy rule data, which can not only reduce the transmission volume during data distribution, but also reduce the number of updates when the policy rules are applied.

[0079] In some embodiments, as a refinement and extension of the specific implementation manner of the above embodiments, in order to fully illustrate the specific implementation process of this embodiment, some embodiments of the present application also provide an IPBlock rule distribution method. Based on the rule distribution method of the above embodiments, this method can also optimize the execution lock at the API entry, adopt a finer-grained lock mechanism, reduce the usage frequency of the global read lock, and reduce the performance loss caused by lock contention. As Figure 7 shown, this method includes:

[0080] S201. Obtain the total number of rules included in the merged rule data.

[0081] When the container orchestration platform applies the merged rule data to the target deployment units, a corresponding lock mechanism can be set for the distribution process. Among them, the lock mechanism is a data processing means to ensure resource consistency, exclusive access, and stability in a distributed system. The lock mechanism can make the access to shared resources in the container orchestration platform mutually exclusive, that is, adapt to the concurrent processing process in a distributed environment through resource synchronization and exclusive access. For resource synchronization, through the lock mechanism, it can be ensured that the access to shared resources is sequential, avoiding data inconsistency caused by concurrent access. And for exclusive access, when a process is accessing a resource, other processes must wait until the current process finishes accessing.

[0082] In some embodiments, the lock mechanisms applied to the container orchestration platform may include types such as ResourceLock, Config Lock, API Lock, etc. Among them, the resource lock is used to lock specific resources, such as Pods, Nodes, Services, etc., to ensure that only one component can modify the resource at the same time. The configuration lock is used to lock the cluster configuration information to ensure configuration consistency. The API lock is used to lock API requests to ensure the order and consistency of requests. For ease of description, in the embodiments of the present application, various types of lock mechanisms applied to the container orchestration platform are collectively referred to as operation locks.

[0083] To set up the lock mechanism, the container orchestration platform may obtain the total number of rules included in the merge rule data. Corresponding to the merge rule data including the first rule, the second rule, and the third rule, the total number of rules is the sum of the number of the first rule, the number of the second rule, and the number of the third rule.

[0084] S202. Invoke the execution lock according to the total number of rules.

[0085] After obtaining the total number of rules included in the merge rule data, the container orchestration platform then invokes the execution lock according to the total number of rules. Among them, the execution lock is a lock mechanism set at the entrance of the application program interface; the execution lock is obtained by refining the global lock granularity from the key-value pair set level to the deployment unit dimension; the number of invocations of the execution lock is equal to the total number of rules.

[0086] That is, in order to adapt to the merge rule data after the execution rule merge, the execution lock at the API entrance can be optimized. That is, at the API entrance, a finer-grained lock mechanism is adopted to reduce the performance loss caused by lock contention. By refining the global lock granularity from the entire map level to the Pod dimension for update, a finer-grained lock mechanism is realized.

[0087] S203. Apply the merge rule data to the target deployment unit based on the execution lock.

[0088] After invoking the execution lock according to the total number of rules, the container orchestration platform can apply the merge rule data to the target deployment unit based on the execution lock. For example, the container orchestration platform can call the execution lock from the distributed lock function provided by etcd based on the storage system of Kubernetes provided by etcd, and store the lock information using etcd according to the storage specificities of the Kubernetes platform. Then, based on the invoked execution lock, the Lease mechanism is adopted to enable the client corresponding to the target deployment unit to exclusively occupy a key within a specified time and apply the policy rules.

[0089] It can be seen that in the above embodiments, the container orchestration platform can optimize the lock mechanism at the API entry, adopt a finer-grained lock mechanism, and refine the granularity of the execution lock to the Pod dimension for updates. Therefore, the usage frequency of the global read lock can be reduced, and the performance loss caused by lock contention can be decreased.

[0090] In some embodiments, as a refinement and extension of the specific implementation manner of the above embodiments, to fully illustrate the specific implementation process of this embodiment, some embodiments of this application further provide an IPBlock rule distribution method. Based on the rule distribution method of the above embodiments, the execution manner of the distribution task can be further optimized, and the parallel processing efficiency can be improved based on the task sharding method. As Figure 8 shown, this method includes:

[0091] S301. Create a rule distribution task based on the merged rule data;

[0092] When the container orchestration platform applies the merged rule data to the target deployment unit, it can first create a rule distribution task based on the merged rule data, that is, create a rule distribution task according to the policy rules included in the merged rule data. Among them, one policy rule corresponds to creating one rule distribution task. For example, when the merged rule data includes n policy rules, n rule distribution tasks can be created according to the number of policy rules.

[0093] In some embodiments, when the container orchestration platform distributes the merged rule data, it can separately read the policy rules in the merged rule data and the application deployment unit information corresponding to the policy rules, and create a rule distribution task according to the type of the policy rules. Among them, each rule distribution task can obtain a lock once when executing data distribution. If the policy rule type is the first rule, a first type of distribution task can be created. The first type of distribution task can include the first rule and the set of application deployment units corresponding to the first rule. The container orchestration platform can distribute the policy rules corresponding to the task to multiple Pods in the set of application deployment units by running the first type of distribution task.

[0094] Similarly, if the policy rule type is the second rule, a second type of task for distribution can be created. The second type of task for distribution can include multiple policy rules applied to the same Pod and the Pod information for applying the policy rules in the same batch. The container orchestration platform can, by running the second type of task for distribution, distribute multiple policy rules to the same Pod in one distribution task. If the policy rule type is the third rule, the container orchestration platform can execute the distribution of the policy rules in the form of one Policy corresponding to one Pod IP and one application port, that is, create a third type of task for distribution according to the distribution method specified in Cilium, and distribute the unmerged policy rules to the corresponding Pods based on the third type of task for distribution.

[0095] S302. Obtain the number of coroutines of the multi-core processor corresponding to the target deployment unit.

[0096] After creating the rule distribution task, the container orchestration platform can also obtain the number of coroutines of the multi-core processor corresponding to the target deployment unit. Herein, the multi-core processor refers to integrating multiple independent processing cores (CPU cores) on one physical chip. Each core can independently execute program instructions to achieve parallel computing. A coroutine is a program component used to implement cooperative multitasking. A multi-core processor can run multiple threads simultaneously, and each thread can manage multiple coroutines. Therefore, by obtaining the mapping relationship among the number of cores, threads, and coroutines, the number of coroutines of the multi-core processor can be obtained.

[0097] In some embodiments, to obtain the number of coroutines of the multi-core processor corresponding to the target deployment unit, the container orchestration platform can send a hardware detection instruction to the target deployment unit. After receiving the hardware detection instruction, the target deployment unit can perform self-check on the hardware parameters of the current device and generate self-check information to feedback to the container orchestration platform. The container orchestration platform then reads the number of coroutines of the multi-core processor corresponding to the target deployment unit from the self-check information.

[0098] S303. Divide the rule distribution task into multiple subtasks according to the number of coroutines.

[0099] After obtaining the number of coroutines of the multi-core processor corresponding to the target deployment unit, the container orchestration platform can divide the rule distribution task into multiple subtasks according to the number of coroutines. Herein, the number of the obtained subtasks is an integer multiple of the number of coroutines.

[0100] For example, after creating n rule distribution tasks according to the number of policy rules, the number of coroutines m can be obtained, and the n rule distribution tasks can be divided into subtasks according to the number of coroutines m, that is, the n rule distribution tasks can be divided into an integer multiple of m to obtain multiple subtask sets.

[0101] S304. Send the merged rule data to the target deployment unit through the multiple subtasks.

[0102] After dividing the rule distribution tasks into multiple subtasks according to the number of coroutines, the container orchestration platform can send the merged rule data to the target deployment unit through multiple subtasks, thereby dividing large-scale rule distribution tasks into multiple small tasks, which are processed by different coroutines respectively, making full use of the parallel processing capabilities of multi-core processors and improving the task processing efficiency.

[0103] In some embodiments, as a specific implementation of the IPBlock rule distribution method in the above embodiments, some embodiments of the present application further provide an IPBlock rule distribution device, as Figure 9 shown, the device includes:

[0104] A rule acquisition module, configured to acquire policy rule data to be distributed, where the policy rule data includes a policy rule and application deployment unit information of the policy rule;

[0105] A rule merging module, configured to merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, where the merged rule data includes at least one of a first rule, a second rule, and a third rule; the first rule is a rule generated by merging policy rules corresponding to the same port of multiple deployment units; the second rule is a rule set obtained by merging multiple policy rules applied to the same deployment unit into the same batch operation; the third rule is a policy rule in the policy rule data that has not been merged;

[0106] A rule application module, configured to apply the merged rule data to a target deployment unit.

[0107] By applying the technical solutions of the above embodiments, an IPBlock rule distribution device is provided in an embodiment of the present application. The device can obtain the policy rule data to be distributed through a rule acquisition module, and then use a rule merging module to merge the policy rules according to the application deployment unit information in the policy rule data to generate merged rule data, and then apply the merged rule data to the target deployment unit through the rule merging module. Among them, the merged rule data includes at least one of a first rule, a second rule, and a third rule. The first rule is a rule generated by merging the policy rules corresponding to the same port of multiple deployment units. The second rule is a rule set obtained by merging multiple policy rules applied to the same deployment unit into the same batch operation. The third rule is the policy rule that has not been merged in the policy rule data. The device can reduce the creation and update times of policy rules, reduce the competition between execution locks, improve the speed and efficiency of rule distribution, and shorten the overall latency of rule distribution by merging and distributing the update policy mechanism to merge rules with the same content and merge rules for the same application deployment unit.

[0108] It should be noted that for other corresponding descriptions of each functional unit involved in the IPBlock rule distribution device provided in the embodiment of the present application, reference can be made to the corresponding descriptions in the IPBlock rule distribution method provided in the above embodiments, and details are not described herein again.

[0109] As Figure 10 shown, an embodiment of the present application also provides a computer device, which may specifically be a personal computer, a server, a network device, etc. The computer device includes a bus, a processor, a memory, and a communication interface, and may further include an input / output interface and a display device. Among them, 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, 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 database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the steps in the method embodiments are implemented.

[0110] Those skilled in the art can understand that the structure of the above computer device is only a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0111] In one embodiment, a computer-readable storage medium is further provided. The computer-readable storage medium may be non-volatile or volatile, and a computer program is stored thereon. When the computer program is executed by a processor, the steps in the foregoing method embodiments are implemented.

[0112] In one embodiment, a computer program product is further provided, including a computer program. When the computer program is executed by a processor, the steps in the foregoing method embodiments are implemented.

[0113] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0114] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the foregoing embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it may include the processes of the foregoing method embodiments.

[0115] Among them, any reference to a memory, database, or other medium used in the embodiments provided in this application may include at least one of non-volatile and volatile memories. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc.

[0116] Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0117] In each of the embodiments provided in the present application, the database involved may include at least one of a relational database and a non-relational database. The non-relational database may include a distributed database based on blockchain, etc., without limitation. In each of the embodiments provided in the present application, the processor involved may be a general-purpose processor, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without limitation.

[0118] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0119] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A method for issuing IPBlock rules, characterized in that, The method includes: Obtaining policy rule data to be issued, where the policy rule data includes a policy rule and application deployment unit information of the policy rule; Merging the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, where the merged rule data includes at least one of a first rule, a second rule, and a third rule; the first rule is a rule generated by merging policy rules corresponding to the same port of multiple deployment units; the second rule is a set of rules obtained by merging multiple policy rules applied to the same deployment unit into the same batch operation; the third rule is a policy rule in the policy rule data that has not been merged; Applying the merged rule data to a target deployment unit.

2. The method according to claim 1, characterized in that, Obtaining policy rule data to be issued includes: Creating a policy rule in response to a policy issuance instruction; Searching for associated deployment units of the policy rule; Extracting application deployment unit information of the associated deployment units, where the application deployment unit information includes an application deployment unit IP and an application port; Establishing an association relationship between the policy rule and the application deployment unit information to generate the policy rule data.

3. The method according to claim 1, characterized in that, Merging the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data includes: Reading multiple policy rules from the policy rule data; Identifying the rule content of the policy rules; Determining policy rules to be merged among the multiple policy rules according to the rule content, where the policy rules to be merged have the same rule content; Merging multiple policy rules to be merged into one policy rule to generate the first rule.

4. The method according to claim 3, wherein The method further includes: Reading application deployment unit information of multiple policy rules to be merged; Generating a deployment unit set according to the multiple application deployment unit information; Establishing an association relationship between the deployment unit set and the first rule to generate the merged rule data including the first rule.

5. The method according to claim 1, wherein Merging the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data includes: Reading the application deployment unit information of the policy rules from the policy rule data, where the application deployment unit information includes an application port and / or an application deployment unit IP; Extracting multiple same-batch policy rules according to the application deployment unit information, where the multiple same-batch policy rules have the application deployment unit information characterizing the same deployment unit; Merging the multiple same-batch policy rules into the same policy issuance task to generate the second rule.

6. The method according to claim 1, wherein Applying the merged rule data to a target deployment unit includes: Determining a target deployment unit according to the merged rule data, where the target deployment unit includes a deployment unit in the deployment unit set corresponding to the first rule, and / or, a deployment unit corresponding to the second rule, and / or, a deployment unit corresponding to the third rule; Issuing the merged rule data to the target deployment unit; Obtain the total number of rules included in the merged rule data, where the total number of rules is the sum of the number of the first rules, the number of the second rules, and the number of the third rules; Invoke an execution lock according to the total number of rules. The execution lock is a lock mechanism set at the entrance of the application programming interface. The execution lock is obtained by refining the global lock granularity from the key-value pair set level to the dimension of the deployment unit. The number of invocations of the execution lock is equal to the total number of rules; Apply the merged rule data to the target deployment unit based on the execution lock.

7. The method according to claim 1, characterized in that Applying the merged rule data to the target deployment unit includes: Create a rule distribution task based on the merged rule data; Obtain the number of coroutines of the multi-core processor corresponding to the target deployment unit; Divide the rule distribution task into multiple subtasks according to the number of coroutines. The number of subtasks is an integer multiple of the number of coroutines; Send the merged rule data to the target deployment unit through the multiple subtasks.

8. An IPBlock rule distribution device, characterized in that, The device includes: A rule acquisition module, configured to acquire policy rule data to be distributed, where the policy rule data includes policy rules and application deployment unit information of the policy rules; A rule merging module, configured to merge the policy rules in the policy rule data according to the application deployment unit information to generate merged rule data, where the merged rule data includes at least one of the first rule, the second rule, and the third rule. The first rule is a rule generated by merging the policy rules corresponding to the same port of multiple deployment units. The second rule is a rule set that merges multiple policy rules applied to the same deployment unit into the same batch operation. The third rule is the policy rule in the policy rule data that has not been merged; A rule application module, configured to apply the merged rule data to the target deployment unit.

9. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

10. A storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 7.

Images