Cross-processor architecture multi-container cluster service discovery method, device and equipment

By using local cluster proxy components and global service intermediary components in each cluster, service information sharing and parsing between multi-container clusters across processor architecture is solved, and the problem of cross-cluster service discovery is achieved, and the development of cross-cluster high availability and processor diversification is achieved.

CN114153566BActive Publication Date: 2025-04-29GUANGDONG INSPUR BIG DATA RES CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202111558236.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-12-20
Publication Date
2025-04-29
Estimated Expiration
2041-12-20

AI Technical Summary

Technical Problem

The prior art cannot realize service discovery between multi-container clusters across processor architectures, resulting in service discovery being unable to be realized when cross-cluster service access is accessed.

Method used

Service information sharing across clusters is achieved by using local cluster proxy components in each cluster and sending it to the global service mediation component. Using the global service mediation component and the local DNS server plug-in, parse service requests and determine access routing information to achieve cross-cluster service access.

Benefits of technology

It realizes service discovery capabilities between multi-container clusters across processor architectures, supports the deployment of applications across clusters and processor architectures, realizes high availability of applications across clusters, accelerates the diversified development of processors, and promotes the implementation of cloud-native technology.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114153566B_ABST
    Figure CN114153566B_ABST
Patent Text Reader

Abstract

The present application discloses a method, device and equipment for service discovery between multi-container clusters across processor architectures, and relates to the field of computer technology. The method includes: using a local cluster proxy component to generate service information of a local cluster based on local service resources, and sending the service information to a global service intermediary component of the cluster set; importing service information of other clusters in the cluster set from the global service intermediary component through the cluster proxy component; obtaining a service request, using a local DNS server plug-in to parse the service request based on the locally stored service information, and determining the access routing information corresponding to the service request to achieve service access. It can achieve service discovery between multi-container clusters across processor architectures.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device and equipment for discovering services between multi-container clusters across a cross-processor architecture. Background Art

[0002] Since the "Internet +", Internet companies have replaced traditional IT companies and become leaders in the data era. With open source technology as the "nutrient solution" and a series of native application operations such as microservices, containers, iterations, DevOps, and AIOps, Internet companies have ruthlessly crushed traditional industries / enterprises. For traditional industry companies, it is necessary to accelerate the transformation and innovation of cloud native applications. At present, in addition to traditional X86 processors, processors such as ARM and RISC-V are also developing rapidly, showing a trend of coexistence of multiple architectures; at the same time, with the continuous expansion of the scale of container business, the scale and number of user clusters are getting larger and larger. In order to avoid the high availability risks of applications brought by centralized construction and reduce the complexity of scheduling a single large-scale cluster, users generally adopt small and medium-sized multi-cluster methods to build container computing capabilities. Therefore, how to achieve cross-cluster service discovery between different clusters across processor architectures has become particularly important.

[0003] In the prior art, the existing service discovery mechanism of the Kubernetes cluster saves the correspondence between the service name and the internal IP of the cluster to the CoreDNS component of the cluster. When the cluster is used for service discovery, CoreDNS will perform domain name resolution based on the service name and the namespace to which the service belongs to complete the service discovery (DNS stands for Domain name resolution, and the Chinese name is domain name resolution. Domain name resolution refers to a service that points the domain name to the website space IP so that people can easily access the website through the registered domain name; CoreDNS is a DNS server provided by Kubernetes). However, when there is cross-cluster service access, service discovery cannot be achieved using the original CoreDNS solution. Therefore, how to achieve service discovery between multi-container clusters across processor architectures is an urgent problem that needs to be solved. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a method, device and equipment for service discovery between multi-container clusters across processor architectures, which can realize service discovery between multi-container clusters across processor architectures. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a cross-processor architecture multi-container cluster service discovery method, comprising:

[0006] Optionally, generating service information of a local cluster according to local service resources and sending the service information to a global service broker component of the cluster set includes:

[0007] Determine the service resources of the cross-cluster services created in the local cluster by querying the exposed services;

[0008] A corresponding shadow service is created based on the service resource, and the shadow service is sent as the service information to the global service broker component of the cluster set.

[0009] Optionally, the importing service information of other clusters in the cluster set from the global service broker component includes:

[0010] Acquire service information of other clusters in the cluster set from the global service broker component to obtain shadow services corresponding to service resources in other clusters;

[0011] Create a copy of the shadow service and store the copy locally.

[0012] Optionally, generating the service information of the local cluster according to the local service resources includes:

[0013] According to a first preset detection period, periodically detecting newly created local service resources, and generating service information of the local cluster according to the service resources;

[0014] The importing of service information of other clusters in the cluster set from the global service broker component includes:

[0015] According to a second preset detection period, service information of other clusters in the cluster set newly received by the global service broker component is periodically imported from the global service broker component.

[0016] Optionally, before sending the service information to the global service broker component of the cluster set, the method further includes:

[0017] Creating a singleton component on a target cluster in the cluster set, and storing the singleton component in a key-value data storage system of the target cluster; the target cluster includes an open access API;

[0018] The service account and role access control information of the singleton component are configured, and endpoint parameters and cluster parameters are defined to obtain the global service broker component; the endpoint parameters include an IP address, and the cluster parameters include a classless inter-domain routing of the service.

[0019] Optionally, after determining the access routing information corresponding to the service request, the method further includes:

[0020] If it is determined according to the access routing information that the service request is a cross-cluster service request, service access is performed through a cross-cluster tunnel according to the access routing information.

[0021] Optionally, the cross-processor architecture multi-container cluster service discovery method further includes:

[0022] The running state of the global service broker component is monitored, and if the global service broker component fails, a pre-created standby global service broker component is enabled.

[0023] Optionally, obtaining the service request, parsing the service request according to the locally stored service information using a local DNS server plug-in, and determining access routing information corresponding to the service request to implement service access, includes:

[0024] Parse the service request to extract the domain name field, and determine whether the domain name field is a cross-cluster service access domain name;

[0025] If the domain name field is a cross-cluster service access domain name, the service request is forwarded to the DNS server plug-in through the CoreDNS component;

[0026] The DNS server plug-in is used to perform DNS resolution on the service request according to the service information stored locally, so as to determine the access routing information corresponding to the service request, so as to perform service access according to the access routing information.

[0027] In a second aspect, the present application discloses a cross-processor architecture multi-container cluster service discovery device, comprising:

[0028] A service information sending module, used to generate service information of a local cluster according to local service resources by using a local cluster proxy component, and send the service information to a global service broker component of the cluster set;

[0029] A service information acquisition module, used to import service information of other clusters in the cluster set from the global service intermediary component through the cluster proxy component;

[0030] The access route determination module is used to obtain a service request, use a local DNS server plug-in to parse the service request according to the locally stored service information, and determine the access route information corresponding to the service request to achieve service access.

[0031] In a third aspect, the present application discloses an electronic device, comprising:

[0032] Memory, used to store computer programs;

[0033] The processor is used to execute the computer program to implement the aforementioned cross-processor architecture multi-container cluster service discovery method.

[0034] In this application, a local cluster proxy component is used to generate service information of a local cluster according to local service resources, and the service information is sent to the global service intermediary component of the cluster set; through the cluster proxy component, the service information of other clusters in the cluster set is imported from the global service intermediary component; a service request is obtained, and the service request is parsed according to the locally stored service information by the local DNS server plug-in, and the access routing information corresponding to the service request is determined to achieve service access. As can be seen from the above, the global service intermediary component of the cluster set is used as a storage intermediary for service information to receive the service information sent by the cluster, and the obtained service information is provided to other clusters in the cluster set. At the same time, each cluster uses the local cluster proxy component to import the service information of other clusters from the global service intermediary component, so that each cluster can save the service information uploaded to the global service intermediary component by all clusters in the cluster set. Then, after receiving the service request, the cluster uses the local DNS server plug-in to parse the service request according to the locally stored service information, and determines the access routing information corresponding to the service request to achieve service access, so as to have the service discovery capability between multi-container clusters with different architectures, support the deployment of applications across clusters and processor architectures, achieve high availability of applications across clusters, accelerate the diversified development of processors, and promote the development and implementation of cloud native technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0036] Figure 1 A flow chart of a cross-processor architecture multi-container cluster service discovery method provided by this application;

