Cross-Kubernetes cluster service access method and device, computer equipment and storage medium

Abstract

The invention relates to a cross-Kubernetes cluster service access method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: respectively setting an Ingress Nginx controller in a service providing cluster and a service consumption cluster; using a NodePort mode to set an access path used for providing use permission of an Ingress Nginx controller for an external cluster of the service providing cluster or the service consuming cluster; a Kube-apiserver is used to monitor a service updating state with an annotation mark in the service providing cluster; when it is determined that the new service appears in the service providing cluster, an Ingress access rule is created in the service providing cluster, and the Ingress access rule is used for determining a target service consumption cluster with the access permission; and starting an IP address resolution plug-in in the target service consumption cluster, and accessing the new service through a domain name access mode. By adopting the method, the new service limitation can be exposed to the specified cluster, and the cross-cluster service access efficiency and reliability are improved.

Description

Technical Field

[0001] The present application relates to the field of cloud service technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for accessing services across Kubernetes clusters. Background Art

[0002] With the rapid development of cloud computing technology, Kubernetes, as a container cluster orchestration management system, has been widely used to manage containerized workloads and services. In a multi-cloud and multi-cluster environment, a single Kubernetes cluster is difficult to meet the needs of complex scenarios such as multi-active in the same city and disaster recovery in different locations. Therefore, multi-cloud and multi-cluster has become a new trend. In this context, when a local cluster application fails, it becomes particularly important to access services and applications in a remote cluster across clusters.

[0003] Traditional cross-cluster service access mainly relies on the open source component Submariner, but it has the following problems: newly created services are exposed to all clusters at the same time, and exposure to specified clusters cannot be restricted; too many components need to be introduced and installed in each cluster, such as lighthouse-coredns, lighthouse-agent, routeagent, gateway, etc. At the same time, multiple tunnels are built between clusters, and the networking structure is too complex, which consumes more resources for clusters with smaller scale and fewer nodes, and has high troubleshooting costs.

[0004] In view of the above problems, the present invention proposes a method and device for cross-Kubernetes cluster service access, which can limit the exposure of newly created services to specified clusters and improve the efficiency and reliability of cross-cluster service access. Summary of the invention

[0005] Based on this, it is necessary to provide a cross-Kubernetes cluster service access method, device, computer equipment, computer-readable storage medium and computer program product that can limit the exposure of newly created services to specified clusters and improve the efficiency and reliability of cross-cluster service access in response to the above technical problems.

[0006] In a first aspect, the present application provides a method for accessing services across Kubernetes clusters, including:

[0007] Obtain a list including at least one Kubernetes cluster, where types of the Kubernetes cluster include a service providing cluster and a service consuming cluster;

[0008] Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively;

[0009] Using the NodePort method, an access path is set, where the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0010] Using the Kube-apiserver server, monitor the update status of the service with annotated tags in the service provider cluster;

[0011] In a case where it is determined based on the service update status that a new service appears in the service providing cluster, creating an Ingress access rule in the service providing cluster, the Ingress access rule being used to determine a target service consuming cluster with access rights;

[0012] The IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by the Ingress Nginx controller through domain name access.

[0013] In one embodiment, before accessing the newly created service by using the Ingress Nginx controller through the domain name access method, the method further includes:

[0014] Using the Kube-apiserver server, create a service object with the same name as the newly created service in the namespace of the target service consumption cluster;

[0015] Set the node IP address of the service provider cluster in the external IP address list;

[0016] A DNS record is created so that the access domain name of the service object after being resolved matches the node IP address of the service providing cluster.

[0017] In one embodiment, the IP address resolution plug-in includes a k8s_external resolution plug-in; starting the IP address resolution plug-in in the target service consumption cluster, and accessing the newly created service by using an Ingress Nginx controller through a domain name access method, includes:

[0018] In the core DNS configuration file, configure the k8s_external resolution plug-in;

[0019] Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster;

[0020] The newly created service is accessed using the Ingress Nginx controller based on the node IP address of the service provider cluster.

[0021] In one embodiment, starting the k8s_external parsing plug-in in the target service consumption cluster includes:

[0022] Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS server in the Kube-system namespace;

[0023] When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, the k8s_external parsing plug-in is started in the target service consumption cluster.

[0024] In one embodiment, the method further comprises:

[0025] When the service providing cluster removes the newly created service, the access domain name of the corresponding service object is removed.

[0026] In one of the embodiments, the cluster access controller is deployed independently or in the form of a workload inside any one of the service providing cluster and the service consuming cluster.

[0027] In a second aspect, the present application also provides a cross-Kubernetes cluster service access device, including:

[0028] An acquisition module is used to acquire a list containing at least one Kubernetes cluster, where the types of the Kubernetes cluster include a service providing cluster and a service consuming cluster;

[0029] A setting module, used to set an IngressNginx controller in the service providing cluster and the service consuming cluster respectively;

[0030] The setting module is further used to set an access path by using the NodePort method, wherein the access path is used to provide the use permission of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0031] A control module, used to monitor the update status of services with annotation marks in the service provider cluster by using the Kube-apiserver server;

[0032] The setting module is further used to create an Ingress access rule in the service providing cluster when it is determined based on the service update status that a new service appears in the service providing cluster, wherein the Ingress access rule is used to determine a target service consuming cluster with access rights;

[0033] The control module is also used to start the IP address resolution plug-in in the target service consumption cluster, and access the newly created service through the domain name access method using the Ingress Nginx controller.

