Joint debugging test methods, devices, equipment and media based on Kubernetes

Abstract

The disclosed embodiments relate to a joint debugging and testing method, apparatus, device and medium based on Kubernetes, wherein the method comprises: receiving a joint debugging and testing request sent by a local development device; sending the joint debugging and testing request to a first network resource object in the Kubernetes cluster based on a pre-created network tunnel between the local development device and the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card; and performing a joint debugging and testing of the local development device and the first network resource object based on the network tunnel. By adopting the above technical solution, the network tunnel created based on the TUN / TAP virtual network card can connect the network of the local development environment and the Kubernetes cluster test environment, realize the joint debugging and testing of the development and test environments, avoid the high manpower and cost consumption in related technologies, and improve the efficiency of the joint debugging and testing.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular to a joint debugging test method, device, equipment and medium based on Kubernetes. Background Art

[0002] Kubernetes is a containerized application used to manage multiple hosts in a cloud platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient.

[0003] In the related technology, the local development environment of the cloud platform based on Kubernetes is applied to the joint debugging test of the container group (Pod) in the test environment Kubernetes. There are usually two ways to implement it. One is to expose the service port running in the cloud platform as NodePort for external access. Developers need to debug the running service through NodePort; the other is to implement the joint debugging test of the local environment and the test environment based on self-developed tools. However, both of the above methods consume a lot of manpower and cost, and the test efficiency is low, which cannot meet the needs. Summary of the invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, the present disclosure provides a network access method, device, equipment and medium based on Kubernetes.

[0005] The present disclosure provides a joint debugging test method based on Kubernetes, the method comprising:

[0006] Receive joint debugging test requests sent by local development devices;

[0007] Based on a pre-created network tunnel between the local development device and the Kubernetes cluster, sending the joint debugging test request to a first network resource object in the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card;

[0008] A joint debugging test between the local development device and the first network resource object is performed based on the network tunnel.

[0009] The present disclosure also provides a joint debugging test device based on Kubernetes, the device comprising:

[0010] The request receiving module is used to receive the joint debugging test request sent by the local development device;

[0011] A request sending module, used to send the joint debugging test request to the first network resource object in the Kubernetes cluster based on a pre-created network tunnel between the local development device and the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card;

[0012] A test execution module is used to perform a joint debugging test between the local development device and the first network resource object based on the network tunnel.

[0013] An embodiment of the present disclosure also provides an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; the processor is used to read the executable instructions from the memory and execute the instructions to implement the Kubernetes-based joint debugging and testing method provided in the embodiment of the present disclosure.

[0014] The embodiment of the present disclosure also provides a computer-readable storage medium, which stores a computer program, and the computer program is used to execute the Kubernetes-based joint debugging test method provided in the embodiment of the present disclosure.

[0015] The technical solution provided by the embodiments of the present disclosure has the following advantages over the prior art: the joint debugging and testing solution based on Kubernetes provided by the embodiments of the present disclosure receives the joint debugging and testing request sent by the local development device; based on the pre-created network tunnel between the local development device and the Kubernetes cluster, the joint debugging and testing request is sent to the first network resource object in the Kubernetes cluster, wherein the network tunnel is created based on the TUN / TAP virtual network card; the joint debugging and testing of the local development device and the first network resource object is performed based on the network tunnel. With the above technical solution, the network tunnel between the local development device and the Kubernetes cluster created based on the TUN / TAP virtual network card can open up the network of the local development environment and the Kubernetes cluster test environment, and can realize the joint debugging and testing of the development and test environments, avoiding the high manpower and cost consumption in related technologies, and improving the efficiency of the joint debugging and testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 A flowchart of a joint debugging test method based on Kubernetes provided in an embodiment of the present disclosure;

[0019] Figure 2 A flowchart of another Kubernetes-based joint debugging test method provided in an embodiment of the present disclosure;

[0020] Figure 3 A schematic diagram of a joint debugging and testing system provided in an embodiment of the present disclosure;

[0021] Figure 4 A schematic diagram of a joint debugging test provided by an embodiment of the present disclosure;

[0022] Figure 5 A schematic diagram of the structure of a joint debugging and testing device based on Kubernetes provided in an embodiment of the present disclosure;

