Service access methods, devices, electronic devices and storage media

Abstract

This application provides a service access method, apparatus, electronic device, and storage medium, comprising: deploying a Domain Name System (DNS) center in a central cluster, and deploying DNS sentinels in a dedicated cluster and the central cluster respectively. The dedicated cluster includes business containers and a cluster DNS system. A communication connection is established between the central cluster and the dedicated cluster through the DNS sentinels. The cluster DNS system determines whether a business container accesses a service container in the central cluster. If a business container accesses a service container in the central cluster, the target service address is obtained through the DNS center, and the service corresponding to the target service address in the service container is accessed based on the target service address. This application, by deploying a DNS center and DNS sentinels in both the central and dedicated clusters, and utilizing the DNS sentinels to establish a link between the central and dedicated clusters, enables cross-Kubernetes cluster service access in business deployment scenarios.

Description

Technical Field

[0001] This application relates to the field of K8S cluster technology, and in particular to a service access method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, containerization has become the mainstream method for modern application deployment. Kubernetes (K8S), as a container orchestration system, has become the de facto standard for container orchestration in cloud computing due to its powerful functions and flexibility. K8S not only supports rapid deployment and scaling of applications, but also provides key functions such as service discovery and load balancing, making it widely adopted by major cloud vendors.

[0003] However, as enterprise businesses continue to expand and become more complex, the demand for cross-Kubernetes cluster service deployments is gradually increasing. In scenarios where services are deployed across multiple clusters, existing intra-Kubernetes cluster service access methods cannot meet the needs of cross-cluster service access. Therefore, how to achieve cross-Kubernetes cluster service access in cross-Kubernetes cluster service deployment scenarios has become an urgent problem to be solved. Summary of the Invention

[0004] In view of the above problems, methods, apparatus, electronic devices, and storage media for providing service access that overcomes or at least partially solves the above problems have been proposed, including:

[0005] In a first aspect, embodiments of this application provide a service access method, the method comprising:

[0006] Use any cluster as the central cluster, and deploy the Domain Name System (DNS) center in the central cluster;

[0007] At least one of the clusters other than the central cluster is designated as a dedicated cluster, and a Domain Name System Sentinel, a business container, and a cluster domain name system are deployed in the dedicated cluster and the central cluster, respectively.

[0008] The communication connection between the central cluster and the dedicated cluster is established through the Domain Name System Sentinel;

[0009] Once the communication connection between the central cluster and the dedicated cluster is established, the cluster domain name system is used to determine whether the business container accesses the service container in the central cluster.

[0010] When the business container accesses a service container in the central cluster, the target service address is obtained through the Domain Name System (DNS).

[0011] Access the service in the service container corresponding to the target service address according to the target service address.

[0012] Optionally, establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes:

[0013] Obtain the configuration file of the Domain Name System Sentinel, wherein the configuration file includes the service name;

[0014] The domain name system sentinel sends a query request to the cluster domain name system, wherein the query request includes the service name;

[0015] When the cluster domain name system receives the query request, it resolves the service name to obtain the service address;

[0016] Send the service address to the Domain Name System Sentinel;

[0017] When the Domain Name System Sentinel receives the service address, it sends a registration request to the Domain Name System Center, wherein the registration request includes the service name and the service address;

[0018] Upon receiving the registration request, the Domain Name System (DNS) registers the service name and the service address, thus obtaining a registration result.

[0019] The registration result is sent to the Domain Name System Sentinel.

[0020] Optionally, the cluster includes nodes;

[0021] The step of establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes:

[0022] When the node where the Domain Name System Sentinel is located is a network element node, the service address and the cluster corresponding to the service address are sent to the pre-deployed switch through the Domain Name System Sentinel;

[0023] When the switch receives the service address and the cluster corresponding to the service address, it establishes a correspondence between the service address and the cluster and stores the correspondence between the service address and the cluster.

[0024] Optionally, establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes:

[0025] The configuration file of the cluster's domain name system is obtained through the domain name system sentinel;

[0026] Configure the upstream DNS server of the cluster DNS system in the configuration file as the DNS center;

[0027] Once the configuration is complete, the service address is obtained from the Domain Name System (DNS) center via the DNS sentinel.

[0028] When the Domain Name System Sentinel receives the service address, it configures the next hop of the service address as the switch.

[0029] Optionally, determining whether the business container accesses the service container in the central cluster through the cluster domain name system includes:

[0030] The service container sends a query request to the cluster domain name system in the dedicated cluster, wherein the query request includes the target service name;

[0031] When the cluster domain name system receives the query request, it determines whether the target service address corresponding to the target service name exists in the local cache of the cluster domain name system;

[0032] If the target service address corresponding to the target service name exists in the local cache, it is determined that the business container stops accessing the service container in the central cluster;