[0034] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0035] Obtain a list including at least one Kubernetes cluster, where types of the Kubernetes cluster include a service providing cluster and a service consuming cluster;

[0036] Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively;

[0037] Using the NodePort method, an access path is set, where the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0038] Using the Kube-apiserver server, monitor the update status of the service with annotated tags in the service provider cluster;

[0039] In a case where it is determined based on the service update status that a new service appears in the service providing cluster, creating an Ingress access rule in the service providing cluster, the Ingress access rule being used to determine a target service consuming cluster with access rights;

[0040] The IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by the Ingress Nginx controller through domain name access.

[0041] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0042] Obtain a list including at least one Kubernetes cluster, where types of the Kubernetes cluster include a service providing cluster and a service consuming cluster;

[0043] Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively;

[0044] Using the NodePort method, an access path is set, where the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0045] Using the Kube-apiserver server, monitor the update status of the service with annotated tags in the service provider cluster;

[0046] In a case where it is determined based on the service update status that a new service appears in the service providing cluster, creating an Ingress access rule in the service providing cluster, the Ingress access rule being used to determine a target service consuming cluster with access rights;

[0047] The IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by the Ingress Nginx controller through domain name access.

[0048] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0049] Obtain a list including at least one Kubernetes cluster, where types of the Kubernetes cluster include a service providing cluster and a service consuming cluster;

[0050] Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively;

[0051] Using the NodePort method, an access path is set, where the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0052] Using the Kube-apiserver server, monitor the update status of the service with annotated tags in the service provider cluster;

[0053] In a case where it is determined based on the service update status that a new service appears in the service providing cluster, creating an Ingress access rule in the service providing cluster, the Ingress access rule being used to determine a target service consuming cluster with access rights;

[0054] The IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by the Ingress Nginx controller through domain name access.

[0055] The above cross-Kubernetes cluster service access method, device, computer device, computer-readable storage medium and computer program product can specify that the newly created service is exposed only to a specific cluster instead of all clusters by using the annotation of the Service. This improves the flexibility of service exposure and enhances security because access to the service can be restricted to prevent unauthorized access. It avoids introducing and installing multiple components in each cluster, thereby simplifying the networking structure. This simplification reduces the demand for resources, especially for clusters with smaller scale and fewer nodes, reducing resource consumption and troubleshooting costs. This solution implements the addition / removal of domain names by creating / deleting Services, reduces the number of times the Configmap configuration file is reloaded, and improves the real-time effectiveness of domain name resolution. Through the Ingress NginxController and Ingress resources, external traffic can be more effectively routed to the internal services of the Kubernetes cluster, improving the efficiency of service access. At the same time, the reliability of the service is also improved due to the reduction in the number of components and tunnels. The controller can be deployed independently or in any cluster in the form of a workload, which provides deployment flexibility. At the same time, due to the reduction in the number and complexity of components, the maintenance cost is also reduced accordingly. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0057] FIG1 is an application environment diagram of a method for accessing services across Kubernetes clusters in one embodiment;

[0058] FIG2 is a schematic diagram of a process flow of a method for accessing services across Kubernetes clusters in one embodiment;

[0059] FIG3 is a schematic diagram of a flow chart of a method for accessing services across Kubernetes clusters in another embodiment;

[0060] FIG4 is a device architecture diagram of a cross-Kubernetes cluster service access device in the most detailed embodiment;

[0061] FIG5 is a structural block diagram of a cross-Kubernetes cluster service access device in one embodiment;

[0062] FIG. 6 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0064] The cross-Kubernetes cluster service access method provided in the embodiment of the present application can be applied in the application environment shown in Figure 1. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers.

[0065] The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The server 104 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0066] In an exemplary embodiment, as shown in FIG2 , a cross-Kubernetes cluster service access method is provided, which is described by taking the method applied to the server in FIG1 as an example, and includes the following steps S202 to S212 . Among them:

[0067] Step S202: Obtain a list containing at least one Kubernetes cluster, where the types of Kubernetes clusters include service provision clusters and service consumption clusters.

[0068] Specifically, you first need to obtain a list containing at least one Kubernetes cluster. This list should clearly distinguish between service provider clusters and service consumer clusters. Different cluster roles will take different operations and configurations.

[0069] The Service Provider Cluster runs services that need to be accessed by other clusters. In this setting, the Service Provider Cluster is responsible for hosting services and exposing them to the outside world or other clusters through specific mechanisms.

[0070] The Service Consumer Cluster needs to access the services provided by the Service Provider Cluster. The Service Consumer Cluster uses specific technical means to discover and access the services in the Service Provider Cluster.

[0071] Step S204: Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively.

[0072] Among them, the Ingress Nginx controller is a component in Kubernetes for managing Ingress resources. It is responsible for forwarding received HTTP / HTTPS requests to the corresponding Service according to the rules defined in the Ingress resources. The Ingress resource defines a set of rules for how external traffic is routed to services within the Kubernetes cluster. Through Ingress, a unified access portal can be provided to the outside world to achieve load balancing, SSL termination, name base virtual hosting, etc.

[0073] Specifically, the Ingress Nginx controller is set in the service provider cluster to expose the services in the cluster to the outside world or a specific service consumption cluster through Ingress. The Ingress Nginx controller listens to the creation of services with specific annotations and creates corresponding Ingress rules for these services so that these services can be accessed externally through domain names.

