CN115967662A

CN115967662A - Method, system, equipment and storage medium for realizing three-layer network intercommunication

Info

Publication number: CN115967662A
Application number: CN202211411343.8A
Authority: CN
Inventors: 杨乐乐
Original assignee: Jinan Inspur Data Technology Co Ltd
Current assignee: Jinan Inspur Data Technology Co Ltd
Priority date: 2022-11-11
Filing date: 2022-11-11
Publication date: 2023-04-14

Abstract

The embodiment of the application provides a method, a system, equipment and a storage medium for realizing three-layer network intercommunication, which are used for solving the technical problem that the existing test scheme of a two-layer network cannot meet the actual use scene. The method comprises the following steps: deploying components of a MetalLB load balancer based on a Kubernets tool; acquiring resources based on the deployed components of the MetalLB load balancer, adding the resources into a list of a message queue, and monitoring the change condition of the resources in real time; the neighbor relation of BGP is established at the exchange side to realize the route dynamic notification. This application just can realize k8s pipe soft platform's three-layer network intercommunication through only needing the plug-in components installation through the pipe soft platform, saves operating time. The network verification of the software management platform is not only limited to a two-Layer network connection mode in a Layer2 mode, and a Speaker component establishes a BGP neighbor relation at the switch side to realize the routing dynamic notification in the BGP mode so as to achieve the purpose of three-Layer network intercommunication.

Description

Method, system, equipment and storage medium for realizing three-layer network intercommunication

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, a system, a device, and a storage medium for implementing three-layer network interworking.

Background

In the current k8s management platform, a network is a test scenario based on a Layer2 mode, and only the network intercommunication situation of pod in the same network segment can be tested in the Layer2 mode, for example: in this scenario, a pod is created, and if different pods are allocated to different nodes, the pods cannot be directly accessed.

If the actual usage scenario is a network planned by a user and the network segments relate to different network ranges, the existing test scheme cannot meet the actual usage scenario, so that a method for three-layer network intercommunication based on a container MetalLB plug-in is urgently needed to be introduced.

Disclosure of Invention

The embodiment of the application provides a method, a system, equipment and a storage medium for realizing three-layer network intercommunication, which are used for solving the technical problem that the existing test scheme of a two-layer network cannot meet the actual use scene.

In one aspect, an embodiment of the present application provides a method for implementing three-layer network interworking, where the method includes:

deploying components of a MetalLB load balancer based on a Kubernets tool;

acquiring resources based on the deployed components of the MetalLB load balancer, adding the resources into a list of a message queue, and monitoring the change condition of the resources in real time;

the neighbor relation of BGP is established at the exchange side to realize the route dynamic notification.

In an implementation manner of the present application, the deploying components of the MetalLB load balancer based on the kubernets tool specifically includes:

deploying a Controller component of a MetalLB load balancer based on a Kubernets tool;

the Speaker component of the MetalLB load balancer is deployed based on the Kubernets tool.

In an implementation manner of the present application, the acquiring a resource based on a deployed component of the MetalLB load balancer, adding the resource to a list of a message queue, and monitoring a change condition of the resource in real time specifically includes:

acquiring the change condition of service resources;

calling a function to distribute an external IP address to the load balancing service;

and detecting cluster nodes, and writing node information into the protocol to monitor data and announce the data to the outside.

In an implementation manner of the present application, the obtaining a change condition of the service resource specifically includes:

when the change of the service resources is sensed, the service name is used as a keyword, and the service details are obtained from the apiServer;

and if the service resources do not exist and the service type is not load balancing, executing load balancing deleting processing and deleting the external IP address distribution record.

In one implementation of the present application, the method further comprises:

if the service resource exists and the service type is load balancing, whether an external IP address exists in a load balancing field is inquired;

if the external IP address exists, calling an AssignIPs function, recording related information of the external IP address, and determining whether an address pool exists or not;

and if the address pool exists, executing a service updating process.

In an implementation manner of the present application, the detecting a cluster node and writing node information into a protocol to monitor data and advertise to the outside specifically includes:

generating an FRR configuration file according to the FRR configuration template and triggering the FRR to load configuration;

implementing BGP neighbor establishment based on the FRR load configuration;

and acquiring the state information of the service, and realizing the dynamic notification of the route based on FRR BGP.

In one implementation of the present application, the method further comprises:

determining whether the mode of the Speaker component is a Layer2 mode;

if yes, scanning all interfaces on the host machine and filtering the interfaces;

and then a new response value is created on the interface, and the ARP/NDP external notification is realized.

On the other hand, an embodiment of the present application further provides a system for implementing three-layer network interworking, where the system includes:

the device comprises a component deployment unit, a component selection unit and a component selection unit, wherein the component deployment unit is used for deploying components of the MetalLB load balancer based on a Kubernets tool;

the monitoring unit is used for acquiring resources and adding the resources into a list of a message queue based on the deployed components of the MetalLB load balancer, and monitoring the change condition of the resources in real time;

and the control unit is used for establishing a neighbor relation of BGP at the switch side so as to realize the dynamic notification of the route.

In addition, an embodiment of the present application further provides an apparatus for implementing three-layer network interworking, where the apparatus includes:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to:

deploying components of a MetalLB load balancer based on a Kubernets tool;

the neighbor relation of BGP is established at the exchanger side to realize the dynamic notification of the route.

Finally, an embodiment of the present application further provides a non-volatile computer storage medium for implementing three-layer network interworking, where the non-volatile computer storage medium stores computer-executable instructions, and the computer-executable instructions are set to:

deploying components of a MetalLB load balancer based on a Kubernets tool;

The method, the system, the equipment and the storage medium for realizing the intercommunication of the three-layer network can realize the intercommunication of the three-layer network of the k8s tube soft platform only by the installation of the plug-in of the tube soft platform, thereby saving the operation time. The network verification of the soft platform is not only limited to a two-Layer network connection mode in a Layer2 mode, and three-Layer network intercommunication can be realized. The method for realizing three-layer network intercommunication provided by the embodiment of the application establishes the resource monitoring coroutine through the Controller component, and the main coroutine circularly acquires data from the queue and calls a specific processing method according to a specific resource type. By establishing the neighbor relation of BGP at the exchange side through the Speaker component, the dynamic notification of the route in the BGP mode is realized, so that the purpose of three-layer network intercommunication is achieved, large-scale network information access can be carried, and the operation is convenient and fast.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a flowchart of a method for implementing three-layer network interworking provided in an embodiment of the present application;

fig. 2 is a diagram of a system configured to implement three-layer network interworking provided in an embodiment of the present application;

fig. 3 is a schematic diagram of an apparatus for implementing three-layer network interworking provided in the embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The two-layer network structure forms are a core layer and an access layer, the operation is simple, and the exchanger forwards the data packet according to the MAC address table. If yes, forwarding, if no, flooding, and broadcasting and sending the data packet to all ports, if the intended terminal receives the response, the switch can add the MAC address into the address table, which is the process of the switch for setting up the MAC address. However, such frequent broadcasting of data packets with unknown MAC policies results in a huge network storm formed in a large-scale network architecture, which greatly limits the expansion of the two-layer network design, and therefore the networking of the two-layer network can be very limited, and therefore, the two-layer network is generally only used for establishing a small local area network.

Unlike a two-tier network, a three-tier network structure can be populated with large networks. The core layer is a supporting ridge and a data transmission channel of the whole network, and the importance is self-evident. Therefore, in the whole three-layer network structure, the requirement of the core layer device is the highest, and a high-performance data redundancy transit device and a load balancing device for preventing overload must be equipped so as to reduce the data volume carried by each core layer switch. The convergence layer is a core layer of the connectivity network and an application layer of each access layer, and serves as a medium transmission between the two layers. The converging layer should have the following function: implement security functions (VLAN differentiation and ACL configuration), workgroup integrity access functions, virtual network filtering functions. Therefore, the convergence layer switch device should adopt a three-layer switch. The object oriented access layer is the end client, which is provided with access functionality.