[0033] If the target service address corresponding to the target service name does not exist in the local cache, it is determined that the business container accesses the service container in the central cluster.

[0034] Optionally, obtaining the target service address through the Domain Name System (DNS) includes:

[0035] The query request is sent to the domain name system center through the cluster domain name system;

[0036] Upon receiving the query request, the Domain Name System Center obtains the target service address corresponding to the target service name;

[0037] Send the target service address corresponding to the target service name to the cluster domain name system;

[0038] Upon receiving the target service address from the cluster domain name system, the target service address is sent to the business container.

[0039] Optionally, the central cluster includes a Domain Name System (DNS) sentinel container and a service container;

[0040] The step of accessing the service in the service container corresponding to the target service address based on the target service address includes:

[0041] Upon receiving the target service address, the service container generates a target message containing the target service address.

[0042] Send the target message to the switch;

[0043] When the switch receives the target packet, it determines whether the cluster corresponding to the target service address is the central cluster based on the target service address and the correspondence between the service address and the cluster.

[0044] If the cluster corresponding to the target service address is the central cluster, the target packet is sent to the Domain Name System Sentinel Container;

[0045] When the Domain Name System Sentinel container receives the target message, it sends the target message to the service container so that the services in the service container can access the services in the service container.

[0046] Secondly, embodiments of this application provide a service access device, the device comprising:

[0047] The Domain Name System (DNS) Central Deployment Module is used to deploy the DNS in any cluster as a central cluster.

[0048] The Domain Name System Sentinel Deployment Module is used to treat at least one of the clusters other than the central cluster as a dedicated cluster, and to deploy the Domain Name System Sentinel, business containers and cluster domain name system in the dedicated cluster and the central cluster respectively.

[0049] The Domain Name System Sentinel Configuration Module is used to establish a communication connection between the central cluster and the dedicated cluster through the Domain Name System Sentinel.

[0050] The cross-cluster access determination module is used to determine, through the cluster domain name system, whether the business container accesses the service container in the central cluster after the communication connection between the central cluster and the dedicated cluster has been established.

[0051] The service address determination module is used to obtain the target service address through the Domain Name System (DNS) when the business container accesses a service container in the central cluster.

[0052] The target service access module is used to access the service in the service container corresponding to the target service address based on the target service address.

[0053] Thirdly, embodiments of this application also provide an electronic device, including: a processor; and a memory for storing processor-executable instructions, wherein the processor is configured to execute the instructions to implement any of the service access methods described above.

[0054] Fourthly, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform any of the service access methods described above.

[0055] In this embodiment, any one cluster is designated as the central cluster, and a Domain Name System (DNS) center is deployed within it. At least one cluster outside the central cluster is designated as a dedicated cluster, and DNS sentinels are deployed in both the dedicated and central clusters. Each dedicated cluster includes service containers and a cluster DNS system. A communication connection is established between the central and dedicated clusters via the DNS sentinels. Once this connection is established, the cluster DNS system determines whether a service container is accessing a service container in the central cluster. If so, the DNS center obtains the target service address, and the service corresponding to that address is accessed within the service container. This application, by deploying a DNS center and DNS sentinels in both the central and dedicated clusters, and utilizing the DNS sentinels to establish a link between them, enables cross-Kubernetes cluster service access in cross-Kubernetes cluster deployment scenarios. Furthermore, services can be accessed across clusters simply by using the service address, allowing users to access services across clusters without requiring code modifications at the business level or configuration changes at the operational deployment level – essentially achieving seamless cross-cluster service access. In addition, by establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System Sentinel, maintenance personnel no longer need to manually specify IPs (Internet Protocol) and ports, which reduces the complexity of maintenance and improves the maintainability of the system.

[0056] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0057] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0058] Figure 1 This is one of the flowcharts of a service access method provided in an embodiment of this application;

[0059] Figure 2 This is a schematic diagram illustrating a scenario where some services in a central cluster are deployed in a dedicated cluster, as provided in this application.

[0060] Figure 3 This is a schematic diagram of the workflow of a Domain Name System (DNS) center provided in an embodiment of this application;

[0061] Figure 4 This is a schematic diagram illustrating a service registration method provided in this application.

[0062] Figure 5 This is a schematic diagram of the workflow of a Domain Name System Sentinel provided in this application;

[0063] Figure 6 This is a schematic diagram of a service address routing advertisement provided in this application.

[0064] Figure 7 This is a schematic diagram illustrating a service address lookup method provided by this application.

[0065] Figure 8 This is a schematic diagram of the workflow for providing a service address query in this application.

[0066] Figure 9 This is a schematic diagram illustrating a cross-cluster access service container provided in this application.

[0067] Figure 10 This is a device block diagram of a service access device provided in an embodiment of this application;