[0037] Figure 2 A specific cross-processor architecture multi-container cluster service discovery system operation flow chart provided for this application;

[0038] Figure 3 A schematic diagram of the structure of a cross-processor architecture multi-container cluster service discovery device provided by this application;

[0039] Figure 4 A structural diagram of an electronic device provided for this application. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] In the prior art, the existing service discovery mechanism of the Kubernetes cluster saves the correspondence between the service name and the internal IP of the cluster to the CoreDNS component of the cluster. When service discovery is performed within the cluster, CoreDNS will perform domain name resolution based on the service name and the namespace to which the service belongs to complete service discovery. However, when there is cross-cluster service access, service discovery cannot be achieved using the original CoreDNS solution. In order to overcome the above technical problems, the present application discloses a cross-processor architecture multi-container cluster service discovery method, which can achieve service discovery between cross-processor architecture multi-container clusters.

[0042] The present application embodiment discloses a cross-processor architecture multi-container cluster service discovery method, see Figure 1 As shown, the method may include the following steps:

[0043] Step S11: using the local cluster proxy component to generate service information of the local cluster according to the local service resources, and sending the service information to the global service broker component of the cluster set.

[0044] In this embodiment, each cluster uses a local cluster proxy component to generate service information of the local cluster based on local service resources, and sends the above service information to the global service broker component of the cluster set (ClusterSet), thereby sharing the local service information with other components in the cluster set through the global service broker component.

[0045] In this embodiment, the service information of the local cluster is generated according to the local service resources, and the service information is sent to the global service broker component of the cluster set, which may include: determining the service resources of the cross-cluster service (ServiceExport) created in the local cluster by querying the exposed service; creating a corresponding shadow service (ServiceImport) based on the service resources, and sending the shadow service as the service information to the global service broker component of the cluster set. It can be understood that the services in the cluster may include cross-cluster services and services provided only locally. For cross-cluster services, this type of service itself will expose the service to represent that it wants to be shared. Therefore, the service resources of the cross-cluster service created in the local cluster can be determined by querying the exposed service, and then the corresponding shadow service is created based on the above service resources, and the shadow service is sent as the service information to the global service broker component of the cluster set.

[0046] In this embodiment, the generating of the service information of the local cluster according to the local service resources may include: periodically detecting the newly created local service resources according to the first preset detection period, and generating the service information of the local cluster according to the service resources. That is, periodically detecting the newly created local service resources according to the first preset detection period, and generating the service information of the local cluster according to the service resources, so as to timely upload the newly generated local cross-cluster service resources to the global service intermediary component, wherein the first preset detection period may be configured according to user needs.

[0047] Step S12: Importing service information of other clusters in the cluster set from the global service broker component through the cluster proxy component.

[0048] In this embodiment, the cluster proxy component uploads local service information to the global service broker component, and also imports service information of other clusters in the cluster set from the global service broker component. Specifically, in this embodiment, the importing of service information of other clusters in the cluster set from the global service broker component may include: obtaining service information of other clusters in the cluster set from the global service broker component to obtain shadow services corresponding to service resources in other clusters; creating a copy of the shadow service and storing the copy locally. That is, for each service information exported from other clusters to the global service broker component, a copy is created in the local cluster.

[0049] In this embodiment, the importing of service information of other clusters in the cluster set from the global service intermediary component may include: periodically importing service information of other clusters in the cluster set newly received by the global service intermediary component from the global service intermediary component according to a second preset detection period. That is, according to the second preset detection period, the service information newly acquired by the global service intermediary component is periodically detected so as to timely acquire service resources newly uploaded to the global service intermediary component by other clusters in the cluster set, wherein the second preset detection period may be configured according to user needs.

