Service access method and apparatus

Abstract

The present disclosure relates to a service access method and device, which is applied to the field of container cloud cluster, and the method comprises the following steps: receiving, by a first BGP Peer device, a service access message sent by a target device based on a first routing rule, the service access message being used to indicate a second server to access a first resource IP in a target container cloud cluster, a plurality of routing rules being stored in the target device, a routing rule corresponding to a Pod IP being used to indicate that a next hop of a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, and a routing rule corresponding to a Service IP being used to indicate that a next hop of a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster; and sending, by the first BGP Peer device, the service access message to a target Pod IP corresponding to the first resource IP.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of container cloud cluster. More particularly, it relates to a service access method and device. BACKGROUND

[0002] Under the Kubernetes-based container cloud cluster, the basic running unit of the application in the Kubernetes cluster is a Pod, and the Kubernetes provides an IP address for each Pod. A single Pod can be accessed through the Pod IP in the Kubernetes cluster. Meanwhile, the Kubernetes can create a Service resource, the Service load balances to a group of Pods with the same function, and the Kubernetes also allocates an IP for each Service. The Service IP in the cluster can access the multiple Pod applications behind the Service IP, thereby realizing load balancing.

[0003] However, both the Pod IP and the Service IP are internal IP addresses allocated by the Kubernetes, which can be directly accessed from the Kubernetes cluster, but cannot be directly accessed from outside the Kubernetes cluster. At present, when accessing from outside the Kubernetes cluster, whether in the NodePort mode or in the Ingress mode, a layer of proxy needs to be added to forward to the Service IP or the Pod IP.

[0004] However, the proxy forwarding mode may cause a relatively large access delay. Therefore, the method for accessing the resources in the container cloud cluster from outside the container cloud cluster in the related art has the problem of low access efficiency. SUMMARY

[0005] In order to solve the above technical problems or at least partially solve the above technical problems, embodiments of the present application provide a service access method and device, which can improve the access efficiency of accessing the resources in the container cloud cluster from outside the container cloud cluster.

[0006] In a first aspect, an embodiment of the present application provides a service access method, applied to a first server in a target container cloud cluster, the first server comprising a first BGP Peer device, and the method comprises: receiving, by the first BGP Peer device, a service access message sent by a target device based on a first routing rule, the service access message being used to instruct a second server to access a first resource IP in the target container cloud cluster, the first resource IP being a first Pod IP or a first Service IP, the target device storing a plurality of routing rules, each routing rule corresponding to a Pod IP or corresponding to a Service IP, a routing rule corresponding to a Pod IP being used to instruct a next hop for accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, a routing rule corresponding to a Service IP being used to instruct a next hop for accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules comprising the first routing rule, the first routing rule corresponding to the first BGP Peer device, and the second server not belonging to the target container cloud cluster; and sending, by the first BGP Peer device, the service access message to a target Pod IP corresponding to the first resource IP.

[0007] In a second aspect, an embodiment of the present application provides a service access method, applied to a target device, and the method comprises: determining, from a plurality of stored routing rules, a first routing rule for accessing a first resource IP, each routing rule corresponding to a Pod IP or corresponding to a Service IP, a routing rule corresponding to a Pod IP being used to instruct a next hop for accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, a routing rule corresponding to a Service IP being used to instruct a next hop for accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, and the first routing rule corresponding to a first BGP Peer device of a first server of a target container cloud cluster; and sending, based on the first routing rule, a service access message to the first BGP Peer device, so as to enable the first BGP Peer device to send the service access message to a target Pod IP corresponding to the first resource IP, the service access message being used to instruct a second server to access the first resource IP of the target container cloud cluster, the first resource IP being a first Pod IP or a first Service IP.

[0008] In a third aspect, an embodiment of the present application provides a service access method, applied to a second server, and the method comprises:

[0009] In a case that the second server comprises a second BGP Peer device, and the first server and the second server are not connected to the same routing device, the service access message is sent to a target BGP RR device through the second BGP Peer device, so that the target BGP RR device sends the service access message to a target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on a first routing rule, and the second server belongs to a container cloud cluster different from the target container cloud cluster;

[0010] Or,

[0011] In a case that the second server does not belong to any container cloud cluster, the service access message is sent to a target BGP RR device, so that the target BGP RR device sends the service access message to a target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on a first routing rule, and the target BGP RR device is a routing gateway of the second server to an IP network segment in the target container cloud cluster;

[0012] The service access message is used to indicate that the second server accesses the first resource IP in the target container cloud cluster, the first resource IP is the first Pod IP or the first Service IP, the target BGP RR device stores a plurality of routing rules, each routing rule corresponds to a Pod IP or a Service IP, the routing rule corresponding to a Pod IP is used to indicate that a next hop of accessing a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, the routing rule corresponding to a Service IP is used to indicate that a next hop of accessing a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster, and the plurality of routing rules comprise the first routing rule, and the first routing rule corresponds to the first BGP Peer device in the first server.

[0013] In a fourth aspect, an embodiment of the present application provides a server, which is a target container cloud cluster, and the server comprises a first BGP Peer device, which comprises: a receiving module, configured to receive, by the first BGP Peer device, a service access message sent by a target device based on a first routing rule, the service access message being used to instruct a second server to access a first resource IP in the target container cloud cluster, the first resource IP being a first Pod IP or a first Service IP, the target device storing a plurality of routing rules, each routing rule corresponding to a Pod IP or corresponding to a Service IP, a routing rule corresponding to a Pod IP being used to instruct a next hop for accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, a routing rule corresponding to a Service IP being used to instruct a next hop for accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules comprising the first routing rule, the first routing rule corresponding to the first BGP Peer device, and the second server not belonging to the target container cloud cluster; and a sending module, configured to send, by the first BGP Peer device, the service access message to a target Pod IP corresponding to the first resource IP.

[0014] In a fifth aspect, an embodiment of the present application provides a target device, which comprises: a control module, configured to determine, from a plurality of stored routing rules, a first routing rule for accessing a first resource IP, each routing rule corresponding to a Pod IP or corresponding to a Service IP, a routing rule corresponding to a Pod IP being used to instruct a next hop for accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, a routing rule corresponding to a Service IP being used to instruct a next hop for accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, and the first routing rule corresponding to a first BGP Peer device of a first server of a target container cloud cluster; and a sending module, configured to send, based on the first routing rule, a service access message to the first BGP Peer device, so that the first BGP Peer device sends the service access message to a target Pod IP corresponding to the first resource IP, the service access message being used to instruct a second server to access the first resource IP in the target container cloud cluster, and the first resource IP being a first Pod IP or a first Service IP.

[0015] In a sixth aspect, an embodiment of the present application provides a server, which is a second server, and the server comprises:

[0016] The sending module is configured to, in a case where the second server comprises a second BGP Peer device, and the first server and the second server are not connected to a same routing device, send, to a target BGP RR device, a service access message through the second BGP Peer device, so that the target BGP RR device sends, to a target Pod IP corresponding to the first resource IP, the service access message through the first BGP Peer device of the first server based on a first routing rule, and the second server belongs to a container cloud cluster different from a target container cloud cluster; or, in a case where the second server does not belong to any container cloud cluster, send, to the target BGP RR device, the service access message, so that the target BGP RR device sends, to the target Pod IP corresponding to the first resource IP, the service access message through the first BGP Peer device of the first server based on the first routing rule; the target BGP RR device is a routing gateway of the second server to an IP network segment in the target container cloud cluster; the service access message is used to instruct the second server to access the first resource IP in the target container cloud cluster, the first resource IP is the first Pod IP or the first Service IP, and the target BGP RR device stores a plurality of routing rules, each routing rule corresponds to a Pod IP or a Service IP, a routing rule corresponding to a Pod IP is used to instruct a next hop of accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, and a routing rule corresponding to a Service IP is used to instruct a next hop of accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules comprise the first routing rule, and the first routing rule corresponds to the first BGP Peer device in the first server.