[0068] Figure 11 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0069] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0070] To facilitate understanding, the terminology used in the embodiments of this application will be briefly introduced first.

[0071] 1. K8S (Kubernetes) cluster

[0072] Kubernetes (K8S) is a container orchestration tool, an open-source system for automatically deploying, scaling, and managing containerized applications.

[0073] 2. DNS (Domain Name System)

[0074] DNS is a distributed database on the Internet that maps domain names to IP addresses, enabling users to access the Internet more conveniently without having to remember the IP address strings that can be directly read by machines. The process of obtaining the IP address corresponding to a hostname is called domain name resolution (or hostname resolution). The DNS protocol runs on top of the UDP protocol, using port number 53.

[0075] 3. BGP (Border Gateway Protocol)

[0076] BGP is a core decentralized autonomous routing protocol on the Internet.

[0077] 4. CIDR (Classless Inter-Domain Routing)

[0078] CIDR eliminates the traditional Class A, B, and C addresses and the concept of subnetting, thus allowing for more efficient allocation of IPv4 address space. It can combine several IP networks using a classless inter-domain routing algorithm, merging them into a single route, thereby reducing the number of routing entries in routing tables and alleviating the burden on Internet routers.

[0079] 5. Service Name

[0080] Service name is a concept in Kubernetes clusters, equivalent to a domain name in DNS.

[0081] 6. Service Address

[0082] The service address is a concept in Kubernetes clusters, equivalent to the IP address in DNS.

[0083] The following detailed description, in conjunction with the accompanying drawings, of a service access method, apparatus, storage medium, and vehicle provided in this application, through specific embodiments and application scenarios, illustrates in detail an example of such an application.

[0084] Figure 1This is a flowchart illustrating the steps of a service access method provided in an embodiment of this application, such as... Figure 1 As shown, the method includes:

[0085] Step 101: Select any cluster as the central cluster and deploy the Domain Name System (DNS) center in the central cluster.

[0086] Step 102: Designate at least one cluster other than the central cluster as a dedicated cluster, and deploy the Domain Name System Sentinel, business container and cluster domain name system in the dedicated cluster and the central cluster respectively.

[0087] It should be noted that, in this embodiment of the application, the cluster can be a Kubernetes (K8S) cluster.

[0088] The application scenario of this application is that some services in a Kubernetes cluster are deployed in other Kubernetes clusters besides the Kubernetes cluster itself, such as... Figure 2 As shown, the management platform in a Kubernetes cluster can be deployed on other Kubernetes clusters besides the current one, and the Kubernetes cluster where the management platform is deployed can be a general-purpose computing Kubernetes cluster; the compute-intensive services in a Kubernetes cluster can be deployed on other Kubernetes clusters besides the current one, and the Kubernetes cluster where the compute-intensive services are deployed can be a compute-intensive Kubernetes cluster; the high-IO (Input / Output) services in a Kubernetes cluster can be deployed on other Kubernetes clusters besides the current one, and the Kubernetes cluster where the high-IO services are deployed can be a high-IO type Kubernetes cluster; the heterogeneous computing services in a Kubernetes cluster can be deployed on other Kubernetes clusters besides the current one, and the Kubernetes cluster where the heterogeneous computing services are deployed can be a heterogeneous Kubernetes cluster.

[0089] In this application scenario, where some services in a K8S cluster are deployed on other K8S clusters, the K8S cluster can be used as the central cluster, and the other K8S clusters can be used as dedicated clusters.

[0090] To ensure that service containers in the dedicated cluster can access service containers in the central cluster, after setting up the central cluster and the dedicated cluster, you can deploy DNS-central in the central cluster, and DNS-sentinel, service containers and coredns in the dedicated cluster and the central cluster, respectively.

[0091] After completing the deployment of the Domain Name System (DNS) center, such as Figure 3As shown, when the Domain Name System (DNS) starts up, it sends a query request to the cluster DNS in the Kubernetes cluster. This query request includes the DNS's service name. Upon receiving the query request, the cluster DNS resolves the DNS's service name to obtain its service address and sends this address back to the DNS. Once the DNS receives the service address, it stores both the service name and address as the first record in the DNS and manages them.

[0092] In addition, the Domain Name System (DNS) regularly organizes the stored service names and service addresses, and performs CIDR (Classless InterDomain Routing) aggregation on the service addresses.

[0093] Furthermore, if a new cluster needs to be added, only the Domain Name System Sentinel needs to be deployed in the new cluster to complete the registration of service names and service addresses, as well as the announcement of service address routes, thereby enabling seamless migration or expansion of services.

[0094] Step 103: Establish a communication connection between the central cluster and the dedicated cluster through the Domain Name System Sentinel.

[0095] Step 104: After establishing a communication connection between the central cluster and the dedicated cluster, determine whether the business container accesses the service container in the central cluster through the cluster domain name system.

