Cross-node service inter-visit method, kubernetes cluster node and kubernetes cluster

Abstract

The application relates to the technical field of communication, and provides a cross-node service intercommunication method, a Kubernetes cluster node and a Kubernetes cluster. The method comprises the following steps: when any Pod initiates a cross-node service access request for a target service, a load balancer corresponding to the Pod selects a target Pod from all Pods corresponding to the target service, acquires a proxy Pod belonging to the same node as the target Pod, and sends the service access request to the proxy Pod after modifying the service access request based on the target Pod and the proxy Pod; the proxy Pod authenticates the service access request to obtain an authentication result, and forwards the service access request carrying the authentication result to the target Pod; and the target Pod determines whether to allow the Pod to access the target service provided by the target Pod according to the authentication result carried in the received service access request. Therefore, the security of data transmission between services in the cluster is improved, the management process of service certificates is simplified, and the stability of communication between Pods in the cluster is ensured.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a method for cross-node service access, a Kubernetes cluster node, and a Kubernetes cluster. Background Technology

[0002] In cloud computing environments, Kubernetes (K8s), a container cluster management system, has become the standard platform for managing containerized applications. Each Kubernetes cluster consists of multiple nodes, each composed of a physical machine or a virtual machine. A Pod is the smallest unit of scheduling and management in a Kubernetes cluster; a Pod can include one or more containers that implement corresponding services. Each node is responsible for running one or more Pods. With the widespread adoption of microservice architectures, secure cross-node communication between services has become particularly important. Traditional service authentication methods typically rely on static configuration or a single authentication mechanism, which is neither flexible nor efficient enough in the dynamically changing Kubernetes environment.

[0003] Software product security has become a trend, and service security authentication in Kubernetes and Spring Cloud (an open-source framework for distributed systems) clusters is a complex issue. Furthermore, some application scenarios have high security requirements. Currently, there are two solutions. The first is that the target Pod supports encrypted authentication, but the Pod initiating the service access request does not. Although data transmission between the target Pod and the Pod initiating the service access request is encrypted, the lack of authentication reduces the security of the communication connection. The second solution involves one-to-one authentication between the target Pod and the Pod initiating the service access request, meaning each Pod must have a certificate. However, as the service scales, service certificate management becomes more complex, so this approach can affect the stability of communication between Pods in the cluster. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method for cross-node service communication, a Kubernetes cluster node, and a Kubernetes cluster.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows:

[0006] In a first aspect, the present invention provides a method for cross-node service access, applied to a Kubernetes cluster, wherein the Kubernetes cluster includes multiple nodes and each node deploys an authentication proxy service, and each Pod running on each node is configured with a corresponding load balancer, the method comprising:

[0007] When any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to that Pod selects a target Pod from all Pods corresponding to the target service, and selects a proxy Pod from all Pods corresponding to the authentication proxy service based on the target Pod; wherein, the proxy Pod and the target Pod belong to the same node;

[0008] The load balancer modifies the service access request based on the target Pod and the proxy Pod, and then sends it to the proxy Pod.

[0009] The proxy Pod authenticates the service access request to obtain the authentication result, and forwards the service access request carrying the authentication result to the target Pod;

[0010] The target Pod determines whether to allow any Pod to access the target service it provides based on the authentication result carried in the received service access request.

[0011] In an optional implementation, the load balancer selects the target Pod from all Pods corresponding to the target service, including:

[0012] The load balancer retrieves each Pod corresponding to the target service from the Kubernetes cluster based on the name of the target service, and selects one Pod as the target Pod from all the Pods corresponding to the target service according to a preset load balancing strategy.

[0013] In an optional implementation, the address of each Pod includes the network number of its own node;

[0014] The load balancer selects a proxy Pod from all Pods corresponding to the authentication proxy service based on the target Pod, including:

[0015] The load balancer obtains the address of the target Pod and the address of each Pod corresponding to the authentication proxy service, and selects the Pod whose network number is the same as the network number of the target Pod from all the Pods corresponding to the authentication proxy service as the proxy Pod.

[0016] In an optional implementation, the load balancer modifies the service access request based on the target Pod and the proxy Pod and sends it to the proxy Pod, including:

[0017] The load balancer modifies the target address of the service access request from the address of the target Pod to the address of the proxy Pod, stores the address of the target Pod in the request header of the service access request, and then sends it to the proxy Pod.

