Cloud Native Edge Container Control Method, System and Storage Medium

Abstract

This application proposes a cloud-native edge container control method, system, and storage medium. For a network request initiated by a business component of any edge node, i.e., the first edge node, on the edge side, it can be reverse-proxied to the proxy service component of the first edge node. When the proxy service component determines that the network state between the first edge node and the cloud side is in an offline state, it will call the health check component of the first edge node to perform regional node health checks, reliably obtain the target health check result of the first edge node, and thus respond to the above reverse-proxied network request by calling the cache management component of the first edge node, which can feedback the cache data of the first edge node to the corresponding business component, so that the corresponding business service requested by the first edge node can run normally. That is to say, in the case of network disconnection of the edge container, it enables the edge autonomous function of maintaining the stability of the edge business service.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and more specifically, to a cloud-native edge container control method, system, and storage medium. Background Art

[0002] Kubernetes, abbreviated as K8s, is an open-source container orchestration engine that supports automated deployment, large-scale scalability, and application containerization management. Since it shields the differences in underlying architectures, it can help applications run smoothly on different infrastructures, facilitating the expansion of the service boundary of Kubernetes in the cloud and the combined application of cloud-native and edge computing to meet the application requirements of Kubernetes in the edge environment.

[0003] However, in the Internet of Things edge computing application scenario, due to the extremely complex network environment between the edge side and the cloud side, the connection between the edge nodes on the edge side and the cloud side is unreliable. If the communication link between the kube-apiserver on the cloud side and the edge nodes is disconnected, the business services on the edge nodes will not be able to run properly, which is not conducive to the expansion of the application scenario of Kubernetes. Summary of the Invention

[0004] In view of this, to solve the above technical problems, this application provides the following technical solutions:

[0005] On the one hand, this application proposes a cloud-native edge container control method, and the method includes:

[0006] The business component of the first edge node on the edge side initiates a network request, and the proxy service component of the first edge node reverse-proxies the network request to obtain the network status between the first edge node and the cloud side;

[0007] When it is determined that the network status is an offline state, the proxy service component calls the health check component of the first edge node for distributed health check to obtain the target health check result of the first edge node;

[0008] The proxy service component responds to the network request according to the target health check result, calls the cache management component of the first edge node, and reads the corresponding cache data stored in the cache database of the first edge node;

[0009] The proxy service component feeds back the cache data to the corresponding business component to enable the corresponding business service of the first edge node to run properly.

[0010] Optionally, obtaining the network status between the first edge node and the cloud side includes: a health check component of the first edge node monitors the health status of the first edge node and sends the monitored health status to the proxy service component;

[0011] The proxy service component determines the network status of the communication link between the first edge node and the cloud side based on the health status; the network status includes an online status and an offline status.

[0012] Optionally, when the proxy service component responds to the network request according to the target health check result, it calls the cache management component in the first edge node to read the corresponding cache data stored in the cache database of the first edge node, including:

[0013] If the target health check result is that the health check passes, the proxy service component calls the cache management component in the first edge node to read the corresponding cache data stored in the cache database of the first edge node;

[0014] If the target health check result is that the health check fails, the proxy service component adjusts the corresponding service model and / or service strategy of the first edge node, and executes the step that the proxy service component calls the cache management component in the first edge node to read the corresponding cache data stored in the cache database of the first edge node.

[0015] Optionally, the method further includes:

[0016] When it is determined that the network status is the online status, the proxy service component forwards the network request to the cloud side for processing and receives the response data feedback by the cloud side in response to the network request;

[0017] The proxy service component sends the response data to the cache management component for cache processing;

[0018] The cache management component sends the cached response data to the cache database in the first edge node for updated storage.

[0019] Optionally, the method further includes:

[0020] The cache management component of the first edge node sends the network configuration information of each process running on the first edge node to the cache database for storage;

[0021] When it is determined that the first edge node restarts, the proxy service component of the first edge node calls the cache management component to prohibit updating the podIP address and MAC address in the network configuration information stored in the cache database;

[0022] The proxy service component adjusts the domain name resolution parameter of the preset service component in the first edge node to the private IP address of the first edge node, so that the restarted first edge node can implement domain name resolution and service invocation.

[0023] Optionally, when the first edge node is in the offline state or restarted, the method further includes:

[0024] The node management component of the Master node on the cloud side obtains a preset event for the first edge node through the Webhook mechanism to prevent the Pods built by the first edge node from being evicted or rescheduled.

[0025] Optionally, the proxy service component invokes the health check component of the first edge node to perform regional node health checks and obtains the target health check result of the first edge node, including:

[0026] The proxy service component invokes the health check component of the first edge node, and based on the regional labels of the edge nodes on the edge side, performs health checks on the corresponding edge nodes in the first region where the first edge node is located, and obtains the first health check result of the corresponding edge nodes;

[0027] The proxy service component obtains the second health check result of the first edge node sent by the second edge node in the first region; the second edge node refers to multiple edge nodes in the first region other than the first edge node, and the second health check result is obtained by the second edge node performing a health check on the first edge node based on a preset detection interface;

[0028] The proxy service component classifies the first health check result of the first edge node and multiple second health check results through a voting election method to obtain the target health check result of the first edge node.

