A local debugging method and system for microservices based on container platform

Abstract

The present invention provides a local debugging method for microservices based on a container platform, comprising the following steps: selecting at least one working node among several working nodes in a container platform as a proxy node, connecting a container set in the container platform and a local production network through the proxy node; configuring an address of the proxy node for a switch of the local production network, so that a data flow between the local production network and the container platform is forwarded only through the proxy node; thereby: a data flow sent by the local production network is forwarded to the container set in the container platform through the proxy node, and a data flow sent by the container set is forwarded to the local production network through the proxy node.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a local debugging method and system for microservices based on a container platform. Background Art

[0002] In a large-scale distributed microservice system, there are hundreds or even thousands of services developed, and the calling relationships between services are very complex. Once a program has a bug or the latency is very high, online debugging is very troublesome. The kubernetes container network makes debugging even more difficult. Generally, developers have little basic knowledge of the network, and it is difficult to solve the interoperability problems of multiple network environments, and thus debug the microservices deployed in kubernetes.

[0003] Many current network interconnection solutions adopt a single-point interconnection method, that is, developers install and deploy network tools locally, and then do some network configuration to achieve interconnection between the local development environment and the kubernetes container network environment. However, the whole process is cumbersome and can only be used by one person.

[0004] The current local debugging of microservices has the following difficulties or disadvantages:

[0005] 1) The current network interconnection solution has load configuration and can basically only be used by one person, that is, each developer needs to make the same configuration (such as Kt-Connect).

[0006] 2) The configuration is complex and difficult for general developers to understand or the configuration efficiency is too low, making it impossible to quickly use network interoperability tools to troubleshoot service anomalies or failures deployed on the container platform. Summary of the invention

[0007] In order to overcome the above technical defects, the purpose of the present invention is to provide a local debugging method and system for microservices based on a container platform, which can speed up the efficiency of developers debugging microservices.

[0008] The present invention discloses a local debugging method for a microservice based on a container platform, comprising the following steps: selecting at least one working node among a plurality of working nodes in a container platform as a proxy node, connecting a container set in the container platform and a local production network through the proxy node; configuring an address of the proxy node for a switch of the local production network, so that a data flow between the local production network and the container platform is forwarded only through the proxy node; thereby: the data flow sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data flow sent by the container set is forwarded to the local production network through the proxy node.

[0009] Preferably, after selecting at least one working node from among several working nodes in the container platform as the proxy node, the method further includes: the proxy node enables a routing forwarding function, and converts the source address through a firewall rule table, so that: the proxy node converts the data stream sent by the local production network into an internal address segment of the container set, and forwards the data stream to the container set through the firewall rule table of the proxy node; the proxy node converts the data stream sent by the container set into an internal address segment of the local production network, and forwards the data stream to the local production network through the firewall rule table of the proxy node.

[0010] Preferably, it also includes: if the proxy node includes more than two working nodes, then based on the traffic load on the proxy node, a routing forwarding strategy is configured on the switch of the local production network to regulate the difference in traffic of the data flow to the proxy node.

[0011] Preferably, the selecting at least one working node from among several working nodes in the container platform as the proxy node includes: selecting a working node with the lowest business volume from among several working nodes in the container platform as the proxy node.

[0012] Preferably, it also includes: real-time monitoring of the traffic load on the proxy node; when the monitored traffic load exceeds a preset threshold, reselecting at least one of all the working nodes except the proxy node, and replacing the proxy node with an update node.

[0013] Preferably, it also includes: real-time monitoring of the traffic load on the proxy node; when the monitored traffic load exceeds a preset threshold, selecting at least one of all the working nodes except the proxy node, and combining it with the proxy node to form an update node, and connecting the container set in the container platform and the local production network through the update node.

[0014] Preferably, the real-time monitoring of the traffic load on the proxy node comprises: a service on the switch side of the local production network collects statistics on the load data on the proxy node or the update node.

[0015] Preferably, the method further comprises: an administrator controlling whether to configure or not configure the address of the proxy node for the switch of the local production network.

[0016] Preferably, it also includes: configuring the domain name system of the container platform in the domain name system of the local production network, the domain name system includes the Core domain name system, including: obtaining the service IP address inside the container set through the service of the domain name system inside the container platform; configuring the service IP address of the domain name system of the container platform in the service of the domain name system of the local production network.