In the current k8s management platform, a network is a test scenario based on a Layer2 mode, and only the same network segment can be tested in the Layer2 mode, and the network intercommunication situation of pod is as follows, for example: in this scenario, a pod is created, and if different pods are allocated to different nodes, the pods cannot be directly accessed.

If the actual usage scenario is a network planned by a user and the network segments relate to different network ranges, the existing test scheme cannot meet the actual usage scenario, so that a method for three-layer network intercommunication based on a container MetalLB plug-in is urgently needed to be introduced. MetalLB is a load balancer implemented for bare cell Kubernets cluster, using the standard routing protocol ARP or BGP. Kubernets authorities do not provide an implementation of a network load balancer (LoadBalancer type of service) for bare metal clusters. Each cloud vendor (GCP, AWS, azure \8230;), has a corresponding implementation, but must run on its own cloud environment to be used, and if not on a supported IaaS platform (GCP, AWS, azure \8230;), the load balancer will remain pending indefinitely upon creation.

Metallb will run in Kubernets, monitor the change of service objects, and once a new LoadBanancer service is perceived to run and there is no applicable load balancer, it will complete two parts of work: and address allocation, wherein a user needs to provide an address pool in configuration, and Metallb selects an address to allocate to a service. And (4) address broadcasting, wherein the Metalbe broadcasts the address in a two-layer (ARP/NDP) or BGP mode according to different configurations.

After MetalLB is started in the kubernets cluster, metalLB does not generate IP by virtue of vacancy. Therefore, the user is required to configure the IP address pool and the broadcasting method used by the corresponding address pool. The MetalB can respond to the IP allocation and the IP recovery when the state of the Service changes, wherein the change of the state comprises the addition, the deletion and the modification of the Service. The source of the IP mainly has two modes, namely a public network IP or a local area network IP and a virtual IP. If the local area network has abundant IP or IP segments are available from cloud vendors, approach one may be used. The broadcast in the first mode is realized by ARP and NDP in layer2 mode. If cost considerations dictate, approach two can be used without conflicting IP segments with the network. The second mode needs to support a BGP network, or a router supports a BGP routing protocol.

The technical solutions proposed in the embodiments of the present application are explained in detail below with reference to the accompanying drawings.

Fig. 1 is a flowchart of a method for implementing three-layer network interworking according to an embodiment of the present application. As shown in fig. 1, the method mainly comprises the following steps:

step 101, deploying components of a MetalLB load balancer based on a Kubernets tool.

In the embodiment of the application, a Controller component of a MetalLB load balancer is deployed based on a Kubernets tool; the Speaker component of the MetalLB load balancer is deployed based on the Kubernets tool. A testing scene of cross three-layer network intercommunication on a tube soft platform is realized through a Controller component and a Speaker component.

And 102, acquiring resources based on the deployed components of the MetalLB load balancer, adding the resources into a list of a message queue, and monitoring the change condition of the resources in real time.

In the embodiment of the application, after the controller component of the MetalLB is started, a resource monitoring protocol such as service and resource configuration is run, and a message queue monitors resources such as service, resource configuration and a port and adds the acquired resources to a list of the message queue. The main coroutine circularly obtains data from the queue and calls a specific processing method according to a specific resource type.

And when the Controller component senses the change of the service resources, the Controller component finally calls a function to realize the allocation of the external IP address to the load balancing service. The main processing logic is as follows:

when the change of the service resources is sensed, the service name is used as a keyword, service details are obtained from the apiServer, if the service resources do not exist or the type of the service is not load balancing, load balancing deleting processing is executed, and external IP address distribution records are deleted; the operations that trigger this flow may be: deleting load balancing type services; the service type is modified from load balancing to other types.