[0029] In another aspect, the present application also proposes a cloud native edge container control system, the system includes a cloud side and an edge side, the edge side is configured with multiple edge nodes, and each edge node is configured with a proxy service component, a health check component, a cache management component, and a cache database, wherein:

[0030] The health check component is used to sense the health status of the first edge node where it is located and support distributed health checks by region; the first edge node refers to any edge node on the edge side;

[0031] The proxy service component is used to reverse proxy network requests initiated by business components of the first edge node where it is located, obtain the network status between the first edge node and the cloud side, and when determining that the network status of the first edge node is an offline state, call the health check component to perform distributed health checks and obtain the target health check result of the first edge node;

[0032] The cache management component is used to manage the cache data of the first edge node where it is located and send the cache data to the cache data for storage;

[0033] The proxy service component is further used to respond to the network request according to the target health check result, call the cache management component to read the corresponding cache data stored in the cache database of the first edge node, and feedback the cache data to the corresponding business component, so that the corresponding business service of the first edge node can run normally.

[0034] Optionally, a Master node is configured on the cloud side, and a node management component is configured on the Master node, where:

[0035] The node management component is used to obtain a preset event for the edge node through the Webhook mechanism when there is an edge node on the edge side that has been restarted or is in an offline state, so as to prevent the Pods built by the edge node from being evicted or rescheduled.

[0036] On the other hand, the present application also proposes a storage medium, on which a computer program is stored, and the computer program is loaded and executed by a processor to implement the cloud native edge container control method as described above.

[0037] Thus, it can be seen that the present application provides a cloud native edge container control method, system and storage medium. For a network request initiated by a business component of any edge node on the edge side, that is, the first edge node, it can be reverse proxied to the proxy service component of the first edge node. When the proxy service component determines that the network status between the first edge node and the cloud side is in an offline state, it will call the health check component of the first edge node to perform regional node health checks, reliably obtain the target health check result of the first edge node, and thus respond to the reverse proxy network request accordingly, call the cache management component of the first edge node, and be able to feedback the cache data of the first edge node to the corresponding business component, so that the corresponding business service requested by the first edge node can run normally. That is to say, in the case of network disconnection of the edge container, it has the edge autonomy function to maintain the stability of edge business services, expands the application scenario of Kubernetes, and effectively promotes the integration of cloud native container technology and Internet of Things edge computing technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0039] Figure 1 It shows a schematic architecture diagram of an optional example for implementing the cloud-native edge container control system proposed in the present application;

[0040] Figure 2 It shows a schematic architecture diagram of another optional example for implementing the cloud-native edge container control system proposed in the present application;

[0041] Figure 3 It shows a schematic flow diagram of an optional example of the cloud-native edge container control method proposed in the present application;

[0042] Figure 4 It shows a schematic flow diagram of another optional example of the cloud-native edge container control method proposed in the present application;

[0043] Figure 5 It shows a schematic flow diagram of another optional example of the cloud-native edge container control method proposed in the present application;

[0044] Figure 6 It shows a schematic flow diagram of another optional example of the cloud-native edge container control method proposed in the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] As can be seen from the description in the background art section, in the Kubernetes environment, how to achieve the autonomy of IoT edge containers is an important research direction at present, especially for the autonomous management of edge containers such as maintaining edge services with network disconnection for industrial IoT edge containers, automatically reconnecting and restoring the network, and self-healing services for edge node or container restart. Therefore, the present application will fully consider the characteristics of edge computing, adopt cloud-native container technology, and fully combine cloud-native and edge computing to avoid the migration and reconstruction of pods on edge nodes caused by unreliable network connections between the cloud side and edge nodes, thereby improving the stability of business services on edge nodes and expanding the application scenarios of Kubernetes.

[0046] Based on this, in the embodiment of the present application, when the network state between the edge node and the cloud side is in an offline state, the cloud side can obtain preset events associated with the edge node, such as pod events, node events, network events, cluster security warning events, etc., to prevent the edge node from being evicted or rescheduled by the cluster; at the same time, the edge node can also perform distributed node health checks implemented by regions, and accordingly adopt corresponding processing rules, and can feedback the cached data stored previously to the business components in the edge node to ensure that the edge node can operate normally and improve the stability of the business services on the edge node.

[0047] Next, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0048] Refer to Figure 1 , to implement the architecture schematic diagram of an optional example of the cloud-native edge container control system proposed in the present application. In the embodiment of the present application, the system may be an Internet of Things system in a Kubernetes environment, which may be referred to as a Kubernetes cluster. It may use a C / S architecture for communication. The present application does not elaborate on its application scenario, the basic architecture of native cloud Kubernetes, and its working principle. This embodiment may describe the system structure related to how to implement the edge autonomy function of the system, but the entire system is not limited to the structure described in this embodiment. As Figure 1 shown, the system may include a cloud side 100 and an edge side 200. The cloud side 100 is configured with a Master node 110, and the edge side 200 is configured with multiple edge nodes 210. The present application does not limit the deployment method of the Master node 110 in the system, the deployment relationship between the multiple edge nodes 210, and the communication method between the cloud side and the edge side, etc., which can be determined according to the situation.