[0023] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0024] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0025] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0026] At present, most applications are developed in a distributed manner based on a microservice architecture, and the development model is a waterfall development process, that is, continuous updates and iterations, and the bugs or temporary emergency needs of the product or business itself are constantly corrected during the iteration process. In this context, higher requirements are placed on developers, development and testing environments, and development workflows.

[0027] In the related technology, the local development environment where the Kubernetes-based cloud platform is located is applied to the joint debugging test of the container group (Pod) in the test environment Kubernetes is usually implemented in two ways. One is to expose the service port running in the cloud platform as NodePort for external access. Developers need to debug the running service through NodePort; the other is to implement the joint debugging test of the local environment and the test environment based on self-developed tools.

[0028] However, in the first method mentioned above, when the number of application services or services that need joint debugging and testing increases, it will cost a lot of manpower to expose the NodePort for each service separately, and subsequent maintenance is also relatively difficult; in the second method, developers need to be familiar with the use of self-developed tools, which has a certain learning cost. Before each debugging, they need to open the corresponding port through the command line tool, which affects the development and debugging efficiency to a certain extent. Both of the above methods consume a lot of manpower and cost, and the testing efficiency is low and cannot meet the needs. In order to solve the above problems, the embodiments of the present disclosure provide a joint debugging and testing method based on Kubernetes, which is introduced in conjunction with specific embodiments below.

[0029] Figure 1 The present invention provides a flowchart of a joint debugging and testing method based on Kubernetes, which can be performed by a joint debugging and testing device based on Kubernetes, wherein the device can be implemented by software and / or hardware and can generally be integrated in an electronic device. Figure 1 As shown, the method includes:

[0030] Step 101: Receive a joint debugging test request sent by a local development device.

[0031] The local development device can be an electronic device used by developers to develop products or services, such as a developer's laptop. Kubernetes, or K8s for short, is an application used to manage containerization on multiple hosts in a cloud platform. It is an open source container orchestration engine used to automatically deploy, scale, and manage containerized applications. Joint debugging can be understood as a joint test between a local development device and a Kubernetes cluster test environment.

[0032] Specifically, the local development device can send a joint debugging test request based on the trigger operation of the developer, and the joint debugging test device based on Kubernetes (referred to as the joint debugging test device) can receive the joint debugging test request.

[0033] Step 102: Based on the pre-created network tunnel between the local development device and the Kubernetes cluster, send the joint debugging test request to the first network resource object in the Kubernetes cluster.

[0034] The network tunnel is created based on the TUN / TAP virtual network card. The TUN / TAP virtual network card can be a network device simulated by software, which can provide the same functions as the network device. The TAP network card simulates the Ethernet device, that is, operates the second layer data packets, such as Ethernet data frames, etc., and the TUN network card simulates the network layer device, that is, operates the third layer data packets, such as IP data packets, etc.

[0035] In the disclosed embodiment, before step 102 or step 101, the joint debugging test method based on Kubernetes may further include: creating a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card.

[0036] Optionally, creating a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card may include: deploying a virtual private network in the target host of the Kubernetes cluster and the local development device; using the virtual private network, creating a TAP network card in the target host of the Kubernetes cluster, and creating a TUN network card in the container group of the Kubernetes cluster and the local development device; determining the network architecture of the combination of the TAP network card and the TUN network card as a network tunnel.

[0037] Among them, a virtual private network (VPN) can establish a private network on a public network for encrypted communication, and remote access can be achieved through the virtual private network. The joint debugging test device can deploy a virtual private network to the target host of the Kubernetes cluster and the local development device, and then use the virtual private network to create a TAP network card in the target host of the Kubernetes cluster, and create a TUN network card in the container group of the Kubernetes cluster and the local development device, and determine the network architecture of the combination of the TAP network card and the TUN network card as a network tunnel.

[0038] Optionally, deploy a virtual private network in the target host of the Kubernetes cluster and the local development device, including: deploying a virtual private network server on the target host of the Kubernetes cluster, and deploying a virtual private network client in a global project of any system tenant of the Kubernetes cluster and the local development device.