[0074] The Ingress Nginx controller is set in the service consumption cluster to access the services exposed in the service provider cluster through the Ingress Nginx controller. The Ingress Nginx controller in the service consumption cluster does not need to expose services directly, but serves as a springboard to access the services of the service provider cluster, forwarding requests to the services of the service provider cluster through the Ingress rules.

[0075] Step S206, using the NodePort method, setting an access path, the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster.

[0076] Specifically, Services in Kubernetes can be configured as different types, of which NodePort is a type that allows access to the Service through the IP address of any node in the cluster plus a static port (NodePort). NodePort is a port between 30000 and 32767, automatically assigned by Kubernetes unless manually specified.

[0077] As a component that manages Ingress resources, the Ingress Nginx controller needs to be accessible externally to handle traffic entering the cluster. By configuring the service of the Ingress Nginx controller as the NodePort type, you can ensure that external traffic can access the Ingress Nginx controller through the specific port of the cluster node.

[0078] When the service of the Ingress Nginx controller is set to NodePort, you can <nodeip> : <nodeport>The controller is accessed in the form of <nodeip>is the IP address of any node in the cluster. <nodeport>This is the port assigned to the controller service. This approach allows external users or services to access the Ingress resources inside the cluster directly through the cluster boundary without any additional configuration inside the cluster.

[0079] In the cross-Kubernetes cluster service access scenario, the Ingress Nginx controller in the service provider cluster needs to be accessed by the service consumer cluster in order to forward requests to the correct service. Through the NodePort method, the service consumer cluster can easily access the Ingress Nginx controller through the IP address and NodePort of the service provider cluster node to achieve cross-cluster service access.

[0080] Although NodePort provides a simple way to access the external server, in a production environment, it is usually combined with a load balancer (such as Nginx, HAProxy, or a load balancing service provided by a cloud service provider) to improve performance and security. The load balancer can provide additional security layers, such as SSL / TLS termination, and more efficient request distribution.

[0081] In summary, using NodePort to set the access path from outside the Kubernetes cluster to the Ingress Nginx controller is a simple way to achieve service communication within and outside the cluster. This method enables the Ingress Nginx controller to handle traffic from outside the cluster, providing a basis for cross-cluster service access.

[0082] Step S208: Use the Kube-apiserver server to monitor the update status of services with annotation marks in the service provider cluster.

[0083] Specifically, Kube-apiserver is the core component of the Kubernetes cluster, responsible for processing all RESTful requests, including authentication and authorization, data verification, and cluster status changes. It is the hub for communication between the functional modules of the cluster. All modules query or modify data through the API Server, and only the API Server directly operates etcd.

[0084] Components in Kubernetes, such as kubelet, kube-controller-manager, and kube-scheduler, need to monitor changes in various resources (such as Pods, Services, etc.). When these objects change (such as additions, deletions, updates), kube-apiserver will actively notify these components. This process is similar to a publish-subscribe system. List-Watch is the core mechanism of Kubernetes, allowing components to monitor changes in resources.

[0085] Annotations are key-value pairs used in Kubernetes to store auxiliary information, especially data used by external tools or system extension plug-ins. Annotations can be used to mark services so that cluster access controllers or API servers can identify and process them accordingly.

[0086] Through the Watch interface provided by kube-apiserver, you can monitor the update status of services marked with specific annotations in the service provider cluster. When the service object changes, kube-apiserver will notify the monitoring components, which can respond accordingly, such as creating, updating or deleting resources.

[0087] The cluster access controller can use this mechanism to automatically handle service updates. For example, when a service with a specific annotation is detected to be created, the cluster access controller can automatically create the corresponding Ingress resource to expose the service.

[0088] Step S210: When it is determined based on the service update status that a new service appears in the service providing cluster, an Ingress access rule is created in the service providing cluster, where the Ingress access rule is used to determine a target service consuming cluster with access rights.

[0089] Specifically, through the monitoring mechanism of Kube-apiserver, the cluster access controller can monitor the creation, update or deletion events of services in the service provider cluster. In particular, when a new service appears, the cluster access controller will determine the exposure requirements of the service based on the annotation of the service. New services usually contain specific annotations, which contain information about service exposure, such as whether cross-cluster exposure is required, the identifier of the target service consumption cluster, the domain name suffix, etc.

[0090] Once the cluster access controller detects a newly created service with a specific annotation, it creates corresponding Ingress rules in the service provider cluster based on these annotation information. Ingress rules define how to route external traffic (based on domain name, path, etc.) to specific services within the cluster. These rules allow precise control over which external requests can access services within the cluster. Ingress access rules can contain access control logic, such as whitelisting based on source IP, certificate routing based on SNI (Server Name Indication), etc., to ensure that only authorized service consumer clusters can access specific services.

[0091] In this way, the service provider cluster can restrict access to newly created services, allowing only specific service consumer clusters (i.e., target service consumer clusters) to access these services through Ingress. Ingress rules specify which service consumer clusters have access to newly created services. This is usually achieved through the information in the annotation, such as specifying the identifiers of one or more target service consumer clusters. The controller creates Ingress rules based on this information to ensure that only the target service consumer cluster can access the services in the service provider cluster through domain name resolution and Ingress routing. Through the setting of Ingress rules, the services in the service provider cluster can be accessed by the target service consumer cluster through the network, realizing cross-cluster communication.

[0092] Step S212, start the IP address resolution plug-in in the target service consumption cluster, and access the newly created service through the domain name access method using the Ingress Nginx controller.

[0093] Specifically, the Pod in the target service consumption cluster can access the Service in the service provider cluster through the domain name. This domain name follows a specific format, such as svc-name.ns-name.example.org, where example.org is the domain name suffix configured in the k8s_external plug-in.

