A cluster Pod registration and communication method and device

Abstract

This invention discloses a method and apparatus for Pod registration and communication in a cluster. The method includes: creating a listening Pod on multiple Nodes in the cluster, wherein the listening Pod listens for the creation of multiple service Pods on the Nodes and generates port mappings for each service Pod; creating a service Pod in response to a service Pod creation request and inserting a preset initialization program into the service Pod; initializing and starting the service Pod, wherein the preset initialization program runs during the service Pod initialization process to obtain the port mappings generated by the listening Pods for the service Pods; registering the service Pod with a registration center according to the address and port mappings of the Node where the service Pod resides; and a first Pod communicating with a second Pod according to the address and port mappings of the Node where the second Pod resides, thereby achieving a cost reduction effect.

Description

Technical Field

[0001] This invention relates to the field of cloud-native technology, and in particular to a method and apparatus for Pod registration and communication in a cluster. Background Technology

[0002] Kubernetes (K8s) is a popular application management platform. Users can use K8s to distribute a large number of application instances across different nodes and continuously manage these running instances. It is well-suited for the needs of operations personnel in microservice architectures to manage application instances in batches. To control risks or improve service level scalability, operations personnel often distribute application instances across different K8s clusters. However, K8s still has the following issues regarding Pod communication between clusters:

[0003] 1. Service mesh-based solutions require additional service mesh management planes, sidecars, and edge gateways to interconnect with the cluster, resulting in higher costs; 2. Kubernetes' built-in solutions have inherent problems.

[0004] No effective solutions have yet been proposed to address the aforementioned technical problems in the relevant technologies. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention aims to provide a cluster Pod registration and communication method and apparatus that can solve the technical problems of high cost of service mesh-based solutions and inherent problems of the built-in Kubernetes solution in related technologies.

[0006] This invention provides a method for registering Pods in a cluster, comprising: creating a listening Pod on multiple nodes of the cluster, wherein the listening Pod is used to listen for the creation of multiple service Pods on the Node and generate a port mapping for each service Pod; in response to a service Pod creation request, creating a service Pod and inserting a preset initialization program into the service Pod; initializing the service Pod and starting the service Pod, wherein the preset initialization program is run during the initialization process of the service Pod to obtain the port mapping generated by the listening Pod for the service Pod; and registering the service Pod to a registration center according to the address of the Node where the service Pod is located and the port mapping.

[0007] Optionally, creating a listening Pod on multiple Nodes in the cluster includes: when a new Node joins the cluster, creating a Daemon Pod as the listening Pod on the new Node via the Daemonset controller.

[0008] Optionally, the service Pod includes an initialization container and an application container; in response to a service Pod creation request, creating the service Pod and inserting a preset initialization program into the service Pod includes: upon receiving the service Pod creation request, creating the service Pod and triggering a preset callback function of the webhook; executing the preset callback function to insert the preset initialization program into the initialization container of the service Pod.

[0009] Optionally, the initialization container includes an init container.

[0010] Optionally, registering the service Pod to the registry center based on the address of the Node where the service Pod resides and the port mapping includes: obtaining the address of the Node where the service Pod resides and the port mapping through a registration program; and registering the service Pod with the registry center through the registration program; wherein the registration program includes: a Java agent or an SDK.

[0011] Optionally, the service Pod includes an initialization container and an application container. The application container includes a user process. During initialization, the port mapping is stored in the startup parameters of the application container or the environment variables of the user process. Obtaining the port mapping through the registration program includes obtaining the port mapping from the startup parameters or the environment variables through the registration program.

[0012] Optionally, the initialization program obtains the port mapping directly from the listening Pod or the controller of the listening Pod without going through the cluster controller; or, the initialization program obtains the port mapping from the cluster controller, wherein the port mapping is obtained by the cluster controller from the listening Pod or the controller of the listening Pod.

[0013] This invention also provides a Pod communication method for a cluster, characterized by comprising: a first Pod in a first cluster obtaining registration information of a second Pod in a second cluster from a registry center, wherein the registration information is registered to the registry center by the second Pod according to the above-described registration method; the first Pod determining the address and port mapping of the Node where the second Pod is located based on the registration information; and the first Pod communicating with the second Pod based on the address and port mapping of the Node where the second Pod is located.

[0014] This invention also provides a cluster Pod registration device, comprising: a first creation module, configured to create a listening Pod on multiple Nodes of the cluster, wherein the listening Pod is used to listen for the creation of multiple service Pods on the Nodes and generate a port mapping for each service Pod; a second creation module, configured to create a service Pod in response to a service Pod creation request and insert a preset initialization program into the service Pod; a processing module, configured to initialize the service Pod and start the service Pod, wherein the preset initialization program is run during the initialization process of the service Pod to obtain the port mapping generated by the listening Pod for the service Pod; and a registration module, configured to register the service Pod to a registration center according to the address of the Node where the service Pod is located and the port mapping.