[0017] The present invention also discloses a local debugging system for microservices based on a container platform, including a container platform and a local production network; selecting at least one working node in the container platform as a proxy node, connecting the container set in the container platform and the local production network through the proxy node; configuring the address of the proxy node for the switch of the local production network, so that the data flow between the local production network and the container platform is forwarded only through the proxy node; thereby: the data flow sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data flow sent by the container set is forwarded to the local production network through the proxy node.

[0018] Compared with the prior art, the above technical solution has the following beneficial effects:

[0019] 1. The present invention forwards the network segment (container network segment) with a special traffic identifier to the working node of the container platform through the switch of the local production network (office network), and then connects the working node with the container network to achieve the interconnection of the container platform traffic and the container node, and then transfers it to the local production network (office network), thereby achieving the interconnection of the local network and the container network of the container platform, so that local services can call remote services; the present invention is developer-friendly, and there is no need for developers to participate in the network interconnection configuration. Only one configuration is required to achieve the effect that all developers can use, and there is no risk of single point failure. The traffic load balancing strategy can be implemented, thereby greatly improving the implementation efficiency and development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A flowchart of a local debugging method for microservices based on a container platform according to an embodiment of the present invention;

[0021] Figure 2 A functional block diagram of a local debugging system for microservices based on a container platform according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] The advantages of the present invention are further described below in conjunction with the accompanying drawings and specific embodiments.

[0023] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0024] The terms used in this disclosure are for the purpose of describing specific embodiments only and are not intended to limit the disclosure. The singular forms of "a", "said" and "the" used in this disclosure and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0025] It should be understood that although the terms first, second, third, etc. may be used in the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0026] In the description of the present invention, it is necessary to understand that the terms "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0027] In the description of the present invention, unless otherwise specified and limited, it should be noted that the terms "installed", "connected" and "connected" should be understood in a broad sense. For example, it can be a mechanical connection or an electrical connection, or it can be the internal connection between two components. It can be a direct connection or an indirect connection through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to the specific circumstances.

[0028] In the following description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present invention, and have no specific meanings. Therefore, "module" and "component" can be used interchangeably.

[0029] See attached Figure 1 The present invention discloses a local debugging method for microservices based on a container platform. Due to a problem often encountered during the development process, the local production network (office network) needs to access the internal container node resources of the container platform. The initial access data flow directly requests the container service of kubernetes. At this time, when the production network segment user directly accesses the pods address segment, there is no pods segment route when the data flow reaches the gateway switch or the default route goes to the public network (it can be understood that the physical network cannot directly access the container network in the container). Therefore, the pods resources cannot be accessed, so the production network segment user will find that it cannot be accessed.

[0030] The local debugging method of microservices based on a container platform of the present invention configures a container node routing forwarding strategy to enable the container platform intranet and the production intranet to access each other.

[0031] The container platform of the present invention is preferably kubernetes (k8s for short), but can also be applied to other container management platforms, such as Swam, Meso, etc.

[0032] The present invention discloses a local debugging method for microservices based on a container platform, comprising the following steps:

[0033] S100, selecting at least one working node from among several working nodes in the container platform as a proxy node, and connecting the container set in the container platform and the local production network through the proxy node;

[0034] S200. The switch of the local production network configures the address of the proxy node so that the data flow between the local production network and the container platform is forwarded only through the proxy node; thereby: the data flow sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data flow sent by the container set is forwarded to the local production network through the proxy node.

[0035] The Kubernetes cluster is composed of a group of container nodes, which can be physical hosts or virtual machines. The Kubernetes platform runs on these nodes to form a cluster. The Kubernetes cluster includes MasterNode and the worker node Node for the actual deployment of Pod. Worker node (Node): Node is the real workload node in the K8s cluster. The K8s cluster is shared by multiple Nodes. The pod is assigned to a specific node for execution. The worker node node includes Pod, Kubelet, Kube-proxy, and cAdvisor components, among which, container set (Pod): A container group deployed on a single worker node Node and containing one or more containers. All containers in the same container set share the same IP address, IPC, host name and other resources. In some embodiments, one or more worker nodes can be selected from several worker nodes of the container platform as proxy nodes, wherein the proxy node is a routing forwarding node, and the container set of the container platform and the local production network are connected through the proxy node to realize that the container platform intranet and the production intranet can access each other. In this embodiment, the selection strategy of the proxy node and the number of worker nodes included are not limited. After selecting the proxy node, configure the address of the proxy node (such as IP address, etc.) on the switch of the local production network so that the data flow between the local production network and the container platform is forwarded only through the proxy node, so that the data flow sent by the local production network (such as the data flow sent by the local production network to the container platform, etc.) is forwarded to the container set in the container platform through the proxy node, and the data flow sent by the container set (such as the data flow sent by the container platform to the local production network, etc.) is forwarded to the local production network through the proxy node. See Appendix Figure 2 The working node node corresponds to the Kubernetes container set pod. The figure shows three nodes, such as node1, node2, and node3 (actually not limited to three). Node1, node2, and node3 correspond to one pod respectively, or multiple pods respectively. There is no limit. Each pod corresponds to an independent address (IP address). The proxy node can be any one or more of node1, node2, or node3.