If the service exists and the type is load balancing, whether the external IP exists in the load balancing field is inquired. And if the external IP exists, calling an assignIPs function, and recording external IP related information of the service. And judging whether operations such as specifying an address pool, specifying a specific IP address, changing the service IP type and the like exist, and entering a service updating process if the operations exist. The relevant operations that trigger this flow may be: changing a service field to cause the switching of a service single stack and a service double stack; appointing an address pool by annotating an external IP service to be allocated, and reallocating IP; appointing specific IP c for the service which is already allocated with the external-IP through an annotation mode; modify fields such as service disconnect; the Controller component restarts or reschedules abnormally; after the external IP address is allocated to the service, the allocation IP record allocation information is called, but the record information is lost after the Controller component is abnormally restarted or rescheduled.

In the embodiment of the present application, when creating the load balancing service, the external IP address may be allocated in three ways. Designating address pool assignments by annotations; specifying specific IP address allocation by annotating meta. Univorse. Tf/load balancing IPs; and selecting an address pool meeting the conditions from the configuration address pools for allocation in a default allocation mode.

In the embodiment of the application, the MemberList module is used as a Speaker cluster management module, and the functions of Speaker node discovery, node failure detection and the like are realized. When the cluster node failure is detected, the node information is written into the protocol to monitor the data, if the data exists, all the service information is added into the message queue, and a full-volume service external notification is triggered.

Step 103, establishing a neighbor relation of BGP at the switch side to realize dynamic route notification.

In the embodiment of the present application, the Speaker module has two main modes: BGP mode and Layer2 mode. The FRR module is used as a Speaker BGP back end to realize the functions of BGP neighbor establishment, route announcement and the like. When the Speaker acquires the service configuration resources, the Speaker generates an FRR configuration file according to the FRR configuration template and triggers an FRR loading configuration action, so that functions such as BGP neighbor establishment are realized. After the Speaker acquires the service information, the state information of the service is acquired, and the FRR BGP realizes the dynamic notification of the route.

The ARP/NDP module is used as the back end of the Gratuitous ARP/NDP to realize the function of externally announcing the ARP/NDP. When executing the function, if the Layer2 mode is the Layer2 mode, all interfaces on the host machine are scanned and filtered (the interface up can send ARP/NDP). And then a new response value is established on the interface, and ARP/NDP external notification is realized.

In the embodiment of the application, the system needs to be verified after configuration is completed, the use environment of a verification scene is the isolation of a management network and a service network, and a client node simulates a client outside a cluster to initiate access to a load balancing type service. The service supports dual stacks, i.e. ipv4 and ipv6 simultaneously. The Metallb-Speaker establishes a BGP neighbor relation with an external cluster switch through a service network, a management network supports an IPv4 single stack, and a network node: named net, and establishes connection with the cluster control node through the management network. In terms of RR nodes, some nodes act as route reflectors and are configured to build a complete mesh between them. The other nodes are then configured to peer with a subset (typically redundant, typically 2) of these route reflectors, thereby reducing the total number of BGP peering connections compared to the full mesh.

After the IP in the IP pool is allocated, the allocated IP needs to be notified that the network access IP outside the cluster is reachable. In MetalB, standard routing protocol implementations are used, ARP, NDP, or BGP, respectively. Wherein ARP is responsible for IPv4 broadcasting and NDP is responsible for IPv6 broadcasting. MetalLB uses two modes, layer2 and BGP. In the Layer2 mode, the relation between the host and the service is ensured in the cluster, and the IP accessibility is realized through a standard ARP or NDP protocol. In Layer2 mode, leader is elected as the host for the exposed service by all hosts in the cluster. From the network perspective, it is equivalent to having multiple IPs on this host. During the operation of the system, if the node is lost or fails, leader node election is automatically initiated, and the node IP is routed to a new node. Thus in Layer2 mode, the function is similar to that of keepalived. But keepalived employs a vrrp protocol implementation. Election of a node is provided by memberlist engineering. In Layer2 mode, a Leader node is elected from all nodes as an exposed node. Resulting in the bandwidth of the entire cluster to expose services to the outside depending on the bandwidth of the Leader node. Some operating systems have a cache problem, and finally cannot be quickly switched to a new Leader node host when a Leader node fails, so that a short service request failure condition occurs.