[0015] Optionally, the first creation module is further configured to create a Daemon Pod as the listening Pod on the new Node when a new Node joins the cluster, via the Daemonset controller.

[0016] Optionally, when the service Pod includes an initialization container and an application container, the second creation module is further configured to create the service Pod upon receiving a creation request for the service Pod, and trigger a preset callback function of the webhook to execute the preset callback function to insert the preset initialization program into the initialization container of the service Pod; the initialization container includes an init container.

[0017] Optionally, the registration module is further configured to obtain the address of the Node where the service Pod is located and the port mapping through the registration program, and register the service Pod with the registration center through the registration program; wherein, the registration program includes: a Java agent or an SDK.

[0018] The service Pod includes an initialization container and an application container. The application container includes a user process. During initialization, the port mapping is stored in the startup parameters of the application container or the environment variables of the user process. The registration module is also used to obtain the port mapping from the startup parameters or the environment variables through the registration program.

[0019] Optionally, the initialization program obtains the port mapping directly from the listening Pod or the controller of the listening Pod without going through the cluster controller; or, the initialization program obtains the port mapping from the cluster controller, wherein the port mapping is obtained by the cluster controller from the listening Pod or the controller of the listening Pod.

[0020] This invention also provides a Pod communication device for a cluster, comprising: a first control module, configured to control a first Pod in a first cluster to obtain registration information of a second Pod in a second cluster from a registration center, wherein the registration information is obtained by the second Pod registering to the registration center using the aforementioned registration device; and a second control module, configured to control the first Pod to determine the address and port mapping of the Node where the second Pod is located based on the registration information, and to communicate with the second Pod based on the address and port mapping of the Node where the second Pod is located.

[0021] This invention provides an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of any of the above methods.

[0022] This invention provides a computer-readable storage medium storing instructions that, when executed by a processor, implement the steps of any of the above methods.

[0023] This invention provides a cluster Pod registration and communication method and apparatus. The cluster Pod registration method includes: creating a listening Pod on multiple Nodes of the cluster, wherein the listening Pod is used to listen for the creation of multiple service Pods on the Nodes and generates a port mapping for each service Pod; in response to a service Pod creation request, creating a service Pod and inserting a preset initialization program into the service Pod; initializing the service Pod and starting the service Pod, wherein the preset initialization program is run during the initialization process of the service Pod to obtain the port mapping generated by the listening Pod for the service Pod; and registering the service Pod to a registration center according to the address of the Node where the service Pod resides and the port mapping. The cluster Pod communication method includes: a first Pod in a first cluster obtaining registration information of a second Pod in a second cluster from a registration center, wherein the registration information is registered to the registration center by the second Pod according to the method of any one of claims 1-7; the first Pod determining the address and port mapping of the Node where the second Pod resides based on the registration information; and the first Pod communicating with the second Pod based on the address and port mapping of the Node where the second Pod resides. In other words, compared to service mesh solutions in related technologies, where each service Pod requires a sidecar container, this embodiment of the invention does not involve any new containers within the service Pod. Instead, a listening Pod is started on each Node, reducing the number of new containers by an order of magnitude—from the number of Pods to the number of Nodes—thus achieving a cost reduction. Furthermore, compared to the hostPort solution in the built-in Kubernetes solution, the port mapping process in this embodiment occurs after the service Pod scheduling is complete, thus not affecting Kubernetes' service Pod scheduling. Compared to the NodePort solution in the built-in Kubernetes solution, the port mapping on the Node in this embodiment is a one-to-one mapping with the service Pod, without load balancing, thus not affecting microservice governance functions and preventing the proliferation of iptables / IP virtual server (IPVS) rules across the cluster, resulting in minimal performance impact. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0025] Figure 1 It is an architecture diagram for inter-cluster Pod communication based on related technologies;

[0026] Figure 2 It is an architecture diagram for inter-cluster Pod communication based on related technologies;

[0027] Figure 3 A flowchart illustrating a Pod registration method for a cluster provided in an embodiment of the present invention;

[0028] Figure 4 A flowchart illustrating a Pod communication method in a cluster provided by an embodiment of the present invention;

[0029] Figure 5 A flowchart illustrating another method for registering Pods in a cluster, provided in an embodiment of the present invention;

[0030] Figure 6 A flowchart illustrating another method for registering Pods in a cluster, as provided in an embodiment of the present invention;

[0031] Figure 7 This is a hardware structure block diagram of a cluster Pod registration device according to an embodiment of the present invention;

[0032] Figure 8 This is a hardware structure block diagram of a cluster Pod communication device according to an embodiment of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] Example 1

[0036] Glossary

[0037] Microservices are applications that are developed as a set of small services as an independent application system. Each service runs in its own process and the services communicate with each other using the lightweight Hypertext Transfer Protocol (HTTP).

[0038] The registry center, a microservice, is a component used to register and subscribe to service addresses, enabling services to discover each other.

[0039] Kubernetes cluster, or K8s for short, is an application scheduler based on container technology. A K8s cluster is a collection of computing, storage, and network resources that K8s uses to run various container-based applications.