[0039] The target host of the Kubernetes cluster can be a host in the same network segment as the Kubernetes cluster, a host in the Kubernetes cluster, or a host on the public network. When the client of the VPN needs to connect to the server of the VPN through the Internet, the target host of the Kubernetes cluster is a host on the public network, that is, a host with a public IP address; when the client of the VPN does not need to connect to the server of the VPN through the Internet, the target host of the Kubernetes cluster can be a host in the same network segment as the Kubernetes cluster or any host in the Kubernetes cluster.

[0040] When the joint debugging test device deploys the client of the virtual private network in the global project (Name Space) of any system tenant in the Kubernetes cluster, it can be deployed through the Kubernetes native resource object deployment (deployment). It is understandable that in order to ensure that the services in the global project can be accessed by other projects in the cluster, no network isolation strategy is implemented for system tenants or global projects; and the same Kubernetes cluster only needs to deploy one virtual private network client, and the virtual private network client will be able to realize the communication of all applications in all cluster computing nodes, which can be realized through internal routing rules.

[0041] In the embodiment of the present disclosure, after the joint debugging test device receives the joint debugging test request sent by the local development device, it can parse the information of the first network resource object in the joint debugging test request, and based on the pre-created network tunnel between the local development device and the Kubernetes cluster and the information of the above-mentioned first network resource object, send the joint debugging test request to the first network resource object in the Kubernetes cluster.

[0042] The network resource object may be a resource object that can be accessed and included in the Kubernetes cluster. In the embodiment of the present disclosure, the network resource object may include a container group (Pod) and a Service, etc. Pod may be the smallest unit created or deployed by Kubernetes. A Pod encapsulates one or more containers (container), storage resources (volume), an independent network IP, and policy options for managing and controlling the operation mode of the container; Service may be a resource object of Kubernetes and provide Kubernetes with external network and pod network access. Service may be understood as an abstraction that defines a logical set of pods and a policy for accessing them. Service may provide a bridge to provide a fixed access IP address for external access, which is used to redirect to the corresponding backend pod network when accessed. KubernetesService types may include ClusterIP, NodePort, LoadBalancer, and ExternalName, where ClusterIP may be redirected to its local port by kube-proxy using Iptables rules, and then balanced to the IP address of the backend Pod, and NodePort may be the port of the host machine where the container is located.

[0043] Step 103: Perform a joint debugging test between the local development device and the first network resource object based on the network tunnel.

[0044] The joint debugging test device in the embodiment of the present disclosure can be set in the target host of the server side where the virtual private network is deployed, or the target host can be regarded as the joint testing device. The joint debugging test can be understood as a call relationship or dependency relationship between two services or two objects, and when testing any one of them, communication between the two services or two objects is required to implement the test.

[0045] In the disclosed embodiment, after the joint debugging test apparatus sends the joint debugging test request to the first network resource object, data can be forwarded between the local development device and the first network resource object based on the network tunnel, thereby realizing the required joint debugging test.

[0046] For example, suppose a microservice application A is developed in a local development device. Microservice application A depends on a service B in the Kubernetes cluster when it starts, that is, it needs to communicate with service B when it starts. Therefore, the functional test of microservice application A belongs to joint debugging test. The joint debugging test device establishes a network connection between microservice application A and service B through the above-mentioned network tunnel to realize data forwarding, thereby realizing the functional test of microservice application A.

[0047] The joint debugging and testing solution based on Kubernetes provided by the disclosed embodiment receives a joint debugging and testing request sent by a local development device; based on a pre-created network tunnel between the local development device and the Kubernetes cluster, sends the joint debugging and testing request to the first network resource object in the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card; and performs a joint debugging and testing of the local development device and the first network resource object based on the network tunnel. By adopting the above technical solution, the network tunnel between the local development device and the Kubernetes cluster created based on the TUN / TAP virtual network card can connect the local and Kubernetes cluster test environment networks, realize the joint debugging and testing of the development and test environments, avoid the high manpower and cost consumed in related technologies, and improve the efficiency of the joint debugging and testing.

[0048] In some embodiments, a preset routing rule is configured in the local development device, and the preset routing rule is used to send the communication information of all hosts in the Kubernetes cluster to the TUN network card in the Kubernetes cluster.

[0049] Among them, the preset routing rules can be pre-set data forwarding rules. The preset routing rules can be configured in the local development device, and the communication information of each network resource object in all hosts in the Kubernetes cluster can be sent to the TUN network card in the Kubernetes cluster for storage, so that the local development device can access the network resource objects on other hosts except the host of the TUN network card by adding routing rules on the basis of the network tunnel.