According to the method for realizing the three-layer network intercommunication, the three-layer network intercommunication of the k8s tube soft platform can be realized only by installing the plug-in of the tube soft platform, and the operation time is saved. The network verification of the software management platform is not only limited to the two-Layer network connection mode in the Layer2 mode, and three-Layer network intercommunication can be realized. The method for realizing three-layer network intercommunication provided by the embodiment of the application establishes the resource monitoring coroutine through the Controller component, and the master coroutine circularly acquires data from the queue and calls a specific processing method according to a specific resource type. By establishing the neighbor relation of BGP at the exchange side through the Speaker component, the dynamic notification of the route in the BGP mode is realized, so that the purpose of three-layer network intercommunication is achieved, large-scale network information access can be carried, and the operation is convenient and fast.

The above is a method for implementing three-layer network interworking provided in the embodiment of the present application, and based on the same inventive concept, the embodiment of the present application further provides a system for implementing three-layer network interworking, fig. 2 is a composition diagram of the system for implementing three-layer network interworking provided in the embodiment of the present application, and as shown in fig. 2, the system mainly includes:

the component deploying unit 201 is used for deploying components of the MetalLB load balancer based on a Kubernets tool;

a monitoring unit 202, configured to obtain a resource based on a deployed component of the MetalLB load balancer, add the resource to a list of a message queue, and monitor a change condition of the resource in real time;

the control unit 203 is configured to establish a neighbor relationship of BGP at the switch side to implement dynamic route advertisement.

In the embodiment of the present application, the component deployment unit 201 mainly executes: a Speaker component and a Controller component of a MetalLB load balancer are deployed based on a Kubernets tool.

In the embodiment of the present application, the listening unit 202 mainly performs: after the controller component of MetalLB is started, it will run the resource monitoring protocol such as service, resource allocation, etc., and the message queue monitors the resources such as service, resource allocation, port, etc., and adds the acquired resources into the list of message queue. The main coroutine circularly obtains data from the queue and calls a specific processing method according to a specific resource type.

If the service exists and the type is load balancing, whether the external IP exists in the load balancing field is inquired. And if the external IP exists, calling an assignIPs function, and recording external IP related information of the service. And judging whether operations such as specifying an address pool, specifying a specific IP address, changing the service IP type and the like exist, and entering a service updating process if the operations exist. The relevant operations that trigger this flow may be: changing a service field to cause the switching of a service single stack and a service double stack; appointing an address pool by an annotation mode for allocating external IP services, and reallocating IP; appointing a specific IP c for the service which is already distributed with the external IP through an annotation mode; modify fields such as service disconnect; the Controller component restarts or reschedules abnormally; after the external IP address is allocated to the service, the allocation IP record allocation information is called, but the record information is lost after the Controller component is abnormally restarted or rescheduled.

In this embodiment of the present application, the listening unit 202 is further configured to: when the Speaker acquires the service configuration resources, the Speaker generates an FRR configuration file according to the FRR configuration template and triggers an FRR loading configuration action, so that functions such as BGP neighbor establishment are realized. After the Speaker acquires the service information, the state information of the service is acquired, and the FRR BGP realizes the dynamic notification of the route. The ARP/NDP module is used as the back end of the Gratuitous ARP/NDP to realize the function of externally announcing the ARP/NDP. When executing the function, if the Layer2 mode is the host, all interfaces on the host are scanned and filtered (interface up, ARP/NDP can be sent). And then a new response value is established on the interface, and ARP/NDP external notification is realized.