[0040] A Pod is the smallest unit of work in Kubernetes, and each Pod contains one or more containers.

[0041] A node is an independent physical machine or virtual machine. Nodes provide computing resources for Kubernetes, and Kubernetes schedules container groups onto nodes. Nodes belong to a cluster, and a cluster contains multiple nodes. A node is essentially a computer (which can be a virtual machine or a physical machine).

[0042] Overlay mode is one of the network modes used by Kubernetes, in which the Pod network has an address range that is independent of the Node network.

[0043] This invention provides an embodiment of a Pod registration and communication method for a cluster, which can solve the problem of cross-cluster communication in K8s in related technologies.

[0044] In related technologies, when Pod networks in a Kubernetes cluster use Overlay mode, access based on the Container Registry Network Protocol (Pod IP) is only guaranteed to be accessible within the same cluster. Therefore, communication between Pods in one cluster and Pods in other clusters requires a gateway and additional network routing strategies. When the network address ranges of Pods in two clusters conflict, direct access between them cannot be achieved through routing. In applications using a microservice architecture, this can lead to problems such as service call failures or chaotic call behavior. Figure 1 As shown, the Service Consumer of Pod A in cluster A should normally access the Service Provider A of Pod B and the Service Provider B of Pod C in cluster A. However, a call error occurs, and the local route request accesses the Service Provider X of Pod A in cluster A, so cross-cluster communication is not possible.

[0045] A service mesh solution has been proposed in related technologies. This solution hijacks Pod traffic by adding sidecar containers to Pods and uses edge gateways for cross-cluster routing. Figure 2 As shown, App-B (i.e., service PodB) in cluster B registers with the registry center, using the IP of the proxy Envoy-B for registration. App-A (i.e., service PodA) in cluster A discovers the service and returns the host of App-B. The endpoint corresponding to this host in the service mesh is Envoy-B. The proxy Envoy of App-A finds the endpoint corresponding to the host of App-B as Envoy-B, adds a header to the request, and sends the modified request to Envoy-B. Upon receiving the modified request, Envoy-B forwards the request to the specified backend service App-B based on the request header, thus completing cross-cluster communication. In other words, the service mesh primarily identifies microservice registration requests issued by Pods, rewrites the Pod's registration information, and automatically routes cross-cluster calls to the edge gateways of other clusters. The edge gateways then route the requests to the service Pods within their respective clusters based on the request identifier. However, this service mesh solution requires the introduction of an additional service mesh management plane, sidecar, and edge gateway to interconnect with the cluster. The solution is highly complex, difficult to maintain, and the risk of failure increases accordingly. Communication between Pods in the same cluster is proxied by the sidecar, and communication between Pods in different clusters is proxied by both the sidecar and the edge gateway, resulting in additional performance overhead.

[0046] In addition, Kubernetes (K8s) provides two solutions to achieve similar goals. Solution 1: Users define a hostport in the K8s Pod. This configuration maps container ports to Nodes. This functionality is implemented by the Container Network Interface (CNI), and port mapping is completed when the container starts. Typically, users use built-in K8s workloads such as Deployments to manage Pods and define Pod declarations using templates. In this approach, the hostport definition is the same for all instances of an application. Solution 2: Users declare a Service of type NodePort for a group of Pods in K8s. This solution originates from outside the cluster and uses the NodePort service to call the Pods in the local cluster.

[0047] The above-mentioned solution 1 has the following problems: The hostPort definition is configured before pod scheduling. Since the same port on a Node cannot be reused by multiple Pods, users need to plan the hostPort used by each microservice before using this solution to avoid potential conflicts. The hostPort configuration will affect pod scheduling. Multiple Pods of the same application cannot be scheduled to the same Node, which is not conducive to the full utilization of resources.

[0048] Solution 2 has the following problems: If a NodePort service is declared for all Pods within the cluster, the NodePort service itself has load balancing capabilities and cannot intervene to direct incoming access to specific Pods within the cluster. This leads to a partial lack of service governance capabilities, such as canary deployments. If a corresponding NodePort service is declared for each Pod within the cluster, the working mechanism of kube-proxy in Kubernetes causes the number of iptables / ipvs rules broadcast to each Node to expand rapidly, impacting performance.

[0049] To effectively solve the above-mentioned technical problems, this application provides an embodiment of Pod registration and communication in a cluster. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0050] In this embodiment, the application scenarios of the above-mentioned cluster Pod registration method include, but are not limited to: 1. Multiple clusters use the same microservice registry center, and there is a requirement for cross-cluster Pod communication; 2. The Pod network uses the Overlay mode, and there may be conflicts between Pod network segments between clusters; 3. The Node networks between clusters are communicable.

[0051] It should be noted that the Node networks between the above clusters are interconnected, meaning that Nodes in two clusters can directly access each other. For example, Node a in cluster A can access Node b in cluster B.