[0050] Exemplarily, the preset routing rule may be "ip route add 10.0.11.4 dev edge0; ip routeadd 10.0.11.0 / 24 via 10.0.11.4dev edge0". The purpose of the above two preset routing rules is to send the addresses of the 10.0.11.0 / 24 network segment through the edge0 network card (10.0.11.4 as the gateway).

[0051] In the above solution, by setting routing rules in the local development device, access to all network resource objects in the Kubernetes cluster can be achieved, and then the joint debugging test of the local development device and all network resource objects can be realized.

[0052] In the disclosed embodiment, a communication list is stored in the TAP network card, which includes the communication information of the local development device where the TUN network card is located and the communication information of the network resource object that creates the TUN network card in the Kubernetes cluster, and the communication information includes port information, IP address and MAC address.

[0053] The TAP network card of the target host in the Kubernetes cluster can maintain the communication information of all virtual private network clients through a communication list through the virtual private network server. Since a TUN network card is created in the local development device and a TUN network card is also created in the network resource object of the global project of a system tenant in the Kubernetes cluster, the communication between different TUN network cards can be established based on the communication information in the communication list.

[0054] If one of the NAT types of the two connected TUN network cards is Cone NAT, the two TUN network cards can communicate directly; if the NAT types of the two connected TUN network cards are both Symmetric NAT, the two TUN network cards cannot communicate directly and need to be forwarded through the TAP network card (that is, the server of the virtual private network).

[0055] In some embodiments, sending the joint debugging test request to the first network resource object in the Kubernetes cluster may include: when the network address translation type of the local development device and the first network resource object is symmetric, forwarding the joint debugging test request to the first network resource object through the TAP network card.

[0056] Based on the above embodiment, after receiving the joint debugging test request sent by the local development device, the joint debugging test device can determine the network address translation type of the local development device and the first network resource object. If the network address translation type of the local development device or the first network resource object is conical, the joint debugging test request can be sent directly to the first network resource object without passing through the TAP network card; if the network address translation type of the local development device and the first network resource object is symmetric, the joint debugging test request is forwarded to the first network resource object through the TAP network card.

[0057] In the above solution, the developer's local development device (with a TUN network card) can access all network resource objects in the Kubernetes cluster of the test environment directly or through a TAP network card.

[0058] In some embodiments, the Kubernetes-based joint debugging test method of the embodiment of the present disclosure may also include: configuring preset firewall rules on the host where the TUN network card is located in the Kubernetes cluster, and the preset firewall rules are used to enable the Kubernetes cluster to access the local development device.

[0059] In the Kubernetes cluster, except for the host configured with a TUN network card, the network resource objects in other hosts cannot reversely access the local development device. Some special joint debugging tests cannot be implemented, affecting the test performance.

[0060] The disclosed embodiment can configure preset firewall rules on the host where the TUN network card in the Kubernetes cluster is located. The preset firewall rules can realize reverse access of network resource objects in the Kubernetes cluster to local development devices.

[0061] Figure 2 A flow chart of another joint debugging test method based on Kubernetes provided in an embodiment of the present disclosure is shown as follows: Figure 2 As shown, on the basis of configuring the preset firewall rules on the host where the TUN network card in the Kubernetes cluster is located, the joint debugging test method based on Kubernetes in the embodiment of the present disclosure may also include the following steps:

[0062] Step 201: Receive another joint debugging test request sent by the second network resource object.

[0063] The second network resource object may be any one of multiple types of network resource objects in the Kubernetes cluster, without limitation.

[0064] Step 202: Based on the preset firewall rule, the source IP address of the second network resource object is replaced with the IP address of the network card of the host where the TUN network card is located.

[0065] The second network resource object may be any network resource object in a host configured with a preset firewall rule, without limitation.

[0066] The preset firewall rule may be a rule for implementing a routing forwarding function, which may replace the source IP address with the IP address of the network card that sends the data, and send the data out through the network card. For example, the preset firewall rule may be implemented using Iptables, which may be an application software running in user space, and manages the processing and forwarding of network data packets by controlling the Linux kernel netfilter module.