[0050] In this embodiment, before sending the service information to the global service broker component of the cluster set, it can also include: creating a singleton component on the target cluster in the cluster set, and storing the singleton component in the key-value data storage system of the target cluster; the target cluster includes an open access API (Application Programming Interface); configuring the service account and role access control information of the singleton component, defining endpoint parameters and cluster parameters to obtain the global service broker component; the endpoint parameters include an IP address, and the cluster parameters include a classless inter-domain route of the service. It can be understood that since the global service broker component, as an information exchange intermediary for service information, needs to be accessible to all clusters in the cluster, by deploying the singleton component on the target cluster, the Kubernetes API of the target cluster must be accessible to all participating clusters, which can be one of the participating clusters or an independent cluster that does not participate in service discovery, and storing the above singleton component in the key-value data storage system of the target cluster, the above key-value data storage system can be Kubernetes Etcd (Etcd is an open source, highly available, distributed key-value data storage system), so that the global service broker component can promote the metadata information exchange of services between participating clusters in the cluster set. That is, there is at least one global service broker component configured in a cluster set.

[0051] Furthermore, the service account and role access control information of the above singleton component can be configured, and the endpoint parameters and cluster parameters can be defined to obtain a fully functional global service intermediary component with permission management. The above endpoint parameters include IP addresses, and the above cluster parameters include classless inter-domain routing of services. Specifically, define service accounts (ServiceAccount, Service Account provides identity information for processes and external users in Pod) and role access control information (Role-Based Access Control, RBAC, role-based access control). In RBAC, permissions are associated with roles. Users obtain permissions of these roles by becoming members of appropriate roles, so that other components can safely access the intermediary API. Endpoint parameters (endpoint) and cluster parameters (Cluster) are defined. Endpoint mainly carries information such as the connection IP of the cluster, and Cluster mainly carries original cluster information, such as classless inter-domain routing (Classless Inter-DomainRouting, Service CIDR) information, etc. By configuring endpoint parameters and cluster parameters for the global service intermediary component, the association between the cluster and the IP is saved in the global service intermediary component.

[0052] Thus, all clusters in the cluster set send the service information that needs to be exposed to the entire cluster set to the global service broker component, and take away the service information exposed by other clusters from the global service broker component. When the global service broker component fails, it does not affect the data plane traffic distribution, because each cluster has saved the service information imported from the global service broker component. At this time, it will only affect the synchronization of subsequent service information. To solve this problem, in this embodiment, the cross-processor architecture multi-container cluster service discovery method may also include: monitoring the running status of the global service broker component, and if the global service broker component fails, enabling the pre-created backup global service broker component. That is, in this embodiment, by creating a backup global service broker component on a cluster that meets the target cluster, in any process, if it is found that the currently used global service broker component fails and no longer runs, the pre-created backup global service broker component can be enabled.

[0053] That is to say, each cluster is configured with at least one cluster proxy component, which runs on each cluster in the cluster set and can exchange service metadata with other clusters by accessing the API Server of the K8s cluster of the global service broker component. Export the service information of the current cluster and import the service information of other clusters. Specifically, the cluster proxy component in each cluster connects to the API Server of the cluster to which the global service broker component belongs. Then, for the service resources of the cross-cluster service that has been created in the local cluster, the local cluster proxy creates the corresponding shadow service and exports it to the global service broker for use by other clusters. For each service information exported to the global service broker component by other clusters, a copy is created in the local cluster.

[0054] Step S13: Obtain a service request, use a local DNS server plug-in to parse the service request according to the locally stored service information, and determine access routing information corresponding to the service request to implement service access.

[0055] In this embodiment, after obtaining the service request, the cluster uses the local DNS server plug-in to resolve the service request according to the above service information stored locally. Since the service information stores the resource access location of each service, the access routing information corresponding to the service request can be determined to achieve service access.

[0056] In this embodiment, after determining the access routing information corresponding to the service request, the method may further include: if the service request is determined to be a cross-cluster service request according to the access routing information, accessing the service through a cross-cluster tunnel according to the access routing information. That is, when it is determined to be cross-cluster traffic, access is performed through a cross-cluster tunnel, thereby achieving cross-cluster service access and service discovery.