[0052] Additionally, it should be noted that a Pod is a container group, and each container group has its own IP address. These IP addresses come from the Pod network. Pods within each cluster belong to the same Pod network, while Pods across multiple clusters belong to different Pod networks.

[0053] In the above application scenarios, the embodiments of this application provide as follows: Figure 3 The diagram shows the Pod registration method for the cluster. Figure 3 As shown in the figure, this application embodiment provides a Pod registration method for a cluster, which includes the following steps:

[0054] S302, create a listening Pod on multiple Nodes in the cluster. This listening Pod is used to listen to the creation of multiple service Pods on the Node and generate port mappings for each service Pod.

[0055] Optionally, in this embodiment, the aforementioned cluster includes, but is not limited to, a Kubernetes cluster. The aforementioned listening Pod can be a daemonset or other components that implement the same listening function; no limitations are imposed here. When completing port mapping, daemonset can automatically avoid port conflicts. Specifically, daemonset generates a management process (which is itself a Pod) on each Node. This process records the Node ports that have been allocated on the current Node and automatically avoids conflicts when a new mapping request is initiated. When the Pod is destroyed, the process also deletes the mapping record, releasing the previously occupied Node ports for future use.

[0056] Optionally, creating listening Pods on multiple Nodes in the cluster includes:

[0057] S11, when a new Node joins the cluster, the DaemonSet controller creates a Daemon Pod on the new Node to serve as the listening Pod.

[0058] In step S11 above, the DaemonSet controller's ability to create Pods enables the creation of a listening Pod. Due to the characteristics of Daemon Pods, the listening Pod is automatically created on a new Node. Therefore, the DaemonSet controller creates a Daemon Pod on the new Node that serves as the listening Pod. In other words, the creation of the listening Pod in this embodiment of the invention is achieved using existing Kubernetes mechanisms.

[0059] S304, In response to the service Pod creation request, create the service Pod and insert a preset initializer into the service Pod;

[0060] Optionally, in this embodiment, the aforementioned preset initialization program may be an initialization init container or other components that implement the same initialization function. No limitation is made here.

[0061] Optionally, the aforementioned service Pod includes an initialization container and an application container, wherein the initialization container may include an init container, wherein, in response to a service Pod creation request, the service Pod is created and a preset initializer is inserted into the service Pod, including:

[0062] S21, Upon receiving a request to create the service Pod, create the service Pod and trigger the webhook's preset callback function;

[0063] It should be noted that the above-mentioned preset callback functions are used to modify the Pod and may include: MutatingAdmissionWebhook.

[0064] S22, execute the preset callback function to insert the preset initializer into the initialization container of the service Pod.

[0065] By using S21 to S22 above, a preset initialization program is inserted into the initialization container of the service Pod. This allows the preset initialization program to be executed before the application container starts in order to obtain port mapping.

[0066] S306, Initialize the service Pod and start the service Pod. During the initialization process of the service Pod, the preset initialization program is run to obtain the port mapping generated by the listening Pod for the service Pod.

[0067] For example, assuming the port to be mapped is port 8080, the listening Pod will listen on port 8080 after it starts. When the service Pod starts and is scheduled to a Node, it will recognize the service Pod's port 8080 mapping request and allocate a Node port corresponding to the service Pod's port 8080, such as port 50000. After the mapping is completed, accessing port 50000 on the Node is equivalent to accessing port 8080 on the service Pod.

[0068] S308. Based on the address of the Node where the service Pod resides and the port mapping, register the service Pod with the registry center.

[0069] Optionally, in this embodiment, after port mapping is completed through the above steps, the service address registered by the service Pod with the registry center will be the IP address and port mapping of the Node. When this address is subscribed to by consumer Pods in other clusters, the consumer Pod will directly access the IP address and port of the Node. Since this embodiment assumes that the network between nodes in different clusters is accessible, cross-cluster communication is naturally achieved.

[0070] Optionally, registering the service Pod with the registry center based on the address of the Node where the service Pod resides and the port mapping includes:

[0071] S31, obtain the address of the Node where the service Pod is located and the port mapping through the registration program;

[0072] S32, through this registration procedure, register the service Pod with the registry center;

[0073] Optionally, the registration process described above may include: a Java agent and a Software Development Kit (SDK). For Java applications, the agent is transparent and requires no user awareness.

[0074] By using different registration procedures in S31 to S32 above to register service Pods with the registration center, the embodiments of this application can adapt to different development languages ​​and framework requirements.

[0075] Optionally, the service Pod includes an initialization container and an application container. The application container contains a user process, and during initialization, the port mapping is stored in the application container's startup parameters or the user process's environment variables. Obtaining the port mapping through the registration process includes:

[0076] S311, the port mapping is obtained from the startup parameter or environment variable through the registration program.

[0077] It should be noted that the above application can be a program that the user wants to run, such as a web service written in Java.

[0078] Optionally, in this embodiment, the aforementioned startup parameters and environment variables are configured differently in Kubernetes, but their functions can be similar. It mainly depends on whether the user's programming framework uses environment variables or startup parameters for configuration, requiring corresponding adaptation.