[0036] In step S100, after selecting at least one working node from several working nodes in the container platform as a proxy node, it is also necessary to enable the routing forwarding function for the proxy node, and convert the source address through the firewall rule table, so that the proxy node converts the data stream sent by the local production network (office network) into the internal address segment of the container set, and forwards the data stream to the container set through the firewall rule table of the proxy node (such as iptables, etc.). In this way, the data stream sent by the local production network can be forwarded to the container set, that is, the data of the local production network (office network) can be forwarded to the container platform kubernetes.

[0037] In addition, the proxy node can convert the data stream sent by the container set into the internal address segment of the local production network, and forward the data stream to the local production network through the proxy node's firewall rule table (such as iptables, etc.), so that the data stream sent by the container set can be forwarded to the local production network (office network), that is, the data of the container platform kubernetes can be forwarded to the local production network (office network). Thus, the local production network (office network) and the container platform kubernetes are completely connected.

[0038] Therefore, the request sent by the local application service to the container platform network segment can smoothly reach the service deployed on the container network, and the request sent by the service deployed on the container platform to the local service network segment can also smoothly reach the local office area, and then to the developer's local deployment service. In this way, whether it is calling the container platform service from the local or the container platform calling the local microservice, it can be implemented very simply, and the developer does not need to participate in the process of connecting the entire network. Only a one-time configuration is required to enable all developers in the office area to debug any service in the container in the local environment.

[0039] When selecting a working node as a proxy node, a preferred solution is to select a working node with the lowest business volume among several working nodes in the container platform as a proxy node. For example, a working node with the lowest business volume is selected in the k8s cluster as a proxy node, which is specially used as a routing forwarding node to connect the production network and the k8s cluster pods. Of course, other selection strategies can also be used, which are not limited here. For example, multiple working nodes with low business volume are selected in the k8s cluster as proxy nodes to serve as routing forwarding nodes, etc.

[0040] In some embodiments, when the number of working nodes in the proxy node is one, static routing is configured on the switch of the local production network so that the data flow between the local production network and the container platform is forwarded only through the proxy node. Since there is only one working node in the proxy node at this time, the proxy node may have too much traffic and too high load. It can be further extended to other nodes to share the load by modifying the routing policy of the switch in the local production network, thereby reducing the risk of single point failure. For example, the switch of the local production network is changed from configuring static routing to configuring dynamic routing, and the number of working nodes in the corresponding proxy node is changed from one to multiple, etc., so as to avoid requesting all the request traffic to one working node, and avoid causing the working node to be overloaded or down.

[0041] Furthermore, when the proxy node includes more than two working nodes, multiple working nodes in the proxy node can be connected to the container set in the container platform and the local production network at the same time, or can be connected to the container set in the container platform and the local production network in sequence. When connected in sequence, the connection priority can be set according to the actual business volume of different working nodes in the proxy node, that is, which working node is connected first, which working node is connected second, and which working node is connected last.

[0042] Preferably, since the number of working nodes in a proxy node can be one or more, if the proxy node includes more than two working nodes, a routing forwarding strategy is configured on the switch of the local production network based on the traffic load on the proxy node to regulate the difference in traffic of the data flow to the proxy node.

[0043] It can be understood that when the proxy node includes more than two working nodes, in order to achieve load balancing of the proxy node, the real-time statistics of the proxy node load data are performed through the service on the switch side of the local production network (office network), so that the routing forwarding strategy can be dynamically configured on the switch according to the load situation on the proxy node, so as to dynamically adjust the difference in the flow of data flows passing through the working nodes in the proxy node. For example, the proxy node includes two working nodes (node1 and node2), and the switch first configures the IP addresses of the two working nodes in the proxy node, and then performs real-time statistics of the load data of the two working nodes in the proxy node through the service on the switch side of the local production network (office network), and dynamically configures the routing forwarding strategy on the switch according to the load situation, such as 30% of the data volume to node1 and 70% of the data volume to node2.