[0049] As Figure 1 shown, for each edge node 210 on the edge side, a proxy service (EC-ApiHub) component 211, a health check (EC-HealthCheck) component 212, a cache management (EC-CacheManager) component 213, and a cache database (LevelDB) 214, etc. may be configured, but not limited to Figure 1For the components shown above, according to the requirements of business services, the edge node can also be configured with corresponding business components, which can be determined in combination with, but not limited to, the edge network configuration of the Kubernetes cluster. This application will not elaborate on this here.

[0050] In the embodiments of this application, the above proxy service component 211 can be the core component for realizing edge autonomy. Essentially, it can be the proxy service of the traditional kube-apiserver component (which can be called the API service component) on the cloud side. For example, it can be a lightweight reverse proxy gateway with data caching capabilities. In this way, in the case of an abnormal disconnection of the communication network between the cloud side and the edge side, if the edge node on the edge side or the components it contains are restarted, the business components in this edge node can obtain the required business data from the proxy service component 211, effectively solving the problem of edge autonomy. The implementation can refer to, but is not limited to, the description of the corresponding part of the method embodiment below. This embodiment will not be elaborated here.

[0051] Among them, in actual applications, after the edge node is first started and enters the working state, the included proxy service component 211 can be initialized, and data such as the pod information, various k8s (i.e., Kubernetes) resource information, and network information of this edge node are submitted to the cache management component 213 for cache processing, and can also be persistently stored in the local cache database 214 as needed.

[0052] It can be seen that the cache management component 213 can be used to manage various cache data of the edge node (which can include, but is not limited to, the node full amount information, local network snapshot information, etc. listed above), and supports the cache management of request data for Kubernetes native components such as kubelet, kubeProxy, flanneld, coreDNS and other business components. These cache data can be persisted to local storage as needed.

[0053] The cache database 214 can be a data storage device for storing cache data. It can be the excellent local key-value database (key-value store) open-sourced by Google, that is, a non-relational database, which uses a simple key-value kv method to implement data storage. That is to say, each cache data sent by the cache management component 213 is stored as a set of key-value pairs, where the key is used as the unique identifier to query the corresponding data content. The embodiments of this application can adopt, but are not limited to, LevelDB as the cache database. It can adopt a single-process mode and, based on the LSM (Least Mean Square) algorithm, efficiently support the data storage of a data volume at the billion level. This application will not elaborate on the working principle of this type of database DB.

[0054] The health check component 212 can be used to monitor and detect the network status of the edge node, the running status of k8s components, the running status of business pods and services, etc., to sense the health status of the edge node, and send the health status to the proxy service component 211 on the edge node, so that the proxy service component 211 can perform preset operations accordingly to achieve the autonomy of the edge node.

[0055] Moreover, in the embodiments of the present application, the health check component 212 can support regional node health checks and can perform distributed node health checks in a voting election manner, such as implementing health checks on each edge node in the region, so that the proxy service component 211 of each edge node in the region can obtain multiple health check results for the edge node, and then use the voting election method to determine the target health check result of the edge node with more than half of the voting quantity, so as to improve the reliability of the edge node health check result.

[0056] It should be noted that for the proxy service (EC-ApiHub) component 211, health check (EC-HealthCheck) component 212, cache management (EC-CacheManager) component 213, and cache database (LevelDB) 214 configured on each edge node 210, in the actual application of Internet of Things edge container processing, the functions implemented by each component include but are not limited to the content described above, and the structural composition of the edge node 210 includes but is not limited to the components listed above, and may also include other business components according to application requirements.

[0057] Exemplarily, as Figure 2 shown, combined with the Kubernetes cluster structure, it can be seen that in each edge node on the edge side, in addition to the components listed above, it can also include Kubernetes native components, such as business components such as kubelet, kube-proxy, flanneld, coreDNS, etc., and multiple Pods created according to business service requirements, that is, the smallest / simplest basic unit created or deployed by Kubernetes. A Pod can represent a process running on the Kubernetes cluster. A Pod usually has an independent network IP address and policy options for managing and controlling the running mode of the container. The types and functions of the native components on the edge side in the Kubernetes cluster are not described in detail in this application.

[0058] Therefore, for any edge node recorded as the first edge node, the health check component can be used to sense the health status of the first edge node where it is located and support distributed health checks by region; the proxy service component can be used to reverse proxy network requests initiated by the business components of the first edge node where it is located, obtain the network status between the first edge node and the cloud side, and when it is determined that the network status of the first edge node is an offline state, call the health check component to perform a distributed health check to obtain the target health check result of the first edge node; the cache management component can be used to manage the cache data of the first edge node where it is located and send the cache data to the cache data for storage; the proxy service component is also used to respond to network requests based on the target health check result, call the cache management component to read the corresponding cache data stored in the cache database of the first edge node, and feedback the cache data to the corresponding business components, so that the corresponding business services of the first edge node can run normally. The implementation process can refer to but is not limited to the description of the corresponding part of the method embodiment below.

[0059] Combined with the above description, in the case of anomalies such as restart or network disconnection of the edge node, in order to avoid interruption or fluctuation of the business services of the edge node and ensure the normal operation of the business of the edge node, the proxy service component 211 can call the cache management component 213 to feedback the cache data of the corresponding business components stored in the cache database 214 to the business components for execution, so that the business components can run using the obtained cache data to meet the corresponding business service requirements. The implementation process can refer to but is not limited to the description of the corresponding part of the method embodiment below, and this embodiment will not be elaborated here.