[0079] In an alternative implementation, the initialization procedure obtains the port mapping directly from the listening Pod or the controller of the listening Pod without going through the cluster controller; or, the initialization procedure obtains the port mapping from the cluster controller, wherein the port mapping is obtained by the cluster controller from the listening Pod or the controller of the listening Pod.

[0080] This invention also provides a cluster Pod communication method, such as... Figure 4 As shown, it includes:

[0081] S402, the first Pod in the first cluster obtains the registration information of the second Pod in the second cluster from the registration center, wherein the registration information is obtained by the second Pod registering to the registration center according to the above registration method;

[0082] S404, the first Pod determines the address and port mapping of the Node where the second Pod is located based on the registration information, and the first Pod communicates with the second Pod based on the address and port mapping of the Node where the second Pod is located.

[0083] Using the registration method provided in steps S302-S308 and the communication method provided in steps S402-S404, listening Pods are created on multiple Nodes in the cluster. Each listening Pod listens for the creation of multiple service Pods on a Node and generates a port mapping for each service Pod. In response to a service Pod creation request, a service Pod is created, and a preset initialization program is inserted into it. The service Pod is initialized and started, wherein the preset initialization program is run during the initialization process to obtain the port mapping generated by the listening Pod for the service Pod. The service Pod is registered with a registration center based on the address of the Node where the service Pod resides and the port mapping. The cluster's Pod communication method includes: a first Pod in a first cluster obtaining registration information for a second Pod in a second cluster from the registration center, wherein the registration information is obtained by the second Pod registering with the registration center using the above registration method; the first Pod determines the address and port mapping of the Node where the second Pod resides based on the registration information; and the first Pod communicates with the second Pod based on the address and port mapping of the Node where the second Pod resides. In other words, compared to service mesh solutions in related technologies, where each service Pod requires a sidecar container, this embodiment of the invention does not involve any new containers within the service Pod. Instead, a listening Pod is started on each Node, reducing the number of new containers by an order of magnitude—from the number of Pods to the number of Nodes—thus achieving a cost reduction. Furthermore, compared to the hostPort solution in the built-in Kubernetes solution, the port mapping process in this embodiment occurs after the service Pod scheduling is complete, thus not affecting Kubernetes' service Pod scheduling. Compared to the NodePort solution in the built-in Kubernetes solution, the port mapping on the Node in this embodiment is a one-to-one mapping with the service Pod, without load balancing, thus not affecting microservice governance functions and preventing the proliferation of iptables / IP virtual server (IPVS) rules across the cluster, resulting in minimal performance impact.

[0084] The embodiments of this application will be illustrated below with specific examples.

[0085] This example provides a method for registering Pods in a cluster, as shown in Figure 5, including the following steps:

[0086] In the S501 K8s cluster, a service port is declared for a service Pod, and a service Pod creation request is initiated.

[0087] S502, after receiving a service Pod creation request, the webhook triggers the webhook's preset callback function (e.g., MutatingAdmissionWebhook); the webhook executes the preset callback function and inserts the preset initializer into the service Pod's initialization container;

[0088] S503 involves a listening pod that monitors the creation of service pods on listening nodes and generates port mappings for those service pods. The listening pod starts on all nodes in the cluster. After starting, the listening pod process listens for scheduling requests from all pods on that node. Based on the pod's service definition, it executes commands to map the pod's port to the specified port. This can be done using commands such as iptables, ipvs, netcat, and socat. After mapping, the mapping result is written to the pod.

[0089] S504, the cluster controller obtains port mappings from the listening Pod;

[0090] S505, Service Pod Initialization and Startup. During the initialization process of Service Pod, a preset initialization program is run. The initialization program obtains port mappings from the cluster controller. The port mappings are obtained by the cluster controller from the listening Pod or the controller of the listening Pod. Then, the port mappings are stored in the startup parameters of the application container of Service Pod or the environment variables of the user process.

[0091] S506, the registration program (e.g., a Java agent) reads port mappings from the startup parameters of the application container of the service Pod or from the environment variables of the user process;

[0092] S507, the registration program uses the address and port mapping of the Node where the service Pod is located to register the service Pod with the registry center.

[0093] In the example above, the interaction between the service Pod and the listening Pod can be replaced with direct interaction, and the registry (Java agent) can be replaced with a registry (SDK) to adapt to the needs of different development languages ​​and frameworks, such as... Figure 6 As shown, it includes the following steps:

[0094] In S601, the K8s cluster declares a service port for a service Pod and initiates a service Pod creation request;

[0095] S602, after receiving a service Pod creation request, the webhook triggers the webhook's preset callback function (e.g., MutatingAdmissionWebhook); the webhook executes the preset callback function and inserts the preset initializer into the service Pod's initialization container;

[0096] S603 listens for the creation of service Pods on the Pod Listener Node and generates port mappings for the service Pods.