[0044] Furthermore, when the number of working nodes in a proxy node is one, or even if the proxy node includes multiple working nodes, a certain working node may still be overloaded. In this case, we need further regulation. Here, there are two regulation schemes:

[0045] The first control scheme is to monitor the traffic load on the proxy node in real time. When the monitored traffic load exceeds the preset threshold, at least one of the other working nodes except the proxy node among all the working nodes is reselected to replace the proxy node with the update node. In this scheme, the traffic load on the proxy node is monitored in real time, such as real-time statistics of the proxy node load data through the service on the switch side of the local production network (office network). When the monitored traffic load exceeds the preset threshold, the proxy node is replaced (the proxy node can include one or more working nodes at this time, which is not limited here), and at least one of the other working nodes except the proxy node among all the working nodes is selected as the update node, and the update node performs routing forwarding work. At this time, the update node can be understood as the updated proxy node, which plays the role of the proxy node. Among them, the number of working nodes contained in the update node and the number of working nodes contained in the original proxy node can be the same or different, which is not limited here. The selection strategy of the working nodes contained in the update node is also not limited. In some embodiments, the traffic load on the update node is subsequently monitored in real time. When the monitored traffic load exceeds a preset threshold, the update node is replaced, and at least one of the other working nodes except the update node (and the proxy node) among all the working nodes is reselected as a new update node, and the new update node performs routing forwarding work. Those skilled in the art should understand that this control scheme will continue and will not be described in detail here. The second control scheme monitors the traffic load on the proxy node in real time. When the monitored traffic load exceeds a preset threshold, at least one of the other working nodes except the proxy node among all the working nodes is selected and combined with the proxy node to form an update node, and the container set in the container platform and the local production network are connected through the update node. In this scheme, the traffic load on the proxy node is monitored in real time, such as real-time statistics of the proxy node load data through the service on the switch side of the local production network (office network). When the monitored traffic load exceeds the preset threshold, the proxy node is not replaced. It can be understood that, instead, a new working node is added (such as selecting at least one of the other working nodes other than the proxy node among all the working nodes), and the proxy node and the newly added working node are used as update nodes together, and the update node performs routing forwarding work. At this time, the update node can be understood as the updated proxy node, which plays the role of the proxy node. Among them, the selection strategy of the newly added working node is not limited here. In some embodiments, the traffic load on the update node is subsequently monitored in real time. When the monitored traffic load exceeds the preset threshold, a new working node is added (such as selecting at least one of the other working nodes other than the update node (and the proxy node) among all the working nodes), and the update node and the newly added working node are used as new update nodes to perform routing forwarding work. Those skilled in the art should understand that this control scheme will continue, and will not be repeated here.

[0046] Preferably, for monitoring the traffic load on the proxy node, it is preferred to collect the load data of the proxy node through the service statistics of the switch side of the local production network.

[0047] Preferably, the routing forwarding function can be set as an advanced setting, that is, a function that only the administrator has the authority to configure. Specifically, the administrator can configure or not configure the address of the proxy node for the switch of the local production network, that is, turn on or off the routing forwarding function, thereby controlling whether to connect the container platform and the local production network to ensure the security of the data of the container platform and the local production network.

[0048] Preferably, in the container platform Kubernetes environment, many requests are initiated in the form of domain names. If you only connect the container environment and the office network environment, but ignore the domain name resolution service, it may cause obstacles in calling, thereby affecting the system diagnosis and system debugging of the development environment. Therefore, the present invention also configures the domain name system DNS of the upstream container platform, such as CoreDNS, in the DNS of the office environment.

[0049] Specifically: The clusterIP address inside the cluster is obtained through the DNS Service inside the container platform, and the clusterIP address of the upstream container platform DNS is configured in the DNS service of the local office environment. This allows: when the container platform domain name is used in the local environment, it can be forwarded to the container platform internal DNS for domain name resolution through the local DNS, so as to obtain the container IP for accessing the service. In this way, local services can call the services and data of the container platform regardless of the IP and container platform domain name.

[0050] In general, when an online service fails and needs local debugging, or when local developers need to debug, but the full microservice cluster cannot be deployed locally, debugging can be performed with the help of some local services and most of the services on the container platform. Since the solution of the present invention enables local source code-level tracking and debugging, the efficiency of troubleshooting can be rapidly improved.

