A BGP support method and system in a cloud native network environment

Abstract

The present invention discloses a BGP support method and system in a cloud native network environment. The BGP support method in a cloud native network environment of the present invention includes deploying a BGP routing client and a BGP routing server in each node in the cloud native network environment, and completing the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client, and notifying the BGP routing server to update the route to an external router; monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing strategy at the same time, and starting a virtual routing server to announce the route to an external router. The present invention aims to announce the container network dedicated subnet PodCIDR of the cloud native network to an external router through the BGP protocol to realize BGP support in a cloud native network environment.

Description

Technical Field

[0001] The present invention relates to a cloud native network configuration technology in the field of computer networks, and in particular to a BGP support method and system in a cloud native network environment. Background Art

[0002] In a cloud-native network environment, the BGP protocol (Border Gateway Protocol) can be used to perform routing exchanges on the container network of each node. The BGP protocol is supported in the cloud-native network environment in the following ways:

[0003] Method 1: Use the software BIRD to configure BGP routing. BIRD is a full-featured routing daemon that supports many different routing protocols, including BGP. Container network routing exchanges can be performed through BIRD. There are several main disadvantages to using the software BIRD for BGP routing: 1. BIRD is a third-party software that needs to be installed separately on the operating system. The installation method of BIRD on different OS (operating systems) is different, which brings complexity in use; 2. You need to be familiar with the configuration of BIRD, and you need to manually restart BIRD every time you modify the BIRD configuration, which is inconvenient in use and maintenance; 3. BIRD needs to obtain the container network dedicated subnet PodCIDR, but the container network dedicated subnet PodCIDR is automatically generated, and the information of the container network dedicated subnet PodCIDR can only be written into the BIRD configuration file through manual query. It is cumbersome and complicated to use the BIRD software directly in a cloud-native network environment.

[0004] Method 2: Rely on the built-in BGP support of third-party CNI plug-ins. Currently, the mainstream CNI plug-ins are mainly Calico and Cilium, both of which support BGP. However, the support of third-party CNI plug-ins for BGP has the following disadvantages: 1. The degree of support for BGP is different. Calico implements BGP support based on BIRD, and the underlying layer depends on the degree of BGP implementation of BIRD. Some advanced BGP features cannot be supported by Calico if BIRD does not implement support. In addition, BIRD is an independently maintained software and is not controlled in terms of adding new features. Cilium's support for BGP is related to the IPAM mode. In some IPAM modes, container network routing announcements are not yet supported; 2. Third-party CNI plug-ins can only support BGP within the scope of their own plug-ins. Calico and Cilium have different BGP configurations and usage methods. When switching from one CNI plug-in to another, you need to rewrite the BGP configuration and be familiar with the configuration rules. In a complex environment, two CNI plug-ins may be used at the same time, which will result in two different BGP configurations and usage methods in the same cluster environment. When the cluster environment changes, it will also cause complexity in use and maintenance. Summary of the invention

[0005] Technical problem to be solved by the present invention: In view of the above-mentioned problems in the prior art, a BGP support method and system in a cloud native network environment are provided. The present invention aims to announce the PodCIDR of the cloud native network to an external router through the BGP protocol to realize BGP support in the cloud native network environment.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0007] A BGP support method in a cloud native network environment includes deploying a BGP routing client and a BGP routing server on each node in the cloud native network environment, and completing the acquisition, conversion and monitoring of a container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client, and notifying the BGP routing server to update the route to an external router; monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy at the same time, and starting a virtual routing server to announce the route to the external router.

[0008] Optionally, the BGP routing client is composed of one or more routing plug-ins, and the routing plug-ins are container network interface plug-ins corresponding to different containers in the cloud native network environment, which are used to convert the corresponding container network interface resources into a unified resource type to complete the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network.

[0009] Optionally, the container network interface plug-in is a Calico plug-in or a Cilium plug-in.

[0010] Optionally, the acquisition, conversion, and monitoring of the container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client includes:

[0011] Step 101, start the BGP routing client and initialize it;

[0012] Step 102, determining the type of container network interface plug-in provided by the BGP routing client;