[0097] S604, Service Pod Initialization and Startup: During the initialization process of Service Pod, a preset initialization program is run. The initialization program obtains the port mapping directly from the listening Pod and then stores the port mapping in the startup parameters of the application container of Service Pod or in the environment variables of the user process.

[0098] S605, the registration program (e.g., a Java agent) reads port mappings from the startup parameters of the application container of the service Pod or from the environment variables of the user process;

[0099] S606, the registration program uses the address and port mapping of the Node where the service Pod is located to register the service Pod with the registry center.

[0100] As can be seen from the above, the cluster Pod registration and communication method provided in this embodiment of the invention introduces fewer components and has a single responsibility compared to the service mesh solution. It has lower requirements for customer operation and maintenance, lower stability risks, and application traffic does not pass through sidecars and edge gateways, only through port mapping on the Node once. The use of iptables / ipvs forwarding has minimal performance impact. This embodiment is also applicable to scenarios where Kubernetes and non-Kubernetes cluster instances call each other. Compared to the hostPort solution, where users define hostPort in the Kubernetes Pod, this configuration maps container ports to the Node. This functionality is implemented by CNI, and port mapping is completed when the container starts. Typically, users use workloads such as Deployments to manage Pods and define Pod declarations using templates. In this usage, the hostPort definition is the same for all instances under an application. Furthermore, the port mapping process in this embodiment of the invention occurs after Pod scheduling is completed, therefore it does not affect Kubernetes' Pod scheduling. Listening to the Pod complete port mapping automatically avoids port conflicts, eliminating the need for users to reserve Node ports. Compared to the NodePort solution, where users declare a service of type NodePort for a group of Pods in Kubernetes, external solutions use the NodePort service to call Pods within the cluster. The port mapping on the Node is a one-to-one mapping with the Pod, there is no load balancing, it does not affect microservice governance, and it does not cause cluster-wide propagation of iptables / ipvs rules, resulting in minimal performance impact.

[0101] In summary, the embodiments of this application solve the problem of Pod microservices accessing each other in multiple clusters in a low-cost manner. Moreover, the performance overhead, maintenance cost and applicability of the embodiments of this application are significantly better than those using service mesh, and avoid the inherent problems of using the built-in solutions of Kubernetes.

[0102] Example 2

[0103] According to embodiments of the present invention, an embodiment of a Pod registration and communication device for a cluster implementing the above-described method embodiments is also provided. In this embodiment, the application scenarios of the above-described Pod registration and communication method for the cluster include, but are not limited to: 1. Multiple clusters use the same microservice registry center, and there are cross-cluster Pod communication requirements; 2. The Pod network uses Overlay mode, and there may be conflicts between Pod network segments between clusters; 3. Node networks between clusters are communicable.

[0104] It should be noted that the Node networks between the above clusters are interconnected, meaning that Nodes in two clusters can directly access each other. For example, Node a in cluster A can access Node b in cluster B.

[0105] Additionally, it should be noted that a Pod is a container group, and each container group has its own IP address. These IP addresses come from the Pod network. Pods within each cluster belong to the same Pod network, while Pods across multiple clusters belong to different Pod networks.

[0106] like Figure 7 As shown, the Pod registration device for the above cluster includes:

[0107] The first creation module 72 is used to create listening Pods on multiple Nodes in the cluster. The listening Pod is used to listen to the creation of multiple service Pods on the Node and generate port mappings for each service Pod.

[0108] Optionally, in this embodiment, the aforementioned cluster includes, but is not limited to, a Kubernetes cluster. The aforementioned listening Pod can be a daemonset or other components that implement the same listening function; no limitations are imposed here. When completing port mapping, daemonset can automatically avoid port conflicts. Specifically, daemonset generates a management process (which is itself a Pod) on each Node. This process records the Node ports that have been allocated on the current Node and automatically avoids conflicts when a new mapping request is initiated. When the Pod is destroyed, the process also deletes the mapping record, releasing the previously occupied Node ports for future use.

[0109] The second creation module 74 is used to create a service Pod in response to a service Pod creation request and insert a preset initialization program into the service Pod;

[0110] Optionally, in this embodiment, the aforementioned preset initialization program can be an init container or other components that implement the same initialization function; no limitations are imposed here.

[0111] Processing module 76 is used to initialize and start the service Pod, wherein the preset initialization program is run during the initialization process of the service Pod to obtain the port mapping generated by the listening Pod for the service Pod;

[0112] For example, assuming the port to be mapped is port 8080, the listening Pod will listen on port 8080 after it starts. When the service Pod starts and is scheduled to a Node, it will recognize the service Pod's port 8080 mapping request and allocate a Node port corresponding to the service Pod's port 8080, such as port 50000. After the mapping is completed, accessing port 50000 on the Node is equivalent to accessing port 8080 on the service Pod.

[0113] Registration module 78 is used to register the service Pod to the registry center based on the address of the Node where the service Pod is located and the port mapping.

