Access relationship acquisition method and apparatus, server, and storage medium

Abstract

The application discloses an access relationship acquisition method and device, a server and a storage medium. The access relationship acquisition method comprises the following steps: acquiring node access flow information reported by a target virtual machine node in a hyper-converged HCI cluster as first access flow information; acquiring access flow information of a pod in a k8s cluster node reported by a k8s cluster node as second access flow information; aggregating the first access flow information and the second access flow information to obtain an aggregation result; and determining an end-to-end access relationship of the pod in the k8s cluster node according to the aggregation result. The method aggregates the first access flow information reported by the virtual machine node and the access flow information reported by the k8s cluster node, and obtains the end-to-end access relationship of the pod in the k8s cluster node. By establishing the end-to-end access relationship of the pod in the k8s cluster node, the access flow information reported by the virtual machine node is aggregated, and interference caused by the access flow information reported by the virtual machine node is avoided.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, server, and storage medium for obtaining access relationships. Background Technology

[0002] In related technologies, application software (Kubernetes, k8s) cluster nodes are deployed on virtual machine nodes. Hyper-Converged Infrastructure (HCI) clusters provide virtual machine nodes as worker nodes required by the k8s cluster nodes, and k8s cluster nodes are deployed within these nodes. Virtual machine nodes communicate with each other using virtual networks. HCI clusters not only utilize k8s cluster nodes to collect access flow information of pods within the k8s cluster nodes, but also utilize virtual machine nodes to collect access flow information through the virtual network. Furthermore, the access flow relationships collected by virtual machine nodes can interfere with the determination of pod access relationships within the k8s cluster nodes. Summary of the Invention

[0003] In view of the above problems, this application proposes a method, apparatus, server and storage medium for obtaining access relationships.

[0004] In a first aspect, embodiments of this application provide a method for obtaining access relationships. The method includes: obtaining node access flow information reported by a target virtual machine node in a hyperconverged infrastructure (HCI) cluster as first access flow information, wherein the first access flow information includes access flow information generated by a scheduling unit pod within an application software Kubernetes cluster node in the HCI cluster through a virtual network, wherein the target virtual machine node is another virtual machine node in the HCI cluster besides the Kubernetes cluster node, and the virtual network is a network through which all virtual machine nodes in the HCI cluster communicate; obtaining access flow information of pods within the Kubernetes cluster node reported by the Kubernetes cluster node as second access flow information; aggregating the first access flow information and the second access flow information to obtain an aggregation result; and determining the end-to-end access relationship of pods within the Kubernetes cluster node based on the aggregation result, wherein the end-to-end access relationship includes at least one of the following: access relationship between the pod and the public network, access relationship between the pod and other pods within the Kubernetes cluster nodes in the HCI cluster, and access relationship between the pod and other virtual machine nodes in the HCI cluster.

[0005] Secondly, embodiments of this application provide an access relationship acquisition device, the device comprising: a first access flow information acquisition module, used to acquire node access flow information reported by a target virtual machine node in a hyperconverged infrastructure (HCI) cluster, as the first access flow information, the first access flow information including access flow information generated by a scheduling unit pod within an application software Kubernetes cluster node in the HCI cluster through a virtual network, the target virtual machine node being other virtual machine nodes in the HCI cluster besides the Kubernetes cluster node, and the virtual network being the network through which all virtual machine nodes in the HCI cluster communicate; and a second access flow information acquisition module. The first access flow information module is used to obtain access flow information of pods within the Kubernetes cluster node reported by the Kubernetes cluster node, as the second access flow information; the second access flow information module is used to aggregate the first access flow information and the second access flow information to obtain an aggregation result; the third access relationship determination module is used to determine the end-to-end access relationship of pods within the Kubernetes cluster node based on the aggregation result, wherein the end-to-end access relationship includes at least one of the following: the access relationship between the pod and the public network, the access relationship between the pod and other pods within the Kubernetes cluster node in the HCI cluster, and the access relationship between the pod and other virtual machine nodes in the HCI cluster.

[0006] Thirdly, embodiments of this application provide a server, the server comprising: one or more processors; a memory; one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the access relationship acquisition method provided in the first aspect above.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, which can be invoked by a processor to execute the access relationship acquisition method provided in the first aspect above.

[0008] The solution provided in this application aggregates the first access flow information reported by the virtual machine node and the access flow information reported by the Kubernetes cluster node to establish the association between the virtual machine node and the Kubernetes cluster node, and obtains the end-to-end access relationship of the pods in the Kubernetes cluster node. By establishing the end-to-end access relationship of the pods in the Kubernetes cluster node, the access flow information reported by the virtual machine node is aggregated, avoiding the interference caused by the access flow information reported by the virtual machine node. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This diagram illustrates access flow information in an HCI cluster within a related technology.

[0011] Figure 2 A flowchart illustrating a method for obtaining access relationships according to an embodiment of this application is shown.

[0012] Figure 3 A flowchart illustrating a method for obtaining access relationships according to another embodiment of this application is shown.

[0013] Figure 4 A flowchart illustrating a method for obtaining access relationships according to another embodiment of this application is shown.

[0014] Figure 5 A schematic diagram of an application scenario provided by an embodiment of this application is shown.

[0015] Figure 6 A structural block diagram of the access relationship acquisition device provided in an embodiment of this application is shown.

[0016] Figure 7 A structural block diagram of a server for performing an access relationship acquisition method according to an embodiment of this application is shown.

[0017] Figure 8 This application illustrates a storage medium for storing or carrying program code that implements a method for obtaining access relationships according to an embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0019] In related technologies, access flow information within a Kubernetes cluster node includes not only access flow information between pods within the cluster node, but also access flow information from pods accessing external Kubernetes cluster nodes and from external Kubernetes cluster nodes accessing internal Kubernetes cluster nodes. For example, this could include access flow information from a pod to a virtual machine node within an HCI cluster outside the Kubernetes cluster node, access flow information from a pod to the public network outside the HCI cluster, or access flow information from a virtual machine node within an HCI cluster outside the Kubernetes cluster node to a pod within the Kubernetes cluster node.