[0094] Requests in the target service consumption cluster will first pass through the Ingress Nginx controller, which will route the requests to the correct Service based on the Ingress rules. The Ingress rules will specify how to route external traffic (based on domain names and paths) to the Service in the service provider cluster to ensure that the requests can be forwarded correctly.

[0095] When a Pod in the target service consumption cluster tries to access the newly created service, it uses the resolved domain name (including externalIPs) to initiate a request. This request first reaches the Ingress Nginx controller, and then is forwarded to the Service in the service provider cluster according to the Ingress rules. Therefore, the target service consumption cluster can access the newly created service in the service provider cluster through domain name resolution and Ingress routing, realizing communication across Kubernetes clusters.

[0096] In the above cross-Kubernetes cluster service access method, by using the Service annotation, you can specify that the newly created service is exposed only to a specific cluster, rather than to all clusters. This improves the flexibility of service exposure and enhances security, because access to services can be restricted to prevent unauthorized access. It avoids the introduction and installation of multiple components in each cluster, thereby simplifying the networking structure. This simplification reduces the demand for resources, especially for clusters with smaller scale and fewer nodes, reducing resource consumption and troubleshooting costs. This solution implements the addition / removal of domain names by creating / deleting Services, reducing the number of times the Configmap configuration file is reloaded and improving the real-time nature of domain name resolution. Through the Ingress Nginx Controller and Ingress resources, external traffic can be more effectively routed to services inside the Kubernetes cluster, improving the efficiency of service access. At the same time, the reliability of the service is also improved due to the reduction in the number of components and tunnels.

[0097] In an exemplary embodiment, as shown in FIG3 , the step of accessing the newly created service by using the IngressNginx controller through the domain name access method also includes:

[0098] Step S302: Using the Kube-apiserver server, create a service object with the same name as the newly created service in the namespace of the target service consumption cluster;

[0099] Step S304, setting the node IP address of the service provider cluster in the external IP address list;

[0100] Step S306: Create a DNS record so that the access domain name of the service object after resolution matches the node IP address of the service providing cluster.

[0101] Specifically, through the Kube-apiserver server, the cluster access controller creates a new service object in a specific namespace of the target service consumption cluster. The name of this service object is the same as the name of the newly created service in the service provider cluster, in order to establish a proxy or reference in the target service consumption cluster to the newly created service in the service provider cluster.

[0102] In the created service object, the external IPs address list (i.e., the external IP address list) is set to the node IP addresses of the service provider cluster. This means that the Pods in the target service consumption cluster can directly access the nodes in the service provider cluster through this external IPs list, ensuring that the traffic in the target service consumption cluster can be correctly routed to the nodes in the service provider cluster.

[0103] In order to make the service object accessible through the domain name, you need to create a DNS record in the target service consumption cluster. This DNS record resolves the access domain name of the service object (for example, svc-name.ns-name.example.org) to the node IP address of the service provider cluster. This step is achieved by configuring the k8s_external plug-in of coredns, which can parse domain names in a specific format and return the corresponding external IPs. Pods or other clients in the target service consumption cluster can access the newly created service through the domain name. This domain name is resolved by coredns and points to the node IP address of the service provider cluster, thereby realizing cross-cluster service access.

[0104] When a request arrives at the service consumption cluster, the Ingress Nginx controller routes the request to the correct service object according to the configured Ingress rules. If the external IPs of the service object point to the node of the service provider cluster, the request will be forwarded to the service provider cluster. The Ingress Nginx controller plays a role in traffic forwarding here to ensure that the request can reach the correct service.

[0105] In this embodiment, a service object with the same name as the newly created service in the service provider cluster is created in the service consumption cluster, the external IPs of this service object are configured as the node IP addresses of the service provider cluster, and the domain names are resolved to these IP addresses through DNS records. In this way, the traffic in the service consumption cluster can be correctly routed to the service in the service provider cluster through the Ingress Nginx controller, realizing cross-cluster service access.

[0106] In an exemplary embodiment, the IP address resolution plug-in includes a k8s_external resolution plug-in; the IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by using the Ingress Nginx controller through the domain name access method, including:

[0107] Configure the k8s_external resolution plug-in in the core DNS configuration file;

[0108] Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster;

[0109] Use the Ingress Nginx controller to access the newly created service based on the node IP address of the service provider cluster.

[0110] Specifically, the IP address resolution plug-in includes the k8s_external resolution plug-in, which is a plug-in of coredns (i.e. core DNS) for handling external DNS resolution of Kubernetes services. It allows access to newly created services in the service provider cluster by domain name, rather than directly using the ClusterIP or NodePort of the newly created service. To enable the k8s_external plug-in, you need to configure it in the core DNS configuration file. This configuration specifies the domain name suffix. When coredns resolves a domain name ending with this suffix, it uses the k8s_external plug-in to find the corresponding Service and return its externalIPs. In the target service consumption cluster, you need to start the k8s_external plug-in so that coredns can resolve the access domain name of the service object. This domain name follows a specific format, such as svc-name.ns-name.example.org, where example.org is the domain name suffix configured in the k8s_external plug-in. When a client in the target service consumption cluster tries to access a newly created service in the service provider cluster by domain name, coredns uses the k8s_external plug-in to resolve this domain name. The plugin will look up the corresponding Service and return the externalIPs, i.e., the node IP addresses, of the Service in the service provider cluster. Once the client obtains the node IP addresses of the service provider cluster, it can directly access the newly created services through these IP addresses. In the target service consumption cluster, the Ingress Nginx controller is responsible for forwarding incoming requests to the correct service. If the request is targeted at a newly created service in the service provider cluster, the Ingress Nginx controller will forward the request to the node IP address of the service provider cluster.