[0017] In a seventh aspect, an embodiment of the present application provides a service device, including: a processor, a memory, and a program or instruction stored in the memory and executable on the processor, and the program or instruction is executed by the processor to implement the service access method in any one of the first aspect to the third aspect.

[0018] In an eighth aspect, an embodiment of the present application provides a computer readable storage medium, including: a computer program stored on the computer readable storage medium, and the computer program is executed by a processor to implement the service access method in any one of the first aspect to the third aspect.

[0019] In a ninth aspect, an embodiment of the present application provides a computer program product, including: when the computer program product is executed on a computer, the computer program product causes the computer to implement the service access method in any one of the first aspect to the third aspect.

[0020] The technical scheme provided by the embodiments of the present application has the following advantages compared with the prior art: in the embodiments of the present application, the first server receives a service access message sent by a target device based on a first routing rule through the first BGP Peer device, the service access message is used to instruct the second server to access a first resource IP in the target container cloud cluster, the first resource IP is a first Pod IP or a first Service IP, the target device stores a plurality of routing rules, each routing rule corresponds to a Pod IP or a Service IP, the routing rule corresponding to a Pod IP is used to instruct that the next hop of accessing a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, the routing rule corresponding to a Service IP is used to instruct that the next hop of accessing a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules include the first routing rule, the first routing rule corresponds to the first BGP Peer device, and the second server does not belong to the target container cloud cluster; and the first server sends the service access message to a target Pod IP corresponding to the first resource IP through the first BGP Peer device. In the scheme, the BGP Peer device is arranged on each server in the target container cloud cluster, the BGP Peer device is arranged as the next hop of accessing the first resource IP (Pod IP or Service IP) in the container cloud cluster from outside the container cloud cluster, the corresponding routing rule is generated and saved in the target device, then when the first resource IP in the container cloud cluster is accessed from outside the container cloud cluster, the server in the cluster receives the service access message sent by the target device based on the first routing rule through the BGP Peer device, and sends the service access message to the target Pod IP corresponding to the first resource IP through the BGP Peer device, so as to realize the access of the first resource IP in the container cloud cluster from outside the container cloud cluster. In this way, the BGP Peer device arranged in the server can realize the direct access of the first resource IP in the container cloud cluster from outside the container cloud cluster, and compared with the access mode through the proxy, the access delay is greatly reduced, and the access efficiency can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the implementation manners in the related art, the drawings needed to be used in the embodiments or related art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art according to these drawings.

[0022] Figure 1 The overall network topology diagram of the proxy mode through Ingress is shown;

[0023] Figure 2 One of flowchart diagrams of service access method according to some embodiments is shown;

[0024] Figure 3 One of flowchart diagrams of service access method according to some embodiments is shown;

[0025] Figure 4 One of flowchart diagrams of service access method according to some embodiments is shown;

[0026] Figure 5 One of flowchart diagrams of service access method according to some embodiments is shown;

[0027] Figure 6 One of flowchart diagrams of service access method according to some embodiments is shown;

[0028] Figure 7 One of flowchart diagrams of service access method according to some embodiments is shown;

[0029] Figure 8 One of flowchart diagrams of service access method according to some embodiments is shown;

[0030] Figure 9 One of flowchart diagrams of service access method according to some embodiments is shown;

[0031] Figure 10 One of flowchart diagrams of service access method according to some embodiments is shown;

[0032] Figure 11 One of flowchart diagrams of service access method according to some embodiments is shown;

[0033] Figure 12 One of flowchart diagrams of service access method according to some embodiments is shown; DETAILED DESCRIPTION

[0034] For the purpose of clarity and a thorough understanding of the application, the application will be described in conjunction with the drawings of the exemplary embodiments of the application. It is apparent that the described exemplary embodiments are only a part of the embodiments of the application, and are not all the embodiments of the application.

[0035] It should be noted that the brief description of the terms in the present application is only for the convenience of understanding the subsequently described embodiments, and is not intended to limit the embodiments of the present application. Unless otherwise specified, these terms should be understood according to their ordinary and general meanings.

[0036] The terms "first", "second", "third", etc. in the specification and claims of the present application and in the above drawings are used to distinguish similar or like objects or entities, and do not necessarily imply a specific order or sequence unless otherwise noted. It is to be understood that the terms so used are interchangeable under appropriate circumstances.

[0037] The terms "comprise", "comprising", "include", "including", "have", "having" and their variants, are intended to cover both the singular and the plural, unless otherwise noted. The terms "comprise", "comprising", "include", "including", "have", "having" and their variants, are intended to cover a product or device that comprises a series of components, without necessarily being limited to the clear list of components, but can include other components not clearly listed or inherent to such products or devices.

[0038] Next, some of the terms and related technologies involved in the present application are explained and described, so as to facilitate the understanding of those skilled in the art.

[0039] Kubernetes, commonly referred to as k8s, is an open source container cluster management system for automatically deploying, expanding and managing containerized applications. The system builds a container scheduling service based on the Container Runtime Interface (CRI) (such as the open source application container engine (Docker), the Container Storage Interface (CSI), etc.). Kubernetes can automatically select a working container for use in a container cluster. It aims to provide a "platform for automatically deploying, expanding and running application containers across a host cluster". It supports a series of container tools, including Docker, CRI-O, etc.

[0040] Server: also known as a node, a node represents a host device (physical machine).

[0041] Pod, the smallest unit that can be created and deployed in Kubernetes (the basic scheduling unit), is an application instance in the Kubernetes cluster, which is used to provide services. In the Kubernetes cluster, Pod is the basis of all business types and the smallest unit level managed by Kubernetes, which is composed of one or more containers, each of which runs an application, and Kubernetes directly manages Pods rather than containers. For example, in the original Kubernetes design, a group of functionally similar containers form a Pod, that is, multiple containers run in each Pod. Alternatively, each Pod can be customized to one-to-one with containers, that is, only one container runs in each Pod. Two important features of Pod are network: each Pod is assigned a unique IP address, and each container in the Pod shares the network namespace, including IP address and network port, containers in the same Pod can communicate with each other as localhost, and when the containers in the Pod need to communicate with entities outside the Pod, they need to use shared network resources such as ports. Storage: Pod can be assigned a set of shared storage volumes, and all containers in the Pod can access the shared storage volumes.

[0042] At the same time, Kubernetes can create Service resources, and Kubernetes also allocates its own IP to each Service. Service is routed to a server in Kubernetes based on load balancing principles, or Service IP is routed to each server including Pod in Kubernetes. Accessing Service IP in the cluster can access multiple Pod applications behind it.

[0043] Among them, a Pod IP corresponds to a server in the container cloud cluster, and a service IP corresponds to multiple servers in the container cloud cluster.

[0044] BGP: Border Gateway Protocol, is a protocol that manages how data packets are routed through the Internet by exchanging routing and reachability information between edge routers.

[0045] BGP RR: BGP Route Reflector (RR). It can be a software deployed on a separate server or a network hardware device that supports BGP protocol, responsible for exchanging routing rules with other BGP Peer.

[0046] BGP Peer: BGP peer. Deployed on each server in the container cloud cluster, responsible for listening to the Pod information on the server it is located on, generating a routing rule taking itself as the next hop to the Pod IP, and synchronizing the routing rule to the BGP RR through the BGP protocol. On the other hand, collect the routing rules synchronized by other servers in the cluster through the BGP RR, and add them to the routing rules of the server.

[0047] Currently, the industry uses NodePort or Ingress proxy to access services in the private Kubernetes cluster. Kubernetes is currently mainly used to deploy stateless applications (such as web applications). Stateless applications do not require access to specific Pods each time, and load balancing can meet the requirements, and are not sensitive to delay, so the above proxy method is widely used. However, if Kubernetes is used to deploy stateful services such as various databases and caches, such stateful applications require access to specific Pods, and databases and caches as underlying components have higher requirements for delay. As Kubernetes is more used for the management of stateful applications, the industry will gradually realize the defects of the proxy solution.