[0020] Please see Figure 1 , Figure 1 This diagram illustrates access flow information in an HCI cluster within related technologies. Figure 1 In this example, pod1's Internet Protocol address (IP) is ip1, the IP of node A in the Kubernetes cluster is NodeIP1, and the IP of node B in the Kubernetes cluster is NodeIP2, or the external IP of pod2 is NodeIP2. This is because access to the cluster from outside the cluster is obtained through the node's listening port (nodeport) or the external IP of the load balancer (LB). The IP of virtual machine 1 is VMIP, and its public IP is IP2.

[0021] In access relationship 1 corresponding to pod1 accessing the public network, the message sent by pod1 is from IP1 to IP2. When this message is sent to node A of the Kubernetes cluster, it becomes from NodeIP1 to IP2. The access flow information reported by node A of the Kubernetes cluster is pod1 accessing the public network. However, when the traffic passes through the virtual network, it becomes from NodeIP1 to IP2, and the virtual machine node reports the access relationship from NodeIP1 to IP2. Therefore, the access relationship reported by the virtual machine node is redundant; the final end-to-end access relationship should be from IP1 to IP2.

[0022] Access relationship 2 is similar to access relationship 1. When pod1 accesses virtual machine 1, the message sent by pod1 is ip1 to VMIP. When this message is sent to node A of the Kubernetes cluster, it becomes NodeIP1 to VMIP. The access flow information reported by node A of the Kubernetes cluster is pod1 accessing virtual machine 1. However, when the traffic passes through the virtual network, it becomes NodeIP1 to VMIP, and the virtual machine node reports the access relationship as NodeIP1 to VMIP. This reporting by the virtual machine node causes access interference, resulting in an additional access relationship.

[0023] In access relationship 3, where pod1 accesses pod2, NodeIP1 on node A of the Kubernetes cluster generates an access relationship from IP1 to NodeIP2. Within the virtual network, an access relationship from NodeIP1 to NodeIP2 is also generated. On node B of the Kubernetes cluster, an access relationship from NodeIP1 to pod2 is generated, converting access to NodeIP2 into access to pod2. This results in three access relationships, none of which are end-to-end (pod1 to pod2). In access relationships 1-3, not only do the Kubernetes cluster nodes report access flow information, but the virtual machine nodes also report access flow information through the virtual network. The access flow information reported by the virtual machine nodes interferes with the access flow information of the pods within the Kubernetes cluster nodes.

[0024] Furthermore, since the access flow information reported by the virtual machine node and the access flow information reported by the Kubernetes cluster node are two independent access flow information, when a pod fails, it is necessary to troubleshoot not only based on the access flow information reported by the virtual machine node, but also based on the access flow information reported by the Kubernetes cluster node. Too much access flow information will affect the speed of fault determination.

[0025] To address the problems in the background art, the inventors have proposed a method, apparatus, server, and storage medium for obtaining access relationships, as provided in the embodiments of this application. The method aggregates the first access flow information reported by virtual machine nodes and the access flow information reported by Kubernetes cluster nodes to establish the association between the virtual machine nodes and Kubernetes cluster nodes, and obtains the end-to-end access relationships between pods within the Kubernetes cluster nodes. By establishing the end-to-end access relationships between pods within the Kubernetes cluster nodes, the access flow information reported by virtual machine nodes is aggregated, avoiding interference caused by the access flow information reported by virtual machine nodes. Furthermore, when a pod fails, there is no need to troubleshoot based on the access flow information reported by both virtual machine nodes and Kubernetes cluster nodes, thus improving the efficiency of troubleshooting.

[0026] The following description, in conjunction with the accompanying drawings, details the method, apparatus, server, and storage medium for obtaining access relationships provided in the embodiments of this application.

[0027] Please see Figure 1 , Figure 1 A flowchart illustrating a method for obtaining access relationships provided in an embodiment of this application is shown. This method for obtaining access relationships can be applied to, for example... Figure 6 The access relationship acquisition device 300 shown and the server 100 configured with the access relationship acquisition device 300 ( Figure 7 ).

[0028] The method for obtaining the access relationship may specifically include the following steps:

[0029] Step S110: Obtain the node access flow information reported by the target virtual machine node in the hyperconverged hci cluster as the first access flow information. The first access flow information includes the access flow information generated by the scheduling unit pod in the application software k8s cluster node in the hci cluster through the virtual network. The target virtual machine node is the other virtual machine node in the hci cluster besides the k8s cluster node. The virtual network is the network through which all virtual machine nodes in the hci cluster communicate.

[0030] Among them, a hyper-converged infrastructure (HCI) cluster refers to a virtual computer system under a hyper-converged infrastructure (HCI). An HCI cluster combines multiple servers into a cluster with a unified storage pool across nodes to obtain the performance, capacity scalability, and data availability required for the entire virtualization environment. The computing performance and storage space of the entire HCI cluster can be expanded by increasing the number of nodes in the cluster.

[0031] Application software Kubernetes cluster refers to a Kubernetes cluster, which is an open-source system for automating the deployment, scaling, and management of containerized applications. A Kubernetes cluster node is a worker node within the Kubernetes cluster. Each Kubernetes cluster node contains multiple scheduling units called pods. A pod is the smallest unit of an application within a Kubernetes cluster node; it is a collection of one or more containers, and logically, a pod can be viewed as a virtual machine.

