Cross-node service mutual access method, Kubernetes cluster node and Kubernetes cluster

Abstract

The invention relates to the technical field of communication, and provides a cross-node service mutual access 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 with the target Pod, modifies the service access request based on the target Pod and the proxy Pod, and sends the modified service access request to 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 among the services of the cluster is improved, the management process of the service certificate is simplified, and the stability of communication among the Pods in the cluster is ensured.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a cross-node service mutual access method, a Kubernetes cluster node, and a Kubernetes cluster. Background Art

[0002] In the cloud computing environment, Kubernetes (Container Cluster Management System), referred to as K8s, has become a standard platform for managing containerized applications. Each Kubernetes cluster includes multiple nodes, each of which is composed of a physical machine or a virtual machine. Pod is the smallest unit of scheduling and management in a Kubernetes cluster. A Pod can include one or more containers, which implement corresponding services. Each node is responsible for running one or more Pods. With the popularity of microservice architecture, cross-node communication security between services has become particularly important. Traditional service authentication methods usually rely on static configuration or a single authentication mechanism, which is not flexible and efficient in the dynamically changing Kubernetes environment.

[0003] Software product security has become a trend. It is a complex issue to perform service security authentication in Kubernetes and Spring Cloud (open source framework for distributed systems) clusters. In addition, some application scenarios have higher requirements for product security. There are currently two solutions. The first is that the target Pod supports encryption authentication, but the Pod that initiates the service access request does not use authentication. Although the data transmission between the target Pod and the Pod that initiates the service access request is encrypted in this way, no authentication is performed, which reduces the security of the communication connection. The second is that the target Pod and the Pod that initiates the service access request perform one-to-one authentication, which means that each Pod must have a certificate. However, as the scale of services expands, service certificate management becomes more complicated, so this method will affect the stability of communication between Pods in the cluster. Summary of the invention

[0004] In view of this, the object of the present invention is to provide a cross-node service mutual access method, a Kubernetes cluster node and a Kubernetes cluster.

[0005] In order to achieve the above purpose, the technical solution adopted by the embodiment of the present invention is as follows:

[0006] In a first aspect, the present invention provides a cross-node service mutual access method, which is applied to a Kubernetes cluster, wherein the Kubernetes cluster includes multiple nodes and each node is deployed with an authentication proxy service, and each Pod running in each node is provided with a corresponding load balancer, and the method includes:

[0007] When any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to any 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 according to 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 sends the request to the proxy Pod;

[0009] 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;

[0010] The target Pod determines whether to allow any of the Pods to access the target service provided by itself according to the authentication result carried in the received service access request.

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

[0012] 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 a Pod as the target Pod from all 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 the node to which it belongs;

[0014] The load balancer selects a proxy Pod from all Pods corresponding to the authentication proxy service according to 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 obtains a Pod whose address network number is the same as the network number of the target Pod from all Pods corresponding to the authentication proxy service as a proxy Pod.

[0016] In an optional implementation manner, the load balancer modifies the service access request based on the target Pod and the proxy Pod and sends the request 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 manner, 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 to obtain an authentication result, and obtains 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, and modifies the target address of the service access request to the address of the target Pod and 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] When the authentication result is successful, the proxy Pod stores a first flag indicating successful authentication in the request header of the service access request;

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

[0024] In an optional implementation manner, the target Pod determines whether to allow any Pod to access the target service provided by itself according to 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 of the Pods to access the target service provided by itself based on the flag.

[0027] In an optional implementation manner, the target Pod determines whether to allow any of the Pods to access the target service provided by itself based on the flag, including:

[0028] When the flag is the first flag, the target Pod allows any Pod to access the target service provided by itself;

[0029] When the flag is the second flag, the target Pod denies any Pod access to the target service provided by itself.

[0030] In a second aspect, the present invention provides a Kubernetes cluster node, comprising a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, the cross-node service inter-access method in any one of the aforementioned implementation modes is implemented.