[0048] As shown in Figure 1 The overall network topology diagram of the proxy method through Ingress is shown. The Ingress solution is adopted, and the traffic first enters the node where the Ingress is deployed through the access switch, and then the traffic is forwarded to other nodes in the cluster by the Ingress node. This method will cause all traffic pressure to be concentrated on the node where the Ingress is deployed, which is easy to cause performance loss and performance bottleneck, and the forwarding of traffic through the node where the Ingress is deployed in the cluster is easy to cause access delay.

[0049] In addition, in some proxy methods through Ingress, an IngressController Service component needs to be additionally installed on the Ingress node. This component is mostly a software layer proxy (such as openresty, nginx, etc.), which will cause an increase in network delay of the calling link. Moreover, the upper layer of the Ingress Controller Server needs to be connected to the F5 hardware LB (load balancing) device, which increases the delay and also increases the cost of the device.

[0050] There is also an openresty-based solution in the related art: mainly optimizing the configuration function of Ingress, the disadvantages are the same as the above-mentioned Ingress solution, there is performance loss and performance bottleneck, and Service IP or Pod IP cannot be directly accessed. There is also an iptables rule-based solution in the related art: complex configuration and management, requires the development of a supporting system; the access port is changed; Service IP or Pod IP cannot be directly accessed. There is also a DNS+LB-based solution in the related art: complex configuration and management; each Pod needs to be assigned an IP when accessing a single Pod, but it still does not meet the needs of software that needs to access Pod IP.

[0051] In summary, the existing method of accessing resources in a container cloud cluster from outside the container cloud cluster has the following problems: it is easy to cause performance loss and performance bottleneck, it is easy to cause large network delay (cannot access resources in time), configuration and management are complex, a supporting system needs to be developed, device costs need to be increased, and Service IP or Pod IP cannot be directly accessed. Therefore, there is an urgent need for a method of accessing resources in a container cloud cluster from outside the container cloud cluster that can reduce access delay.

[0052] To solve the above technical problems, the embodiments of the present application provide a service access method, which sets a BGP Peer device on each server in a target container cloud cluster, sets the BGP Peer device as the next hop for accessing a first resource IP (Pod IP or Service IP) in the container cloud cluster from outside the container cloud cluster, generates a corresponding routing rule, and saves it in a target device. Then, when accessing the first resource IP in the container cloud cluster from outside the container cloud cluster, the server in the cluster receives a service access message sent by the target device based on the first routing rule through the BGP Peer device, and sends the service access message to the target Pod IP corresponding to the first resource IP through the BGP Peer device, to realize accessing the first resource IP in the container cloud cluster from outside the container cloud cluster. In this way, the BGP Peer device set in the server can realize direct access to the first resource IP in the container cloud cluster from outside the container cloud cluster, which greatly reduces the access delay compared to the access method through a proxy, and can improve the access efficiency.

[0053] Figure 2 To implement the service access method according to one or more embodiments of the present application, a step flowchart is provided, which can include S201 to S204 as follows.

[0054] S201, the target device determines a first routing rule corresponding to accessing a first resource IP from a plurality of stored routing rules.

[0055] Corresponding to a Pod IP, the routing rule corresponding to the Pod IP is used to indicate that a next hop of accessing a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, and the routing rule corresponding to a Service IP is used to indicate that a next hop of accessing a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster, and the first routing rule corresponds to the first BGP Peer device of the first server of the target container cloud cluster.

[0056] S202, the target device sends a service access message to the first BGP Peer device based on the first routing rule.

[0057] The target device sends a service access message to the first BGP Peer device based on the first routing rule, so that the first BGP Peer device sends a service access message to the target Pod IP corresponding to the first resource IP.

[0058] S203, the first server receives the service access message sent by the target device based on the first routing rule through the first BGP Peer device.

[0059] The first server belongs to the target container cloud cluster, and the first server includes the first BGP Peer device.

[0060] The service access message is used to instruct the second server to access the first resource IP in the target container cloud cluster, the first resource IP is the first Pod IP or the first Service IP, the target device stores a plurality of routing rules, each routing rule corresponds to a Pod IP or a Service IP, the routing rule corresponding to the Pod IP is used to indicate that a next hop of accessing a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, and the routing rule corresponding to a Service IP is used to indicate that a next hop of accessing a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules include the first routing rule, the first routing rule corresponds to the first BGP Peer device, and the second server does not belong to the target container cloud cluster.

[0061] The service access message can be a Hyper Text Transfer Protocol (HTTP) message or a Transmission Control Protocol (TCP) message. When the service access message is a TCP message, the service access message can be a database access message, which can be a redis message or a MySQL message.

[0062] The target device stores a plurality of routing rules. When the service access message needs to be transmitted, a routing rule corresponding to the service access message is determined from the plurality of routing rules, and the service access message is transmitted based on the determined routing rule.

[0063] The first routing rule is a routing rule corresponding to the service access message determined by the target device from the plurality of routing rules. When the first resource IP is the first Pod IP, the first routing rule corresponds to the first Pod IP, and the first routing rule is used to indicate that the next hop of the Pod IP accessing the first server is the first BGP Peer device. When the first resource IP is the first Service IP, the first routing rule corresponds to the first Service IP, and the first routing rule is used to indicate that the next hop of the Service IP accessing the target container cloud cluster is a BGP Peer device of at least one server in the target container cloud cluster, and the at least one server includes the first server, and the BGP Peer device of the at least one server includes the BGP Peer device of the first server.

[0064] In some embodiments of the application, when the access type of the first Service IP is a load balancing type, the at least one server is all servers in the target container cloud cluster, and the first server is determined from the at least one server corresponding to the first routing rule according to the load balancing principle. When the access type of the first Service IP is a type including a Pod IP, the at least one server is a server including a Pod IP, and the at least one server includes the first server.

[0065] In some embodiments of the application, the target device is a target BGP RR device. Whether the first server and the second server are connected to the same routing device or not, and whether the second server belongs to the container cloud cluster or not, the second server needs to transmit the service access message to the first server through the target BGP RR device. Correspondingly, in this case, the BGP RR stores a plurality of routing rules, and the plurality of routing rules can be stored in each BGP Peer device or not.

[0066] In some embodiments of the present application, in the case that the second server belongs to the container cloud cluster and the first server and the second server access the target routing device, the target device is a second BGP Peer device of the second server; in the case that the second server belongs to the container cloud cluster and the first server and the second server do not access the same routing device, the target device is a target BGP RR device; in the case that the second server does not belong to the container cloud cluster, the target device is a target BGP RR device. In this case, the BGP RR stores a plurality of routing rules, and the plurality of routing rules are saved in each BGP Peer device.

[0067] S204, the first server sends a service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device.

[0068] In some embodiments of the present application, in the case that the first resource IP is the first Pod IP, the target Pod IP is the first Pod IP, and the target Pod IP belongs to the first server.

[0069] In some embodiments of the present application, in the case that the first resource IP is the first Service IP and the access type of the first Service IP is a load balancing type, the target Pod IP can or can not belong to the first server. The target Pod IP does not belong to the first server specifically that the first server does not include the Pod IP. Therefore, when the first BGP Peer device receives the service access message, the first BGP Peer device forwards the service access message to other servers in the target container cloud cluster that include the target Pod IP.

[0070] In the embodiments of the present application, by setting a BGP Peer device on each server in the target container cloud cluster and setting the BGP Peer device as the next hop for accessing the first resource IP (Pod IP or Service IP) in the container cloud cluster from outside the container cloud cluster, a corresponding routing rule is generated and saved in the target device. Then, when the first resource IP in the container cloud cluster is accessed from outside the container cloud cluster, the server in the cluster receives the service access message sent by the target device based on the first routing rule through the BGP Peer device, and sends the service access message to the target Pod IP corresponding to the first resource IP through the BGP Peer device, so as to realize the access of the first resource IP in the container cloud cluster from outside the container cloud cluster. In this way, the BGP Peer device set in the server can realize the direct access of the first resource IP in the container cloud cluster from outside the container cloud cluster, which greatly reduces the access delay and improves the access efficiency compared with the access mode through a proxy.