[0032] In this embodiment, an HCI cluster provides virtual machine nodes as the nodes required by the Kubernetes cluster. The Kubernetes cluster is deployed within these virtual machine nodes, serving as the Kubernetes cluster nodes within the Kubernetes cluster. An HCI cluster contains multiple Kubernetes cluster nodes and multiple virtual machines for virtual machine operation. Communication between the Kubernetes cluster nodes and virtual machine nodes within the HCI cluster is via a virtual network. Access between pods on Kubernetes cluster nodes, between pods on Kubernetes cluster nodes and virtual machine nodes, and between pods on Kubernetes cluster nodes and the public network all occur through the virtual network. The virtual machine nodes collect and report the access flow information for the virtual network.

[0033] In some implementations, access flow information to the virtual network is collected by the virtual machine node's exporter and then reported by the virtual machine node.

[0034] Step S120: Obtain the access flow information of the pods within the k8s cluster node reported by the k8s cluster node, as the second access flow information.

[0035] In this embodiment, a Kubernetes cluster node includes one or more pods. When access relationships occur between pods within a Kubernetes cluster node, between pods on different Kubernetes cluster nodes, between pods on a Kubernetes cluster node and virtual machine nodes, and between pods on a Kubernetes cluster node and the public network, the Kubernetes cluster node will collect and report the access flow information of the pods.

[0036] In some implementations, the exporter of the Kubernetes cluster node collects access flow information of all pods in the Kubernetes cluster node and reports the access flow information.

[0037] Step S130: Aggregate the first access flow information and the second access flow information to obtain the aggregation result.

[0038] The aggregation method can be to extract information from the first and second access streams to obtain the aggregation result. Alternatively, it can be to integrate the first and second access streams to obtain the aggregation result. Another method is to aggregate the first and second access streams for information specific to a particular pod. The aggregation method can be determined based on actual needs and is not specifically limited here.

[0039] In this embodiment of the application, the first access stream information and the second access stream information are aggregated according to the aggregation method to obtain the aggregation result.

[0040] Step S140: Based on the aggregation result, determine the end-to-end access relationship of pods within the k8s cluster node. The end-to-end access relationship includes at least one of the following: the access relationship between the pod and the public network, the pod and other pods within the k8s cluster node in the hci cluster, and the pod and other virtual machine nodes in the hci cluster.

[0041] In this embodiment, based on the aggregation result, the source address and destination address of the access relationship in the aggregation result are determined, and then an end-to-end access relationship between pods in the k8s cluster node is established. The end-to-end access relationship can be between a pod and the public network, between a pod and other pods in the hci cluster, between a pod and other virtual machine nodes in the hci cluster, or at least one of the following access relationships: between a pod and the public network, between a pod and other pods in the hci cluster, or between a pod and other virtual machine nodes in the hci cluster. No specific limitation is made to the end-to-end access relationship here.

[0042] For example, a Kubernetes cluster node contains two pods: pod1 and pod2. pod1 is located at podip1, and pod2 at podip2. The public IP address is pupip1, and the virtual machine node's address is vmip1. The aggregation result includes the aggregation results between podip1 and podip2, between podip1 and pupip1, and between podip2 and vmip1. This determines the end-to-end access relationship between pod1 and pod2, the access relationship between pod1 and the public IP address, and the access relationship between pod2 and the virtual machine node.

[0043] The solution provided in this embodiment aggregates the first access flow information reported by the virtual machine node and the access flow information reported by the Kubernetes cluster node to establish the association between the virtual machine node and the Kubernetes cluster node, and obtains the end-to-end access relationship of pods in the Kubernetes cluster node. By establishing the end-to-end access relationship of pods in the Kubernetes cluster node, the access flow information reported by the virtual machine node is aggregated, avoiding interference caused by the access flow information reported by the virtual machine node. Moreover, when a pod fails, there is no need to troubleshoot the access flow information reported by the virtual machine node and the access flow information reported by the Kubernetes cluster node, thus improving the efficiency of troubleshooting.

[0044] The hci cluster includes the first pod within the first Kubernetes cluster node and the second pod within the second Kubernetes cluster node. Please refer to [link / reference]. Figure 3 , Figure 3 A flowchart illustrating a method for obtaining access relationships according to another embodiment of this application is shown.

[0045] Step S210: Obtain the node access flow information reported by the target virtual machine node in the hyperconverged HCI cluster as the first access flow information. The first access flow information includes the access flow information generated by the scheduling unit pod in the application software Kubernetes cluster node in the HCI cluster through the virtual network. The target virtual machine node is the other virtual machine node in the HCI cluster besides the Kubernetes cluster node. The virtual network is the network through which all virtual machine nodes in the HCI cluster communicate.

[0046] Please refer to the detailed description of step S110 in the foregoing embodiments for step S210, which will not be repeated here.

[0047] Step S220: Obtain the access flow information of the pods within the k8s cluster node reported by the k8s cluster node, as the second access flow information.

[0048] In some implementations, before obtaining the access flow information of the pods within the Kubernetes cluster node reported by the Kubernetes cluster node as the second access flow information, the method further includes: obtaining the 5-tuple information corresponding to the first pod from the access flow information of the first pod through the Kubernetes cluster node. If the 5-tuple information indicates that the source address and / or destination address of the first pod is a translated address, a network tag is set for the access flow information of the first pod through the Kubernetes cluster node.

[0049] The 5-tuple information includes the source Internet Protocol Address (IP) address, source port, destination IP address, destination port, and transport layer protocol. The source IP address is the IP address of the pod sending the data packet. The source port is the port number on the pod sending the data packet. The destination IP address is the IP address of the pod receiving the data packet. The destination port is the port number on the pod receiving the data packet. The transport layer protocol is the transport layer protocol used to send the data packet; transport layer protocols include, but are not limited to, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