[0018] In an optional implementation, the proxy Pod authenticates the service access request to obtain an authentication result, and forwards the service access request carrying the authentication result to the target Pod, including:

[0019] The proxy Pod authenticates the service access request according to the transport layer security protocol, obtains the authentication result, and retrieves the address of the target Pod from the request header of the service access request.

[0020] The proxy Pod stores the authentication result in the request header of the service access request, modifies the target address of the service access request to the address of the target Pod, and then sends it to the target Pod.

[0021] In an optional implementation, the proxy Pod stores the authentication result in the request header of the service access request, including:

[0022] If the authentication result is successful, the proxy Pod will store the first flag indicating successful authentication in the request header of the service access request;

[0023] If the authentication result is authentication failure, the proxy Pod will store a second flag indicating authentication failure in the request header of the service access request.

[0024] In an optional implementation, the target Pod determines whether to allow any Pod to access the target service it provides based on the authentication result carried in the received service access request, including:

[0025] The target Pod receives the service access request sent by the proxy Pod and obtains a flag indicating the authentication result from the request header of the service access request;

[0026] The target Pod determines whether to allow any Pod to access the target service it provides based on the flag.

[0027] In an optional implementation, the target Pod determines whether to allow any Pod to access the target service it provides based on the flag, including:

[0028] When the flag is set to the first flag, the target Pod is allowed to access the target service it provides.

[0029] If the target Pod is set to the second flag, it will deny any Pod access to the target service it provides.

[0030] Secondly, the present invention provides a Kubernetes cluster node, including a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the cross-node service access method described in any of the foregoing embodiments.

[0031] Thirdly, the present invention provides a Kubernetes cluster, which includes multiple nodes and each node is equipped with an authentication proxy service. Each Pod running on each node is equipped with a corresponding load balancer. The Kubernetes cluster is used to implement the cross-node service access method described in any of the foregoing embodiments.

[0032] This invention provides a cross-node service access method, Kubernetes cluster nodes, and a Kubernetes cluster. The method is applied to a Kubernetes cluster comprising multiple nodes, each node having an authentication proxy service deployed. Each Pod running on each node has a corresponding load balancer. The method includes: when any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to that Pod selects the target Pod from all Pods corresponding to the target service and obtains a proxy Pod belonging to the same node as the target Pod. Based on the target Pod and the proxy Pod, the load balancer modifies the service access request and sends it to the proxy Pod. The proxy Pod authenticates the service access request, obtains the authentication result, and forwards the service access request carrying the authentication result to the target Pod. The target Pod determines whether to allow the Pod to access the target service it provides based on the authentication result carried in the received service access request. By deploying an authentication proxy service on each node, the proxy Pod is used to authenticate cross-node service access requests and forward the service access requests carrying the authentication result to the target Pod for processing. This improves the security of data transmission between services in the cluster, eliminates the need to configure certificates for each Pod, simplifies the service certificate management process, and ensures the stability of communication between Pods in the cluster.

[0033] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 An example diagram of a Kubernetes cluster provided in an embodiment of the present invention is shown;

[0036] Figure 2 A block diagram of a Kubernetes cluster node provided in an embodiment of the present invention is shown;

[0037] Figure 3 This illustration shows one of the flowcharts of the cross-node service access method provided in an embodiment of the present invention;

[0038] Figure 4 The second flowchart illustrates the cross-node service access method provided in this embodiment of the invention.

[0039] Icons: 110 - Processor; 120 - Memory; 130 - Communication module. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0041] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0042] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0043] Please see Figure 1 This is an example diagram of a Kubernetes cluster provided in an embodiment of the present invention. The Kubernetes cluster includes three nodes: node 1, node 2, and node 3. Each node includes multiple Pods; for example, node 1 includes Pod1 and Pod2, node 2 includes Pod3, Pod4, and Pod5, and node 3 includes Pod6, Pod7, and Pod8.

[0044] The Kubernetes cluster provides three services: Service A, Service B, and Service C. Each service has corresponding Pods; for example, Service A corresponds to Pods 1, 3, and 6; Service B corresponds to Pods 2 and 4; and Service C corresponds to Pods 5, 7, and 8. Service A is an authentication proxy service, meaning each node includes a Pod corresponding to this service. It's important to note that the resource type for the authentication proxy service is StatefulSet (a collection of stateful applications used to manage the cluster). This resource type has the characteristic that the service name and the name of the corresponding Pod remain unchanged after a service restart.