[0071] In some embodiments of this application, the second server belongs to a container cloud cluster different from the target container cloud cluster; when the first server and the second server are not connected to the same routing device, the target device is a target BGP RR device; combined with Figure 2 ,like Figure 3 As shown, prior to S201, the service access method provided in this application embodiment may further include S205 and S206. Specifically, S201 can be implemented by S201a, S202 can be implemented by S202a, and S203 can be implemented by S203a.

[0072] S205. If the second server includes a second BGP Peer device, and the first server and the second server are not connected to the same routing device, the second server sends a service access message to the target BGP RR device through the second BGP Peer device.

[0073] When the second server includes a second BGP Peer device, and the first server and the second server are not connected to the same routing device, the second server sends a service access message to the target BGP RR device through the second BGP Peer device, so that the target BGP RR device sends a service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on the first routing rule.

[0074] The second server belongs to a different container cloud cluster than the target container cloud cluster.

[0075] S206. The target BGP RR device receives a service access message from the second BGP Peer device.

[0076] S201a, The target BGP RR device determines the first routing rule corresponding to the first resource IP from multiple stored routing rules.

[0077] S202a, The target BGP RR device sends a service access message to the first BGP Peer device based on the first routing rule.

[0078] S203a, The first server receives a service access message sent by the target BGP RR device based on the first routing rule through the first BGP Peer device.

[0079] The second BGP Peer device can directly send the service access message to the target BGP RR without forwarding through other routing devices; or the second BGP Peer device can forward the service access message to the target BGP RR through other routing devices, which is not limited here.

[0080] In the embodiments of the present application, in the case where the first server and the second server are not connected to the same routing device, the second BGP RR device can realize direct access of resources in the container cloud cluster from outside the container cloud cluster through the target BGP RR device to the first BGP Peer device, and can improve the access efficiency.

[0081] In some embodiments of the present application, the second server includes a second BGP Peer device, and the second server belongs to a container cloud cluster different from the target container cloud cluster; in the case where the first server and the second server are connected to the target routing device, the target device is the second BGP Peer device, and in combination with Figure 2 As shown in Figure 4 S201 can be implemented by the following step S201b, S202 can be implemented by the following step S202b, and S203 can be implemented by the following step S203b.

[0082] S201b, the second server determines a first routing rule corresponding to the access of the first resource IP through the second BGP Peer device from the stored plurality of routing rules.

[0083] S202b, the second server sends a service access message to the first BGP Peer device based on the first routing rule through the second BGP Peer device.

[0084] S203b, the first server receives a service access message sent by the second BGP Peer device through the target routing device based on the first routing rule through the first BGP Peer device.

[0085] Specifically, the second server sends a service access message to the target routing device based on the first routing rule through the second BGP Peer device, and the target routing device sends the service access message to the first BGP Peer device of the first server.

[0086] In the embodiments of the present application, the second BGP Peer device determines the first routing rule from the plurality of routing rules, and the second BGP Peer device sends the service access message to the first BGP Peer device through the target routing device. In this way, the service access message does not need to be forwarded through the BGP RR device, which can reduce the access delay and improve the access efficiency.

[0087] In some embodiments of the present application, the second server does not belong to any container cloud cluster, the target device is a target BGP RR device, and the method is combined with Figure 2 As shown in S201 above, the service access method provided by the embodiments of the present application can further include S207 and S208, and S201 can be implemented through the following step S202c. Figure 5

[0088] S207, in the case where the target BGP RR device is a routing gateway for the second server to access an IP network segment in the target container cloud cluster, the second server sends a service access message to the target BGP RR device.

[0089] In the case where the second server does not belong to any container cloud cluster, a service access message is sent to the target BGP RR device, so that the target BGP RR device sends a service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on the first routing rule.

[0090] S208, the target BGP RR device receives a service access message from the second server.

[0091] S201c, the target BGP RR device determines a first routing rule for accessing a first resource IP from the stored multiple routing rules.

[0092] S202c, the target BGP RR device sends a service access message to the first BGP Peer device based on the first routing rule.

[0093] S203c, the first server receives a service access message sent by the target BGP RR device based on the first routing rule through the first BGP Peer device.

[0094] The service access message is received by the target BGP RR device from the second server, and the target BGP RR device is a routing gateway for the second server to access an IP network segment in the target container cloud cluster.

[0095] The IP network segments in different container cloud clusters are different, for example, the container cloud cluster 1 corresponds to the IP network segment 1, and the container cloud cluster 2 corresponds to the IP network segment 2. The gateway routing for the server in the non-container cloud cluster to access different container cloud clusters can be the same or different. For example, the routing gateway for the server in the non-container cloud cluster to access the IP network segment 1 in the container cloud cluster 1 can be BGP RR device 0, and the routing gateway for the server in the non-container cloud cluster to access the IP network segment 2 in the container cloud cluster 2 can be BGP RR device 0 or other BGP RR devices except BGP RR device 0. ​

[0096] In the embodiments of the present application, in the case that the second server is a non-container cloud cluster server, the target BGP RR device is set as a routing gateway of the second server to the IP network segment in the target container cloud cluster. Therefore, when the second server needs to access the first resource IP in the target container cloud cluster, the second server can access the first resource IP in the target container cloud cluster through the target BGP RR device. In this way, the non-container cloud cluster server outside the container cloud cluster can directly access the resource in the container cloud, and the access efficiency can be improved.

[0097] In some embodiments of the present application, on the basis of the above Figure 2 to Figure 5 , as shown in Figure 6 , the service access method provided by the embodiments of the present application can further include the following S601 and S607.

[0098] S601, in the case that the first server adds a second resource IP, the first server generates a second routing rule through the first BGP Peer device.

[0099] The second routing rule corresponds to the first BGP Peer device. The first server can also save the second routing rule.

[0100] S602, the first server sends the second routing rule to the target BGP RR device through the first BGP Peer device.

[0101] The second routing rule is sent to the target BGP RR device through the first BGP Peer device, so that the target BGP RR device saves the second routing rule, and the target BGP RR device controls each third BGP Peer device to save the second routing rule by sending the second routing rule to the plurality of third BGP Peer devices. Each third BGP Peer device corresponds to a server of a container cloud cluster.

[0102] S603, the target BGP RR device receives the second routing rule from the first BGP Peer device.

[0103] S604, the target BGP RR device saves the second routing rule.

[0104] S605, the target BGP RR device sends the second routing rule to the plurality of third BGP Peer devices.

[0105] The plurality of third BGP Peer devices includes the second BGP Peer device.

[0106] S606, each third BGP Peer device receives the second routing rule from the target BGP RR device.

[0107] S607, each third BGP Peer device saves the second routing rule.

[0108] Exemplarily, a Pod IP 0 is added on the server A in the container cloud cluster, the BGP Peer device on the server A generates a routing rule for accessing the Pod IP 0 and synchronizes the routing rule to the BGP RR device, and tells the BGP RR device that, to access the Pod IP 1, the next hop is the BGP Peer device on the server A. After receiving the routing rule synchronized by the server A, the BGP RR device loads the routing rule into the routing rule of the BGP RR device (to access the Pod IP 1, the next hop is the BGP Peer device on the server A). The BGP RR device reports the routing rule on the BGP Peer device of the server A to other servers (including servers outside the container cloud cluster) through the BGP protocol, and all the servers add the routing rule locally (to access the Pod IP 1, the next hop is the BGP Peer device on the server A).

[0109] In the embodiments of the present application, when a second resource IP is added on a server in a container cloud cluster, the BGP Peer device of the server can generate a second routing rule and send the second routing rule to the BGP RR device, so that the BGP RR device saves the second routing rule and sends the second routing rule to other BGP Peer devices. In this way, when a target container cloud cluster outside accesses a second resource IP in a target container cloud cluster, the access can be realized based on the second routing rule, so as to reduce the access delay.

[0110] In some embodiments of the present application, on the basis of the above Figure 2 to Figure 6 , as shown in Figure 7 , the service access method provided by the embodiments of the present application can further include the following S701 and S706.

[0111] S701, in the case that the third resource IP is destroyed on the first server, the first server sends a deletion message to the target BGP RR device through the first BGP Peer device.