[0111] In this embodiment, the k8s_external plug-in is configured and started in the target service consumption cluster to obtain the node IP address of the service in the service providing cluster through domain name resolution, and access the newly created service through the Ingress Nginx controller. In this way, even if the newly created service is located in a different cluster, the client can access it like accessing local services, realizing cross-cluster service access.

[0112] In an exemplary embodiment, starting the k8s_external parsing plug-in in the target service consumption cluster includes:

[0113] Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS in the Kube-system namespace;

[0114] When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, start the k8s_external parsing plug-in in the target service consumption cluster.

[0115] Specifically, the cluster access controller needs to communicate with the Kube-apiserver server of the target service consumption cluster. Kube-apiserver is the control center of the Kubernetes cluster, responsible for handling all RESTful requests and access to cluster data. In the Kube-system namespace, coredns runs as the cluster's internal DNS service. Its configuration file corefile contains the configuration information of the DNS service, including how to handle domain name resolution requests. The cluster access controller needs to obtain the contents of this configuration file to check whether the k8s_external plug-in has been configured and started.

[0116] Based on the obtained corefile configuration information, the cluster access controller checks whether there is a configuration for the k8s_external plugin. If the corefile does not contain the relevant configuration of k8s_external, or the configuration is incorrect, it means that the k8s_external plugin has not been started. If it is determined that the k8s_external plugin is not started, the cluster access controller will update the corefile configuration file and add the configuration of the k8s_external plugin. After updating the configuration, the coredns service needs to reload the configuration file so that the k8s_external plugin can start working. This usually happens automatically because coredns monitors changes to its configuration files and reloads them.

[0117] Once the k8s_external plugin is started, coredns will be able to resolve domain names in a specific format (such as svc-name.ns-name.example.org) and return the externalIPs of the corresponding Services in the service provider cluster.

[0118] In this embodiment, by checking and updating the coredns configuration to ensure that the k8s_external plugin is correctly configured and started, the Pod in the target service consumption cluster can access the Service in the service provider cluster through the domain name without directly knowing the specific IP address of the backend service. This is a key step in achieving cross-Kubernetes cluster service discovery and access.

[0119] In an exemplary embodiment, when the service providing cluster removes a newly created service, the access domain name of the corresponding service object is removed.

[0120] Specifically, when a newly created service in a service provider cluster is deleted, the cluster access controller receives this event. This may be achieved by listening to the event notifications from the API server, or by periodically polling the status of the service object. Once the removal of the newly created service is detected, the cluster access controller needs to update the DNS configuration to ensure that the domain name associated with the newly created service is no longer resolved. This is because the newly created service no longer exists and any requests to the newly created service should not be routed.

[0121] In the target service consumption cluster, the cluster access controller will find the service object with the same name as the removed service and delete it from the target service consumption cluster. This service object was previously created to access the service of the service provider cluster in the target service consumption cluster. The access domain name associated with the service object will also be removed. This involves updating the coredns configuration file (such as corefile) and removing or updating the k8s_external plugin configuration related to the service to ensure that coredns no longer resolves the domain name pointing to the deleted service.

[0122] After removing the service object and updating the DNS configuration, any request that attempts to access the deleted service through the previously configured domain name will fail because the DNS no longer resolves these domain names, or the resolution results no longer point to valid services. This ensures state consistency between the service provider cluster and the target service consumer cluster. When a service is no longer available, the related DNS records and routing rules should also be updated or deleted accordingly to avoid traffic being mistakenly routed to a non-existent service.

[0123] In this embodiment, when a newly created service in the service providing cluster is removed, in order to maintain the consistency and correctness of the system, the corresponding service object and its access domain name in the service consuming cluster are synchronously removed, including updating the DNS configuration to ensure that the domain name related to the deleted service is no longer resolved, thereby avoiding unnecessary network traffic and potential errors.

[0124] In an exemplary embodiment, after obtaining a list including at least one Kubernetes cluster, the method further includes: obtaining the cluster name of the service providing cluster and the service consuming cluster and the access address of the Kube-apiserver server through a cluster access controller;

[0125] Specifically, the cluster access controller needs to know the specific information of the service provider cluster and the service consumer cluster, including their names and the access address of the Kube-apiserver server. This information is crucial for the cluster access controller to interact with each cluster, because the cluster access controller needs to manage the resources in the cluster, such as services, Ingress rules, etc., through the Kube-apiserver.

[0126] In an exemplary embodiment, the cluster access controller is deployed independently or in the form of a workload inside any one of the service providing cluster and the service consuming cluster.

[0127] Specifically, the cluster access controller can be deployed as a standalone application outside the cluster, such as on a separate server or cloud service. This allows the cluster access controller to be free from the limitations of a single Kubernetes cluster and makes it easier to manage multiple clusters.

[0128] The cluster access controller can also be deployed as a workload (e.g., Deployment, StatefulSet, etc.) inside a Kubernetes cluster. This means that the cluster access controller runs as a Pod on the nodes of the cluster and communicates with other components through the network inside the cluster. That is, the cluster access controller can be deployed in the service provider cluster, which can directly manage the exposure of services and the creation of Ingress rules. Alternatively, the cluster access controller can also be deployed in the service consumer cluster, which makes it easier to manage service access and DNS resolution. Alternatively, the cluster access controller can also be deployed in any cluster as long as it can access all relevant Kube-apiserver servers. This is because the Kubernetes API is a common interface between clusters, and the cluster access controller can interact with any cluster through the API.