[0057] In this embodiment, the process of obtaining a service request and utilizing a local DNS server plug-in to parse the service request according to the locally stored service information, and determining the access routing information corresponding to the service request to implement service access, may include: parsing the service request to extract the domain name field, and determining whether the domain name field is a cross-cluster service access domain name; if the domain name field is a cross-cluster service access domain name, forwarding the service request to the DNS server plug-in through the CoreDNS component; utilizing the DNS server plug-in to perform DNS resolution on the service request according to the locally stored service information, so as to determine the access routing information corresponding to the service request, so as to perform service access according to the access routing information. It is understandable that, according to the access process, cross-cluster access will carry a cross-cluster service access domain name, such as the cross-cluster service access domain name of kubernetes is clusterset.local, that is, the DNS server plug-in is an external DNS server with a clusterset.local domain name, and the CoreDNS component forwards all requests sent to clusterset.local to the DNS server plug-in, and uses the service information stored in the local cluster for DNS resolution to determine the access routing information of the actual service. The specific process is as follows: Figure 2 As shown in the figure, the Pod tries to use the domain name clusterset.local to resolve the service request. If the domain name field of the service request is clusterset.local, the service request is forwarded to the DNS server plug-in through the CoreDNS component. The DNS server plug-in then uses the stored service information for DNS resolution. If the record exists, it returns, otherwise it returns an error prompt, such as NXDomain.

[0058] As the scale of user business systems under the cloud native architecture becomes larger and larger, and due to the diversified development of processor architecture, users' cloud native businesses need to be deployed between multiple clusters across processor architectures to achieve cross-cluster service publishing and service discovery, thereby completing the deployment of complex cloud native businesses across multiple clusters of processor architectures. This application, through cluster proxy components, DNS server plug-ins, and global service intermediary components, realizes cross-processor architecture multi-container cluster service discovery, which can be mainly used for the rapid and non-differential construction of container applications between processors of different architectures, realizing the cross-processor architecture research and development and deployment of applications, reducing the difficulty of landing the container cloud platform in the current production environment where multiple architecture processors coexist, improving the smoothness of processor architecture switching, accelerating the development and implementation of cloud native, and promoting the rapid development of the industry.

[0059] As can be seen from the above, in this embodiment, a local cluster proxy component is used to generate service information of a local cluster based on local service resources, and the service information is sent to a global service broker component of the cluster set; through the cluster proxy component, service information of other clusters in the cluster set is imported from the global service broker component; a service request is obtained, and a local DNS server plug-in is used to parse the service request based on the locally stored service information, and the access routing information corresponding to the service request is determined to achieve service access. As can be seen from the above, the global service broker component of the cluster set acts as a storage intermediary for service information to receive service information sent by the cluster, and provides the obtained service information to other clusters in the cluster set. At the same time, each cluster uses the local cluster proxy component to import service information of other clusters from the global service broker component, so that each cluster can save the service information uploaded to the global service broker component by all clusters in the cluster set. After receiving the service request, the cluster uses the local DNS server plug-in to parse the service request according to the locally stored service information, and determines the access routing information corresponding to the service request to realize service access, so as to have service discovery capabilities between multi-container clusters with different architectures, support cross-cluster and cross-processor architecture deployment of applications, realize high availability of applications across clusters, accelerate the diversified development of processors, and promote the development and implementation of cloud native technologies.

[0060] Correspondingly, the embodiment of the present application also discloses a cross-processor architecture multi-container cluster service discovery device, see Figure 3 As shown, the device comprises:

[0061] A service information sending module 11 is used to generate service information of a local cluster according to local service resources by using a local cluster proxy component, and send the service information to a global service broker component of the cluster set;

[0062] A service information acquisition module 12, configured to import service information of other clusters in the cluster set from the global service intermediary component through the cluster proxy component;

[0063] The access route determination module 13 is used to obtain a service request, use a local DNS server plug-in to parse the service request according to the locally stored service information, and determine the access route information corresponding to the service request to achieve service access.

[0064] As can be seen from the above, in this embodiment, a local cluster proxy component is used to generate service information of a local cluster based on local service resources, and the service information is sent to a global service broker component of the cluster set; through the cluster proxy component, service information of other clusters in the cluster set is imported from the global service broker component; a service request is obtained, and a local DNS server plug-in is used to parse the service request based on the locally stored service information, and the access routing information corresponding to the service request is determined to achieve service access. As can be seen from the above, the global service broker component of the cluster set acts as a storage intermediary for service information to receive service information sent by the cluster, and provides the obtained service information to other clusters in the cluster set. At the same time, each cluster uses the local cluster proxy component to import service information of other clusters from the global service broker component, so that each cluster can save the service information uploaded to the global service broker component by all clusters in the cluster set. After receiving the service request, the cluster uses the local DNS server plug-in to parse the service request according to the locally stored service information, and determines the access routing information corresponding to the service request to realize service access, so as to have service discovery capabilities between multi-container clusters with different architectures, support cross-cluster and cross-processor architecture deployment of applications, realize high availability of applications across clusters, accelerate the diversified development of processors, and promote the development and implementation of cloud native technologies.