[0114] Optionally, in this embodiment, after port mapping is completed through the above steps, the service address registered by the service Pod with the registry center will be the IP address and port mapping of the Node. When this address is subscribed to by consumer Pods in other clusters, the consumer Pod will directly access the IP address and port of the Node. Since this embodiment assumes that the network between nodes in different clusters is accessible, cross-cluster communication is naturally achieved.

[0115] In an optional implementation, the first creation module 72 is further configured to, when a new Node joins the cluster, create a Daemon Pod on the new Node as the listening Pod through the Daemonset controller. That is, the Daemonset controller's ability to create Pods enables the creation of the listening Pod. Due to the characteristics of DaemonPods, the listening Pod is automatically created on the new Node. Therefore, the Daemonset controller creates a Daemon Pod on the new Node as the listening Pod. In other words, the creation of the listening Pod in this embodiment of the invention is achieved using existing Kubernetes mechanisms.

[0116] When the aforementioned service Pod includes an initialization container and an application container, the second creation module 74 is further configured to create the service Pod upon receiving a creation request for the service Pod and trigger a preset callback function of the webhook; execute the preset callback function to insert the preset initialization program into the initialization container of the service Pod; the initialization container includes an init container; by inserting the preset initialization program into the initialization container of the service Pod, the preset initialization program can be executed before the application container starts to obtain port mapping.

[0117] It should be noted that the above-mentioned preset callback functions are used to modify the Pod and may include: MutatingAdmissionWebhook.

[0118] The aforementioned registration module 78 is further configured to obtain the address of the Node where the service Pod resides and the port mapping through a registration program; and register the service Pod with the registration center through the registration program; wherein the registration program includes a Java agent or an SDK. Therefore, different registration programs can be used to register the service Pod with the registration center, allowing this embodiment to adapt to different development languages ​​and framework requirements.

[0119] The service Pod includes an initialization container and an application container. The application container includes a user process. During initialization, the port mapping is stored in the startup parameters of the application container or the environment variables of the user process. The registration module 78 is also used to obtain the port mapping from the startup parameters or the environment variables through the registration program.

[0120] Optionally, the initialization procedure obtains the port mapping directly from the listening Pod or the controller of the listening Pod without going through the cluster controller; or, the initialization procedure obtains the port mapping from the cluster controller, wherein the port mapping is obtained by the cluster controller from the listening Pod or the controller of the listening Pod.

[0121] This invention also provides a Pod communication device for a cluster, such as... Figure 8 As shown, the above-mentioned device includes

[0122] The first control module 82 is used to control the first Pod in the first cluster to obtain the registration information of the second Pod in the second cluster from the registration center, wherein the registration information is registered to the registration center by the second Pod according to the above-mentioned registration device; the second control module 84 is used to control the first Pod to determine the address and port mapping of the Node where the second Pod is located according to the registration information, and the first Pod to communicate with the second Pod according to the address and port mapping of the Node where the second Pod is located.

[0123] Therefore, compared to service mesh solutions in related technologies, which require introducing a sidecar container for each service Pod, this embodiment of the invention does not involve adding a new container within the service Pod. Instead, a listening Pod is started on each Node, reducing the number of new containers by an order of magnitude—from the number of Pods to the number of Nodes—thus achieving a cost reduction. Furthermore, compared to the hostPort solution in the built-in Kubernetes solution, the port mapping process in this embodiment occurs after the service Pod scheduling is completed, thus not affecting Kubernetes' service Pod scheduling. Compared to the NodePort solution in the built-in Kubernetes solution, the port mapping on the Node in this embodiment is a one-to-one mapping with the service Pod, without load balancing, thus not affecting microservice governance functions and preventing the propagation of iptables / IP virtual server (IPVS) rules across the cluster, resulting in minimal performance impact.

[0124] Example 3

[0125] This invention also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of any of the above methods.

[0126] Example 4

[0127] This invention also provides a computer-readable storage medium storing instructions that, when executed by a processor, implement the steps of any of the above methods.

[0128] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0130] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0131] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0133] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for registering a pod in a cluster, characterized in that, The method comprises: Creating a listening Pod on each Node in the cluster, wherein the listening Pod is configured to listen to the creation of a plurality of service Pods on the Node and generate a port mapping for each service Pod; In response to a service Pod creation request, creating a service Pod and inserting a preset initializer into the service Pod; Initializing the service Pod and starting the service Pod, wherein the preset initializer is run during the initialization of the service Pod to obtain the port mapping generated by the listening Pod for the service Pod and store the port mapping in an environment variable or a startup parameter of an application container of the service Pod; wherein the port mapping on the Node and the service Pod are in a one-to-one mapping relationship without load balancing; Through a registration program in the service Pod, obtaining the address of the Node where the service Pod is located and the port mapping from the environment variable or the startup parameter, and registering the service Pod in a registration center according to the address of the Node where the service Pod is located and the port mapping, so as to enable other Pods in different clusters to directly access the service Pod.