[0031] In a third aspect, the present invention provides a Kubernetes cluster, wherein the Kubernetes cluster includes multiple nodes and each node is deployed with an authentication proxy service, and each Pod running in each node is provided with a corresponding load balancer, and the Kubernetes cluster is used to implement the cross-node service inter-access method described in any of the aforementioned implementation methods.

[0032] The cross-node service mutual access method, Kubernetes cluster node and Kubernetes cluster provided by the embodiment of the present invention are applied to the Kubernetes cluster, the Kubernetes cluster includes multiple nodes and each node is deployed with an authentication proxy service, and each Pod running in each node is provided with 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 any Pod selects a target Pod from all Pods corresponding to the target service, obtains a proxy Pod belonging to the same node as the target Pod, and based on the target Pod and the proxy Pod, modifies the service access request and sends it to 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; the target Pod determines whether to allow the Pod to access the target service provided by itself according to 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 the cross-node service access request, and the service access request carrying the authentication result is forwarded to the target Pod for processing. Thereby, the security of data transmission between services in the cluster is improved, and there is no need to configure a certificate for each Pod, which simplifies the management process of the service certificate and ensures the stability of communication between Pods in the cluster.

[0033] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

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

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

[0037] Figure 3 One of the flow diagrams of the cross-node service mutual access method provided by an embodiment of the present invention is shown;

[0038] Figure 4 The second flowchart of the cross-node service mutual access method provided by the embodiment of the present invention is shown.

[0039] Icon: 110 - processor; 120 - memory; 130 - communication module. DETAILED DESCRIPTION

[0040] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0041] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

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

[0043] See also Figure 1 , is an example diagram of a Kubernetes cluster provided by an embodiment of the present invention. The Kubernetes cluster includes three nodes, namely, node 1, node 2, and node 3. Each node includes multiple Pods, for example, node 1 includes Pod 1 and Pod 2, node 2 includes Pod 3, Pod 4, and Pod 5, and node 3 includes Pod 6, Pod 7, and Pod 8.

[0044] The Kubernetes cluster is used to provide three services, namely Service A, Service B, and Service C. And each service has a corresponding Pod, such as Service A corresponds to Pod1, Pod3, and Pod6, Service B corresponds to Pod2 and Pod4, and Service C corresponds to Pod5, Pod7, and Pod8. Moreover, Service A is an authentication proxy service, that is, each node includes a Pod corresponding to the authentication proxy service. It should be noted that the resource type of the authentication proxy service is Statefulset (a collection used to manage stateful applications in the cluster). This resource type has the characteristic that after the service is restarted, the name of the service and the name of the Pod corresponding to the service will not change.

[0045] It should be noted that Figure 1 The Kubernetes cluster shown is only an example. The number of services, nodes, and Pods provided by the Kubernetes cluster, as well as the relationship between the services, nodes, and Pods, can be set according to actual conditions, and the embodiments of the present invention are not limited to this.

[0046] See also Figure 2, is a block diagram of a Kubernetes cluster node provided by an embodiment of the present invention. The Kubernetes cluster node includes a processor 110, a memory 120, and a communication module 130, and each component is directly or indirectly electrically connected to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other via 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 execute corresponding functions. It can be a general-purpose processor, including a CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be a DSP digital signal processor, an ASIC application-specific integrated circuit, an FPGA off-the-shelf programmable gate array or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components.

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

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

[0050] Understandably, Figure 2 The structure shown is only a schematic diagram of the structure of the Kubernetes cluster node. The Kubernetes cluster node can also include Figure 2 More or fewer components as shown, or with Figure 2 Different configurations are shown. Figure 2 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

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

[0052] See also Figure 3 , is a flow chart of a cross-node service inter-access method provided by an embodiment of the present invention.

[0053] Step S202, when any Pod initiates a cross-node service access request for a target service, the load balancer corresponding to any 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.