[0060] Thus, it can be seen that in an edge-side computing environment with unstable network conditions, such as a pipeline monitoring system in a remote area, etc., this application can use the cache data cached by the cache management component or the data read from the cache database and feedback it to the corresponding business components to ensure that the edge node can continue to provide normal services externally. This application does not limit the service type and can be determined according to the situation.

[0061] For the Master node 110 of the cloud side 100, it is the control center of the Kubernetes cluster and realizes the control of each node in the entire system (which can include but is not limited to edge nodes). This application does not elaborate on the control function of the Master node 110 in the Kubernetes cluster. In the embodiment of this application, such as Figure 1As shown, a Node Management (EC-NodeManager) component 111 is configured on the Master node 110 to solve the problem of edge containers being evicted caused by unstable network connections between the cloud side and the edge side. Therefore, in the embodiment of this application, when the edge node on the edge side restarts or the network connection with the cloud side is disconnected, causing it to enter the offline state, the node management component 111 can obtain preset events for the edge node through the Webhook mechanism to prevent the edge node from being evicted (by the Kubernetes cluster) or rescheduled, resulting in the abnormal operation of the current business of the edge node.

[0062] Among them, the preset events can include but are not limited to pod events, node events, network events, cluster (which can be a Kubernetes cluster) security warning events, etc., and can be pre-configured according to the requirements of the application scenario. This application does not limit the types of preset events and their acquisition methods.

[0063] In practical applications, as Figure 2 shown, for the Master node 110 on the cloud side 100, it can also include native components of the Kubernetes cluster, such as the kube-apiserver component (i.e., the API service component), the kube-scheduler component (i.e., the scheduling component, which selects the most suitable node for each Pod in the list of Pods to be scheduled from the list of nodes through a scheduling algorithm), the kube-controller-manager component (i.e., the control management component, which runs various management controllers and is the background thread for handling routine tasks in the Kubernetes cluster), etcd (a distributed storage system), and other controller components. This application does not list them one by one here and can be determined according to the situation.

[0064] Under normal circumstances, for each network request sent by the edge side, it usually accesses the API service (kube-apiserver) component in the Master node 110 of the cloud side 100. The API service component sends the received network request to the corresponding component to meet the network request requirements of the edge side. It can be seen that kube-apiserver is the central hub for data interaction and communication between various functional modules (i.e., each component) within the Kubernetes cluster. It can use the HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer) secure transmission channel and the CA (Certificate Authority) signed digital authentication to enforce two-way authentication to ensure the security of kube-apiserver. The communication implementation process is not described in detail in this application. Therefore, as Figure 2 shown, other components on the cloud side listed above and the node management component 111 proposed in this application can all be connected to this API service component to achieve network communication with the edge side through this API service component. The implementation process is not described in detail in the embodiments of this application.

[0065] It should be understood that Figure 1 and Figure 2 the system structures shown do not constitute a limitation to the cloud-native edge container control system in the embodiments of this application. In practical applications, the cloud-native edge container control system may include more or fewer components than Figure 1 and Figure 2 shown. This application does not list them one by one here.

[0066] Combined with the cloud-native edge container control system shown above in Figure 1 and Figure 2 , and the technical solutions proposed in this application described above, the cloud-native edge container control method proposed in this application will be described in detail by way of examples below, but it is not limited to the technical solutions described in the following embodiments.

[0067] Referring to Figure 3 , which is a schematic flowchart of an optional example of the cloud-native edge container control method proposed in this application. This method can be applied to the cloud-native edge container control system. The embodiments of this application can describe the cloud-native edge container control method from the edge side of the system. As Figure 3 shown, this method may include:

[0068] Step S11, the business component of the first edge node on the edge side initiates a network request, and the proxy service component of the first edge node reverse-proxies the network request to obtain the network status between the first edge node and the cloud side;

[0069] Combined with the relevant descriptions of the system embodiments above, for any edge node in the edge side of the system, for the convenience of description, it can be denoted as the first edge node. Based on its native components, this application deploys components such as a proxy service (EC-ApiHub) component, a health check (EC-HealthCheck) component, a cache management (EC-CacheManager) component, and a cache database (LevelDB), etc., hoping that in the case of network anomalies of the first edge node, these components can be used to ensure the normal operation of the first edge node and avoid interruptions and fluctuations in the business services provided by it.

[0070] Therefore, during the operation of the first edge node, in the case of a network request initiated by business components such as kubelet, kubeProxy, flanneld, etc. on the first edge node, this application proposes that the network request is reverse-proxied to the listening port (such as port 10223) on the proxy service (EC-ApiHub) component and waits for the proxy service component to reply with a message.

[0071] At the same time, the proxy service component of the first edge node can also read the network status between the current first edge node and the cloud side, such as the online state indicating normal network communication between the first edge node and the cloud side; the offline state indicating that the network communication between the first edge node and the remote side is disconnected, etc. This application does not limit the method for obtaining this network status. This application does not limit the method for obtaining this network status.

[0072] In some embodiments, the health check component in the first edge node can be used to detect the health status of the first edge node and send the health status to the corresponding proxy service component, so that the proxy service component can determine the network status of the communication link between the first edge node and the cloud side based on the health status. However, it is not limited to the acquisition method described in this embodiment. The network status of the current first edge node can be determined directly by monitoring the working state of the communication link between the above listening port and the cloud side, whether it is connected or disconnected, etc. This application does not list them one by one.