[0045] It should be noted that, Figure 1 The Kubernetes cluster shown is merely an example. The number of services, nodes, and Pods provided by the Kubernetes cluster, as well as the relationship between these three, can be configured according to the actual situation. This embodiment of the invention does not limit this.

[0046] Please see Figure 2This is a block diagram of a Kubernetes cluster node provided in an embodiment of the present invention. The Kubernetes cluster node includes a processor 110, a memory 120, and a communication module 130. These components are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0047] The processor 110 is used to read / write data or programs stored in the memory 120 and perform corresponding functions. It can be a general-purpose processor, including CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be a DSP digital signal processor, ASIC application-specific integrated circuit, FPGA off-the-shelf programmable gate array or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0048] The memory 120 is used to store programs or data. The memory 120 can be RAM (Random Access Memory), ROM (Read Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), or EEPROM (Electric Erasable Programmable Read-Only Memory).

[0049] The communication module 130 is used for signaling or data communication with other devices.

[0050] Understandable, Figure 2 The structure shown is only a schematic diagram of a Kubernetes cluster node. A Kubernetes cluster node may also include more... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown. Figure 2 The components shown can be implemented using hardware, software, or a combination thereof.

[0051] The following will combine Figure 1 The various steps in the methods provided in the embodiments of the present invention and the technical effects achieved therein will be explained.

[0052] Please see Figure 3 This is a flowchart illustrating a cross-node service access method provided in an embodiment of the present invention.

[0053] In step S202, when any Pod initiates a cross-node service access request for the target service, the load balancer corresponding to any Pod selects the target Pod from all the Pods corresponding to the target service, and selects the proxy Pod from all the Pods corresponding to the authentication proxy service based on the target Pod; wherein, the proxy Pod and the target Pod belong to the same node.

[0054] In step S204, the load balancer modifies the service access request based on the target Pod and the proxy Pod and sends it to the proxy Pod.

[0055] Step S206: The proxy Pod authenticates the service access request, obtains the authentication result, and forwards the service access request carrying the authentication result to the target Pod.

[0056] In step S208, the target Pod determines whether to allow any Pod to access the target service it provides based on the authentication result carried in the received service access request.

[0057] In this embodiment, when any Pod wants to access the service provided by other Pods, that is, when the Pod initiates a cross-node service access request for the target service, the load balancer corresponding to the Pod will first select the Pod to provide the target service from all the Pods corresponding to the target service, thus obtaining the target Pod.

[0058] The load balancer then selects a Pod from all the Pods corresponding to the authentication proxy service that belongs to the same node as the target Pod to serve as the proxy Pod. Furthermore, the load balancer modifies the service access request based on the target Pod and the proxy Pod before sending it to the proxy Pod.

[0059] Next, the proxy Pod receives the service access request, authenticates it to obtain the authentication result, and then forwards the service access request carrying the authentication result to the target Pod. It's understandable that, since the proxy Pod and the target Pod belong to the same node, the proxy Pod can use local forwarding to send the service access request to the target Pod. That is, the communication between the proxy Pod and the target Pod is secure and does not require authentication.

[0060] Finally, the target Pod receives the service access request sent by the proxy Pod and determines whether the Pod that initiated the service access request has the right to access the service it provides, i.e., the target service, based on the authentication result carried in the received service access request, thereby determining whether it should provide the target service to the Pod.

[0061] In essence, compared to existing technologies, this invention, by setting up a Pod on each node to provide authentication proxy services, utilizes the proxy Pod to authenticate cross-node service access requests and forwards the service access requests carrying the authentication results to the target Pod for processing. This improves the security of data transmission between services in the cluster, eliminates the need to configure certificates for each Pod, simplifies the service certificate management process, and ensures the stability of communication between Pods in the cluster.

[0062] As can be seen from the above steps, when any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to that Pod selects the target Pod from all Pods associated with the target service and obtains a proxy Pod belonging to the same node as the target Pod. Based on the target Pod and the proxy Pod, the load balancer modifies the service access request and sends it to the proxy Pod. The proxy Pod authenticates the service access request, obtains the authentication result, and forwards the service access request carrying the authentication result to the target Pod. The target Pod determines whether to allow the Pod to access the target service it provides based on the authentication result carried in the received service access request. By deploying an authentication proxy service on each node, the proxy Pods authenticate cross-node service access requests and forward the service access requests carrying the authentication results to the target Pod for processing. This improves the security of data transmission between services in the cluster, eliminates the need to configure certificates for each Pod, simplifies the service certificate management process, and ensures the stability of communication between Pods in the cluster.