[0050] Network labels include, but are not limited to, SNAT and DNAT labels. SNAT stands for Source Network Address Translation, used to translate the source address of data packets from the internal network from a private address to a public address, so that the packets can be correctly identified by the external network and routed back to the internal network. DNAT stands for Destination Network Address Translation, used to translate the destination address of data packets from the internal network from a private address to a public address, so that the packets can be correctly routed to their destination on the external network.

[0051] For example, a 5-tuple could be "192.168.1.1 10000TCP 121.14.88.76 80", which means that a device with IP address 192.168.1.1 communicates with a device with IP address 121.14.88.76 and port 80 through port 10000 using the TCP protocol.

[0052] In this application implementation, if the source address and / or destination address of the first pod is the converted address, the network label corresponding to the access flow information of the first pod will be determined by the Kubernetes cluster node where the first pod is located based on the converted address, and the corresponding network label will be set for it.

[0053] In an optional implementation, when the source and destination addresses of the first pod are not the translated addresses, it is not necessary to set a network label for the first pod, or the network label can be set to empty. It should be noted that the first pod is any pod on any Kubernetes cluster node in the HCI cluster. For setting the network labels of other pods on any Kubernetes cluster node in the HCI cluster, please refer to the settings for the network label of the first pod; these will not be repeated here.

[0054] For example, the quintuple information is shown in the table below:

[0055] Source IP Source port destination IP Destination port protocol Forward flow information SIP SPORT DIP DPORT PROTO Reverse flow information DIP DPORT SIP SPORT PROTO

[0056] Table 1

[0057] As shown in Table 1, if the forward flow information and the reverse flow information are the same, it is determined that the source address and destination address in the access flow information have not been translated.

[0058] Source IP Source port destination IP Destination port protocol Forward flow information SIP SPORT DIP DPORT PROTO Reverse flow information DIP DPORT SNATIP SNATPORT PROTO

[0059] Table 2

[0060] As shown in Table 2, it can be seen from the reverse flow information that the destination IP and destination port in the reverse flow information are inconsistent with the source IP and source port in the forward flow information. It can be determined that the source IP in the access flow information has been converted. At this time, the snat label is set for the access flow information.

[0061] Source IP Source port destination IP Destination port protocol Forward flow information SIP SPORT DIP DPORT PROTO Reverse flow information DNATIP DNATPORT SIP SPORT PROTO

[0062] Table 3

[0063] As shown in Table 3, the source IP and source port in the reverse flow information are inconsistent with the destination IP and destination port in the forward flow information. Therefore, it is determined that the destination IP in the access flow information has been converted. At this time, a DNAT label is set for the access flow information.

[0064] Step S230: For the first pod and the second pod, if the first access flow information includes the node access flow information corresponding to the first pod and the node access flow information corresponding to the second pod, then delete the target access flow information from the first access flow information. The target access flow information includes the node access flow information of the first pod and the node access flow information of the second pod.

[0065] Step S240: Obtain the access flow information corresponding to the first pod and the access flow information corresponding to the second pod from the second access flow information and the first access flow information after deleting the first target access flow information, as the aggregation result for the first pod and the second pod.

[0066] Since the access flow information of virtual machine nodes is redundant in the end-to-end access relationship, in this embodiment, it is first determined whether there is access flow information related to the first pod and the second pod in the first access flow information. If so, the access flow information of the first pod and the second pod in the first access flow information is deleted. Then, the first access flow information after deleting the access flow information of the first pod and the second access flow information is aggregated with the second access flow information, which is actually aggregated from the access flow information of the first pod and the second pod in the second access flow information. This yields an aggregation result for the first pod and the second pod, thereby eliminating the impact of the access flow information between the first pod and the second pod in the virtual machine node on the aggregation result, and further reducing the access flow information between the first pod and the second pod in the aggregation result.

[0067] In some implementations, obtaining the access flow information corresponding to the first pod and the access flow information corresponding to the second pod from the second access flow information and the first access flow information after deleting the first target access flow information, as an aggregation result for the first pod and the second pod, includes: obtaining the access flow information of the first pod and the access flow information of the second pod located in the second access flow information from the second access flow information and the first access flow information after deleting the first target access flow information; if the access flow information of the first pod and the access flow information of the second pod meet a preset matching condition, then determining the aggregation result for the first pod and the second pod based on the source address of the first pod in the access flow information of the first pod and the destination address of the second pod in the access flow information of the second pod.

[0068] The preset matching conditions can be whether the source address and / or the destination address accessed by the first pod and the second pod are the same. The preset matching conditions can also be whether the source address and / or the destination address accessed by the first pod and the second pod undergo address translation. The preset matching conditions can be determined according to different needs, and no specific limitations are imposed on the preset matching conditions here.

[0069] In this embodiment, the first access flow information after deleting the first target access flow information does not contain access information related to the first pod and the second pod. Therefore, the aggregation result is only related to the access information related to the first pod and the second pod in the second access flow information. When the access flow information of the first pod and the second pod in the second access flow information meets the preset matching conditions, the aggregation result corresponding to the first pod and the second pod is determined based on the source address of the first pod and the destination address of the second pod.

[0070] For example, the source address of the first pod is pod1, and the destination address of the second pod is pod2. When the access flow information of the first pod and the second pod meets the preset matching conditions, the aggregation result is pod1-pod2.

[0071] In one feasible implementation, the second access flow information includes a network tag, which is used to characterize whether the pod performs address translation during access. If the access flow information of the first pod and the access flow information of the second pod meet a preset matching condition, then based on the source address of the first pod in the access flow information of the first pod and the destination address of the second pod in the access flow information of the second pod, an aggregation result for the first pod and the second pod is determined, including: obtaining the network tag corresponding to the first pod in the second flow information as a first network tag; obtaining the network tag corresponding to the second pod in the second flow information as a second network tag; if the first network tag... Both the first and second network tags indicate that the pod underwent address translation during access. Based on the first network tag, the source address of the access flow information of the first pod in the second access flow information is translated to obtain the first sub-access flow information. Based on the second network tag, the destination address of the access flow information of the second pod in the second access flow information is translated to obtain the second sub-access flow information. If the first sub-access flow information and the second sub-access flow information satisfy the preset matching condition, the aggregation result for the first pod and the second pod is determined according to the source address of the first pod in the first sub-access flow information and the destination address of the second pod in the second sub-access flow information.