[0073] In actual applications, when the first edge node is running for the first time, the proxy service component on the first edge node often needs to be initialized, such as List request node full information, local network snapshot information, etc., that is, the Pod information contained in the first edge node, various K8s resource information, various network information, etc. This application does not limit the data content required for the initialization of the proxy service component, which can be determined according to the situation. Afterwards, as analyzed above, the acquired data can be cached through the cache management component and persistently stored in the local cache database. The implementation process is not described in detail. Step S12, determine that the network status is offline, the proxy service component calls the health check component of the first edge node to perform a distributed health check, and obtains the target health check result of the first edge node;

[0074] In combination with the relevant description of the regional node health check in the edge node in the above embodiment, the present application can use voting to determine the health check result of the edge node based on the health check results of the same edge node by each health check component in the same area. That is, in the process of performing distributed health checks on the edge nodes in the same area, voting can be used. The present application does not describe in detail the implementation process of this distributed health check.

[0075] It should be noted that for different edge nodes in the same area, health checks can be performed using, but not limited to, preset monitoring and detection technical means. Exemplarily, other edge nodes can directly determine whether a certain edge node is healthy or exists based on the return information of the interface call by ping (a communication protocol) or a preset http interface, and send the obtained health check result to the edge node so that the edge node obtains multiple health check results, and then conducts a health vote on the edge node, and uses the health check result with more than 50% of the votes as the target health check result, but it is not limited to this implementation method.

[0076] Step S13, the proxy service component responds to the network request according to the target health check result, calls the cache management component of the first edge node, and reads the corresponding cache data stored in the cache database of the first edge node;

[0077] Step S14: the proxy service component feeds back the cached data to the corresponding service component of the first edge node, so that the corresponding service of the first edge node can operate normally.

[0078] In the embodiment of the present application, according to the above analysis, when the proxy service component of the first edge node determines that the health check of the first edge node passes, it can directly call the cache management component to read the cache data stored in the local cache and related to the business service running on the first edge node, so that the proxy service component can perform message response based on the read cache data, that is, respond to the network request reverse-proxied by the proxy service component, and feedback the cache data required by the business component that initiated the network request to the business component, meeting the business service operation requirements of the business component to ensure that the business service of the first edge node can run normally. The present application does not elaborate on the types of business services that the first edge node can run and their working principles.

[0079] It can be understood that for different types of business services, that is, different network requests sent by different business components, the business data they request is often different. When the proxy service component reads the cache data stored in the cache database through the cache management component, it can be determined based on but not limited to the content included in each network request of the reverse proxy. The present application does not elaborate on its implementation process. And in practical applications, according to the business service requirements, the proxy service component can also obtain the corresponding business data based on the obtained cache data and the request content of the corresponding network request, and then feedback it to the corresponding business component, etc. The present application does not limit this and can be determined according to the situation.

[0080] In summary, in the embodiment of the present application, for the network request initiated by the business component of any edge node on the edge side, that is, the first edge node, it can be reverse-proxied to the proxy service component of the first edge node. When the proxy service component determines that the network state between the first edge node and the cloud side is in an offline state, it will call the health check component of the first edge node to perform regional node health checks, reliably obtain the target health check result of the first edge node, and thus respond to the above reverse-proxied network request, call the cache management component of the first edge node, and be able to feedback the cache data of the first edge node to the corresponding business component, so that the corresponding business service requested by the first edge node can run normally. That is to say, in the case of network disconnection of the edge container, it has the edge autonomy function to maintain the stability of edge business services, expands the application scenario of Kubernetes, and effectively promotes the integration of cloud-native container technology and Internet of Things edge computing technology.

[0081] Refer to Figure 4 , which is a schematic flowchart of another optional example of the cloud-native edge container control method proposed by the present application. This embodiment can be an optional refined implementation method of the cloud-native edge container control method described above, but is not limited to this refined implementation method described in this embodiment. As Figure 4 shown, the method may include:

[0082] Step S21, the proxy service component of the first edge node reverse-proxies the network requests initiated by the service components of the first edge node.

[0083] Regarding how the proxy service component deployed for the first edge node reverse-proxies the network requests initiated by the service components in the first edge node on the cloud side, reference can be made to, but not limited to, the description of the corresponding part in the above embodiments, and this embodiment will not elaborate.

[0084] Step S22, when the proxy service component determines that the first edge node is in an offline state, it invokes the health check component of the first edge node and performs a distributed health check on the corresponding edge nodes in the first region where the first edge node is located according to the regional labels of each edge node on the edge side.

[0085] In some embodiments proposed in this application, in combination with the above description of the distributed health check on the edge side, after determining each edge node in the same region according to the regional identifier of the edge node, as Figure 2 shown, for multiple edge nodes in the same region, the health check can be performed by the health check components of other edge nodes. For example, the corresponding health check result can be obtained based on the feedback result of the interface call, etc. This health check result is recorded as the second health check result, and the health check result obtained by the health check component of the edge node itself when checking itself is recorded as the first health check result.