[0112] In the case that the third resource IP is destroyed on the first server, a deletion message is sent to the target BGP RR device through the first BGP Peer device, the deletion message is used to instruct the target BGP RR device to delete the third routing rule, and instruct the target BGP RR device to control each BGP Peer device to delete the third routing rule by forwarding the deletion message to the plurality of third BGP Peer devices.

[0113] The third routing rule corresponds to the first BGP Peer device; each third BGP Peer device corresponds to a server of a container cloud cluster. The first server also deletes the third routing rule.

[0114] S702, the target BGP RR device receives a deletion message from the first BGP Peer device.

[0115] S703, the target BGP RR device deletes the third routing rule from the saved plurality of routing rules.

[0116] S704, the target BGP RR device sends a deletion message to a plurality of third BGP Peer devices.

[0117] The plurality of third BGP Peer devices includes the second BGP Peer device.

[0118] S705, each third BGP Peer device receives a deletion message from the target BGP RR device.

[0119] S706, each third BGP Peer device deletes the third routing rule from the saved plurality of routing rules.

[0120] In the embodiments of the present application, when the third resource IP is destroyed on the server in a container cloud cluster, the BGP Peer device of the server can send a deletion message to the BGP RR device, so that the BGP RR device deletes the third routing rule based on the deletion message, and sends a deletion message to other BGP Peer devices (so that other BGP Peer devices delete the third routing rule based on the deletion message). In this way, when the third resource IP in the target container cloud cluster is destroyed, the third routing rule saved in the BGP RR device and each BGP Peer device is deleted in time, and invalid routing rules are processed in time, saving storage space.

[0121] In some embodiments of the present application, when the first resource IP is a first Service IP, and the access type corresponding to the first Service IP is a load balancing type, the first BGP Peer device is the BGP Peer device of the at least one server corresponding to the first routing rule, and the BGP Peer device satisfies the load balancing principle.

[0122] It can be understood that the load balancing type of Service IP corresponds to each server in the container cloud cluster, and therefore the routing rule corresponding to the load balancing type of Service IP corresponds to each server in the container cloud cluster. Therefore, when the first resource IP is the load balancing type of Service IP, the first routing rule corresponds to the BGP Peer device of each server in the target container cloud cluster, and the first BGP Peer device of the first server is determined from the BGP Peer device of each server in the target container cloud cluster according to the load balancing principle. The first BGP Peer device of the first server is the next hop of the first Service IP in the target container cloud accessed by the second server outside the target container cloud cluster.

[0123] It can be understood that accessing the Service IP in the target container cloud cluster eventually falls on the Pod IP in the target container cloud cluster, and therefore, if the target Pod IP is included in the first server (the first server can also include other Pod IPs, and the target Pod IP is any one of the Pod IPs in the first server), the first BGP Peer device sends a service access message to the target Pod IP to realize the access of the first Service IP in the target container cloud cluster by the second server outside the target container cloud cluster; if the Pod IP is not included in the first server, the first BGP Peer device determines a server in the target container cloud cluster that includes the Pod IP (denoted as a fourth server, the fourth server includes a fourth BGP Peer device, and the fourth server includes at least one Pod IP, and the target Pod IP is any one of the at least one Pod IP), and the first BGP Peer device sends a service access message to the fourth BGP Peer device, and the fourth BGP Peer device sends a service access message to the target Pod IP to realize the access of the first Service IP in the target container cloud cluster by the second server outside the target container cloud cluster.

[0124] In some embodiments of the present application, when the first resource IP is the first Service IP, and the access type corresponding to the first Service IP is a server including a Pod IP, the BGP Peer device of the at least one server corresponding to the first routing rule is the BGP Peer device of the server including the Pod IP, and the BGP Peer device of the at least one server includes the first BGP Peer device.

[0125] It can be understood that in the case that the access type of the first resource IP (the first Service IP) is access to the server including the Pod IP in the target container cloud cluster, the first routing rule corresponds to the BGP Peer device (including the first BGP Peer device of the first server) of each server including the Pod IP in the target container cloud cluster, and the BGP Peer device of each server including the Pod IP in the target container cloud cluster is the next hop for accessing the first Service IP in the target container cloud cluster. Therefore, the target device sends a service access message to the BGP Peer device of each server including the Pod IP in the target container cloud cluster based on the first routing rule (including sending a service access message to the first BGP Peer device of the first server based on the first routing rule), so as to realize that the second server outside the target container cloud cluster accesses the first Service IP in the target container cloud cluster.

[0126] In some embodiments of the present application, in the case that the first resource IP is the first Pod IP, the first Pod IP is one of the Pod IPs in the first server, and the first Pod IP is the target Pod IP. The first routing rule is used to indicate that the next hop for accessing the first Pod IP in the target container cloud cluster outside the target container cloud cluster is the first BGP Peer device. Therefore, the target device sends a service access message to the first BGP Peer device, and the first BGP Peer device sends a service access message to the first Pod IP, so as to realize that the second server outside the target container cloud cluster accesses the first Pod IP in the target container cloud cluster.

[0127] In the embodiments of the present application, the first routing rule can be determined from the plurality of routing rules according to the type of the first resource IP, and then the resource IP in the container cloud cluster is directly accessed from outside the container cloud cluster, which can reduce the access delay.

[0128] Exemplarily, as Figure 8As shown, it is a possible overall network topology diagram of the service access method provided by the embodiment. Wherein, the label "21" is used to indicate the BGP RR device 1, the label "22" is used to indicate the BGP RR device 2, the BGP RR device 1 and the BGP RR device 2 each save a plurality of routing rules, and the BGP RR device 1 and the BGP RR device 2 are high availability, that is, the BGP RR device 1 and the BGP RR device 2 can exchange the acquired routing rules with each other, when the BGP RR device 1 as the master device fails, the BGP RR device 2 as the standby device can replace the BGP RR device 1 to realize the service access method provided by the embodiment, and vice versa, when the BGP RR device 2 as the master device fails, the BGP RR device 1 as the standby device can replace the BGP RR device 2 to realize the service access method provided by the embodiment. Or the BGP RR device 1 and the BGP RR device 2 can be identical, when the BGP RR device forwarding service access message is needed, the BGP RR device 1 or the BGP RR device 2 can be selected according to the needs, which is not limited here.

[0129] Wherein, the Kubernetes cluster 1 includes a plurality of servers, each server includes a BGP Peer device, the label "23" and the label "24" are used to indicate a BGP Peer device in the Kubernetes cluster 1, wherein the label "23" is used to indicate the BGP Peer device 1 of the server 1 in the Kubernetes cluster 1, and the label "24" is used to indicate the BGP Peer device 2 of the server 2 in the Kubernetes cluster 1; the Kubernetes cluster 2 includes a plurality of servers, each server includes a BGP Peer device, and the label "25" is used to indicate the BGP Peer device 3 of the server 3 in the Kubernetes cluster 2. The label "26" is used to indicate the server 4 in the non-Kubernetes cluster, and the server 4 does not include a BGP Peer device. The label "27" is used to indicate the routing device 1 accessed by the server 3 and the server 2 together. The BGP RR device 1 is the gateway route for the non-Kubernetes cluster server 4 to access the IP network segment in the Kubernetes cluster 1, and the BGP RR device 2 is the gateway route for the non-Kubernetes cluster server 4 to access the IP network segment in the Kubernetes cluster 2.

[0130] Among them, the Kubernetes cluster 1 includes Service IP 1 and Service IP 2, wherein the access type of Service IP 1 is a load balancing type, and the access type of Service IP 2 is a server type of accessing Pod IP. Server 1 in the Kubernetes cluster 1 includes Pod IP, server 2 includes Pod IP, and other servers do not include Pod IP.

[0131] In combination Figure 8 If server 3 in the Kubernetes cluster 2 needs to access Pod IP 1 in server 1 in the Kubernetes cluster 1, the BGP Peer device 3 of server 3 sends a service access message to the BGP RR device 1, the BGP RR device 1 receives the service access message, determines the routing rule 1 corresponding to the Pod IP 1 from the plurality of routing rules, and then the BGP RR device 1 sends a service access message to the BGP Peer device 1 of server 1 based on the routing rule 1, and the BGP Peer device 1 receives the service access message and sends a service access message to the Pod IP 1.