[0072] In this embodiment, the first sub-access flow information corresponding to the first pod and the second sub-access flow information corresponding to the second pod are determined based on the network tags corresponding to the first pod and the second pod. Then, the first sub-access flow information and the second sub-access flow information are aggregated to obtain the aggregation result for the first pod and the second pod.

[0073] For example, if the first network label is an SNAT label and the second network label is a DNAT label, then it is determined that the first sub-access flow information and the second sub-access flow information meet the preset matching conditions. The source IP of the first sub-access flow information is used as the source address of the aggregation result, and the source port and transport protocol of the first sub-access flow information are used as the source port and protocol of the aggregation result. The destination address of the second sub-access flow information is used as the destination address of the aggregation result, and the destination port number of the second sub-access flow information is used as the destination port number of the aggregation result. For example, the first sub-access flow information is flow1; the source address and source port number of the first sub-access flow information are host1ip:host1port; the destination address, destination port number, and transport protocol of the first sub-access flow information are host2ip:host2port,proto1, and the first network label is an SNAT label. The second sub-access flow information is flow2; the source address and source port number of the second sub-access flow information are host1ip:host1port, the destination address, destination port number, and transport protocol of the second sub-access flow information are host2ip:host2port,proto2, the second network label is the dnat label, and the aggregation result is host1ip:host1port-host2ip:host2port,proto1, that is, pod1:port1-pod2:port2,proto1.

[0074] In other implementations, the target access flow information also includes access flow information where the source IP is the IP of the pod on the Kubernetes cluster node, access flow information where the destination IP is the IP of the pod on the Kubernetes cluster node, and access flow information where the destination IP, destination port, and protocol are listed in the service list of the Kubernetes cluster node. No specific limitations are imposed on the target access flow information here.

[0075] Step S250: Based on the aggregation result, determine the end-to-end access relationship of pods within the k8s cluster node. The end-to-end access relationship includes at least one of the following: the access relationship between the pod and the public network, the access relationship between the pod and other pods within the k8s cluster node in the hci cluster, and the access relationship between the pod and other virtual machine nodes in the hci cluster.

[0076] Please refer to the detailed description of step S140 in the foregoing embodiments for step S250, which will not be repeated here.

[0077] The solution provided in this embodiment deletes the relevant access flow information of pods in the first access flow information, and then aggregates the deleted first access flow information with the second access flow information. In fact, it only uses the second access flow information for aggregation to obtain the end-to-end access relationship of pods, reducing the access interference caused by the first access flow information collected by the virtual machine node.

[0078] Please see Figure 4 , Figure 4 This diagram illustrates a flowchart of an access relationship acquisition method provided in another embodiment of this application. Step S310: Obtain node access flow information reported by the target virtual machine node in the hyperconverged infrastructure (HCI) cluster as first access flow information. The first access flow information includes access flow information generated by the scheduling unit pod within the application software Kubernetes cluster node in the HCI cluster through the virtual network. The target virtual machine node is any virtual machine node in the HCI cluster other than the Kubernetes cluster node, and the virtual network is the network through which all virtual machine nodes in the HCI cluster communicate.

[0079] Please refer to the detailed description of step S110 in the foregoing embodiments for step S310, which will not be repeated here.

[0080] Step S320: Collect the original access flow information of the pods in the k8s cluster node and the access parameters corresponding to the original access flow information through the k8s cluster node. The access parameters include the source address and the destination address of each pod.

[0081] The original access flow information includes, but is not limited to, access flow information between all pods in the Kubernetes cluster node, access flow information between pods in the Kubernetes cluster node and pods in other Kubernetes cluster nodes, access flow information between pods in the Kubernetes cluster node and the target virtual machine node, and access flow information between pods in the Kubernetes cluster node and the public network.

[0082] Furthermore, the access parameters include, but are not limited to, the five-tuple information for each pod, Kubernetes service parameters, and podIPs. The five-tuple information for each pod includes the pod's source address and the destination address accessed by the pod. The podIP is obtained through Classless Inter-Domain Routing (CIDR). CIDR is a technology used for allocating IP addresses and performing routing. It eliminates the traditional concepts of Class A, B, and C addresses and subnet masks. Kubernetes service parameters include the service IP, service protocol, and a list of ports for the pods involved in the service, making it easier to aggregate the CIDR-translated IP addresses.

[0083] Step S330: The Kubernetes cluster node determines the second access flow information from the original access flow information based on the access parameters, and reports the second access flow information.

[0084] In this embodiment of the application, the original access flow information is filtered by access parameters to determine the second access flow information that the k8s cluster node needs to report.

[0085] In some implementations, the access parameters corresponding to the original access flow information can be obtained through the connection tracking (Conntrack) of the Kubernetes cluster node. Conntrack can identify information such as the source IP address, destination IP address, source port, and destination port of the connection and store this information in a connection tracking table.

[0086] Furthermore, the filtering methods can be based on the source address of the pod to filter the original access flow information, or based on the destination address of the pod access, or by combining the source address and the destination address, or by combining the source address, the destination address, Kubernetes service parameters, and the nodeip table to filter the original access flow information to obtain the second access flow information.