[0067] Exemplarily, the preset firewall rule may be "iptables-tnat-APOSTROUTING-s10.0.10.0 / 24-oeth0-jMASQUERADE", "10.0.10.0 / 24" may be the network segment of the virtual private network of the TUN network card, and a network resource object may correspond to an IP address in the network segment. The preset firewall rule may perform source address translation (SNAT conversion) on the address from the 10.0.10.0 / 24 segment and convert it into the IP address of the network card eth0 of the host where the TUN network card is located. MASQUERADE may replace the source IP with the IP on the network card sending data.

[0068] After receiving another joint debugging test request, the joint debugging test device can replace the source IP address of the second network resource with the network card IP address of the host where the TUN network card is located based on the preset firewall rule.

[0069] Step 203: Send another joint debugging test request to the local development device through the network card of the host where the TUN network card is located.

[0070] Optionally, when network resource objects in other hosts in the Kubernetes cluster except the host where the TUN network card is located need to access the local development device, internal routing rules can be configured in other hosts to send data or requests on other hosts to the local development device through the network card of the host where the TUN network card is located.

[0071] Exemplarily, the internal routing rule may be "ip route add 10.0.11.0 / 24 via 10.0.11.4dev eth0", and "10.0.11.0 / 24" may be the network segment of the network card of another host. The internal routing rule may be used to send data with the address of the "10.0.11.0 / 24" network segment through the network card eth0 (10.0.11.4 as the gateway) of the host where the TUN network card is located.

[0072] In the above solution, by configuring the firewall rules and routing rules of the host in the Kubernetes cluster once, reverse access of all network resource objects in the Kubernetes cluster to the local development device can be achieved, and then some special joint debugging tests that require reverse access can be implemented, thereby realizing two-way access or mutual access between the local development environment and all network resource objects in the Kubernetes cluster, which is more conducive to improving the efficiency of joint debugging tests.

[0073] Next, the joint debugging test method based on Kubernetes in the embodiment of the present disclosure is further described through a specific example. Figure 3A schematic diagram of a joint debugging test system provided by an embodiment of the present disclosure is shown in FIG. Figure 3 As shown, the joint debugging test system may include a local development device 301, a joint debugging test device 302 and a Kubernetes cluster 303. The joint debugging test device 302 is set outside the local development device 301 and the Kubernetes cluster 303 as an example. The joint debugging test device 302 can create a network tunnel based on the TUN / TAP virtual network card between the local development device 301 and the Kubernetes cluster 303 to open up the network connection. Microservice applications can be run in the Kubernetes cluster 303 under the test environment, wherein each module or subservice of a microservice application is responsible for a developer, who needs to use the local integrated development environment (IDE) on the local development device 301 to develop applications, and then call or access other microservice application modules in the test ring Kubernetes cluster 303 through a local area network or the Internet. At the same time, other microservice applications in the Kubernetes cluster 303 can also call or access the services started by the IDE on the local development device 301 of the developer.

[0074] And if Figure 3 As shown, the dotted arrow 31 in the figure can represent the system / VPN data flow, the dotted arrow 32 can represent the business process data flow, the dotted arrow 33 can represent the user's normal request flow, and the dotted arrow represents the debug agent (DebugAgent) process data flow. Figure 3 The local development device 301 may include multiple functional modules, such as the local integrated development environment, local microservice processes A and B, and the local browser in the figure. The Kubernetes cluster 303 may include multiple tenant modules, such as the system tenant A, system tenant B, and business tenant in the figure. Each tenant module may include multiple corresponding functional modules, which are not explained one by one here.

[0075] For example, Figure 4 A schematic diagram of a joint debugging test provided by an embodiment of the present disclosure, Figure 4 LAN B in the Figure 3 The network segment where the Kubernetes cluster 303 is located, LAN A corresponds to Figure 3 The local development device 301 is located in the network segment, and the wide area network C corresponds to the network segment of the public network.

[0076] like Figure 3 and Figure 4 , the implementation process of two-way access to all network resource objects in the local development device and the Kubernetes cluster is as follows:

[0077] 1. In the Kubernetes cluster, in the host in the same network segment as the Kubernetes cluster, or in the host with a public IP, you can deploy a virtual private network server (VPN-Serve). After the deployment is complete, you can see a TAP network card created by the VPN-Server process in the host. The network card name is supernode0. See Figure 4 As shown in "WAN C" in the above. When the client of the virtual private network (VPN-Client) needs to connect to the VPN-Server through the Internet, the VPN-Server should be deployed in a host with a public IP.

[0078] 2. Install VPN-Client on the local development device. After the installation is complete, you will see a TUN network card created by the VPN-Client process on the host. The network card name is edge0. Figure 4 as shown in "LAN A".

[0079] 3. Deploy the VPN-Client to any system tenant of the platform, such as the system default global project of "system tenant A", through the native resource object deployment of the Kubernetes cluster. After the deployment is completed, a TUN network card can be created in the POD. The network card name is edge0. See Figure 4 as shown in "LAN B" of the

[0080] It is understandable that network isolation policies cannot be implemented for system tenants or global projects, that is, services in global projects can be accessed by other projects in the cluster; only one VPN-Client needs to be deployed in the same Kubernetes cluster, and the VPN-Client will be able to realize communication among all applications in all cluster computing nodes.

[0081] 4. VPN-Server will maintain the communication list of all "online" VPN-Clients. The communication information may include MAC address, IP address and port number. The communication between different VPN-Clients will establish a connection with the other end based on the information in the list. If the connection can be established, the communication traffic of the VPN-Client will not pass through the VPN-Server; if the connection cannot be established, the traffic will be forwarded via the VPN-Server.

[0082] See Figure 4As shown in the solid arrow in the figure, after the VPN-Server and VPN-Client are deployed, you can first test the connectivity between VPN-Client and VPN-Client. That is, both parties can test whether the other party is reachable by using the Ping command.

[0083] 5. After completing the above steps, VPN-Client (local development device) can access all network resource objects in the Kubernetes cluster of the test environment through VPN-Server.

[0084] In addition, while establishing the network tunnel, VPN-Client (here refers to Figure 4 "edge01-host A1") in the table can also configure routing rules. The specific routing rules are as follows Figure 4 As shown in the "Routing Rules" of "LAN A".

[0085] 6. After the above local development devices are connected through the VPN service in the Kubernetes cluster, they can access the services provided by all resource objects in the Kubernetes cluster, except for Figure 4 The network resource objects in the host with the TUN network card configured can access the local development device, while the network resource objects in other hosts cannot access the VPN-Client, that is, the local development device. This is a bit inconvenient for developers. What developers want is that after connecting to the VPN, the local development device is completely in the same LAN as the Kubernetes cluster, that is, to achieve two-way interconnection.

[0086] The host with the TUN network card configured above also cannot access the local development device in reverse. To solve the above problem, this solution also requires configuring firewall rules on the host with the TUN network card configured in the Kubernetes cluster. For details about firewall rules, see Figure 4 This preset firewall rule enables the network resource objects of the host with TUN network card in Kubernetes cluster to access the local development device in reverse, as shown in "LAN B" in the example. Figure 4 Host B1 accesses the local development device.

[0087] In addition, when network resource objects in other hosts in the Kubernetes cluster need to access the local development device except the host where the TUN network card is located, you can configure internal routing rules in other hosts to send data or requests on other hosts to the local development device through the network card of the host where the TUN network card is located. Figure 4The internal routing rule in host B3 in the "LAN B" can be "ip route add 10.0.11.0 / 24 via10.0.11.4 dev eth0", and "10.0.11.0 / 24" can be the network segment of the network card of other hosts. This internal routing rule can be used to send the data with the address of the "10.0.11.0 / 24" network segment through the network card eth0 of the host where the TUN network card is located (10.0.11.4 is the gateway).

[0088] In this solution, a network tunnel can be created using the TUN / TAP virtual network card to connect the local and test environment networks, and VPN can be used to achieve point-to-point communication. This solution does not require additional learning costs, and solves the joint debugging and testing problems between the local development environment and the Kubernetes cluster test environment through a pure network solution. There is no need to frequently operate the network service configuration in the Kubernetes cluster to complete the external access of the container application in the Kubernetes cluster, and by configuring the firewall rules and routing rules of the host in the Kubernetes cluster once, all network resource objects in the Kubernetes cluster can achieve reverse access to the local development device, and then some special joint debugging tests that require reverse access can be implemented, thereby achieving two-way access or mutual access between all network resource objects in the local development environment and the Kubernetes cluster, which is more conducive to improving the efficiency of joint debugging and testing.