[0129] No matter where it is deployed, the main function of the cluster access controller is to monitor and respond to service changes in the service provider cluster, and to configure the corresponding DNS resolution and access rules in the service consumer cluster. Regardless of how the cluster access controller is deployed, appropriate network configuration and permissions are required to access the Kube-apiserver of all relevant clusters.

[0130] In this embodiment, after obtaining the cluster list, the cluster access controller needs to obtain detailed information about the service providing cluster and the service consuming cluster, and manage cross-cluster service access based on this information. The deployment method and location of the cluster access controller need to be determined according to the actual network architecture and security requirements to ensure that the cluster access controller can effectively perform its duties.

[0131] The most detailed embodiment of this application is:

[0132] As shown in FIG4 , a device architecture diagram of the most detailed embodiment is shown, and the steps include:

[0133] 1. Cluster creation:

[0134] Create two Kubernetes clusters, one of which is defined as the service provider cluster cluster-P, and the other is defined as the service consumer cluster cluster-C. The implementation goal is to achieve cross-cluster access to services in the service provider cluster in the service consumer cluster.

[0135] 2. Cluster access controller deployment:

[0136] Install and deploy the cluster access controller, which obtains the cluster names of the above two clusters, the access address of the cluster Kube-apiserver server, and the cluster kubeconfig through the database or configuration files. The cluster access controller can be deployed independently or as a workload in any cluster of the service provider cluster or service consumer cluster.

[0137] 3. Install the Ingress Nginx controller:

[0138] During the first run, the cluster access controller detects whether the Ingress Nginx controller component is installed in the service provider cluster and the service consumer cluster. If not, it installs them respectively and exposes the ingress-nginx-controller service through NodePort, with the port set to 30080.

[0139] 4. Monitor service update status:

[0140] The cluster access controller listens to the creation, modification, and deletion events of services with specified annotations in each cluster through the Kube-apiserver server of each cluster.

[0141] 5. Create new service:

[0142] The user creates a service named svc-name in the ns-name namespace of the service provider cluster through the kubectl command line tool or web page. The annotation configuration includes export=true, targetCluster=[cluster-C], and domainSuffix=example.org, indicating that the service is exposed to the service consumption cluster. Applications in the service consumption cluster need to access the application across clusters through the svc-name.ns-name.example.org domain name.

[0143] 6. Create Ingress access rules:

[0144] When the cluster access controller detects that the Service in the service provider cluster needs to be exposed outside the cluster, it creates an Ingress under the ns-name namespace in the service provider cluster and adds a rule to forward requests with host svc-name.ns-name.example.org to svc-name in the service provider cluster's namespace, thereby exposing the newly created service outside the service provider cluster. At this point, clusters outside the service provider cluster (such as the target service consumption cluster) can access the newly created service by configuring host: svc-name.ns-name.example.org {any node IP of the service provider cluster} and then using the domain name svc-name.ns-name.example.org:30080 to access the ingress-nginx-controller in the service provider cluster.

[0145] 7. Configure the k8s_external plug-in:

[0146] The cluster access controller accesses the Kube-apiserver of the target service consumption cluster, obtains the corefile configuration file in the coredns Configmap under the kube-system namespace, and determines whether the k8s_external plug-in is enabled; if not, add the k8s_external example.org configuration to the corefile configuration file in the Configmap to enable it. This step is only performed once when the cluster is used as the target service consumption cluster for the first time, so coredns only needs to reload the corefile configuration file from the Configmap once.

[0147] 8. Bind domain name and externalIPs:

[0148] The cluster access controller accesses the Kube-apiserver of the target service consumption cluster, creates a service object with the same name as svc-name in the ns-name namespace, sets externalIPs to the node IP list of the service provider cluster, and implements the binding of the svc-name.ns-name.example.org domain name to externalIPs. At this point, the pod of the target service consumption cluster can be resolved to the node IP of the service provider cluster through the svc-name.ns-name.example.org domain name. After coredns opens the k8s_external plug-in, domain names can be added / removed by creating / deleting Services, which improves the timeliness of domain name resolution.

[0149] 9. Cross-cluster access test:

[0150] Create an application workload in the target service consumption cluster to test cross-cluster access. Execute curl svc-name.ns-name.example.org:30080 in the application workload Pod to access the svc-name service in the ns-name namespace of the service provider cluster.

[0151] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0152] Based on the same inventive concept, the embodiment of the present application also provides a cross-Kubernetes cluster service access device for implementing the cross-Kubernetes cluster service access method involved above. The implementation solution for solving the problem provided by the device is similar to the implementation solution recorded in the above method, so the specific limitations in the one or more cross-Kubernetes cluster service access device embodiments provided below can be found in the above limitations on the cross-Kubernetes cluster service access method, which will not be repeated here.

[0153] In an exemplary embodiment, as shown in FIG5 , a cross-Kubernetes cluster service access device is provided, including:

[0154] An acquisition module 502 is used to acquire a list including at least one Kubernetes cluster, where the types of Kubernetes clusters include service provision clusters and service consumption clusters;

[0155] A setting module 504, used to set an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively;

[0156] The setting module 504 is further used to set an access path by using the NodePort method, and the access path is used to provide the use permission of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster;