[0132] In combination Figure 8 If server 3 in the Kubernetes cluster 2 needs to access Pod IP 2 in server 2 in the Kubernetes cluster 1 (server 3 and server 2 jointly access the routing device 1), the BGP Peer device 3 of server 3 determines the routing rule 2 corresponding to the Pod IP 2 from the plurality of routing rules, and then the BGP Peer device 3 sends a service access message to the BGP Peer device 2 of server 2 through the routing device 1 based on the routing rule 2, and the BGP Peer device 2 receives the service access message and sends a service access message to the Pod IP 2.

[0133] In combination Figure 8 If server 4 outside the Kubernetes cluster needs to access Pod IP 1 in server 1 in the Kubernetes cluster 1 (server 4 does not include a BGP Peer device), server 4 sends a service access message to the BGP RR device 1 (the BGP RR device 1 is the gateway route for server 4 to access the IP network segment in the Kubernetes cluster 1), the BGP RR device 1 receives the service access message, determines the routing rule 1 corresponding to the Pod IP 1 from the plurality of routing rules, and then the BGP RR device 1 sends a service access message to the BGP Peer device 1 of server 1 based on the routing rule 1, and the BGP Peer device 1 receives the service access message and sends a service access message to the Pod IP 1.

[0134] In combination Figure 8 If server 3 in Kubernetes cluster 2 needs to access Service IP 1 in Kubernetes cluster 1, the BGP Peer device 3 of server 3 sends a service access message to the BGP RR device 1, the BGP RR device 1 receives the service access message, determines the routing rule 3 corresponding to the Service IP 1 from the plurality of routing rules, and then the BGP RR device 1 determines the BGP Peer device 1 from the BGP Peer devices of the servers in Kubernetes cluster 1 based on the load balancing principle, the BGP RR device 1 sends the service access message to the BGP Peer device 1 of server 1 based on the routing rule 1, and the BGP Peer device 1 receives the service access message and sends the service access message to any Pod IP in the first server.

[0135] In combination Figure 8 If server 3 in Kubernetes cluster 2 needs to access Service IP 2 in Kubernetes cluster 1, the BGP Peer device 3 of server 3 determines the routing rule 4 corresponding to the Service IP 2 from the plurality of routing rules, and then the BGP Peer device 3 determines that the servers including the Pod IP in Kubernetes cluster 1 are server 1 and server 2, the BGP Peer device 3 sends the service access message to the BGP Peer device 1 of server 1 and the BGP Peer device 2 of server 2 based on the routing rule 4, the BGP Peer device 1 receives the service access message and sends the service access message to any Pod IP in the first server, and the BGP Peer device 2 receives the service access message and sends the service access message to any Pod IP in the second server.

[0136] The embodiment of the application provides a scheme for directly accessing the Service IP or the Pod IP in a container cloud cluster from outside the container cloud cluster, which is suitable for various network scenes, can reduce proxy loss, reduce access delay, and adapt to complex network scenes.

[0137] Figure 9 The structural block diagram of the server shown in the embodiment of the present disclosure is provided, the server is a first server, belongs to a target container cloud cluster, and includes a first BGP Peer device, as shown in Figure 9 The server includes:

[0138] The receiving module 901 is configured to receive, by the first BGP Peer device, a service access message sent by a target device based on a first routing rule, the service access message being used to instruct a second server to access a first resource IP in the target container cloud cluster, the first resource IP being a first Pod IP or a first Service IP, the target device storing a plurality of routing rules, each routing rule corresponding to a Pod IP or a Service IP, a routing rule corresponding to a Pod IP being used to instruct a next hop for accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, a routing rule corresponding to a Service IP being used to instruct a next hop for accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, the plurality of routing rules including the first routing rule, the first routing rule corresponding to the first BGP Peer device, and the second server not belonging to the target container cloud cluster; and the sending module 902 is configured to send, by the first BGP Peer device, the service access message to a target Pod IP corresponding to the first resource IP.

[0139] In some embodiments of the present application, the second server includes a second BGP Peer device, and the second server belongs to a container cloud cluster different from the target container cloud cluster; in the case where the first server and the second server access a target routing device, the target device is the second BGP Peer device, the receiving module 901 is specifically configured to receive, by the first BGP Peer device, a service access message sent by the second BGP Peer device based on the first routing rule through the target routing device; in the case where the first server and the second server do not access the same routing device, the target device is a target BGP RR device, and the receiving module 901 is specifically configured to receive, by the first BGP Peer device, a service access message sent by the target BGP RR device based on the first routing rule, the service access message being received by the target BGP RR device from the second BGP Peer device.

[0140] In some embodiments of the present application, the second server does not belong to any container cloud cluster, the target device is a target BGP RR device, the receiving module 901 is specifically configured to receive, by the first BGP Peer device, a service access message sent by the target BGP RR device based on the first routing rule, the service access message being received by the target BGP RR device from the second server; and the target BGP RR device is a routing gateway for the second server to access an IP network segment in the target container cloud cluster.

[0141] In some embodiments of the present application, the device further comprises a generating module configured to generate a second routing rule through the first BGP Peer device in a case where the first server adds a second resource IP, the second routing rule corresponding to the first BGP Peer device; the sending module 902 is further configured to send the second routing rule to the target BGP RR device through the first BGP Peer device, so that the target BGP RR device saves the second routing rule, and so that the target BGP RR device controls each third BGP Peer device to save the second routing rule by sending the second routing rule to the plurality of third BGP Peer devices; or the sending module 902 is further configured to send a deletion message to the target BGP RR device through the first BGP Peer device in a case where the first server destroys a third resource IP, the deletion message being configured to instruct the target BGP RR device to delete a third routing rule, and instruct the target BGP RR device to control each BGP Peer device to delete the third routing rule by forwarding the deletion message to the plurality of third BGP Peer devices, the third routing rule corresponding to the first BGP Peer device; wherein each third BGP Peer device corresponds to a server of a container cloud cluster.

[0142] In the embodiments of the present application, the modules of the server can implement the service access method provided by the method embodiments, and achieve the same technical effects. To avoid repetition, details are not repeated here.

[0143] Figure 10 The target device shown in the embodiments of the present disclosure is a structural block diagram, as shown in Figure 10 The target device comprises:

[0144] The control module 1001 is configured to determine a first routing rule corresponding to the first resource IP from the plurality of stored routing rules, each routing rule corresponding to a Pod IP or corresponding to a Service IP, the routing rule corresponding to the Pod IP being used to indicate that a next hop of accessing a Pod IP of a server in a container cloud cluster is a BGP Peer device of the server, the routing rule corresponding to the Service IP being used to indicate that a next hop of accessing a Service IP of a container cloud cluster is a BGP Peer device of at least one server in the container cloud cluster, and the first routing rule corresponding to a first BGP Peer device of a first server of the target container cloud cluster; and the sending module 1002 is configured to send, based on the first routing rule, a service access message to the first BGP Peer device, so that the first BGP Peer device sends the service access message to a target Pod IP corresponding to the first resource IP, and the service access message is used to instruct the second server to access the first resource IP of the target container cloud cluster, and the first resource IP is the first Pod IP or the first Service IP.

[0145] In some embodiments of the present application, in the case that the first server and the second server access a target routing device, the target device is a second BGP Peer device of the second server; in the case that the first server and the second server do not access the same routing device, the target device is a target BGP RR device; the device further includes a receiving module configured to receive a service access message from the second BGP Peer device before determining the first routing rule corresponding to the first resource IP from the plurality of stored routing rules.

[0146] In some embodiments of the present application, in the case that the first resource IP is the first Service IP, and an access type corresponding to the first Service IP is a load balancing type, the first BGP Peer device is a BGP Peer device of the at least one server corresponding to the first routing rule, which satisfies a load balancing principle; in the case that the first resource IP is the first Service IP, and an access type corresponding to the first Service IP is a server including a Pod IP, the BGP Peer device of the at least one server corresponding to the first routing rule is a BGP Peer device of the server including the Pod IP, and the BGP Peer device of the at least one server includes the first BGP Peer device.