[0051] The present invention also discloses a local debugging system for microservices based on a container platform, including a container platform and a local production network. At least one working node in the container platform is selected as a proxy node, and the container set in the container platform and the local production network are connected through the proxy node. Next, the address of the proxy node is configured for the switch of the local production network, so that the data flow between the local production network and the container platform is forwarded only through the proxy node, so that: the data flow sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data flow sent by the container set is forwarded to the local production network through the proxy node. In this way, the office development network environment and the kubernetes container network environment are connected, the problem of developers debugging microservices in local development tools is solved, the difficulty of local debugging for developers is greatly reduced, and the efficiency of project development is improved.

[0052] It should be noted that the embodiments of the present invention have better practicability and do not impose any form of limitation on the present invention. Any technician familiar with the field may use the technical content disclosed above to change or modify it into an equivalent effective embodiment. However, any modification or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention are still within the scope of the technical solution of the present invention.

Claims

1. A local debugging method for microservices based on a container platform, characterized in that: The steps include: Select at least one working node from among several working nodes in the container platform as a proxy node, and connect the container set in the container platform and the local production network through the proxy node; The switch of the local production network configures the address of the proxy node so that the data flow between the local production network and the container platform is forwarded only through the proxy node; Thus: the data stream sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data stream sent by the container set is forwarded to the local production network through the proxy node; Also includes: If the proxy node includes more than two working nodes, a routing forwarding strategy is configured on the switch of the local production network based on the traffic load on the proxy node to regulate the difference in traffic of the data flow to the proxy node.

2. The local debugging method of microservices based on a container platform according to claim 1, characterized in that: After selecting at least one working node from among a plurality of working nodes in the container platform as a proxy node, the method further includes: The proxy node enables the routing forwarding function and converts the source address through the firewall rule table, so that: The proxy node converts the data stream sent by the local production network into the internal address segment of the container set, and forwards the data stream to the container set through the firewall rule table of the proxy node; The proxy node converts the data stream sent by the container set into an internal address segment of the local production network, and forwards the data stream to the local production network through a firewall rule table of the proxy node.

3. The local debugging method of microservices based on a container platform according to claim 1, characterized in that: The selecting at least one working node from among the plurality of working nodes in the container platform as a proxy node comprises: A working node with the lowest business volume among several working nodes in the container platform is selected as the proxy node.

4. The local debugging method of microservices based on a container platform according to claim 1, characterized in that: Also includes: Monitoring the traffic load on the proxy node in real time; When the monitored traffic load exceeds a preset threshold, at least one of the other working nodes except the proxy node among all the working nodes is reselected to replace the proxy node as the update node.

5. The local debugging method of microservices based on a container platform according to claim 1, characterized in that: Also includes: Monitoring the traffic load on the proxy node in real time; When the monitored traffic load exceeds a preset threshold, at least one of all the working nodes except the proxy node is selected and combined with the proxy node to form an update node, and the container set in the container platform and the local production network are connected through the update node.

6. The local debugging method for microservices based on a container platform according to claim 4 or 5, characterized in that: The real-time monitoring of the traffic load on the proxy node includes: The service statistics on the switch side of the local production network collects load data on the proxy node or the update node.

7. The local debugging method of microservices based on a container platform according to claim 1, characterized in that: Also includes: An administrator controls whether to configure or not configure the address of the proxy node for the switch of the local production network.

8. The local debugging method for microservices based on a container platform according to claim 1 or 2, characterized in that: Also includes: Configuring the domain name system of the container platform in the domain name system of the local production network, the domain name system including CoreDNS, including: Obtaining a service IP address inside the container set through a service of a domain name system inside the container platform; The service IP address of the domain name system of the container platform is configured in the service of the domain name system of the local production network.

9. A local debugging system for microservices based on a container platform, characterized in that: Including container platforms and local production networks; Select at least one working node in the container platform as a proxy node, and connect the container set in the container platform and the local production network through the proxy node; Configuring the address of the proxy node for the switch of the local production network so that the data flow between the local production network and the container platform is forwarded only through the proxy node; Thus: the data stream sent by the local production network is forwarded to the container set in the container platform through the proxy node, and the data stream sent by the container set is forwarded to the local production network through the proxy node; If the proxy node includes more than two working nodes, a routing forwarding strategy is configured on the switch of the local production network based on the traffic load on the proxy node to regulate the difference in traffic of the data flow to the proxy node.

Images