[0086] That is to say, the proxy service component invokes the health check component of the first edge node and performs a health check on the corresponding edge nodes in the first region where the first edge node is located according to the regional labels of each edge node on the edge side, and obtains the first health check result of the corresponding edge nodes; at the same time, the second health check result of the first edge node sent by the second edge node in the first region can be obtained; where the second edge node can refer to multiple edge nodes in the first region other than the first edge node, and the second health check result is obtained by the second edge node performing a health check on the first edge node based on a preset detection interface.

[0087] Therefore, for each edge node in the same region, multiple health check results can be obtained, that is, one first health check result and multiple second health check results. Then, the proxy service component can classify the first health check result and multiple second health check results of the first edge node through a voting and election method to obtain the target health check result of the first edge node, that is, the type of health check result with more categories is recorded as the target health check result, but not limited to the distributed health check method described in this embodiment.

[0088] It can be understood that the distributed health check described above is usually performed when the edge node is disconnected from the cloud side to improve the reliability and accuracy of the edge node health check results; when the network status is online, the above-mentioned distributed health check does not need to be performed, and the real-time monitoring of the health status of the edge node itself can be achieved directly based on the health check components configured by the edge node itself.

[0089] Step S23, whether the health check of the first edge node of the proxy service component passes, if not, proceed to step S24, if passed, execute step 25;

[0090] Step S24, the proxy service component adjusts the corresponding service model and / or service policy of the first edge node;

[0091] Following the above description, when the first edge node is disconnected from the cloud side and it is determined that its health check has not passed, the proxy service component of the first edge node can adjust its business model (i.e., a computing model based on artificial intelligence AI, etc.) and / or business strategy, such as data collection frequency, collection object, etc., to be applicable to the current operating state of the first edge node. This application does not limit the content of the configurable business model and business strategy in the edge node, which can be determined according to the circumstances.

[0092] Step S25, the proxy service component calls the cache management component of the first edge node, and receives the corresponding cache data read by the cache management component from the cache database of the first edge node;

[0093] Step S26, the proxy service component sends the received cache data to the corresponding service component in the first edge node;

[0094] Step S27, the service component of the first edge node executes the received cache data to enable the corresponding service of the first edge node to operate normally;

[0095] It can be seen that in the embodiment of the present application, when the first edge node is disconnected from the cloud side, in order to ensure the stability of the business services of the first edge node, a distributed health check method can be used to further and more accurately determine the health status of the first edge node. If its health check fails, its corresponding business model and business policy can be adjusted in time to be suitable for the current operating status of the first edge node. After that, the proxy service component of the first edge node calls the cache management component again to read the cache data stored in the local cache database that matches the network request, and feeds the cache data back to the business component that initiated the network request. The proxy service component implements a normal response to the response request to ensure the normal operation of the business services of the first edge node.

[0096] Step S28: The node management component of the Master node on the cloud side determines that the first edge node is in an offline state, and obtains a preset event for the first edge node through the Webhook mechanism to prevent the Pods built by the first edge node from being evicted or rescheduled.

[0097] In the embodiment of the present application, according to the method described above, it is determined that the network of the first edge node is unstable or even disconnected from the cloud side, that is, when it enters the offline state, it is unable to send network requests to the cloud side for response. It will respond to network requests using the cached data stored locally as described above to ensure the normal operation of the business services of the first edge node. At the same time, in order to avoid pod migration and reconstruction caused by unreliable cloud-edge networks, the node management (EC-NodeManager) component configured on the Master node on the cloud side can obtain preset events based on the Webhook mechanism, that is, events related to the first edge node, such as pod events, node events, network events, cluster security alert events, etc., to ensure the stability of the business services of the first edge node. The present application does not elaborate on the implementation process of how the node management component prevents the Pods of the first edge node from being evicted or rescheduled by the Kubernetes cluster, resulting in interruption or fluctuation of the business services of the first edge node.

[0098] Refer to Figure 5 , which is a schematic flowchart of another optional example of the cloud-native edge container control method proposed by the present application. Different from the implementation methods of how to achieve the autonomy of the first edge node when it is in an offline state described in the above embodiments, the embodiment of the present application can describe the implementation process of how to perform edge container autonomy and ensure the stability of edge services when the first edge node is in an online state, but is not limited to the implementation methods described in this embodiment. As Figure 5 shown, the method may include:

[0099] Step S31: The proxy service component of the first edge node reverse-proxies the network requests initiated by the business components of the first edge node;

[0100] Step S32: The proxy service component determines that the first edge node is in an online state, forwards the network request to the cloud side for processing, and receives the response data feedback by the cloud side in response to the network request;

[0101] Step S33: The proxy service component sends the response data to the cache management component for caching processing;

[0102] Step S34: The cache management component sends the cached response data to the cache database in the first edge node for updated storage.

[0103] In an embodiment of the present application, the network status between the edge side and the cloud side is monitored in the manner described above. For any edge node on the edge side, namely the first edge node, when it is determined that it is connected to the cloud side network, the network request of the reverse proxy can be forwarded to the cloud side for response. The response implementation process can be determined based on the content of the network request. The present application does not limit the implementation method of how the cloud side responds to the network request sent by the edge side.

[0104] Combined with the above Figure 2 As shown in the system structure diagram, the proxy service component of the first edge node can forward the network request to the kube-apiserver (i.e., API service component) on the cloud side, which forwards it to the corresponding control component on the cloud side, responds to the network request normally, responds to the message, obtains the corresponding response data, such as the message data, and feeds the response data back to the business component that initiated the network request through the proxy service component. At the same time, the proxy service component can also synchronously update the received response data to the local cache database for storage through the cache management component, and the implementation process is not described in detail in this application.