[0096] Step 105: In the case of a service container in the business container access center cluster, obtain the target service address through the Domain Name System (DNS) center.

[0097] Step 106: Access the service in the service container that corresponds to the target service address based on the target service address.

[0098] It should be noted that, in this embodiment, after deploying the Domain Name System (DNS) sentinel, the DNS sentinel is used to establish a link between the central cluster and the dedicated cluster, i.e., to establish a communication connection between the central cluster and the dedicated cluster. Once the communication connection is established, the DNS determines whether the business containers in the dedicated cluster need to access service containers in the central cluster across the Kubernetes cluster. If the determination result indicates that the business containers in the dedicated cluster need to access service containers in the central cluster across the Kubernetes cluster, the business containers will query the DNS for the target service address. Once the business containers obtain the target service address, they will access the service in the service container corresponding to the target service address.

[0099] This application deploys a Domain Name System (DNS) hub and a DNS sentinel in both the central and dedicated clusters. The DNS sentinel establishes a link between the central and dedicated clusters, enabling cross-Kubernetes (K8S) service access in business deployment scenarios. Services can be accessed across clusters simply by using the service address, allowing users to access services without requiring code changes at the business level or configuration modifications at the operational level – essentially achieving seamless cross-cluster service access. Furthermore, by establishing a communication connection between the central and dedicated clusters through the DNS sentinel, operations personnel no longer need to manually specify IP addresses and ports, reducing operational complexity and improving system maintainability.

[0100] Furthermore, in this embodiment of the application, step 103 may further include the following steps:

[0101] Sub-step 11: Obtain the DNS Sentinel configuration file, which includes the service name.

[0102] Sub-step 12: Send a query request to the cluster domain name system through the domain name system sentinel. The query request includes the service name.

[0103] Sub-step 13: When the cluster domain name system receives a query request, it resolves the service name to obtain the service address.

[0104] Sub-step 14: Send the service address to the Domain Name System Sentinel.

[0105] Sub-step 15: Once the Domain Name System Sentinel receives the service address, it sends a registration request to the Domain Name System Center, whereby the registration request includes the service name and service address.

[0106] Sub-step 16: Upon receiving a registration request from the Domain Name System Center, register the service name and service address to obtain the registration result.

[0107] Sub-step 17: Send the registration result to the Domain Name System Sentinel.

[0108] It should be noted that, in the embodiments of this application, as Figure 4 As shown, after the DNS Sentinel is deployed, it will register the information of the services that need to be exposed with the DNS Center. This information includes the service name and service address.

[0109] The specific implementation process of the Domain Name System Sentinel registering information about services that need to be exposed with the Domain Name System Center is as follows: Figure 5As shown, the Domain Name System (DNS) Sentinel first sends a configuration file retrieval request to the backend component kube-apiserver in the Kubernetes cluster. Upon receiving the request, kube-apiserver sends the DNS Sentinel's configuration file (configmap), which includes information about the services to be exposed (service name and service address).

[0110] When the DNS sentinel receives the configuration file from the kube-apiserver, it sends a query request to the cluster DNS, which includes the service name from the configuration file. Upon receiving the query request, the cluster DNS resolves the service name to its corresponding service address and sends this address back to the DNS sentinel. Once the DNS sentinel receives the service address, it sends a registration request to the DNS central office, which includes both the service name and the service address. Upon receiving the registration request, the DNS central office registers the service name and address, generates a registration result, and sends it back to the DNS sentinel.

[0111] This application registers the information of the services to be exposed with the cluster's DNS system through a DNS sentinel. This information includes the service name and service address, ensuring that services within the Kubernetes cluster are only exposed through the node where the DNS sentinel resides, making the data flow clear and controllable. Simultaneously, it avoids host port number contention, thus preventing the additional security maintenance and host port conflicts associated with host port exposure.

[0112] Furthermore, in this embodiment of the application, step 103 may further include the following steps:

[0113] Sub-step 21: If the node where the Domain Name System Sentinel is located is a network element node, the service address and the cluster corresponding to the service address are sent to the pre-deployed switch through the Domain Name System Sentinel.

[0114] Sub-step 22: When the switch receives the service address and the cluster corresponding to the service address, it establishes the correspondence between the service address and the cluster and stores the correspondence between the service address and the cluster.

[0115] It should be noted that, in this embodiment of the application, after the deployment of the Domain Name System Sentinel is completed, such as Figure 6As shown, the Domain Name System Sentinel announces the routing information of the service addresses that need to be exposed to the switch through BGP (Border Gateway Protocol), that is, it announces the service address routes to the switch.