[0063] Optionally, for the process in step S202 where the load balancer selects the target Pod from all Pods corresponding to the target service, this embodiment of the invention provides a possible implementation method, please refer to [link to relevant documentation]. Figure 4 .

[0064] In step S202-1, the load balancer obtains each Pod corresponding to the target service from the Kubernetes cluster according to the name of the target service, and selects one Pod from all the Pods corresponding to the target service as the target Pod according to the preset load balancing strategy.

[0065] For ease of understanding, the following example uses the Pod that initiated the service access request as an example. Figure 1 Let's take Pod2 and the target service C as an example. For instance, when Pod2 makes a request to service C, the load balancer corresponding to Pod2 retrieves each Pod corresponding to service C from the Kubernetes cluster based on the name of service C, resulting in Pod5, Pod7, and Pod8.

[0066] Then, the load balancer corresponding to Pod2 selects one Pod from Pod5, Pod7, and Pod8 according to a preset load balancing strategy to serve C as the target Pod for providing services to Pod2. For example, assuming the load balancing strategy is to select the Pod with the lowest current system resource consumption as the target Pod, then the Pod with the lowest current system resource consumption among Pod5, Pod7, and Pod8, such as Pod8, will be selected as the target Pod. It should be understood that the load balancing strategy can be set according to the actual requests, and this embodiment of the invention is not limited in this respect.

[0067] Optionally, for the process in step S202 where the load balancer selects a proxy Pod from all Pods corresponding to the authentication proxy service based on the target Pod, this embodiment of the invention provides a possible implementation method, please refer to the following: Figure 4 .

[0068] In step S202-3, the load balancer obtains the address of the target Pod and the address of each Pod corresponding to the authentication proxy service, and selects the Pod whose network number is the same as the network number of the target Pod from all the Pods corresponding to the authentication proxy service as the proxy Pod.

[0069] It is understandable that Kubernetes clusters have a network characteristic where the network addresses of Pods on the same node are the same. Therefore, this embodiment of the invention utilizes this network characteristic to obtain proxy Pods that belong to the same node as the target Pod.

[0070] In this embodiment, the address of each Pod includes the network number of its parent node, and the address of a Pod can be an IP (Internet Protocol) address. For example, the IP addresses and network numbers of Pod5, Pod7, and Pod8 corresponding to the target service C are shown in Table 1 below.

[0071] Table 1

[0072]

[0073] Furthermore, the IP addresses and network IDs of Pod1, Pod3, and Pod6 corresponding to the aforementioned authentication proxy service, i.e., service A, are shown in Table 2 below.

[0074] Table 2

[0075]

[0076] To facilitate understanding, the following explanation will combine Tables 1 and 2, continuing with the example where the Pod initiating the service access request is Pod2 and the target Pod is Pod8. For instance, the load balancer corresponding to Pod2 obtains the IP address of Pod8, which is 100.64.175.99, and also obtains the IP addresses of each Pod corresponding to the authentication proxy service, i.e., service A. This yields the IP addresses of Pod1 (100.107.182.107), Pod3 (100.65.108.103), and Pod6 (100.64.175.95).

[0077] Then, the load balancer corresponding to Pod2 selects a Pod from Pod1, Pod3, and Pod6 that has the same network ID as Pod8's IP address to serve as the proxy Pod. Since the network ID of Pod6's IP address is the same as that of Pod8's IP address (i.e., both have the network ID 100.64.175), using Pod6 as the proxy Pod results in a Pod that is on the same node as Pod8 and is used to provide authentication proxy services.

[0078] Optionally, for step S204, this embodiment of the invention provides a possible implementation method, namely: the load balancer modifies the target address of the service access request from the address of the target Pod to the address of the proxy Pod, and stores the address of the target Pod in the request header of the service access request before sending it to the proxy Pod.

[0079] Understandably, existing technology involves the Pod initiating a service access request directly sending the request to the target Pod, which then authenticates the request. However, this invention differs from existing technology by setting up a dedicated Pod on each node for authenticating service access requests. Therefore, this invention modifies the target address of the service access request, changing the process from the Pod initiating the request directly sending it to the target Pod to the Pod initiating the request sending it to a proxy Pod, which then authenticates the request before forwarding it to the target Pod.