[0013] Step 103, container network resource type conversion. For the various container network interface plug-ins provided by the BGP routing client, use a unified interface to convert the network resources containing the container network dedicated subnet PodCIDR read by the container network interface plug-in, generate a unified network resource representation, and write the unified network resource representation into the specified configuration database etcd for recording, so as to facilitate recovery from storage after the BGP routing client is restarted;

[0014] Step 104, start a controller on the BGP routing client, monitor the changes of the container network interface network resources through the controller, and when the container network dedicated subnet PodCIDR in the container network interface network resources is updated, the controller triggers the acquisition of the container network dedicated subnet PodCIDR resources, and then converts them into a unified network resource representation for writing, and updates the records in the specified configuration database etcd;

[0015] Step 105: Send a container network dedicated subnet PodCIDR change signal to the BGP routing server to trigger the BGP routing server's response processing mechanism to the container network dedicated subnet PodCIDR change.

[0016] Optionally, starting the BGP routing client and initializing it in step 101 includes: starting the BGP routing client together with the container cluster management system K8s in the cloud native network environment, and the initialization refers to the BGP routing client restoring the recorded container network dedicated subnet PodCIDR from the specified configuration database etcd when it is started or restarted.

[0017] Optionally, step 102 includes: the BGP routing client determines the type of container network interface plug-in used by the container cluster management system K8s by searching the sock file information and process information of the container network interface plug-in. Each routing plug-in on the BGP routing client corresponds to a specific container network interface plug-in type.

[0018] Optionally, the unified network resource representation in step 103 includes a container network dedicated subnet PodCIDR, node information, an autonomous system number AS, and a routing ID.

[0019] Optionally, monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy, and starting the virtual routing server to announce the route to the external router includes:

[0020] Step 201, after startup, the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client. The BGP routing server also monitors the routing policy resources, and writes the monitored routing policy resources in the form of configuration files. The routing policy resources include the address of the peer router, the autonomous system number AS, the routing announcement method, the restart method, and the BGP configuration information. After receiving the routing policy resources for the first time, the BGP routing server starts a virtual routing server, converts the container network dedicated subnet PodCIDR written and converted by the BGP routing client into the routing written virtual routing server, and the virtual routing server completes the routing announcement of the external router through the underlying interface call; if the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client or the configuration of the routing policy resources changes, jump to the next step;

[0021] Step 202: If a container network dedicated subnet PodCIDR change signal sent by the BGP routing client is monitored, the BGP routing client is made to update the container network dedicated subnet PodCIDR information in a full update manner. Each time the container network dedicated subnet PodCIDR changes, the BGP routing client recalculates the entire acquired routing information; if a change in the configuration of the routing policy resource is monitored, the BGP routing client is made to write the new routing policy resource to the virtual routing server through the controller;

[0022] Step 203: The virtual routing server calls the underlying interface to announce the routing information to the external router via the BGP protocol.

[0023] In addition, the present invention also provides a BGP support system in a cloud-native network environment, comprising a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the BGP support method in the cloud-native network environment.

[0024] In addition, the present invention also provides a computer-readable storage medium, in which a computer program is stored, and the computer program is used to be programmed or configured by a microprocessor to execute the BGP support method in the cloud native network environment.

[0025] Compared with the prior art, the present invention mainly has the following advantages: the BGP support method in the cloud native network environment of the present invention includes deploying a BGP routing client and a BGP routing server on each node in the cloud native network environment, and completing the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client, and notifying the BGP routing server to update the route to the external router; monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy at the same time, and starting the virtual routing server to announce the route to the external router, so that the container network dedicated subnet PodCIDR of the cloud native network can be announced to the external router through the BGP protocol to realize BGP support in the cloud native network environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] FIG1 is a schematic diagram of a basic flow chart of a method according to an embodiment of the present invention.

[0027] FIG. 2 is a flowchart of a BGP routing client in an embodiment of the present invention.

[0028] FIG. 3 is a flowchart of the BGP routing service end in an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The BGP support method in the cloud native network environment of the present invention is applicable to the cloud native network environment, and is aimed at the routing declaration and management of the container network, and the effect achieved is to declare the container network dedicated subnet PodCIDR of the cloud native network to the external router through the BGP protocol. Figure 1 As shown, the BGP support method in the cloud native network environment of this embodiment includes deploying a BGP routing client and a BGP routing server on each node in the cloud native network environment, and completing the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client, and notifying the BGP routing server to update the route to the external router; monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy at the same time, and starting the virtual routing server to announce the route to the external router.