[0116] Specifically, a Kubernetes cluster contains several nodes, each with a Domain Name System (DNS) Sentinel container deployed on it. The DNS Sentinel container contains the DNS Sentinel itself. If the node hosting the DNS Sentinel is a network element node, the DNS Sentinel sends the routing information of the service addresses to be exposed—that is, the service addresses and the corresponding clusters—to a pre-deployed switch. Upon receiving the service addresses and their corresponding clusters, the switch establishes a mapping between the service addresses and clusters, and records and stores this mapping.

[0117] This application achieves automatic configuration of cross-cluster routing through the collaboration of the Domain Name System (DNS) sentinel and the switch, enabling services to continue using service names and transparently access services via service addresses in cross-cluster scenarios. This approach not only enhances business flexibility but also provides strong support for business expansion, allowing enterprises to migrate services and access services across Kubernetes clusters without modifying business code or operational configurations.

[0118] Furthermore, in this embodiment of the application, step 103 may further include the following steps:

[0119] Sub-step 31: Obtain the cluster domain name system configuration file through the domain name system sentinel.

[0120] Sub-step 32: Configure the upstream DNS server of the cluster DNS system in the configuration file as the DNS center.

[0121] Sub-step 33: After completing the configuration, obtain the service address from the Domain Name System Center through the Domain Name System Sentinel.

[0122] Sub-step 34: If the Domain Name System Sentinel receives the service address, configure the next hop of the service address as a switch.

[0123] It should be noted that, in this embodiment of the application, after the deployment of the Domain Name System Sentinel is completed, such as Figure 5As shown, the Domain Name System (DNS) Sentinel sends a configuration file retrieval request to the backend component kube-apiserver in the Kubernetes cluster. Upon receiving the request, kube-apiserver forwards the cluster's DNS configuration file to the DNS Sentinel. Once the DNS Sentinel receives the configuration file, it sets the upstream DNS server for the cluster's DNS in the configuration file to the DNS center.

[0124] Furthermore, because the Domain Name System (DNS) periodically summarizes service addresses for CIDRs, it obtains CIDR information, such as... Figure 5 As shown, the DNS sentinel also periodically retrieves CIDR information, i.e., service addresses, from the DNS center. Upon receiving a service address, the DNS sentinel configures the next hop of the service address to a switch to ensure that the service address is sent to the switch rather than the local end.

[0125] This application establishes a communication connection between the dedicated cluster and the central cluster by configuring the upstream DNS server of the cluster DNS system as the DNS center, ensuring that queries can be performed through the cluster DNS system even when the service address cannot be obtained from the cluster DNS system. Furthermore, this application configures the next hop of the service address as a switch, ensuring that the service address is sent to the switch rather than the local end, thereby enabling cross-cluster service access through the switch.

[0126] Furthermore, in this embodiment of the application, step 104 may further include the following steps:

[0127] Sub-step 41: Send a query request to the cluster domain name system in the dedicated cluster through the business container, wherein the query request includes the target service name;

[0128] Sub-step 42: When the cluster domain name system receives a query request, determine whether the target service address corresponding to the target service name exists in the local cache of the cluster domain name system.

[0129] Sub-step 43: If the target service address corresponding to the target service name exists in the local cache, determine that the business container stops accessing the service container in the central cluster.

[0130] Sub-step 44: If the target service address corresponding to the target service name does not exist in the local cache, determine the service container in the central cluster that the business container accesses.

[0131] It should be noted that, in the embodiments of this application, as Figure 7As shown, in order to determine whether a business container in a dedicated cluster needs to access a service container in the central cluster across K8S clusters, the business container in the dedicated cluster will query the cluster domain name system in the dedicated cluster for the service address.

[0132] Specifically, such as Figure 8 As shown, the business container sends a query request to the cluster domain name system, which includes the target service name. Upon receiving the query request, the cluster domain name system checks whether the target service address corresponding to the target service name exists in its local cache.

[0133] If the target service address corresponding to the target service name exists in the local cache of the cluster's domain name system, then it is determined that the business containers in the dedicated cluster do not need to access the service containers in the central cluster across the Kubernetes cluster. If the target service address corresponding to the target service name does not exist in the local cache of the cluster's domain name system, then it is determined that the business containers in the dedicated cluster need to access the service containers in the central cluster across the Kubernetes cluster.

[0134] This application determines whether a business container in a dedicated cluster needs to access a service container in the central cluster across Kubernetes clusters by querying the local cache of the cluster's domain name system to check if the target service address corresponding to the target service name exists. This not only reduces unnecessary cross-cluster access, thereby lowering network latency and improving service response speed, but also enables rapid service access decisions, allowing businesses to continue using service names and transparently access services via service addresses in cross-cluster scenarios. This approach simplifies the complexity of business migration and avoids code modifications at the business level and configuration changes at the operation and maintenance deployment level, achieving seamless business migration.

[0135] Furthermore, in this embodiment of the application, step 105 may further include the following steps:

[0136] Sub-step 51: Send the query request to the Domain Name System Center through the cluster domain name system.