[0087] For example, let's take the method of determining the second access flow information as a comprehensive filtering of the original access flow information based on the source address, destination address, Kubernetes service parameters, and the nodeip table. First, obtain the source address, destination address, Kubernetes service parameters, and nodeip table corresponding to the pod. Then, determine whether the pod's source address and the destination address are the same. If they are the same, it's possible that a service or application inside the pod is attempting to communicate with itself. It's also possible that the pod is listening on a specific port on a local interface. Alternatively, there might be an error in the network configuration or routing rules, leading to the source address and destination address being the same. In this case, filter out this type of access flow information. Then, further filter the filtered original access flow information using the Kubernetes service parameters and the nodeip table. If the destination IP in the access flow information is not in the podip list and the service corresponding to the destination IP, protocol, and output port is not in the Kubernetes service parameter list, or if the destination IP is in the cluster nodeip list but is not the IP of this node, then report the source IP, source port, protocol number, destination IP, destination port, cluster identifier ID, and Kubernetes cluster node tag of the access flow information. If the source IP in the access flow information is not in the podip list, and the source IP is not the IP of this node, then the source IP, source port, protocol number in the source direction, and the source IP, source port, cluster ID, and Kubernetes cluster flag in the reverse direction of the access flow information are reported. Based on the access flow information determined after filtering, the second access flow information is obtained.

[0088] Step S340: Obtain the access flow information of the pods within the k8s cluster node reported by the k8s cluster node, as the second access flow information.

[0089] Please refer to the detailed description of step S120 in the foregoing embodiments for step S340, which will not be repeated here.

[0090] Step S350: Obtain the access parameters corresponding to the second access flow information.

[0091] Step S360: Obtain access data stream information from the second access stream information where the access parameters match the preset parameter conditions.

[0092] Step S370: Aggregate the first access flow information and the access data flow information to obtain the aggregation result.

[0093] Among them, the preset parameter conditions can be whether the source address and / or destination address are converted, whether the address corresponding to the pod in the second access flow information is in the nodeip table, and whether the service parameters of each pod in the second access flow information are in the k8s service parameter table. The preset parameter conditions can be limited according to actual needs, and no limit is imposed on the preset parameter conditions here.

[0094] For example, taking the preset parameters as network label, nodeip, and Kubernetes service parameters, if the network label in the access flow information is empty (i.e., neither an SNAT nor a DNAT label), it is directly stored in the database. The remaining access flow information is then further analyzed. If the access flow information contains an SNAT tag, it checks whether the pod's destination IP is in the nodeip list or whether the destination IP, protocol, and destination port are in the service list. If none of these are present, the five-tuple information from the access flow information is directly extracted and stored in the database. If the access flow information contains a DNAT tag, it checks whether the pod's source address is in the nodeip list. If not, it indicates that the pod is accessing a Kubernetes cluster node from a virtual machine or from the public network; therefore, aggregation is not required, and the five-tuple information from the flow information is directly extracted and stored in the database. Access flow information not yet stored in the database is treated as access data flow information. Finally, the first access flow information and the access data flow information are aggregated to obtain the aggregation result.

[0095] Step S380: Based on the aggregation result, determine the end-to-end access relationship of pods within the k8s cluster node. The end-to-end access relationship includes at least one of the following: the access relationship between the pod and the public network, the pod and other pods within the k8s cluster node in the hci cluster, and the pod and other virtual machine nodes in the hci cluster.

[0096] Please refer to the detailed description of step S140 in the foregoing embodiments for step S380, which will not be repeated here.

[0097] In the specific implementation process, after the Kubernetes cluster nodes filter the collected access flow information to obtain the second access flow information, the Kubernetes cluster nodes report the second access flow information to the analyzer. The analyzer also obtains the first access flow information reported by the virtual machine nodes. The analyzer aggregates the first and second access flow information to obtain the end-to-end access relationship between pods in the Kubernetes cluster nodes. In this embodiment, a database is also used to store the aggregated access relationships and the access relationships that do not need to be aggregated. The access relationships that do not need to be aggregated include access flow information filtered out by the Kubernetes cluster nodes and access flow information in which the source address and destination address are consistent.

[0098] In this embodiment, the access flow information collected by the Kubernetes cluster nodes is filtered according to access parameters to obtain second access flow information, which is then reported. After reporting, the second access flow information is further filtered according to preset parameter conditions, thereby making the access data flow information aggregated with the first access flow information more accurate. This makes the access relationship obtained after aggregation more accurate, reducing the access interference of the access flow information collected by the virtual machine nodes on the end-to-end access relationship of pods in the Kubernetes cluster nodes, while also improving the establishment of access relationships.

[0099] Based on the above embodiments, please refer to Figure 5 , Figure 5 A schematic diagram illustrating an application scenario provided by an embodiment of this application is shown. Figure 5 In this example, user cluster 01 and user cluster 02 are Kubernetes cluster nodes. In user cluster 01, the pods represent product services, with each pod corresponding to a different product service. In user cluster 02, the pods represent user data services, with each pod corresponding to different user data processing tasks. The end-to-end access relationships between user cluster 01 and user cluster 02, and between the user clusters and the public network, are established according to the access relationship acquisition method provided in the aforementioned embodiment. Figure 1 As shown, an end-to-end access relationship is established between the product list service and the user authentication service in the product service. When a failure occurs in the product list service and / or the user authentication service, this access relationship will not be established or displayed. In this case, the fault can be located based on the unestablished access relationship, thus improving the speed of fault location. Figure 1 In addition, the access relationship between user cluster 01 and the public network and the access relationship between user cluster 02 and the public network were established, realizing the interaction between user cluster 01 and user cluster 02 and the public network.