[0065] In some specific embodiments, the service information sending module 11 may specifically include:

[0066] A service resource determination unit, used to determine the service resources of the cross-cluster service created in the local cluster by querying the exposed service;

[0067] The shadow service creation unit is used to create a corresponding shadow service based on the service resource, and send the shadow service as the service information to the global service broker component of the cluster set.

[0068] In some specific embodiments, the service information acquisition module 12 may specifically include:

[0069] A shadow service acquisition unit, configured to acquire service information of other clusters in the cluster set from the global service broker component, so as to obtain shadow services corresponding to service resources in other clusters;

[0070] The copy creation unit is used to create a copy of the shadow service and store the copy locally.

[0071] In some specific embodiments, the service information sending module 11 may specifically include:

[0072] A service resource detection unit, configured to periodically detect newly created local service resources according to a first preset detection period, and generate service information of a local cluster according to the service resources;

[0073] The service information importing unit is used to periodically import service information of other clusters in the cluster set newly received by the global service broker component from the global service broker component according to a second preset detection period.

[0074] In some specific embodiments, the cross-processor architecture multi-container cluster service discovery device may specifically include:

[0075] A singleton component creation unit, configured to create a singleton component on a target cluster in the cluster set, and store the singleton component in a key-value data storage system of the target cluster; the target cluster includes an open access API;

[0076] The configuration unit is used to configure the service account and role access control information of the singleton component, define endpoint parameters and cluster parameters to obtain the global service broker component; the endpoint parameters include the IP address, and the cluster parameters include the classless inter-domain routing of the service.

[0077] In some specific embodiments, the cross-processor architecture multi-container cluster service discovery device may specifically include:

[0078] The service access unit is configured to perform service access through a cross-cluster tunnel according to the access routing information if it is determined that the service request is a cross-cluster service request according to the access routing information.

[0079] In some specific embodiments, the cross-processor architecture multi-container cluster service discovery device may specifically include:

[0080] The standby global service intermediary component activation unit is used to monitor the running state of the global service intermediary component and activate a pre-created standby global service intermediary component if the global service intermediary component fails.

[0081] In some specific embodiments, the access route determination module 13 may specifically include:

[0082] A domain name determination unit, configured to parse the service request to extract a domain name field, and determine whether the domain name field is a cross-cluster service access domain name;

[0083] A service request forwarding unit, configured to forward the service request to the DNS server plug-in through a CoreDNS component if the domain name field is a cross-cluster service access domain name;

[0084] The resolution unit is used to utilize the DNS server plug-in to perform DNS resolution on the service request according to the service information stored locally, so as to determine the access routing information corresponding to the service request, so as to perform service access according to the access routing information.

[0085] Furthermore, the present application also discloses an electronic device, see Figure 4 As shown, the contents in the drawings should not be considered as any limitation on the scope of use of the present application.

[0086] Figure 4 A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the cross-processor architecture multi-container cluster service discovery method disclosed in any of the aforementioned embodiments.

[0087] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0088] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon include an operating system 221, a computer program 222, and data 223 including service information, etc. The storage method can be temporary storage or permanent storage.

[0089] The operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, so as to realize the operation and processing of the massive data 223 in the memory 22 by the processor 21, and it can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the cross-processor architecture multi-container cluster service discovery method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0090] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0091] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0092] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0093] The above is a detailed introduction to a cross-processor architecture multi-container cluster service discovery method, device and equipment provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A cross-processor architecture multi-container cluster service discovery method, characterized in that: Applicable to clusters, including: Using the local cluster proxy component to generate service information of the local cluster according to the local service resources, and sending the service information to the global service broker component of the cluster set; Importing service information of other clusters in the cluster set from the global service broker component through the local cluster proxy component; Obtaining a service request, using a local DNS server plug-in to parse the service request according to the locally stored service information, and determining access routing information corresponding to the service request to implement service access; Wherein, at least one global service broker component is configured in a cluster set; before sending the service information to the global service broker component in the cluster set, the method further includes: Creating a singleton component on a target cluster in the cluster set, and storing the singleton component in a key-value data storage system of the target cluster; the target cluster includes an open access API; The service account and role access control information of the singleton component are configured, and endpoint parameters and cluster parameters are defined to obtain the global service broker component; the endpoint parameters include an IP address, and the cluster parameters include a classless inter-domain routing of the service.