[0105] It can be understood that for the network requests reverse proxied by the proxy service component and the cache data generated in the process of forwarding them to the cloud side, the cache management component can also synchronously update and store them in the local cache database, so that the historical data of each business service can be obtained by querying the cache database later.

[0106] Optionally, in the application scenario of a Kubernetes cluster, you can use the access service provided by the LoadBalancer component in the Kubernetes cluster, that is, forward the network request to the cloud side through a configured independent network IP address, and receive the response data fed back by the cloud side, but it is not limited to this access service implementation method and can be determined according to the situation.

[0107] Reference Figure 6 , which is a flow chart of another optional example of the cloud native edge container control method proposed in this application. The embodiment of this application can describe how to perform edge container autonomy to ensure edge service stability when the first edge node is restarted due to abnormalities such as network instability, but is not limited to the implementation method described in this embodiment, such as Figure 6 As shown, the method may include:

[0108] Step S41, the proxy service component of the first edge node is initialized, and the cache management component is called to store the initialization data of the first edge node into the cache database of the first edge node;

[0109] When the first edge node runs for the first time, the configured proxy service component will be initialized. The implementation process is not elaborated in this application, and this application does not limit the content of the initialization data persisted in the cache database during the initialization process, including but not limited to node pod information, various k8s resource information, network information, etc., which can be determined according to the situation.

[0110] Step S42, the cache management component sends the network configuration information of each process running on the first edge node to the cache database for storage;

[0111] During the running process of the first edge node, network configuration information such as subnet segments, IP addresses, and MAC addresses responsible by the flannel process running on its host can be saved to the local cache database for subsequent calls. The storage method is not limited in this application.

[0112] Step S43, the health check component of the first edge node monitors the health status of the first edge node and sends the health status to the proxy service component;

[0113] Step S44, after determining that the first edge node has restarted based on the health status, the proxy service component calls the cache management component to prohibit updating the pod IP address and MAC address in the network configuration information stored in the cache database;

[0114] In the case of the first edge node restarting, such as the first edge node restarting or the components it contains restarting, its proxy responsible component collaborates with the cache management component to control the application Pod IP address and Pod Name on the first edge node to maintain the binding relationship unchanged, so that the Pod IP address will remain unchanged. At the same time, the MAC address of the network VTEP (flannel.1 virtual network card) of the first edge node and the node name (Node Name) maintain the binding relationship unchanged, that is, the MAC address of the VTEP remains unchanged. That is to say, the proxy responsible component collaborates with the cache management component to perform preset processing on the processes running on the first edge node to keep the Pod IP address and MAC address unchanged, so that the first edge node can still run the business service processes according to the corresponding relationship after restarting.

[0115] Step S45, the proxy service component adjusts the domain name resolution parameter of the preset business component in the first edge node to the private IP address of the first edge node, so that the restarted first edge node can implement domain name resolution and service call.

[0116] In the case where a first edge node undergoes a restart, its host can modify the local DNS (Domain Name Resolution) to deploy the coredns business component in the first edge node in the form of a DaemonSet (i.e., a type of main resource in K8S that can automatically install a preset application on all nodes in the K8S cluster for monitoring or collecting logs, etc., and the implementation method is not described in detail in this application), ensuring that the first edge node has an available coredns. At the same time, the startup parameter --cluster-dns (i.e., the domain name resolution parameter) of the kubelet business component on the first edge node can also be modified to point to the private IP of the first edge node host, so as to ensure that domain name resolution and service calls can still be performed after the first edge node is restarted after a network disconnection. The implementation process is not described in detail in this application.

[0117] This application also provides a computer-readable storage medium, on which a program is stored. When the program is executed by a processor, it implements the steps of the above cloud-native edge container control method, and the specific implementation process can refer to the description of the corresponding part of the above cloud-native edge container control method embodiment.

[0118] Finally, it should be noted that in the above embodiments, unless the context clearly indicates an exception, words such as "a", "an", "one", and / or "the" do not specifically refer to the singular, but may also include the plural. Generally speaking, the terms "include" and "comprise" only indicate the inclusion of the clearly identified steps and elements, and these steps and elements do not constitute an exclusive list. A method or device may also include other steps or elements. An element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, commodity, or device including the element.

[0119] Among them, in the description of the embodiments of this application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B; the "and / or" in this article is only a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "a plurality" means two or more than two.

[0120] Terms involved in this application such as "first", "second", etc. are only used for descriptive purposes, to distinguish one operation, unit, or module from another operation, unit, or module, and do not necessarily require or imply any such actual relationship or order between these units, operations, or modules. And it cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first", "second" may explicitly or implicitly include one or more of such features.

[0121] In addition, the various embodiments in this specification are described in a progressive or parallel manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts among the embodiments can be referred to each other. For the devices and computer equipment disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method section.