2. The method of claim 1, wherein, Creating a listening Pod on each Node in the cluster comprises: When a new Node joins the cluster, creating a Deamon Pod as the listening Pod on the new Node through a Daemonset controller.

3. The method of claim 1, wherein, The service Pod comprises an initialization container and an application container; in response to a service Pod creation request, creating a service Pod and inserting a preset initializer into the service Pod comprises: Upon receiving the service Pod creation request, creating a service Pod and triggering a preset callback function of a webhook; Executing the preset callback function to insert the preset initializer into the initialization container of the service Pod.

4. The method of claim 3, wherein, The initialization container comprises an init container.

5. The method of claim 1, wherein, Registering the service Pod in the registration center according to the address of the Node where the service Pod is located and the port mapping comprises: Obtaining the address of the Node where the service Pod is located and the port mapping through a registration program; Through the registration program, registering the service Pod in the registration center; The registration program comprises a java agent or an SDK.

6. The method of claim 5, wherein, The service Pod comprises an initialization container and an application container, and the application container comprises a user process; during the initialization, the port mapping is stored in a startup parameter of the application container or an environment variable of the user process; Through the registration program, obtaining the port mapping comprises: Through the registration program, obtaining the port mapping from the startup parameter or the environment variable.

7. The method according to any one of claims 1 to 6, characterized in that, The initializer obtains the port mapping from the listener Pod or the controller of the listener Pod directly without the controller of the cluster, or the initializer obtains the port mapping from the controller of the cluster, wherein the port mapping is obtained by the controller of the cluster from the listener Pod or the controller of the listener Pod. 8.A method for Pod communication of a cluster, characterized in that, Comprise: A first Pod in a first cluster obtains registration information of a second Pod in a second cluster from a registration center, wherein the registration information is registered by the second Pod to the registration center according to the method of any one of claims 1-7; The first Pod determines the address of the Node where the second Pod is located and the port mapping according to the registration information, and the first Pod communicates with the second Pod according to the address of the Node where the second Pod is located and the port mapping. 9.A device for registering a pod of a cluster, characterized in that, The Node network is connected between clusters, comprising: A first creation module for creating a listener Pod on a plurality of Nodes of a cluster, wherein the listener Pod is used to listen to the creation of a plurality of service Pods on the Node, and a port mapping is generated for each service Pod; A second creation module for creating a service Pod in response to a service Pod creation request, and inserting a preset initializer into the service Pod; A processing module for initializing and starting the service Pod, wherein the preset initializer is run in the initialization process of the service Pod to obtain the port mapping generated by the listener Pod for the service Pod; and the port mapping is stored in the environment variable or the startup parameter of the application container of the service Pod; wherein the port mapping on the Node and the service Pod are in a one-to-one mapping relationship, and there is no load balancing; A registration module for obtaining the address of the Node where the service Pod is located and the port mapping from the environment variable or the startup parameter by a registration program in the service Pod, and registering the service Pod to a registration center according to the address of the Node where the service Pod is located and the port mapping, so as to be directly accessed by other Pods in different clusters.

10. The apparatus of claim 9, wherein, The first creation module is also used to create a Deamon Pod as the listener Pod on a new Node by a Daemonset controller when the new Node joins the cluster; When the service Pod includes an initialization container and an application container, the second creation module is also used to create a service Pod and trigger a preset callback function of a webhook when receiving a service Pod creation request, execute the preset callback function to insert the preset initializer into the initialization container of the service Pod; The initialization container comprises an init container; The registration module is further configured to obtain the address of the Node where the service Pod is located and the port mapping through a registration program, and register the service Pod with the registration center through the registration program; wherein the registration program comprises a javaagent or an SDK; wherein the service Pod comprises an initialization container and an application container, and the application container comprises a user process; and the port mapping is stored in a startup parameter of the application container or an environment variable of the user process during an initialization process; and the registration module is further configured to obtain the port mapping from the startup parameter or the environment variable through the registration program. The initialization program directly obtains the port mapping from the listener Pod or a controller of the listener Pod without the controller of the cluster, or the initialization program obtains the port mapping from the controller of the cluster, wherein the port mapping is obtained by the controller of the cluster from the listener Pod or the controller of the listener Pod. 11.A Pod communication apparatus of a cluster, characterized in that, The method comprises: a first control module configured to control a first Pod in a first cluster to obtain registration information of a second Pod in a second cluster from a registration center, wherein the registration information is registered by the second Pod to the registration center according to any one of the apparatuses of claims 9-10; a second control module configured to control the first Pod to determine an address of a Node where the second Pod is located and a port mapping according to the registration information, and control the first Pod to communicate with the second Pod according to the address of the Node where the second Pod is located and the port mapping.

12. An electronic device, comprising: The apparatus comprises: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of any one of the methods of claims 1-7, 8.

13. A computer-readable storage medium having stored thereon instructions, the instructions comprising, The instructions, when executed by the processor, implement the steps of any one of the methods of claims 1-7, 8.

Images