[0147] In the embodiments of the present application, each module of the server can implement the service access method provided by the above-mentioned method embodiments, and achieve the same technical effects. To avoid repetition, details are not described here.

[0148] Figure 11 A structural block diagram of a server is shown in the embodiments of the present disclosure, the server is a second server, as shown in the figure, the server comprises: Figure 11

[0149] The sending module 1101 is configured to, in a case where the second server comprises a second BGP Peer device, and the first server and the second server are not connected to the same routing device, send, by the second BGP Peer device, a service access message to a target BGP RR device, so that the target BGP RR device sends, based on a first routing rule, a service access message to a target Pod IP corresponding to a first resource IP by a first BGP Peer device of the first server, and the second server belongs to a container cloud cluster different from a target container cloud cluster;

[0150] Alternatively,

[0151] The sending module 1102 is configured to, in a case where the second server does not belong to any container cloud cluster, send, to the target BGP RR device, a service access message, so that the target BGP RR device sends, based on a first routing rule, a service access message to a target Pod IP corresponding to a first resource IP by a first BGP Peer device of the first server; and the target BGP RR device is a routing gateway of the second server to an IP network segment in the target container cloud cluster.

[0152] The service access message is used to instruct the second server to access the first resource IP in the target container cloud cluster, the first resource IP is the first Pod IP or the first Service IP, and the target BGP RR device stores a plurality of routing rules, each routing rule corresponds to a Pod IP or a Service IP, the routing rule corresponding to a Pod IP is used to instruct a next hop of accessing a Pod IP of a server in a container cloud cluster to be a BGP Peer device of the server, the routing rule corresponding to a Service IP is used to instruct a next hop of accessing a Service IP of a container cloud cluster to be a BGP Peer device of at least one server in the container cloud cluster, and the plurality of routing rules comprise the first routing rule, and the first routing rule corresponds to the first BGP Peer device in the first server.

[0153] In the embodiments of the present application, the modules of the server can implement the service access method provided by the method embodiments, and achieve the same technical effects. To avoid repetition, details are not repeated here.

[0154] As shown in the figure, the server comprises: Figure 12 ​As shown, the embodiments of the present application further provide a service device 1200, which can be the electronic device or the server. The service device 1200 comprises a processor 1201, a memory 1202, and a computer program stored in the memory 1202 and executable on the processor 1201. The computer program is executed by the processor 1201 to implement the processes performed by the service access method and achieve the same technical effects. To avoid repetition, details are not described herein.

[0155] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the processes performed by the service access method and achieve the same technical effects. To avoid repetition, details are not described herein.

[0156] The computer readable storage medium can be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, etc.

[0157] The present application provides a computer program product, which comprises: when the computer program product is run on a computer, the computer program product enables the computer to implement the service access method.

[0158] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

[0159] In order to facilitate explanation, the above description has been made in combination with specific embodiments. However, the above exemplary discussion is not intended to exhaust or limit the embodiments to the specific forms disclosed above. According to the above teachings, various modifications and variations can be obtained. The selection and description of the above embodiments are to better explain the principles and practical applications, so that those skilled in the art can better use the embodiments and various different modified embodiments suitable for specific use considerations.

Claims

1. A service access method, characterized in that, The method involves applying a first server in a target container cloud cluster, the first server including a first BGP Peer device; the method includes: The first BGP Peer device receives a service access message sent by the target device based on a first routing rule. The service access message is used to instruct the second server to access a first resource IP in the target container cloud cluster. The first resource IP is a first Pod IP or a first Service IP. The target device stores multiple routing rules, each routing rule corresponding to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to instruct the next hop of accessing the Pod IP of a server in a container cloud cluster to be the BGP Peer device of that server. The routing rule corresponding to a Service IP is used to instruct the next hop of accessing the Service IP of a container cloud cluster to be the BGP Peer device of at least one server in the container cloud cluster. The multiple routing rules include the first routing rule, the first routing rule corresponds to the first BGP Peer device, and the second server does not belong to the target container cloud cluster. The service access message is sent to the target Pod IP corresponding to the first resource IP via the first BGP Peer device; Wherein, the second server includes a second BGP Peer device, the second server belongs to a first container cloud cluster different from the target container cloud cluster, the target container cloud cluster includes multiple servers, the multiple servers are respectively connected to at least one first routing device outside the cluster, the multiple servers include the first server, the first container cloud cluster includes multiple target servers, the multiple target servers are respectively connected to at least one second routing device outside the cluster, the multiple target servers include the second server, the at least one first routing device and the at least one second routing device are respectively connected to a target BGP RR device; When the first routing device accessed by the first server and the second routing device accessed by the second server are the same routing device, and the target device is the second BGP Peer device, receiving the service access message sent by the target device based on the first routing rule through the first BGP Peer device includes: The first BGP Peer device receives service access messages sent by the second BGP Peer device based on the first routing rules and accessed through the first routing device of the first server. When the first routing device accessed by the first server and the second routing device accessed by the second server are not the same routing device, the target device is the target BGP RR device. Receiving the service access message sent by the target device based on the first routing rule through the first BGP Peer device includes: The first BGP Peer device receives a service access message sent by the target BGP RR device based on a first routing rule, wherein the service access message is received by the target BGP RR device from the second BGP Peer device; Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

2. The method according to claim 1, characterized in that, The second server does not belong to any container cloud cluster, the target device is a target BGP RR device, and the step of receiving the service access message sent by the target device based on the first routing rule through the first BGP Peer device includes: The first BGP Peer device receives a service access message sent by the target BGP RR device based on a first routing rule, wherein the service access message is received by the target BGP RR device from the second server; The target BGP RR device is the routing gateway from the second server to the IP network segment within the target container cloud cluster.

3. The method according to claim 1 or 2, characterized in that, The method further includes: When a second resource IP is added to the first server, a second routing rule is generated through the first BGP Peer device, and the second routing rule corresponds to the first BGP Peer device. The first BGP Peer device sends the second routing rule to the target BGP RR device, so that the target BGP RR device saves the second routing rule, and the target BGP RR device controls each third BGP Peer device to save the second routing rule by sending the second routing rule to multiple third BGP Peer devices; or, In the case of destroying the third resource IP on the first server, the first BGP Peer device sends a deletion message to the target BGP RR device. The deletion message is used to instruct the target BGP RR device to delete the third routing rule and to instruct the target BGP RR device to control each BGP Peer device to delete the third routing rule by forwarding the deletion message to multiple third BGP Peer devices. The third routing rule corresponds to the first BGP Peer device. Each third BGP Peer device corresponds to a server in a container cloud cluster.

4. A service access method, characterized in that, Applied to a target device, the method includes: The first routing rule corresponding to the access to the first resource IP is determined from multiple stored routing rules. Each routing rule corresponds to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to indicate that the next hop for accessing the Pod IP of a server in a container cloud cluster is the BGP Peer device of the server. The routing rule corresponding to a Service IP is used to indicate that the next hop for accessing the Service IP of a container cloud cluster is the BGP Peer device of at least one server in the container cloud cluster. The first routing rule corresponds to the first BGP Peer device of the first server of the target container cloud cluster. Based on the first routing rule, a service access message is sent to the first BGP Peer device, so that the first BGP Peer device sends the service access message to the target Pod IP corresponding to the first resource IP. The service access message is used to instruct the second server to access the first resource IP of the target container cloud cluster. The first resource IP is the first Pod IP or the first Service IP. Wherein, the second server includes a second BGP Peer device, the second server belongs to a first container cloud cluster different from the target container cloud cluster, the target container cloud cluster includes multiple servers, the multiple servers are respectively connected to at least one first routing device outside the cluster, the multiple servers include the first server, the first container cloud cluster includes multiple target servers, the multiple target servers are respectively connected to at least one second routing device outside the cluster, the multiple target servers include the second server, the at least one first routing device and the at least one second routing device are respectively connected to a target BGP RR device; When the first routing device accessed by the first server and the second routing device accessed by the second server are the same routing device, and the target device is the second BGP Peer device, the step of sending a service access message to the first BGP Peer device based on the first routing rule includes: Based on the first routing rule, the service access message is sent to the first BGPPeer device through the first routing device connected to the first server. When the first routing device accessed by the first server and the second routing device accessed by the second server are not the same routing device, the target device is a target BGP RR device. The step of sending a service access message to the first BGP Peer device based on the first routing rule includes: Based on the first routing rule, the service access message received from the second BGP Peer device is sent to the first BGP Peer device. Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