[0122] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cloud-native edge container control method, characterized in that, The method includes: A service component of a first edge node on the edge side initiates a network request, and a proxy service component of the first edge node reverse-proxies the network request to obtain the network status between the first edge node and the cloud side; When it is determined that the network status is an offline status, the proxy service component calls a health check component of the first edge node to perform a distributed health check to obtain a target health check result of the first edge node; The proxy service component responds to the network request according to the target health check result, calls a cache management component of the first edge node, and reads corresponding cache data stored in a cache database of the first edge node; The proxy service component feeds back the cache data to the corresponding service component, so that the corresponding service of the first edge node runs normally; The proxy service component calls a health check component of the first edge node to perform a distributed health check to obtain a target health check result of the first edge node, including: The proxy service component calls a health check component of the first edge node, and performs a health check on corresponding edge nodes within a first area where the first edge node is located according to area tags of each edge node on the edge side, to obtain a first health check result of the corresponding edge nodes; The proxy service component obtains a second health check result of the first edge node sent by a second edge node within the first area; the second edge node refers to multiple edge nodes other than the first edge node within the first area, and the second health check result is obtained by the second edge node performing a health check on the first edge node based on a preset detection interface; The proxy service component classifies the first health check result of the first edge node and multiple second health check results through a voting election method to obtain a target health check result of the first edge node.

2. The method according to claim 1, wherein The obtaining of the network status between the first edge node and the cloud side includes: a health check component of the first edge node monitors the health status of the first edge node and sends the monitored health status to the proxy service component; The proxy service component determines the network status of a communication link between the first edge node and the cloud side from the health status; the network status includes an online status and an offline status.

3. The method according to claim 1 or 2, characterized in that, The proxy service component responds to the network request according to the target health check result, calls a cache management component in the first edge node, and reads corresponding cache data stored in a cache database of the first edge node, including: If the target health check result is that the health check passes, the proxy service component calls a cache management component in the first edge node and reads corresponding cache data stored in a cache database of the first edge node; If the target health check result indicates that the health check fails, the proxy service component adjusts the corresponding service model and / or service policy of the first edge node and performs the steps where the proxy service component calls the cache management component in the first edge node to read the corresponding cached data stored in the cache database of the first edge node.

4. The method according to claim 1 or 2, characterized in that, The method further includes: When it is determined that the network status is the online state, the proxy service component forwards the network request to the cloud side for processing and receives the response data feedback by the cloud side in response to the network request. The proxy service component sends the response data to the cache management component for cache processing. The cache management component sends the cached response data to the cache database in the first edge node for updated storage.

5. The method according to claim 2, characterized in that, The method further includes: The cache management component of the first edge node sends the network configuration information of each process running on the first edge node to the cache database for storage. After it is determined that the first edge node restarts, the proxy service component of the first edge node calls the cache management component to prohibit updating the pod IP address and MAC address in the network configuration information stored in the cache database. The proxy service component adjusts the domain name resolution parameter of the preset service component in the first edge node to the private IP address of the first edge node, so that the restarted first edge node can implement domain name resolution and service invocation.

6. The method according to claim 5, characterized in that When the first edge node is in the offline state or restarted, the method further includes: The node management component of the Master node on the cloud side obtains a preset event for the first edge node through the Webhook mechanism to prevent the already constructed Pods of the first edge node from being evicted or rescheduled.

7. A cloud-native edge container control system, characterized in that, The system includes a cloud side and an edge side. The edge side is configured with multiple edge nodes, and each edge node is configured with a proxy service component, a health check component, a cache management component, and a cache database, where: The health check component is used to sense the health status of the first edge node where it is located and supports distributed health checks by region; the first edge node refers to any edge node on the edge side. The proxy service component is used to reverse proxy the network requests initiated by the service components of the first edge node where it is located, obtain the network status between the first edge node and the cloud side, and when it is determined that the network status of the first edge node is the offline state, call the health check component to perform a distributed health check to obtain the target health check result of the first edge node. The cache management component is used to manage the cached data of the first edge node where it is located and send the cached data to the cache data for storage. The proxy service component is further configured to respond to the network request according to the target health check result, call the cache management component to read the corresponding cache data stored in the cache database of the first edge node, and feedback the cache data to the corresponding service component, so that the corresponding service of the first edge node runs normally; The proxy service component is configured to call the health check component to perform distributed health checks to obtain the target health check result of the first edge node, including: The proxy service component is configured to call the health check component of the first edge node, and perform health checks on the corresponding edge nodes in the first area where the first edge node is located according to the area labels of the edge nodes on the edge side, so as to obtain the first health check result of the corresponding edge nodes; The proxy service component is further configured to obtain the second health check result of the first edge node sent by the second edge node in the first area; the second edge node refers to multiple edge nodes in the first area other than the first edge node, and the second health check result is the result obtained by the second edge node performing a health check on the first edge node based on a preset detection interface; The proxy service component is further configured to classify the first health check result of the first edge node and the multiple second health check results through a voting election method to obtain the target health check result of the first edge node.

8. The system according to claim 7, characterized in that A Master node is configured on the cloud side, and a node management component is configured on the Master node, where: The node management component is configured to, when there is an edge node that has been restarted or is in an offline state on the edge side, obtain a preset event for the edge node through a Webhook mechanism to prevent the Pods built by the edge node from being evicted or rescheduled.

9. A storage medium, on which a computer program is stored, characterized in that, The computer program is loaded and executed by a processor to implement the cloud-native edge container control method according to any one of claims 1-6.

Images