[0054] 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 to obtain an authentication result, and forwards the service access request carrying the authentication result to the target Pod.

[0056] Step S208: The target Pod determines whether to allow any Pod to access the target service provided by itself according to the authentication result carried in the received service access request.

[0057] In this embodiment, when any Pod expects to access the services 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 used to provide the target service from all the Pods corresponding to the target service, that is, obtain the target Pod.

[0058] The load balancer will then select a Pod that belongs to the same node as the target Pod from all Pods corresponding to the authentication proxy service as the proxy Pod. The load balancer will also modify the service access request based on the target Pod and the proxy Pod and send it to the proxy Pod.

[0059] The proxy Pod then 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 can be understood 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 interaction 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 provided by itself, that is, the target service, based on the authentication result carried in the received service access request, thereby determining whether it provides the target service to the Pod.

[0061] It can be understood that, compared with the prior art, the embodiment of the present invention uses the proxy Pod to authenticate cross-node service access requests by setting up a Pod for providing authentication proxy services on each node, and forwards the service access request carrying the authentication result to the target Pod for processing. This improves the security of data transmission between services in the cluster, and does not require the configuration of certificates for each Pod, simplifies the management process of service certificates, and ensures the stability of communication between Pods in the cluster.

[0062] It can be seen that based on the above steps, 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 Pods corresponding to the target service, and obtains the proxy Pod belonging to the same node as the target Pod, and based on the target Pod and the proxy Pod, modifies the service access request and sends it to the proxy Pod; 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; the target Pod determines whether to allow the Pod to access the target service provided by itself 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 the cross-node service access request, and the service access request carrying the authentication result is forwarded to the target Pod for processing. This improves the security of data transmission between services in the cluster, and there is no need to configure certificates for each Pod, which simplifies the management process of service certificates 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, an embodiment of the present invention provides a possible implementation method, see 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 a Pod as the target Pod from all Pods corresponding to the target service according to a preset load balancing strategy.

[0065] For ease of understanding, the Pod that initiates the service access request is Figure 1 For example, when Pod2 initiates a request for Service C, the load balancer corresponding to Pod2 obtains each Pod corresponding to Service C from the Kubernetes cluster according to the name of Service C, and obtains Pod5, Pod7, and Pod8.

[0066] Then, the load balancer corresponding to Pod2 selects a Pod from Pod5, Pod7 and Pod8 according to the preset load balancing strategy as the target Pod that provides service C to Pod2. For example, assuming that the load balancing strategy is to select the Pod that occupies the least current system resources as the target Pod, then the Pod that occupies the least current system resources among Pod5, Pod7 and Pod8, such as Pod8, is used as the target Pod. It should be understood that the load balancing strategy can be set according to the actual request, and the embodiment of the present invention is not limited to this.

[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 according to the target Pod, the embodiment of the present invention provides a possible implementation method, please continue to refer to 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 obtains the Pod whose address network number is the same as the target Pod's address network number from all Pods corresponding to the authentication proxy service as the proxy Pod.

[0069] It is understandable that the Kubernetes cluster has a network feature that the network numbers of the addresses of the various Pods on the same node are the same. Therefore, the embodiment of the present invention utilizes this network feature to obtain the proxy Pod that belongs to the same node as the target Pod.

[0070] In this embodiment, the address of each Pod includes the network number of the node to which it belongs, and the address of the 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] In addition, the IP addresses and network numbers of Pod1, Pod3 and Pod6 corresponding to the above-mentioned authentication proxy service, namely service A, are shown in Table 2 below.

[0074] Table 2

[0075]

[0076] For ease of understanding, the following will combine Table 1 and Table 2, and continue to use the example that the Pod that initiates the service access request is Pod2 and the target Pod is Pod8. For example, the load balancer corresponding to Pod2 obtains the IP address of Pod8, which is 100.64.175.99, and obtains the IP address of each Pod corresponding to the authentication proxy service, namely Service A, and obtains the IP address of Pod1, which is 100.107.182.107, the IP address of Pod3, which is 100.65.108.103, and the IP address of Pod6, which is 100.64.175.95.