In the embodiment of the present application, the control unit 203 includes a verification subunit, and the verification subunit performs: and after the configuration is completed, verifying the system. The use environment of the verification scenario is that the management network is isolated from the service network, and the client node simulates a client outside the cluster to initiate access to a load balancing type service. The service supports dual stacks, i.e. ipv4 and ipv6 are supported simultaneously. The Metallb-Speaker establishes a BGP neighbor relation with an external cluster switch through a service network, a management network supports an IPv4 single stack, and a network node: named net, establishes connection with the cluster control node through the management network. In terms of RR nodes, some nodes act as route reflectors and are configured to build a complete mesh between them. The other nodes are then configured to peer with a subset (typically redundant, typically 2) of these route reflectors, thereby reducing the total number of BGP peering connections compared to the full mesh.

The system for realizing intercommunication of the three-layer network provided by the embodiment of the application only needs to install the plug-in of the tube soft platform, so that intercommunication of the three-layer network of the k8s tube soft platform can be realized, and the operation time is saved. The network verification of the soft platform is not only limited to a two-Layer network connection mode in a Layer2 mode, and three-Layer network intercommunication can be realized. The method for realizing three-layer network intercommunication provided by the embodiment of the application establishes the resource monitoring coroutine through the Controller component, and the main coroutine circularly acquires data from the queue and calls a specific processing method according to a specific resource type. By establishing the neighbor relation of BGP at the exchange side through the Speaker component, the dynamic notification of the route in the BGP mode is realized, so that the purpose of three-layer network intercommunication is achieved, large-scale network information access can be carried, and the operation is convenient and fast.

The above is a system for implementing three-layer network interworking provided in the embodiment of the present application, and based on the same inventive concept, an embodiment of the present application further provides an apparatus for implementing three-layer network interworking, fig. 3 is a schematic diagram of an apparatus for implementing three-layer network interworking provided in the embodiment of the present application, and as shown in fig. 3, the apparatus mainly includes: at least one processor 301; and a memory 302 communicatively coupled to the at least one processor; wherein the memory 302 stores instructions executable by the at least one processor 301, the instructions being executable by the at least one processor 301 to enable the at least one processor 301 to: deploying components of a MetalLB load balancer based on a Kubernets tool;

In addition, an embodiment of the present application further provides a non-volatile computer storage medium for implementing three-layer network interworking, where the non-volatile computer storage medium stores computer-executable instructions, and the computer-executable instructions are configured to: deploying components of a MetalLB load balancer based on a Kubernets tool;

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for implementing three-layer network interworking, the method comprising:

deploying components of a MetalLB load balancer based on a Kubernets tool;

2. The method for implementing three-layer network interworking according to claim 1, wherein the deployment of the components of the MetalLB load balancer based on the kubernets tool specifically includes:

3. The method of claim 1, wherein the method for implementing three-layer network interworking based on the deployed component of the MetalB load balancer obtains a resource and adds the resource to a list of message queues, and monitors the change condition of the resource in real time, specifically:

acquiring the change condition of service resources;

4. The method according to claim 3, wherein the change of the service resource acquisition specifically includes:

when the change of service resources is sensed, the service name is used as a keyword, and service details are obtained from the apiServer;

5. The method of claim 4, wherein the method further comprises:

and if the address pool exists, executing a service updating process.

6. The method according to claim 3, wherein the detecting a cluster node and writing node information into a protocol to monitor data and advertise to the outside specifically comprises:

implementing BGP neighbor establishment based on the FRR loading configuration;

7. The method of claim 6, wherein the method further comprises:

determining whether the mode of the Speaker component is a Layer2 mode;

and then a new response value is established on the interface, and ARP/NDP external notification is realized.

8. A system for implementing three-layer network interworking, the system comprising:

the component deployment unit is used for deploying components of the MetalLB load balancer based on a Kubernets tool;

and the control unit is used for establishing a neighbor relation of BGP at the exchange side so as to realize dynamic route notification.

9. An apparatus for implementing three-layer network interworking, the apparatus comprising:

at least one processor; and (c) a second step of,

deploying components of a MetalLB load balancer based on a Kubernets tool;

10. A non-transitory computer storage medium for implementing three-tier network interworking, the medium storing computer-executable instructions configured to:

deploying components of a MetalLB load balancer based on a Kubernets tool;