[0137] Sub-step 52: Upon receiving a query request from the Domain Name System Center, obtain the target service address corresponding to the target service name.

[0138] Sub-step 53: Send the target service address corresponding to the target service name to the cluster domain name system.

[0139] Sub-step 54: If the cluster domain name system receives the target service address, send the target service address to the business container.

[0140] It should be noted that, in the embodiments of this application, as Figure 8As shown, if the target service address corresponding to the target service name does not exist in the local cache of the cluster's DNS system, it indicates that the business container in the dedicated cluster needs to access the service container in the central cluster across the Kubernetes cluster. The cluster's DNS system will then send a query request to the DNS center, which will then perform the service address lookup. Upon receiving the query request from the cluster's DNS system, the DNS center will retrieve the target service address corresponding to the target service name included in the query request and send the retrieved target service address back to the cluster's DNS system. Upon receiving the target service address from the DNS center, the cluster's DNS system will return the received target service address to the business container.

[0141] This application, when the target service address corresponding to the target service name does not exist in the local cache of the cluster domain name system, further queries the service address through the domain name system center and sends the target service address to the business container. By centrally managing the service address through the domain name system center, it achieves fast service address query, which not only improves the efficiency of service address query, improves the reliability and stability of the system, realizes the seamless migration of business, but also enhances the flexibility and scalability of the business.

[0142] Furthermore, in this embodiment of the application, step 106 may further include the following steps:

[0143] Sub-step 61: If the service container receives the target service address, generate a target message containing the target service address.

[0144] Sub-step 62: Send the target packet to the switch.

[0145] Sub-step 63: When the switch receives the target packet, it determines whether the cluster corresponding to the target service address is the central cluster based on the correspondence between the target service address and the service address and the cluster.

[0146] Sub-step 64: If the cluster corresponding to the target service address is the central cluster, send the target packet to the Domain Name System Sentinel Container.

[0147] Sub-step 65: If the Domain Name System Sentinel Container receives the target message, it sends the target message to the service container so that the business in the business container can access the service in the service container.

[0148] It should be noted that, in the embodiments of this application, as Figure 9As shown, when a service container in a dedicated cluster receives a target service address from the Domain Name System (DNS), it generates a target packet containing the target service address and sends the target packet to the physical machine where the service container resides. Upon receiving the target packet, the physical machine where the service container resides forwards it to a switch via the physical network. This switch can be a Layer 3 switch.

[0149] Because the switch records and stores the mapping between service addresses and clusters, when the switch receives a target packet sent by the physical machine where the service container resides, the switch will query the corresponding cluster based on the target service address and the mapping between the service address and the cluster in the target packet. Based on the queried cluster, the switch will determine whether the queried cluster is the central cluster. If the queried cluster is the central cluster, the switch will send the target packet to the physical machine in the central cluster.

[0150] When a physical machine in the central cluster receives a target packet, it forwards the packet to a Domain Name System (DNS) Sentinel container deployed on that machine. The DNS Sentinel container contains a DNS Sentinel instance. Upon receiving the target packet, the DNS Sentinel container forwards it to the physical machine hosting the service container via the container network. The physical machine, upon receiving the target packet, forwards it to the service container, which contains the service itself, enabling business applications within the business containers to access the services within the service container.

[0151] This application enables cross-cluster service access by sending a target packet containing the target service address to a switch when the service container receives the target service address. The switch then forwards the target to the service container in the central cluster, allowing services to continue using service names and transparently access services via service addresses in cross-cluster scenarios. This approach not only simplifies the complexity of service migration but also avoids code modifications at the business level and configuration changes at the operation and maintenance deployment level, achieving seamless service migration.

[0152] Corresponding to the method provided in the above-described service access method embodiments of this application, see also: Figure 10 This application also provides a device block diagram of a service access apparatus. In this embodiment, the apparatus includes:

[0153] Domain Name System Center Deployment Module 1001 is used to deploy the Domain Name System Center in any cluster as a central cluster.

[0154] Domain Name System Sentinel Deployment Module 1002 is used to treat at least one of the clusters other than the central cluster as a dedicated cluster, and to deploy a Domain Name System Sentinel, a business container and a cluster domain name system in the dedicated cluster and the central cluster respectively.

[0155] Domain Name System Sentinel Configuration Module 1003 is used to establish a communication connection between the central cluster and the dedicated cluster through the Domain Name System Sentinel;

[0156] The cross-cluster access determination module 1004 is used to determine, through the cluster domain name system, whether the business container accesses the service container in the central cluster after the communication connection between the central cluster and the dedicated cluster has been established.

[0157] The service address determination module 1005 is used to obtain the target service address through the domain name system center when the business container accesses the service container in the central cluster.

[0158] The target service access module 1006 is used to access the service in the service container corresponding to the target service address according to the target service address.