[0077] Then the load balancer corresponding to Pod2 selects the Pod with the same network number as Pod8's IP address from Pod1, Pod3, and Pod6 as the proxy Pod. Since the network number of Pod6's IP address is the same as that of Pod8, that is, the network numbers of both are 100.64.175, Pod6 is used as the proxy Pod, and a Pod that is on the same node as Pod8 and is used to provide authentication proxy services is obtained.

[0078] Optionally, for step S204, an embodiment of the present invention provides a possible implementation method, namely: the load balancer changes 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 and sends it to the proxy Pod.

[0079] It is understandable that in the prior art, the Pod that initiates the service access request directly sends the service access request to the target Pod, and the target Pod authenticates the service access request. The embodiment of the present invention is different from the prior art in that a Pod specifically used to authenticate the service access request is set up on each node. Therefore, the embodiment of the present invention will modify the target address of the service access request, so that the Pod that originally initiated the service access request directly sent the service access request to the target Pod, and the Pod that initiated the service access request will send the service access request to the proxy Pod, and the proxy Pod will authenticate the service access request and then forward it to the target Pod.

[0080] For ease of understanding, let's continue to use the example that the Pod that initiates the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For example, the load balancer corresponding to Pod2 will modify the target address in the service access request for accessing service C from the IP address of the target Pod, Pod8, 100.64.175.99, to the IP address of the proxy Pod, Pod6, 100.64.175.95. And set the IP address of Pod8 to the value of the proxy authentication key field in the request header, ProxyAuthentication, to store the IP address of Pod8 in the request header of the service access request, and then send the modified service access request to Pod6 so that Pod6 can authenticate it.

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

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

[0083] 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 sends it to the target Pod.

[0084] For ease of understanding, let's continue to use the example that the Pod that initiates the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For example, Pod6 authenticates the service access request sent by Pod2 to access service C according to the Transport Layer Security protocol, namely TLS (Transport Layer Security), to obtain the authentication result. And Pod6 obtains the value of the proxy authentication key field in the request header of the service access request, and obtains the IP address of Pod8, namely 100.64.175.99.

[0085] Pod6 then sets the authentication result as the value of the proxy authentication key field in the request header to store 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, the service access request is sent to Pod8, so that Pod8 determines whether to provide services to Pod2 based on the authentication result carried in the service access request.

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

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

[0088] Step S206-3b: When the authentication result is authentication failure, the proxy Pod stores a second flag indicating authentication failure in the request header of the service access request.

[0089] For ease of understanding, let's continue to use the example that the Pod that initiates the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For example, Pod6 authenticates the service access request sent by Pod2 to access service C. If the authentication is successful, it means that Pod2 has the right to access service C, then Pod6 sets the first flag indicating successful authentication, such as True, to the value of the proxy authentication key field in the request header to store the authentication result of successful authentication in the request header of the service access request.

[0090] If the authentication fails, it means that Pod2 has no right to access service C, then Pod6 sets the second flag indicating authentication failure, such as False, to the value of the proxy authentication key field in the request header to store the authentication result of authentication failure in the request header of the service access request. It should be understood that the first flag and the second flag can be set according to actual conditions, and the embodiment of the present invention is not limited to this.

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

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

[0093] Step S208-3: The target Pod determines whether to allow any Pod to access the target service provided by itself based on the flag.

[0094] For ease of understanding, let's continue to use the example that the Pod that initiates the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For example, Pod8 receives the service access request sent by Pod6, and obtains the value of the proxy authentication key field in the request header of the service access request, and then obtains the flag representing the authentication result. Then, based on this flag, Pod8 determines whether Pod2 has the right to access the service it provides, namely service C, and thus determines whether it provides service C to Pod2.

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