[0100] Please see Figure 6This diagram illustrates a structural block diagram of an access relationship acquisition device 300 provided in an embodiment of this application. The access relationship acquisition device 300 is applied to a server 100 and includes: a first access flow information acquisition module 310, used to acquire node access flow information reported by a target virtual machine node in a hyperconverged infrastructure (HCI) cluster. This first access flow information includes access flow information generated by a scheduling unit pod within an application software Kubernetes cluster node in the HCI cluster through a virtual network. The target virtual machine node is any virtual machine node in the HCI cluster other than the Kubernetes cluster node, and the virtual network is the network through which all virtual machine nodes in the HCI cluster communicate; a second access flow information acquisition module... 320 is used to obtain access flow information of pods within the Kubernetes cluster node reported by the Kubernetes cluster node, as the second access flow information; the aggregation result acquisition module 330 is used to aggregate the first access flow information and the second access flow information to obtain an aggregation result; the access relationship determination module 340 is used to determine the end-to-end access relationship of pods within the Kubernetes cluster node according to the aggregation result, wherein the end-to-end access relationship includes at least one of the following: the access relationship between the pod and the public network, the access relationship between the pod and other pods within the Kubernetes cluster node in the HCI cluster, and the access relationship between the pod and other virtual machine nodes in the HCI cluster.

[0101] In some embodiments of this application, the HCI cluster includes a first pod within a first Kubernetes cluster node and a second pod within a second Kubernetes cluster node. The aggregation result acquisition module 330 includes: a deletion unit, configured to delete target access flow information from the first access flow information if the first access flow information includes node access flow information corresponding to the first pod and node access flow information corresponding to the second pod, wherein the target access flow information includes node access flow information of the first pod and node access flow information of the second pod; and an aggregation unit, configured to obtain the access flow information corresponding to the first pod and the access flow information corresponding to the second pod from the second access flow information and the first access flow information after deleting the first target access flow information, as an aggregation result for the first pod and the second pod.

[0102] In some embodiments of this application, the aggregation unit includes: an access flow information acquisition subunit, configured to acquire access flow information of a first pod and access flow information of a second pod located in the second access flow information from the second access flow information and the first access flow information after deleting the first target access flow information; and an aggregation result determination subunit, configured to determine an aggregation result for the first pod and the second pod if the access flow information of the first pod and the access flow information of the second pod meet a preset matching condition, based on the source address of the first pod in the access flow information of the first pod and the destination address of the second pod in the access flow information of the second pod.

[0103] In some embodiments of this application, the second access flow information includes a network tag, which is used to characterize whether the pod performs address translation during access. The aggregation result determination subunit includes: a first network tag acquisition component, used to acquire the network tag corresponding to the first pod in the second flow information as a first network tag; a second network tag acquisition component, used to acquire the network tag corresponding to the second pod in the second flow information as a second network tag; a first sub-access flow information acquisition component, used to perform address translation on the source address of the access flow information of the first pod in the second access flow information based on the first network tag if both the first network tag and the second network tag characterize that the pod performed address translation during access, to obtain first sub-access flow information; a second sub-access flow information acquisition component, used to perform address translation on the destination address of the access flow information of the second pod in the second access flow information based on the second network tag, to obtain second sub-access flow information; and an aggregation result determination component, used to determine the aggregation result for the first pod and the second pod if the first sub-access flow information and the second sub-access flow information satisfy the preset matching condition, based on the source address of the first pod in the first sub-access flow information and the destination address of the second pod in the second sub-access flow information.

[0104] In some embodiments of this application, the access relationship acquisition device 300 further includes: a 5-tuple information acquisition module, used to acquire the 5-tuple information corresponding to the first pod from the access flow information of the first pod through the k8s cluster node; and a network label setting module, used to set network labels for the access flow information of the first pod through the k8s cluster node if the 5-tuple information indicates that the source address and / or destination address of the first pod is a converted address.

[0105] In some embodiments of this application, the access relationship acquisition device 300 further includes: an access parameter acquisition module, used to acquire access parameters corresponding to the second access flow information; and an access data flow information acquisition module, used to acquire access data flow information from the second access flow information whose access parameters match preset parameter conditions. The aggregation result acquisition module 330 further includes: an aggregation unit, used to aggregate the first access flow information and the access data flow information to obtain the aggregation result.

[0106] In some embodiments of this application, the access relationship acquisition device 300 further includes: a collection module, used to collect the original access flow information of pods in the k8s cluster node and the access parameters corresponding to the original access flow information through the k8s cluster node, wherein the access parameters include the source address and the destination address of each pod; and a reporting module, used to determine the second access flow information from the original access flow information according to the access parameters through the k8s cluster node, and report the second access flow information.

[0107] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0108] In the several embodiments provided in this application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0109] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0110] This application provides a structural block diagram of a server according to an embodiment. Please refer to... Figure 7 This diagram illustrates a structural block diagram of a server provided in an embodiment of this application. The server 100 can be a computer, server, or other server capable of running applications. The server 100 in this application may include one or more of the following components: a processor 101, a memory 102, and one or more applications, wherein the one or more applications can be stored in the memory 102 and configured to be executed by one or more processors 101, and the one or more applications are configured to perform the methods described in the foregoing method embodiments.

[0111] Processor 101 may include one or more processing cores. Processor 101 connects to various parts within server 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 102, and by calling data stored in memory 102. Optionally, processor 101 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 101 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 101 and may be implemented separately using a communication chip.

[0112] The memory 102 may include random access memory (RAM) or read-only memory (ROM). The memory 102 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 102 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the server 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0113] Please refer to Figure 8 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable storage medium 200 stores program code that can be invoked by a processor to execute the methods described in the above method embodiments.