[0159] Optionally, the Domain Name System Sentinel Configuration Module 1003 includes:

[0160] The first configuration file retrieval submodule is used to retrieve the configuration file of the Domain Name System Sentinel, where the configuration file includes the service name;

[0161] The first query request sending submodule is used to send query requests to the cluster domain name system through the domain name system sentinel, wherein the query request includes the service name;

[0162] The first service name resolution submodule is used to resolve the service name and obtain the service address when the cluster domain name system receives a query request;

[0163] The service address sending submodule is used to send the service address to the Domain Name System Sentinel;

[0164] The registration request sending submodule is used to send a registration request to the Domain Name System Center when the Domain Name System Sentinel receives the service address. The registration request includes the service name and service address.

[0165] The registration submodule is used to register the service name and service address and obtain the registration result when the Domain Name System receives a registration request;

[0166] The registration result sending submodule is used to send the registration result to the Domain Name System Sentinel.

[0167] Optionally, the cluster includes nodes;

[0168] Domain Name System Sentinel Configuration Module 1003 includes:

[0169] The Service Address Routing Proclamation submodule is used to send the service address and the cluster corresponding to the service address to the pre-deployed switch through the Domain Name System Sentinel when the node where the Domain Name System Sentinel is located is a network element node;

[0170] The service address routing storage submodule is used to establish the mapping relationship between service addresses and clusters when the switch receives a service address and the corresponding cluster, and to store the mapping relationship between service addresses and clusters.

[0171] Optionally, the Domain Name System Sentinel Configuration Module 1003 includes:

[0172] The second configuration file acquisition submodule is used to obtain the configuration file of the cluster's domain name system through the domain name system sentinel;

[0173] The upstream DNS server configuration submodule is used to configure the upstream DNS server of the cluster DNS system in the configuration file as the DNS center;

[0174] The service address acquisition submodule is used to obtain the service address from the Domain Name System Center through the Domain Name System Sentinel after the configuration is completed;

[0175] The service address configuration submodule is used to configure the next hop of the service address as a switch when the Domain Name System Sentinel receives the service address.

[0176] Optionally, the cross-cluster access determination module 1004 includes:

[0177] The second query request sending submodule is used to send query requests to the cluster domain name system in the dedicated cluster through the business container. The query request includes the target service name.

[0178] The data judgment submodule is used to determine whether the target service address corresponding to the target service name exists in the local cache of the cluster domain name system when the cluster domain name system receives a query request.

[0179] The first data judgment result submodule is used to determine whether the business container should stop accessing the service container in the central cluster if the target service address corresponding to the target service name exists in the local cache.

[0180] The second data judgment result submodule is used to determine the service container in the central cluster that the business container accesses when the target service address corresponding to the target service name does not exist in the local cache.

[0181] Optionally, the service address determination module 1005 includes:

[0182] The third query request sending submodule is used to send query requests to the Domain Name System Center through the cluster domain name system;

[0183] The target service address acquisition submodule is used to obtain the target service address corresponding to the target service name when the Domain Name System Center receives a query request;

[0184] The first target service address sending submodule is used to send the target service address corresponding to the target service name to the cluster domain name system;

[0185] The second target service address sending submodule is used to send the target service address to the business container when the cluster domain name system receives the target service address.

[0186] Optionally, the central cluster includes Domain Name System Sentinel containers and service containers;

[0187] Target service access module 1006 includes:

[0188] The target message generation submodule is used to generate a target message containing the target service address when the business container receives the target service address.

[0189] The first target message sending submodule is used to send the target message to the switch;

[0190] The cluster determination submodule is used to determine whether the cluster corresponding to the target service address is the central cluster based on the correspondence between the target service address and the service address and the cluster when the switch receives the target packet.

[0191] The second target message sending submodule is used to send the target message to the Domain Name System Sentinel Container when the cluster corresponding to the target service address is the central cluster.

[0192] The cross-cluster access service submodule is used to send the target packet to the service container when the DNS sentinel container receives the target packet, so that the business in the business container can access the service in the service container.

[0193] Figure 11 This is a structural diagram of an electronic device M00 provided in an embodiment of this application. In the diagram, the electronic device M00 includes a processor M01 and a memory M02. The memory M02 stores a program or instructions that can run on the processor M01. When the program or instructions are executed by the processor M01, they implement the various steps of the above-described service access method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0194] In embodiments of this application, the memory M02 can be used to store software programs and various data. The memory M02 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, applications or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory M02 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory M02 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0195] The processor M01 may include one or more processing units; optionally, the processor M01 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor M01.