[0096] Step S208-3a, when the target Pod is marked with the first mark, any Pod is allowed to access the target service provided by itself.

[0097] Step S208-3b, when the target Pod is marked with the second mark, the target Pod denies any Pod access to the target service provided by itself.

[0098] For ease of understanding, let's continue to use the example that the Pod that initiates the service access request is Pod2, the proxy Pod is Pod6, and the target Pod is Pod8. For example, after Pod8 obtains the flag indicating the authentication result in the request header. If the flag is the first flag, that is, True, it means that Pod2 has the right to access service C, then Pod8 will allow Pod2 to access the service it provides, that is, Pod8 provides service C to Pod2. If the flag is the second flag, that is, False, it means that Pod2 does not have the right to access service C, then Pod8 will deny Pod2 access to the service it provides, that is, Pod8 does not provide service C to Pod2.

[0099] The embodiment of the present invention further 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, the cross-node service mutual access method disclosed in the embodiment of the present invention is implemented.

[0100] The embodiment of the present invention also provides a Kubernetes cluster, which is used to implement the cross-node service mutual access method disclosed in the embodiment of the present invention.

[0101] In summary, the cross-node service inter-access method, Kubernetes cluster node and Kubernetes cluster provided by the embodiments of the present invention have the following technical effects: (1) The present invention can be used for service security authentication within the cluster, and can authenticate and encrypt cross-node requests, thereby improving the security of cluster products. (2) According to security risks, the present invention divides the service inter-access requests within the cluster into cross-node requests and intra-node requests. The authentication proxy service is used to perform security authentication on cross-node requests, and no security authentication is performed on intra-node requests, thereby meeting the need for security authentication of cross-node requests. (3) The present invention provides a solution that does not require configuration of certificates for each Pod, thereby avoiding the complexity of the authentication process caused by the large number of services and non-fixed IP domain names within the cluster.

[0102] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

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

[0104] If the functions are implemented in the form of software function 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 the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0105] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A cross-node service mutual access method, characterized in that: Applied to a Kubernetes cluster, the Kubernetes cluster includes multiple nodes and each node is deployed with an authentication proxy service, and each Pod running in each node is provided with 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 any 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 according to 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 sends the request to the proxy Pod; The proxy Pod authenticates the service access request to obtain an authentication result, and sends the service access request carrying the authentication result to the target Pod; The target Pod determines whether to allow any of the Pods to access the target service provided by itself according to the authentication result carried in the received service access request.

2. The method according to claim 1, characterized in that The load balancer selects a target Pod from all Pods corresponding to the target service, including: 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 a Pod as the target Pod from all Pods corresponding to the target service according to a preset load balancing strategy.

3. The method according to claim 1, characterized in that The address of each Pod contains the network number of the node to which it belongs; The load balancer selects a proxy Pod from all Pods corresponding to the authentication proxy service according to 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 obtains a Pod whose address network number is the same as the network number of the target Pod from all Pods corresponding to the authentication proxy service as a 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 the request 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 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 to obtain an authentication result, and obtains 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, and modifies the target address of the service access request to the address of the target Pod and 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: When the authentication result is successful, the proxy Pod stores a first flag indicating successful authentication in the request header of the service access request; When the authentication result is authentication failure, the proxy Pod stores 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 provided by itself according to 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 of the Pods to access the target service provided by itself based on the flag.

8. The method according to claim 7, characterized in that The target Pod determines whether to allow any of the Pods to access the target service provided by itself based on the flag, including: When the flag is the first flag, the target Pod allows any Pod to access the target service provided by itself; When the flag is the second flag, the target Pod denies any Pod access to the target service provided by itself.

9. A Kubernetes cluster node, characterized in that: It comprises a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, the cross-node service mutual access method in any one of claims 1 to 8 is implemented.

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

Images