[0157] The control module 506 is used to monitor the update status of the service with the annotation mark in the service providing cluster by using the Kube-apiserver server;

[0158] The setting module 504 is further used to create an Ingress access rule in the service providing cluster when it is determined based on the service update status that a new service appears in the service providing cluster, and the Ingress access rule is used to determine the target service consuming cluster with access rights;

[0159] The control module 506 is also used to start the IP address resolution plug-in in the target service consumption cluster, and access the newly created service through the domain name access method using the Ingress Nginx controller.

[0160] In an exemplary embodiment, the setting module 504 is also used to use the Kube-apiserver server to create a service object with the same name as the newly created service in the namespace of the target service consumption cluster; set the node IP address of the service provider cluster in the external IP address list; and create a DNS record so that the access domain name of the service object after resolution matches the node IP address of the service provider cluster.

[0161] In an exemplary embodiment, the IP address resolution plug-in includes a k8s_external resolution plug-in; the setting module 504 is further used to configure the k8s_external resolution plug-in in the core DNS configuration file; the k8s_external resolution plug-in is started in the target service consumption cluster, and the access domain name of the service object is resolved through the domain name access method, and matched with the node IP address of the corresponding service providing cluster;

[0162] The control module 506 is also used to use the Ingress Nginx controller to access the newly created service based on the node IP address of the service provider cluster.

[0163] In an exemplary embodiment, the acquisition module 502 is used to access the Kube-apiserver server of the target service consumption cluster to obtain configuration information in the configuration file of the core DNS server in the Kube-system namespace;

[0164] The control module 506 is also used to start the k8s_external resolution plug-in in the target service consumption cluster when it is determined based on the configuration information that the k8s_external resolution plug-in is not started.

[0165] In an exemplary embodiment, the setting module 504 is further configured to remove the access domain name of the corresponding service object when the service providing cluster removes the newly created service.

[0166] In an exemplary embodiment, the cluster access controller is deployed independently or in the form of a workload inside any one of the service providing cluster and the service consuming cluster.

[0167] Each module in the above cross-Kubernetes cluster service access device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each of the above modules.

[0168] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG6. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for accessing services across Kubernetes clusters is implemented.

[0169] Those skilled in the art will understand that the structure shown in FIG. 6 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0170] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0171] Get a list containing at least one Kubernetes cluster. The types of Kubernetes clusters include service provider clusters and service consumer clusters.

[0172] Set up Ingress Nginx controllers in the service provider cluster and service consumer cluster respectively;

[0173] Use NodePort to set the access path, which is used to provide the Ingress Nginx controller's usage rights to the external cluster of the service provider cluster or service consumer cluster.

[0174] Use the Kube-apiserver server to monitor the update status of services with annotation tags in the service provider cluster;

[0175] When a new service appears in the service providing cluster based on the service update status, an Ingress access rule is created in the service providing cluster. The Ingress access rule is used to determine the target service consuming cluster with access rights.

[0176] Start the IP address resolution plug-in in the target service consumption cluster, and use the IngressNginx controller to access the newly created service through domain name access.

[0177] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0178] Use the Kube-apiserver server to create a service object with the same name as the newly created service in the namespace of the target service consumption cluster;

[0179] Set the node IP address of the service provider cluster in the external IP address list;

[0180] Create a DNS record so that the resolved domain name of the service object matches the node IP address of the service provider cluster.

[0181] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0182] IP address resolution plug-ins include k8s_external resolution plug-in;

[0183] In the core DNS configuration file, configure the k8s_external resolution plug-in;

[0184] Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster;

[0185] Use the Ingress Nginx controller to access the newly created service based on the node IP address of the service provider cluster.

[0186] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0187] Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS server in the Kube-system namespace;

[0188] When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, start the k8s_external parsing plug-in in the target service consumption cluster.

[0189] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0190] When the service provider cluster removes the newly created service, the access domain name of the corresponding service object is removed.

[0191] In one embodiment, the cluster access controller is deployed independently or in the form of workload inside any one of the service providing cluster and the service consuming cluster.

[0192] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0193] Get a list containing at least one Kubernetes cluster. The types of Kubernetes clusters include service provider clusters and service consumer clusters.

[0194] Set up Ingress Nginx controllers in the service provider cluster and service consumer cluster respectively;

[0195] Use NodePort to set the access path, which is used to provide the Ingress Nginx controller's usage rights to the external cluster of the service provider cluster or service consumer cluster.

[0196] Use the Kube-apiserver server to monitor the update status of services with annotation tags in the service provider cluster;

[0197] When a new service appears in the service providing cluster based on the service update status, an Ingress access rule is created in the service providing cluster. The Ingress access rule is used to determine the target service consuming cluster with access rights.

[0198] Start the IP address resolution plug-in in the target service consumption cluster, and use the IngressNginx controller to access the newly created service through domain name access.

[0199] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0200] Use the Kube-apiserver server to create a service object with the same name as the newly created service in the namespace of the target service consumption cluster;

[0201] Set the node IP address of the service provider cluster in the external IP address list;

[0202] Create a DNS record so that the resolved domain name of the service object matches the node IP address of the service provider cluster.

[0203] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0204] IP address resolution plug-ins include k8s_external resolution plug-in;

[0205] In the core DNS configuration file, configure the k8s_external resolution plug-in;

[0206] Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster;

[0207] Use the Ingress Nginx controller to access the newly created service based on the node IP address of the service provider cluster.

[0208] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0209] Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS server in the Kube-system namespace;