[0089] Figure 5 The present invention provides a schematic diagram of a joint debugging and testing device based on Kubernetes, which can be implemented by software and / or hardware and can generally be integrated into an electronic device. Figure 5 As shown, the device comprises:

[0090] The request receiving module 501 is used to receive the joint debugging test request sent by the local development device;

[0091] A request sending module 502 is used to send the joint debugging test request to the first network resource object in the Kubernetes cluster based on a pre-created network tunnel between the local development device and the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card;

[0092] The test execution module 503 is used to execute a joint debugging test between the local development device and the first network resource object based on the network tunnel.

[0093] Optionally, the device further includes a network tunnel module, configured to:

[0094] Create a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card.

[0095] Optionally, the network tunnel module includes:

[0096] The first unit is used to deploy a virtual private network on the target host of the Kubernetes cluster and the local development machine;

[0097] The second unit is used to use the virtual private network to create a TAP network card in the target host of the Kubernetes cluster, and to create a TUN network card in the container group of the Kubernetes cluster and the local development device;

[0098] The third unit is used to determine the network architecture of the combination of the TAP network card and the TUN network card as the network tunnel.

[0099] Optionally, the first unit is specifically used for:

[0100] A virtual private network server is deployed on the target host of the Kubernetes cluster, and a virtual private network client is deployed in a global project of any system tenant of the Kubernetes cluster and in the local development device.

[0101] Optionally, the local development device is configured with a preset routing rule, and the preset routing rule is used to send communication information of all hosts in the Kubernetes cluster to the TUN network card in the Kubernetes cluster.

[0102] Optionally, a communication list is stored in the TAP network card, and the communication list includes communication information of a local development device where the TUN network card is located and communication information of a network resource object for creating the TUN network card in the Kubernetes cluster, and the communication information includes port information, IP address, and MAC address.

[0103] Optionally, the target host of the Kubernetes cluster is a host in the same network segment as the Kubernetes cluster, a host in the Kubernetes cluster, or a host on the public network.

[0104] Optionally, the request sending module 502 is specifically used for:

[0105] When the network address translation type of the local development device and the first network resource object is symmetric, the joint debugging test request is forwarded to the first network resource object through the TAP network card.

[0106] Optionally, the device further includes a firewall rule module, configured to:

[0107] A preset firewall rule is configured on the host where the TUN network card is located in the Kubernetes cluster, and the preset firewall rule is used to enable the Kubernetes cluster to access the local development device.

[0108] Optionally, the device further includes a reverse access module, configured to:

[0109] Receive another joint debugging test request sent by the second network resource object;

[0110] Based on the preset firewall rule, the source IP address of the second network resource object is replaced with the network card IP address of the host where the TUN network card is located;

[0111] The other joint debugging test request is sent to the local development device through the network card of the host where the TUN network card is located.

[0112] The Kubernetes-based joint debugging and testing device provided in the embodiments of the present disclosure can execute the Kubernetes-based joint debugging and testing method provided in any embodiment of the present disclosure, and has the functional modules and beneficial effects corresponding to the execution method.

[0113] Figure 6 The structure diagram of an electronic device provided by the embodiment of the present disclosure is shown in FIG. Figure 6 As shown, the electronic device 600 includes one or more processors 601 and a memory 602 .

[0114] The processor 601 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 600 to perform desired functions.

[0115] The memory 602 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may include, for example, a read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 601 may run the program instructions to implement the Kubernetes-based joint debugging test method and / or other desired functions of the embodiments of the present disclosure described above. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0116] In one example, the electronic device 600 may further include: an input device 603 and an output device 604 , and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0117] In addition, the input device 603 may also include, for example, a keyboard, a mouse, and the like.

[0118] The output device 604 can output various information to the outside, including the determined distance information, direction information, etc. The output device 604 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0119] Of course, to simplify, Figure 6 Only some of the components related to the present disclosure in the electronic device 600 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 600 may also include any other appropriate components.

[0120] In addition to the above-mentioned method and device, an embodiment of the present disclosure may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the Kubernetes-based joint debugging and testing method provided by an embodiment of the present disclosure.