[0114] The computer-readable storage medium 200 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 200 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 200 has storage space for program code 210 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 210 may be compressed, for example, in a suitable form.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An access relationship acquisition method characterized by comprising: The method comprises: obtaining node access flow information reported by a target virtual machine node in a hyper-converged HCI cluster as first access flow information, the first access flow information comprising access flow information generated by a virtual network when a scheduling unit pod in an application software k8s cluster node in the HCI cluster accesses, the target virtual machine node being a virtual machine node other than the k8s cluster node in the HCI cluster, and the virtual network being a network used for communication among all virtual machine nodes in the HCI cluster; obtaining access flow information of pods in the k8s cluster node reported by the k8s cluster node as second access flow information; aggregating the first access flow information and the second access flow information to obtain an aggregation result; determining an end-to-end access relationship of the pods in the k8s cluster node according to the aggregation result, the end-to-end access relationship comprising at least one of an access relationship between the pods and a public network, an access relationship between the pods and other pods in k8s cluster nodes in the HCI cluster, and an access relationship between the pods and other virtual machine nodes in the HCI cluster.

2. The method of claim 1, wherein, The HCI cluster comprises a first pod in a first k8s cluster node and a second pod in a second k8s cluster node, and the aggregation of the first access flow information and the second access flow information to obtain an aggregation result comprises: for the first pod and the second pod, if the first access flow information comprises node access flow information corresponding to the first pod and node access flow information corresponding to the second pod, deleting target access flow information from the first access flow information, the target access flow information comprising the node access flow information of the first pod and the node access flow information of the second pod; from the second access flow information and the first access flow information after the deletion of the target access flow information, obtaining access flow information corresponding to the first pod and access flow information corresponding to the second pod as an aggregation result for the first pod and the second pod.

3. The method of claim 2, wherein, The obtaining of the access flow information corresponding to the first pod and the access flow information corresponding to the second pod from the second access flow information and the first access flow information after the deletion of the target access flow information as the aggregation result for the first pod and the second pod comprises: from the second access flow information and the first access flow information after the deletion of the target access flow information, obtaining the access flow information of the first pod and the access flow information of the second pod located in the second access flow information; if the access flow information of the first pod and the access flow information of the second pod meet a preset matching condition, determining the aggregation result for the first pod and the second pod according to a source address of the first pod in the access flow information of the first pod and a destination address of the second pod in the access flow information of the second pod.

4. The method of claim 3, wherein, The second access flow information includes a network label, and the network label is used to represent whether address conversion is performed by the pod during access. If the first pod access flow information and the second pod access flow information meet a preset matching condition, an aggregation result for the first pod and the second pod is determined according to a source address of the first pod in the first pod access flow information and a destination address of the second pod in the second pod access flow information, and the aggregation result includes: Obtaining a network label corresponding to the first pod in the second access flow information as a first network label; Obtaining a network label corresponding to the second pod in the second access flow information as a second network label; If the first network label and the second network label both represent that address conversion is performed by the pod during access, address conversion is performed on a source address of the first pod access flow information in the second access flow information based on the first network label, and first sub access flow information is obtained; Address conversion is performed on a destination address of the second pod access flow information in the second access flow information based on the second network label, and second sub access flow information is obtained; If the first sub access flow information and the second sub access flow information meet the preset matching condition, an aggregation result for the first pod and the second pod is determined according to a source address of the first pod in the first sub access flow information and a destination address of the second pod in the second sub access flow information.

5. The method of claim 4, wherein, Before the step of obtaining the pod access flow information in the k8s cluster node reported by the k8s cluster node as second access flow information, the method further includes: Obtaining, by the k8s cluster node, five-tuple information corresponding to the first pod from the first pod access flow information; If the five-tuple information represents that a source address and / or a destination address of the first pod are converted addresses, a network label is set for the first pod access flow information by the k8s cluster node.

6. The method of claim 1, wherein, After the step of obtaining the pod access flow information in the k8s cluster node reported by the k8s cluster node as second access flow information, the method further includes: Obtaining access parameters corresponding to the second access flow information; Obtaining, from the second access flow information, access data flow information in which an access parameter matches a preset parameter condition; The step of aggregating the first access flow information and the second access flow information to obtain an aggregation result includes: The first access flow information and the access data flow information are aggregated to obtain the aggregation result.

7. The method according to any one of claims 1 to 6, characterized in that, Before the step of obtaining the pod access flow information in the k8s cluster node reported by the k8s cluster node as second access flow information, the method further includes: The k8s cluster node collects original access flow information of pods in the k8s cluster node and access parameters corresponding to the original access flow information, the access parameters including source addresses corresponding to each pod and destination addresses accessed by the pod; The k8s cluster node determines the second access flow information from the original access flow information according to the access parameters and reports the second access flow information.

8. An access relationship acquisition apparatus characterized by comprising: The apparatus includes: A first access flow information acquisition module is configured to acquire node access flow information reported by a target virtual machine node in an all-in-one HCI (Hyper-Converged Infrastructure) cluster, as first access flow information, the first access flow information including access flow information generated by a scheduling unit pod in a k8s (Kubernetes) cluster node in application software in the HCI cluster when the scheduling unit pod accesses through a virtual network, the target virtual machine node being a virtual machine node other than the k8s cluster node in the HCI cluster, and the virtual network being a network used by all virtual machine nodes in the HCI cluster to communicate; A second access flow information acquisition module is configured to acquire access flow information of pods in the k8s cluster node reported by the k8s cluster node, as second access flow information; An aggregation result acquisition module is configured to aggregate the first access flow information and the second access flow information to obtain an aggregation result; An access relationship determination module is configured to determine an end-to-end access relationship of the pods in the k8s cluster node according to the aggregation result, the end-to-end access relationship including at least one of an access relationship between the pods and a public network, an access relationship between the pods and pods in other k8s cluster nodes in the HCI cluster, and an access relationship between the pods and other virtual machine nodes in the HCI cluster.

9. A server, characterized by The server includes: One or more processors; Memory; One or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method of any one of claims 1 to 7.

10. A computer readable storage medium, characterized in that, The computer-readable storage medium stores program code, and the program code can be invoked and executed by a processor to execute the method of any one of claims 1 to 7.

Images