[0210] When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, start the k8s_external parsing plug-in in the target service consumption cluster.

[0211] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0212] When the service provider cluster removes the newly created service, the access domain name of the corresponding service object is removed.

[0213] In one embodiment, the cluster access controller is deployed independently or in the form of workload inside any one of the service providing cluster and the service consuming cluster.

[0214] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0215] Get a list containing at least one Kubernetes cluster. The types of Kubernetes clusters include service provider clusters and service consumer clusters.

[0216] Set up Ingress Nginx controllers in the service provider cluster and service consumer cluster respectively;

[0217] Use NodePort to set the access path, which is used to provide the Ingress Nginx controller's usage rights to the external cluster of the service provider cluster or service consumer cluster.

[0218] Use the Kube-apiserver server to monitor the update status of services with annotation tags in the service provider cluster;

[0219] When a new service appears in the service providing cluster based on the service update status, an Ingress access rule is created in the service providing cluster. The Ingress access rule is used to determine the target service consuming cluster with access rights.

[0220] Start the IP address resolution plug-in in the target service consumption cluster, and use the IngressNginx controller to access the newly created service through domain name access.

[0221] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0222] Use the Kube-apiserver server to create a service object with the same name as the newly created service in the namespace of the target service consumption cluster;

[0223] Set the node IP address of the service provider cluster in the external IP address list;

[0224] Create a DNS record so that the resolved domain name of the service object matches the node IP address of the service provider cluster.

[0225] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0226] IP address resolution plug-ins include k8s_external resolution plug-in;

[0227] In the core DNS configuration file, configure the k8s_external resolution plug-in;

[0228] Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster;

[0229] Use the Ingress Nginx controller to access the newly created service based on the node IP address of the service provider cluster.

[0230] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0231] Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS server in the Kube-system namespace;

[0232] When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, start the k8s_external parsing plug-in in the target service consumption cluster.

[0233] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0234] When the service provider cluster removes the newly created service, the access domain name of the corresponding service object is removed.

[0235] In one embodiment, the cluster access controller is deployed independently or in the form of workload inside any one of the service providing cluster and the service consuming cluster.

[0236] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0237] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0238] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0239] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.< / nodeport> < / nodeip> < / nodeport> < / nodeip>

Claims

1. A cross-Kubernetes cluster service access method, characterized in that: Applied to a cluster access controller, the method comprises: Obtain a list including at least one Kubernetes cluster, where types of the Kubernetes cluster include a service providing cluster and a service consuming cluster; Setting an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively; Using the NodePort method, an access path is set, where the access path is used to provide the use rights of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster; Using the Kube-apiserver server, monitor the update status of the service with annotated tags in the service provider cluster; In a case where it is determined based on the service update status that a new service appears in the service providing cluster, creating an Ingress access rule in the service providing cluster, the Ingress access rule being used to determine a target service consuming cluster with access rights; The IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by using the IngressNginx controller through domain name access.

2. The method according to claim 1, characterized in that Before accessing the newly created service by using the IngressNginx controller through the domain name access method, the method further includes: Using the Kube-apiserver server, create a service object with the same name as the newly created service in the namespace of the target service consumption cluster; Set the node IP address of the service provider cluster in the external IP address list; A DNS record is created so that the access domain name of the service object after being resolved matches the node IP address of the service providing cluster.

3. The method according to claim 2, characterized in that The IP address resolution plug-in includes a k8s_external resolution plug-in; the IP address resolution plug-in is started in the target service consumption cluster, and the newly created service is accessed by using the Ingress Nginx controller through the domain name access method, including: In the core DNS configuration file, configure the k8s_external resolution plug-in; Start the k8s_external resolution plug-in in the target service consumption cluster, resolve the access domain name of the service object through domain name access, and match it with the node IP address of the corresponding service provider cluster; The newly created service is accessed using the Ingress Nginx controller based on the node IP address of the service provider cluster.

4. The method according to claim 3, characterized in that: The starting of the k8s_external parsing plug-in in the target service consumption cluster includes: Access the Kube-apiserver server of the target service consumption cluster and obtain the configuration information in the configuration file of the core DNS server in the Kube-system namespace; When it is determined based on the configuration information that the k8s_external parsing plug-in is not started, the k8s_external parsing plug-in is started in the target service consumption cluster.

5. The method according to claim 2, characterized in that: The method further comprises: When the service providing cluster removes the newly created service, the access domain name of the corresponding service object is removed.

6. The method according to claim 1, characterized in that The cluster access controller is deployed independently or in the form of workload inside any one of the service providing cluster and the service consuming cluster.

7. A cross-Kubernetes cluster service access device, characterized in that: The device comprises: An acquisition module is used to acquire a list containing at least one Kubernetes cluster, where the types of the Kubernetes cluster include a service providing cluster and a service consuming cluster; A setting module, used to set an Ingress Nginx controller in the service providing cluster and the service consuming cluster respectively; The setting module is further used to set an access path by using the NodePort method, wherein the access path is used to provide the use permission of the Ingress Nginx controller to the external cluster of the service providing cluster or the service consuming cluster; A control module, used to monitor the update status of services with annotation marks in the service provider cluster by using the Kube-apiserver server; The setting module is further used to create an Ingress access rule in the service providing cluster when it is determined based on the service update status that a new service appears in the service providing cluster, wherein the Ingress access rule is used to determine a target service consuming cluster with access rights; The control module is also used to start the IP address resolution plug-in in the target service consumption cluster, and access the newly created service through the domain name access method using the Ingress Nginx controller.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images