[0030] In this embodiment, the BGP routing client is composed of one or more routing plug-ins, and the routing plug-ins are container network interface plug-ins corresponding to different containers in the cloud native network environment, which are used to convert the corresponding container network interface resources into a unified resource type to complete the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network. The container network interface plug-in can be a Calico plug-in or a Cilium plug-in. In addition, other plug-ins can also be used as needed.

[0031] This embodiment designs a method for obtaining cloud-native container network routes and announcing routes to the outside world, specifically including the design of two parts: a BGP routing client and a BGP routing server.

[0032] The BGP routing client consists of a series of routing plug-ins. Routing plug-ins correspond to different container network interface plug-ins (CNI plug-ins). Currently, commonly used CNI plug-ins include Calico and Cilium. Different CNI plug-ins use different resource types to represent different resources in the network. Different routing plug-ins are provided for specific CNIs. The function of the routing plug-in is to convert different CNI network resources into a unified resource type. Currently, only the routing of the container network is converted. The specific conversion method is to read the container network dedicated subnet PodCIDR on the node from the corresponding K8s resource through the plug-in. Since the container network dedicated subnet PodCIDR of the container network in the cloud native environment is dynamically created and changed, another function of the routing plug-in is to complete the monitoring of the changes in the container network dedicated subnet PodCIDR in the CNI.

[0033] like Figure 2 As shown, in this embodiment, the acquisition, conversion and monitoring of the dedicated subnet PodCIDR of the container network of the cloud native network by the BGP routing client include:

[0034] Step 101, start the BGP routing client and initialize it;

[0035] Step 102, determining the type of container network interface plug-in provided by the BGP routing client;

[0036] Step 103, container network resource type conversion. For the various container network interface plug-ins provided by the BGP routing client, a unified interface is used to convert the network resources containing the container network dedicated subnet PodCIDR read by the container network interface plug-in, generate a unified network resource representation, and write the unified network resource representation into the specified configuration database etcd for recording, so as to facilitate recovery from storage after the BGP routing client is restarted; the unified network resource representation in step 103 of this embodiment includes the container network dedicated subnet PodCIDR, node information, autonomous system number AS and routing ID. In addition, the unified network resource representation in step 103 can be adjusted as needed to meet the requirements of advanced BGP features;

[0037] Step 104, start a controller on the BGP routing client, monitor the changes of the container network interface network resources through the controller, and when the container network dedicated subnet PodCIDR in the container network interface network resources is updated, the controller triggers the acquisition of the container network dedicated subnet PodCIDR resources, and then converts them into a unified network resource representation for writing, and updates the records in the specified configuration database etcd;

[0038] Step 105: Send a container network dedicated subnet PodCIDR change signal to the BGP routing server to trigger the BGP routing server's response processing mechanism to the container network dedicated subnet PodCIDR change.

[0039] In step 101 of this embodiment, starting the BGP routing client and initializing it includes: starting the BGP routing client together with the container cluster management system K8s in the cloud native network environment, and the initialization means that when the BGP routing client is started or restarted, it recovers the recorded container network dedicated subnet PodCIDR from the specified configuration database etcd.

[0040] Step 102 of this embodiment includes: the BGP routing client determines the type of container network interface plug-in used by the container cluster management system K8s by searching the sock file information and process information of the container network interface plug-in. Each routing plug-in on the BGP routing client corresponds to a specific container network interface plug-in type.

[0041] The BGP routing server is mainly responsible for monitoring the client's network resources and announcing routes to the outside. When the resources of the BGP routing client change, the BGP routing server will first update the routing resource information of the BGP routing, and then announce the route to the outside. The routing announcement method and the peer configuration of the announcement are completed by the BGP routing server. The information of the peer router is passed to the server through the configuration file. The BGP routing server will start a virtual router to complete the route announcement to the peer router. The BGP routing server also monitors the routing policy. When the routing policy changes, the virtual router will update the routing information to the peer. Figure 3 As shown, in this embodiment, the BGP routing server monitors the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client, monitors the changes of the routing policy, and starts the virtual routing server to announce the route to the external router, including:

[0042] Step 201, after startup, the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client. The BGP routing server also monitors the routing policy resources, and writes the monitored routing policy resources in the form of configuration files. The routing policy resources include the address of the peer router, the autonomous system number AS, the routing announcement method, the restart method, and the BGP configuration information. After receiving the routing policy resources for the first time, the BGP routing server starts a virtual routing server, converts the container network dedicated subnet PodCIDR written and converted by the BGP routing client into the routing written virtual routing server, and the virtual routing server completes the routing announcement of the external router through the underlying interface call; if the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client or the configuration of the routing policy resources changes, jump to the next step;

[0043] Step 202: If a container network dedicated subnet PodCIDR change signal sent by the BGP routing client is monitored, the BGP routing client is made to update the container network dedicated subnet PodCIDR information in a full update manner. Each time the container network dedicated subnet PodCIDR changes, the BGP routing client recalculates the entire acquired routing information; if a change in the configuration of the routing policy resource is monitored, the BGP routing client is made to write the new routing policy resource to the virtual routing server through the controller;

[0044] Step 203: The virtual routing server calls the underlying interface to announce the routing information to the external router via the BGP protocol.

[0045] See also Figure 3It can be seen that the BGP routing server also monitors routing policy resources. The routing policy is written in the form of configuration files, mainly including the address of the peer router, AS number, routing announcement method, restart method, and BGP advanced configuration information. After receiving the routing policy for the first time, the server starts a virtual routing server. The PodCIDR written and converted by the BGP routing client is converted into a route and written to the virtual routing server. The virtual routing server completes the route announcement to the external router through the underlying interface call. The configuration of the virtual router is updated in two cases: the BGP routing client sends a container network dedicated subnet PodCIDR change signal and the routing policy configuration changes. When the container network dedicated subnet PodCIDR changes, the BGP routing client updates the container network dedicated subnet PodCIDR information in a full update manner. Every time the container network dedicated subnet PodCIDR changes, the BGP routing client recalculates the entire route information obtained. The controller of the BGP routing server also monitors the changes in the routing policy. When the routing policy changes, the controller writes the new routing policy to the virtual routing server. Finally, the virtual routing server calls the underlying interface to announce the routing information to the external router through the BGP protocol.

[0046] Compared with the prior art, the advantages of the present invention are: (1) This embodiment does not rely on a specific CNI plug-in (container network interface plug-in) to announce routing through BGP. The BGP routing client can implement different plug-ins for commonly used container network interfaces (CNIs) and can be deployed and used independently of the container network interface (CNI). (2) This embodiment performs unified type conversion for different types of container network interface (CNI) network resources, and the BGP routing policy configuration can be directly used in other cloud native network environments. (3) This embodiment does not affect the existing network environment. It can be deployed in an existing container network environment to achieve support for BGP. (4) This embodiment does not depend on whether the container network interface (CNI) has achieved support for BGP, so for container network interfaces (CNIs) that do not yet support BGP, this embodiment can also achieve support for BGP; (5) The BGP policy custom resources defined in this embodiment facilitate the introduction of other advanced BGP features.

[0047] In addition, this embodiment also provides a BGP support system in a cloud native network environment, including a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the BGP support method in the cloud native network environment. This embodiment also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, wherein the computer program is used to be programmed or configured by the microprocessor to execute the BGP support method in the cloud native network environment.