2. The cross-processor architecture multi-container cluster service discovery method according to claim 1, characterized in that: The generating service information of the local cluster according to the local service resources and sending the service information to the global service broker component of the cluster set includes: Determine the service resources of the cross-cluster services created in the local cluster by querying the exposed services; A corresponding shadow service is created based on the service resource, and the shadow service is sent as the service information to the global service broker component of the cluster set.

3. The cross-processor architecture multi-container cluster service discovery method according to claim 1, characterized in that: The importing of service information of other clusters in the cluster set from the global service broker component includes: Acquire service information of other clusters in the cluster set from the global service broker component to obtain shadow services corresponding to service resources in other clusters; Create a copy of the shadow service and store the copy locally.

4. The cross-processor architecture multi-container cluster service discovery method according to claim 1, characterized in that: The generating the service information of the local cluster according to the local service resources includes: According to a first preset detection period, periodically detecting newly created local service resources, and generating service information of the local cluster according to the service resources; The importing of service information of other clusters in the cluster set from the global service broker component includes: According to a second preset detection period, service information of other clusters in the cluster set newly received by the global service broker component is periodically imported from the global service broker component.

5. The cross-processor architecture multi-container cluster service discovery method according to claim 1, characterized in that: After the access routing information corresponding to the service request is determined, the method further includes: If it is determined according to the access routing information that the service request is a cross-cluster service request, service access is performed through a cross-cluster tunnel according to the access routing information.

6. The cross-processor architecture multi-container cluster service discovery method according to claim 1 further comprises: The running state of the global service broker component is monitored, and if the global service broker component fails, a pre-created standby global service broker component is enabled.

7. The cross-processor architecture multi-container cluster service discovery method according to any one of claims 1 to 6, characterized in that: The obtaining of the service request, parsing the service request according to the locally stored service information using a local DNS server plug-in, and determining access routing information corresponding to the service request to implement service access, includes: Parse the service request to extract the domain name field, and determine whether the domain name field is a cross-cluster service access domain name; If the domain name field is a cross-cluster service access domain name, the service request is forwarded to the DNS server plug-in through the CoreDNS component; The DNS server plug-in is used to perform DNS resolution on the service request according to the service information stored locally, so as to determine the access routing information corresponding to the service request, so as to perform service access according to the access routing information.

8. A cross-processor architecture multi-container cluster service discovery device, characterized in that: Applicable to clusters, including: A service information sending module, used to generate service information of a local cluster according to local service resources by using a local cluster proxy component, and send the service information to a global service broker component of the cluster set; A service information acquisition module, used to import service information of other clusters in the cluster set from the global service intermediary component through the local cluster proxy component; An access route determination module is used to obtain a service request, use a local DNS server plug-in to parse the service request according to the locally stored service information, and determine the access route information corresponding to the service request to achieve service access; Among them, at least one global service broker component is configured in a cluster set, and the cross-processor architecture multi-container cluster service discovery device is also used to create a singleton component on the target cluster in the cluster set before sending the service information to the global service broker component of the cluster set, and store the singleton component in the key-value data storage system of the target cluster; the target cluster contains an open access API; configure the service account and role access control information of the singleton component, define endpoint parameters and cluster parameters to obtain the global service broker component; the endpoint parameters include the IP address, and the cluster parameters include the classless inter-domain routing of the service.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is used to execute the computer program to implement the cross-processor architecture multi-container cluster service discovery method as described in any one of claims 1 to 7.

Citation Information

Patent Citations

  • Cross-platform service system docking method and device

    CN112114977A

  • Cross-cluster data request processing method and device and storage medium

    CN113746887A