[0196] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described service access method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0197] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0198] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above service access method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0199] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0200] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A service access method, characterized in that, The method includes: Use any cluster as the central cluster, and deploy the Domain Name System (DNS) center in the central cluster; At least one of the clusters other than the central cluster is designated as a dedicated cluster, and a Domain Name System Sentinel, a business container, and a cluster domain name system are deployed in the dedicated cluster and the central cluster, respectively. The communication connection between the central cluster and the dedicated cluster is established through the Domain Name System Sentinel; Once the communication connection between the central cluster and the dedicated cluster is established, the cluster domain name system is used to determine whether the business container accesses the service container in the central cluster. When the business container accesses a service container in the central cluster, the target service address is obtained through the Domain Name System (DNS). Access the service in the service container corresponding to the target service address according to the target service address.

2. The method according to claim 1, characterized in that, The step of establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes: Obtain the configuration file of the Domain Name System Sentinel, wherein the configuration file includes the service name; The domain name system sentinel sends a query request to the cluster domain name system, wherein the query request includes the service name; When the cluster domain name system receives the query request, it resolves the service name to obtain the service address; Send the service address to the Domain Name System Sentinel; When the Domain Name System Sentinel receives the service address, it sends a registration request to the Domain Name System Center, wherein the registration request includes the service name and the service address; Upon receiving the registration request, the Domain Name System (DNS) registers the service name and the service address, thus obtaining a registration result. The registration result is sent to the Domain Name System Sentinel.

3. The method according to claim 2, characterized in that, The cluster includes nodes; The step of establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes: When the node where the Domain Name System Sentinel is located is a network element node, the service address and the cluster corresponding to the service address are sent to the pre-deployed switch through the Domain Name System Sentinel; When the switch receives the service address and the cluster corresponding to the service address, it establishes a correspondence between the service address and the cluster and stores the correspondence between the service address and the cluster.

4. The method according to claim 3, characterized in that, The step of establishing a communication connection between the central cluster and the dedicated cluster through the Domain Name System sentinel includes: The configuration file of the cluster's domain name system is obtained through the domain name system sentinel; Configure the upstream DNS server of the cluster DNS system in the configuration file as the DNS center; Once the configuration is complete, the service address is obtained from the Domain Name System (DNS) center via the DNS sentinel. When the Domain Name System Sentinel receives the service address, it configures the next hop of the service address as the switch.

5. The method according to claim 1, characterized in that, The step of determining whether the business container accesses the service container in the central cluster through the cluster domain name system includes: The service container sends a query request to the cluster domain name system in the dedicated cluster, wherein the query request includes the target service name; When the cluster domain name system receives the query request, it determines whether the target service address corresponding to the target service name exists in the local cache of the cluster domain name system; If the target service address corresponding to the target service name exists in the local cache, it is determined that the business container stops accessing the service container in the central cluster; If the target service address corresponding to the target service name does not exist in the local cache, it is determined that the business container accesses the service container in the central cluster.

6. The method according to claim 5, characterized in that, The step of obtaining the target service address through the Domain Name System (DNS) includes: The query request is sent to the domain name system center through the cluster domain name system; Upon receiving the query request, the Domain Name System Center obtains the target service address corresponding to the target service name; Send the target service address corresponding to the target service name to the cluster domain name system; Upon receiving the target service address from the cluster domain name system, the target service address is sent to the business container.

7. The method according to claim 3, characterized in that, The central cluster includes a Domain Name System sentinel container and a service container; The step of accessing the service in the service container corresponding to the target service address based on the target service address includes: Upon receiving the target service address, the service container generates a target message containing the target service address. Send the target message to the switch; When the switch receives the target packet, it determines whether the cluster corresponding to the target service address is the central cluster based on the target service address and the correspondence between the service address and the cluster. If the cluster corresponding to the target service address is the central cluster, the target packet is sent to the Domain Name System Sentinel Container; When the Domain Name System Sentinel container receives the target message, it sends the target message to the service container so that the services in the service container can access the services in the service container.

8. A service access device, characterized in that, The device includes: The Domain Name System (DNS) Central Deployment Module is used to deploy the DNS in any cluster as a central cluster. The Domain Name System Sentinel Deployment Module is used to treat at least one of the clusters other than the central cluster as a dedicated cluster, and to deploy the Domain Name System Sentinel, business containers and cluster domain name system in the dedicated cluster and the central cluster respectively. The Domain Name System Sentinel Configuration Module is used to establish a communication connection between the central cluster and the dedicated cluster through the Domain Name System Sentinel. The cross-cluster access determination module is used to determine, through the cluster domain name system, whether the business container accesses the service container in the central cluster after the communication connection between the central cluster and the dedicated cluster has been established. The service address determination module is used to obtain the target service address through the Domain Name System (DNS) when the business container accesses a service container in the central cluster. The target service access module is used to access the service in the service container corresponding to the target service address based on the target service address.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the service access method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the service access method as described in any one of claims 1 to 7.

Images