5. The method according to claim 4, characterized in that, When the first resource IP is the first service IP and the access type corresponding to the first service IP is the load balancing type, the first BGP Peer device is the BGP Peer device that satisfies the load balancing principle among the BGP Peer devices of the at least one server corresponding to the first routing rule. When the first resource IP is the first service IP and the access type corresponding to the first service IP is a server including Pod IP, the BGP Peer devices of the at least one server corresponding to the first routing rule are all BGP Peer devices of servers including Pod IP, and the BGP Peer devices of the at least one server include the first BGP Peer device.

6. A service access method, characterized in that, Applied to a second server, the method includes: In the case where the second server includes a second BGP Peer device, and the first server and the second server are not connected to the same routing device, a service access message is sent to the target BGP RR device through the second BGP Peer device, so that the target BGP RR device sends the service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on the first routing rules. The second server belongs to a first container cloud cluster that is different from the target container cloud cluster. The target container cloud cluster includes multiple servers, and the multiple servers are respectively connected to at least one first routing device outside the cluster. The multiple servers include the first server. The first container cloud cluster includes multiple target servers, and the multiple target servers are respectively connected to at least one second routing device outside the cluster. The multiple target servers include the second server. The at least one first routing device and the at least one second routing device are respectively connected to the target BGP RR device. The service access message is used to instruct the second server to access the first resource IP in the target container cloud cluster. The first resource IP is either the first Pod IP or the first Service IP. The target BGP RR device stores multiple routing rules, each routing rule corresponding to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to instruct that the next hop for accessing the Pod IP of a server in a container cloud cluster is the BGP Peer device of that server. The routing rule corresponding to a Service IP is used to instruct that the next hop for accessing the Service IP of a container cloud cluster is the BGP Peer device of at least one server in the container cloud cluster. The multiple routing rules include the first routing rule, which corresponds to the first BGP Peer device in the first server. Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

7. A first server, characterized in that, Belonging to the target container cloud cluster, the first server includes a first BGPPeer device, comprising: The receiving module is configured to receive a service access message sent by the target device based on a first routing rule through the first BGP Peer device. The service access message is used to instruct the second server to access a first resource IP in the target container cloud cluster. The first resource IP is a first Pod IP or a first Service IP. The target device stores multiple routing rules, each routing rule corresponding to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to instruct the next hop of accessing the Pod IP of a server in a container cloud cluster to be the BGP Peer device of that server. The routing rule corresponding to a Service IP is used to instruct the next hop of accessing the Service IP of a container cloud cluster to be the BGP Peer device of at least one server in the container cloud cluster. The multiple routing rules include the first routing rule, the first routing rule corresponds to the first BGP Peer device, and the second server does not belong to the target container cloud cluster. The sending module is used to send the service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device; Wherein, the second server includes a second BGP Peer device, the second server belongs to a first container cloud cluster different from the target container cloud cluster, the target container cloud cluster includes multiple servers, the multiple servers are respectively connected to at least one first routing device outside the cluster, the multiple servers include the first server, the first container cloud cluster includes multiple target servers, the multiple target servers are respectively connected to at least one second routing device outside the cluster, the multiple target servers include the second server, the at least one first routing device and the at least one second routing device are respectively connected to a target BGP RR device; When the first routing device accessed by the first server and the second routing device accessed by the second server are the same routing device, the target device is the second BGP Peer device, and the receiving module is specifically used to: receive, through the first BGP Peer device, a service access message sent by the second BGP Peer device based on the first routing rules through the first routing device accessed by the first server; When the first routing device accessed by the first server and the second routing device accessed by the second server are not the same routing device, the target device is the target BGP RR device. The receiving module is specifically used to: receive a service access message sent by the target BGP RR device based on the first routing rule through the first BGP Peer device. The service access message is received by the target BGP RR device from the second BGP Peer device. Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

8. A target device, characterized in that, include: The control module is used to determine the first routing rule corresponding to accessing the first resource IP from multiple stored routing rules. Each routing rule corresponds to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to indicate that the next hop for accessing the Pod IP of a server in a container cloud cluster is the BGP Peer device of the server. The routing rule corresponding to a Service IP is used to indicate that the next hop for accessing the Service IP of a container cloud cluster is the BGP Peer device of at least one server in the container cloud cluster. The first routing rule corresponds to the first BGP Peer device of the first server of the target container cloud cluster. The sending module is configured to send a service access message to the first BGP Peer device based on the first routing rule, so that the first BGP Peer device sends the service access message to the target Pod IP corresponding to the first resource IP. The service access message is used to instruct the second server to access the first resource IP of the target container cloud cluster. The first resource IP is the first Pod IP or the first Service IP. Wherein, the second server includes a second BGP Peer device, the second server belongs to a first container cloud cluster different from the target container cloud cluster, the target container cloud cluster includes multiple servers, the multiple servers are respectively connected to at least one first routing device outside the cluster, the multiple servers include the first server, the first container cloud cluster includes multiple target servers, the multiple target servers are respectively connected to at least one second routing device outside the cluster, the multiple target servers include the second server, the at least one first routing device and the at least one second routing device are respectively connected to a target BGP RR device; When the first routing device accessed by the first server and the second routing device accessed by the second server are the same routing device, the target device is the second BGP Peer device, and the sending module is specifically used to: send the service access message to the first BGP Peer device through the first routing device accessed by the first server based on the first routing rule; When the first routing device accessed by the first server and the second routing device accessed by the second server are not the same routing device, the target device is the target BGP RR device, and the sending module is specifically used to: send the service access message received from the second BGP Peer device to the first BGP Peer device based on the first routing rule. Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

9. A server, characterized in that, The server is a second server, including: The sending module is configured to send a service access message to a target BGP RR device through the second BGP Peer device when the second server includes a second BGP Peer device and the first server and the second server are not connected to the same routing device. This enables the target BGP RR device to send the service access message to the target Pod IP corresponding to the first resource IP through the first BGP Peer device of the first server based on the first routing rules. The second server belongs to a first container cloud cluster that is different from the target container cloud cluster. The target container cloud cluster includes multiple servers, each of which is connected to at least one first routing device outside the cluster. The multiple servers include the first server. The first container cloud cluster includes multiple target servers, each of which is connected to at least one second routing device outside the cluster. The multiple target servers include the second server. The at least one first routing device and the at least one second routing device are connected to the target BGP RR device. The service access message is used to instruct the second server to access the first resource IP in the target container cloud cluster. The first resource IP is either the first Pod IP or the first Service IP. The target BGP RR device stores multiple routing rules, each routing rule corresponding to a Pod IP or a Service IP. The routing rule corresponding to a Pod IP is used to instruct that the next hop for accessing the Pod IP of a server in a container cloud cluster is the BGP Peer device of that server. The routing rule corresponding to a Service IP is used to instruct that the next hop for accessing the Service IP of a container cloud cluster is the BGP Peer device of at least one server in the container cloud cluster. The multiple routing rules include the first routing rule, which corresponds to the first BGP Peer device in the first server. Each server in the container cloud cluster is equipped with a BGP Peer device. The BGP Peer device is used to listen to the resource IPs on its server and generate routing rules for accessing the listened resource IPs as the next hop of the BGP Peer device. The BGP Peer device is also used to synchronize the generated routing rules to the corresponding BGP RR device via the BGP protocol, and to save the routing rules of the servers in each container cloud cluster issued by the corresponding BGP RR.

Images