[0048] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the process Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0049] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A BGP support method in a cloud native network environment, characterized in that: This includes deploying a BGP routing client and a BGP routing server on each node in the cloud native network environment, and completing the acquisition, conversion, and monitoring of the container network dedicated subnet PodCIDR of the cloud native network through the BGP routing client, and notifying the BGP routing server to update the route to the external router; monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy, and starting the virtual routing server to announce the route to the external router; The acquisition, conversion and monitoring of the dedicated subnet PodCIDR of the container network of the cloud native network through the BGP routing client include: Step 101, start the BGP routing client and initialize it; Step 102, determining the type of container network interface plug-in provided by the BGP routing client; Step 103, container network resource type conversion, for the various container network interface plug-ins provided by the BGP routing client, use a unified interface to convert the network resources containing the container network dedicated subnet PodCIDR read by the container network interface plug-in, generate a unified network resource representation, and write the unified network resource representation into the specified configuration database etcd for recording, so as to facilitate recovery from storage after the BGP routing client is restarted; Step 104, start a controller on the BGP routing client, monitor the changes of the container network interface network resources through the controller, and when the container network dedicated subnet PodCIDR in the container network interface network resources is updated, the controller triggers the acquisition of the container network dedicated subnet PodCIDR resources, and then converts them into a unified network resource representation for writing, and updates the records in the specified configuration database etcd; Step 105: Send a container network dedicated subnet PodCIDR change signal to the BGP routing server to trigger the BGP routing server's response processing mechanism to the container network dedicated subnet PodCIDR change.

2. The BGP support method in a cloud native network environment according to claim 1, characterized in that: The BGP routing client is composed of one or more routing plug-ins, and the routing plug-ins are container network interface plug-ins corresponding to different containers in the cloud native network environment, which are used to convert the corresponding container network interface resources into a unified resource type to complete the acquisition, conversion and monitoring of the container network dedicated subnet PodCIDR of the cloud native network.

3. The BGP support method in a cloud native network environment according to claim 2, characterized in that: The container network interface plug-in is a Calico plug-in or a Cilium plug-in.

4. The BGP support method in a cloud native network environment according to claim 1, characterized in that: Starting the BGP routing client and initializing it in step 101 includes: starting the BGP routing client together with the container cluster management system K8s in the cloud native network environment, and the initialization means that when the BGP routing client is started or restarted, it recovers the recorded container network dedicated subnet PodCIDR from the specified configuration database etcd.

5. The BGP support method in a cloud native network environment according to claim 1, characterized in that: Step 102 includes: the BGP routing client determines the type of container network interface plug-in used by the container cluster management system K8s by searching the sock file information and process information of the container network interface plug-in. Each routing plug-in on the BGP routing client corresponds to a specific container network interface plug-in type.

6. The BGP support method in a cloud native network environment according to claim 1, characterized in that: The unified network resource representation in step 103 includes the container network dedicated subnet PodCIDR, node information, autonomous system number AS and routing ID.

7. The BGP support method in a cloud native network environment according to claim 3, characterized in that: The method of monitoring the changes of the container network dedicated subnet PodCIDR obtained by the BGP routing client through the BGP routing server, monitoring the changes of the routing policy, and starting the virtual routing server to announce the route to the external router includes: Step 201, after startup, the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client. The BGP routing server also monitors the routing policy resources, and writes the monitored routing policy resources in the form of configuration files. The routing policy resources include the address of the peer router, the autonomous system number AS, the routing announcement method, the restart method, and the BGP configuration information. After receiving the routing policy resources for the first time, the BGP routing server starts a virtual routing server, converts the container network dedicated subnet PodCIDR written and converted by the BGP routing client into the routing written virtual routing server, and the virtual routing server completes the routing announcement of the external router through the underlying interface call; if the BGP routing server monitors the container network dedicated subnet PodCIDR change signal sent by the BGP routing client or the configuration of the routing policy resources changes, jump to the next step; Step 202: If a container network dedicated subnet PodCIDR change signal sent by the BGP routing client is monitored, the BGP routing client is made to update the container network dedicated subnet PodCIDR information in a full update manner. Each time the container network dedicated subnet PodCIDR changes, the BGP routing client recalculates the entire acquired routing information; if a change in the configuration of the routing policy resource is monitored, the BGP routing client is made to write the new routing policy resource to the virtual routing server through the controller; Step 203: The virtual routing server calls the underlying interface to announce the routing information to the external router via the BGP protocol.

8. A BGP support system in a cloud native network environment, comprising a microprocessor and a memory connected to each other, characterized in that: The microprocessor is programmed or configured to execute the BGP support method in a cloud native network environment as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored therein, characterized in that: The computer program is used to be programmed or configured by a microprocessor to execute the BGP support method in a cloud native network environment as described in any one of claims 1 to 7.

Images