[0080] To facilitate understanding, let's continue with the example where the Pod initiating the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For instance, the load balancer corresponding to Pod2 modifies the target address in the service access request for service C from the IP address of the target Pod (Pod8), which is 100.64.175.99, to the IP address of the proxy Pod (Pod6), which is 100.64.175.95. Furthermore, it sets the IP address of Pod8 to the value of the ProxyAuthentication key field in the request header, storing Pod8's IP address in the service access request header, and then sends the modified service access request to Pod6 so that Pod6 can authenticate it.

[0081] Optionally, for step S206, this embodiment of the invention provides a possible implementation.

[0082] Step S206-1: The proxy Pod authenticates the service access request according to the transport layer security protocol, obtains the authentication result, and retrieves the address of the target Pod from the request header of the service access request.

[0083] In step S206-3, the proxy Pod stores the authentication result in the request header of the service access request, modifies the target address of the service access request to the address of the target Pod, and then sends it to the target Pod.

[0084] To facilitate understanding, let's continue with the example where the Pod initiating the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For instance, Pod6 authenticates the service access request for service C sent by Pod2 using the Transport Layer Security (TLS) protocol to obtain the authentication result. Furthermore, Pod6 retrieves the value of the proxy authentication key field in the request header of this service access request, thus obtaining the IP address of Pod8, which is 100.64.175.99.

[0085] Then, Pod6 sets the authentication result to the value of the proxy authentication key field in the request header, and stores the authentication result in the request header of the service access request. After modifying the target address of the service access request to the IP address of the target Pod, i.e., Pod8, it sends the service access request to Pod8, so that Pod8 can determine whether to provide services to Pod2 based on the authentication result carried in the service access request.

[0086] Optionally, for step S206-3, this embodiment of the invention provides a possible implementation.

[0087] In step S206-3a, if the authentication result is successful, the proxy Pod stores the first flag indicating successful authentication in the request header of the service access request.

[0088] In step S206-3b, if the authentication result is authentication failure, the proxy Pod stores the second flag indicating authentication failure in the request header of the service access request.

[0089] To facilitate understanding, let's continue with the example where the Pod initiating the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For instance, Pod6 authenticates the service access request for service C sent by Pod2. If authentication is successful, it means Pod2 has the right to access service C. Pod6 then sets the first flag indicating successful authentication, such as True, to the value of the proxy authentication key field in the request header, storing this authentication result in the service access request header.

[0090] If authentication fails, it means that Pod2 does not have permission to access service C. Pod6 will then set the second flag indicating authentication failure (e.g., False) to the value of the proxy authentication key field in the request header, storing this authentication failure result in the service access request header. It should be understood that the first and second flags can be set according to actual circumstances, and this embodiment of the invention does not limit this.

[0091] Optionally, for step S208, this embodiment of the invention provides a possible implementation.

[0092] Step S208-1: The target Pod receives the service access request sent by the proxy Pod and obtains the flag indicating the authentication result from the request header of the service access request.

[0093] In step S208-3, the target Pod determines, based on the flag, whether to allow any Pod to access the target service it provides.

[0094] To facilitate understanding, let's continue with the example where the Pod initiating the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For instance, Pod8 receives the service access request from Pod6 and retrieves the value of the proxy authentication key field in the request header, thus obtaining a flag indicating the authentication result. Based on this flag, Pod8 determines whether Pod2 has the right to access the service it provides, namely service C, and therefore whether it should provide service C to Pod2.

[0095] Optionally, for step S208-3, this embodiment of the invention provides a possible implementation.

[0096] In step S208-3a, if the target Pod is marked with the first flag, any Pod is allowed to access the target service it provides.

[0097] In step S208-3b, if the target Pod is marked with the second flag, it will deny any other Pod access to the target service it provides.

[0098] To facilitate understanding, let's continue with the example where the Pod initiating the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For instance, after Pod8 receives the authentication result flag in the request header, if the flag is the first flag (True), it means Pod2 has permission to access service C, and Pod8 will allow Pod2 to access the service it provides; that is, Pod8 will provide service C to Pod2. If the flag is the second flag (False), it means Pod2 does not have permission to access service C, and Pod8 will refuse Pod2 access to the service it provides; that is, Pod8 will not provide service C to Pod2.

[0099] This invention also provides a Kubernetes cluster node, including a processor and a memory. The memory stores a computer program, and when the processor executes the computer program, it implements the cross-node service access method disclosed in this invention.

[0100] This invention also provides a Kubernetes cluster for implementing the cross-node service access method disclosed in this invention.