[0121] The computer program product may be written in any combination of one or more programming languages ​​to write program code for performing the operations of the disclosed embodiments, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0122] In addition, an embodiment of the present disclosure may also be a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the Kubernetes-based joint debugging and testing method provided by an embodiment of the present disclosure.

[0123] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0124] It should be noted that, in this article, relational terms such as "first" and "second" are only used 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.

[0125] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A joint debugging test method based on Kubernetes, characterized in that: include: Receive joint debugging test requests sent by local development devices; Based on a pre-created network tunnel between the local development device and the Kubernetes cluster, sending the joint debugging test request to a first network resource object in the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card; Performing a joint debugging test between the local development device and the first network resource object based on the network tunnel; Create a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card; Create a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card, including: Deploy a virtual private network on the target host in the Kubernetes cluster and on the local development machine; Using the virtual private network, creating a TAP network card in the target host of the Kubernetes cluster, and creating a TUN network card in the container group of the Kubernetes cluster and the local development device; The TAP network card stores a communication list, which includes communication information of a local development device where the TUN network card is located and communication information of a network resource object in the Kubernetes cluster that creates the TUN network card, wherein the communication information includes port information, an IP address, and a MAC address; The network architecture of the combination of the TAP network card and the TUN network card is determined as the network tunnel.

2. The method according to claim 1, characterized in that Deploy a virtual private network on the target host of the Kubernetes cluster and on your local development machine, including: A virtual private network server is deployed on the target host of the Kubernetes cluster, and a virtual private network client is deployed in a global project of any system tenant of the Kubernetes cluster and in the local development device.

3. The method according to claim 1, characterized in that The local development device is configured with a preset routing rule, and the preset routing rule is used to send the communication information of all hosts in the Kubernetes cluster to the TUN network card in the Kubernetes cluster.

4. The method according to claim 2, characterized in that: The target host of the Kubernetes cluster is a host in the same network segment as the Kubernetes cluster, a host in the Kubernetes cluster, or a host on the public network.

5. The method according to claim 1, characterized in that Sending the joint debugging test request to the first network resource object in the Kubernetes cluster includes: When the network address translation type of the local development device and the first network resource object is symmetric, the joint debugging test request is forwarded to the first network resource object through the TAP network card.

6. The method according to claim 1, characterized in that The method further comprises: A preset firewall rule is configured on the host where the TUN network card is located in the Kubernetes cluster, and the preset firewall rule is used to enable the Kubernetes cluster to access the local development device.

7. The method according to claim 6, characterized in that The method further comprises: Receive another joint debugging test request sent by the second network resource object; Based on the preset firewall rule, the source IP address of the second network resource object is replaced with the network card IP address of the host where the TUN network card is located; The other joint debugging test request is sent to the local development device through the network card of the host where the TUN network card is located.

8. A joint debugging test device based on Kubernetes, characterized in that: include: The request receiving module is used to receive the joint debugging test request sent by the local development device; A request sending module, used to send the joint debugging test request to the first network resource object in the Kubernetes cluster based on a pre-created network tunnel between the local development device and the Kubernetes cluster, wherein the network tunnel is created based on a TUN / TAP virtual network card; A test execution module, used to execute a joint debugging test between the local development device and the first network resource object based on the network tunnel; The device also includes a network tunnel module, which is used to: Create a network tunnel between the local development device and the Kubernetes cluster based on the TUN / TAP virtual network card; The network tunnel module includes: The first unit is used to deploy a virtual private network on the target host of the Kubernetes cluster and the local development machine; The second unit is used to use the virtual private network to create a TAP network card in the target host of the Kubernetes cluster, and to create a TUN network card in the container group of the Kubernetes cluster and the local development device; The TAP network card stores a communication list, which includes communication information of a local development device where the TUN network card is located and communication information of a network resource object in the Kubernetes cluster that creates the TUN network card, wherein the communication information includes port information, an IP address, and a MAC address; The third unit is used to determine the network architecture of the combination of the TAP network card and the TUN network card as the network tunnel.

9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the instructions to implement the Kubernetes-based joint debugging and testing method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and the computer program is used to execute the Kubernetes-based joint debugging and testing method described in any one of claims 1 to 7.

Images