[0101] In summary, the cross-node service access method, Kubernetes cluster node, and Kubernetes cluster provided in this embodiment of the invention have the following technical effects: (1) This invention can be used for service security authentication within the cluster, and can authenticate and encrypt cross-node requests, thereby improving the security of the cluster product. (2) Based on security risks, this invention divides service access requests within the cluster into cross-node requests and intra-node requests. It utilizes an authentication proxy service to perform security authentication on cross-node requests, while not performing security authentication on intra-node requests, thus meeting the requirement for security authentication of cross-node requests. (3) This invention provides a solution that eliminates the need to configure certificates for each Pod, avoiding the complexity of the authentication process caused by numerous services and variable IP domain names within the cluster.

[0102] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0103] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0104] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion 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 this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0105] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for cross-node service access, characterized in that, Applied to a Kubernetes cluster, wherein the Kubernetes cluster comprises multiple nodes and each node has an authentication proxy service deployed, and each Pod running on each node has a corresponding load balancer configured, the method includes: When any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to that Pod selects a target Pod from all Pods corresponding to the target service, and selects a proxy Pod from all Pods corresponding to the authentication proxy service based on the target Pod; wherein, the proxy Pod and the target Pod belong to the same node; The load balancer modifies the service access request based on the target Pod and the proxy Pod, and then sends it to the proxy Pod. The proxy Pod authenticates the service access request to obtain the authentication result, and then sends the service access request carrying the authentication result to the target Pod. The target Pod determines whether to allow any Pod to access the target service it provides based on the authentication result carried in the received service access request.

2. The method according to claim 1, characterized in that, The load balancer selects the target Pod from all Pods corresponding to the target service, including: The load balancer retrieves each Pod corresponding to the target service from the Kubernetes cluster based on the name of the target service, and selects one Pod as the target Pod from all the Pods corresponding to the target service according to a preset load balancing strategy.

3. The method according to claim 1, characterized in that, Each Pod's address includes the network number of its own node; The load balancer selects a proxy Pod from all Pods corresponding to the authentication proxy service based on the target Pod, including: The load balancer obtains the address of the target Pod and the address of each Pod corresponding to the authentication proxy service, and selects the Pod whose network number is the same as the network number of the target Pod from all the Pods corresponding to the authentication proxy service as the proxy Pod.

4. The method according to claim 1, characterized in that, The load balancer modifies the service access request based on the target Pod and the proxy Pod and sends it to the proxy Pod, including: The load balancer modifies the target address of the service access request from the address of the target Pod to the address of the proxy Pod, stores the address of the target Pod in the request header of the service access request, and then sends it to the proxy Pod.

5. The method according to claim 1, characterized in that, The proxy Pod authenticates the service access request to obtain an authentication result, and then sends the service access request carrying the authentication result to the target Pod, including: The proxy Pod authenticates the service access request according to the transport layer security protocol, obtains the authentication result, and retrieves the address of the target Pod from the request header of the service access request. The proxy Pod stores the authentication result in the request header of the service access request, modifies the target address of the service access request to the address of the target Pod, and then sends it to the target Pod.

6. The method according to claim 5, characterized in that, The proxy Pod stores the authentication result in the request header of the service access request, including: If the authentication result is successful, the proxy Pod will store the first flag indicating successful authentication in the request header of the service access request; If the authentication result is authentication failure, the proxy Pod will store a second flag indicating authentication failure in the request header of the service access request.

7. The method according to claim 6, characterized in that, The target Pod determines whether to allow any Pod to access the target service it provides based on the authentication result carried in the received service access request, including: The target Pod receives the service access request sent by the proxy Pod and obtains a flag indicating the authentication result from the request header of the service access request; The target Pod determines whether to allow any Pod to access the target service it provides based on the flag.

8. The method according to claim 7, characterized in that, Based on the flag, the target Pod determines whether to allow any Pod to access the target service it provides, including: When the flag is set to the first flag, the target Pod is allowed to access the target service it provides. If the target Pod is set to the second flag, it will deny any Pod access to the target service it provides.

9. A Kubernetes cluster node, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the cross-node service access method of any one of claims 1 to 8.

10. A Kubernetes cluster, characterized in that, The Kubernetes cluster includes multiple nodes, and each node is equipped with an authentication proxy service. Each Pod running on each node is equipped with a corresponding load balancer. The Kubernetes cluster is used to implement the cross-node service access method according to any one of claims 1 to 8.

Images