Edge node autonomy

A computer-implemented method, an apparatus, and a computer program product for edge node autonomy. For a first edge node of a plurality of edge nodes in a federation in a distributed computing framework, one or more processors receive a request to be sent to a central node in the distributed computing framework. The one or more processors determine whether the federation is connected to the central node. In response to determining that the federation is not connected to the central node, the one or more processors determine whether a controller capable of processing the request is available in the federation. In response to determining that the controller capable of processing the request is available in the federation, the one or more processors notify the controller to process the request.

BACKGROUND

The present invention relates generally to edge computing, and more particularly to edge node autonomy.

Edge computing involves a distributed computing framework that brings enterprise applications closer to data sources such as Internet of Things (IoT) devices or local edge servers. This proximity to data at its source can deliver strong business benefits: faster insights, improved response times, and better bandwidth availability.

Generally, the distributed computing framework may comprise a central node and a plurality of edge nodes. Each of the edge nodes may be interacted with the central node through a network connection to access data from the central node. As a result, the edge node may manage local containers on the edge node based on the accessed data. However, in a weak network environment, the edge node may be disconnected from the central node, such that local containers cannot work normally.

Patent application US20200402065A1 (Kapur, 2020) discloses a federated edge-node computing system which allows customers to work in offline mode (e.g., during a disaster). In patent publication CN112035215A (Zhang, 2020), the disclosure provides a node autonomous method, through which the disaster tolerance capability of the slave nodes can be improved, and the edge autonomy of the software container is realized. In patent publication CN113946408A (Zhu, 2022), the disclosure provides a cloud native edge container control method; under the condition that the edge container is disconnected in the network, the method has the edge autonomous function of maintaining the stability of the edge service. Patent publication CN112910981A (Wu, 2022) discloses a control method and a control device, by which the hosting edge node establishes communication connection with the offline edge node. However, none of the references discloses about federation autonomy for edge nodes.

SUMMARY

In one aspect, a computer-implemented method for edge node autonomy is provided. The method includes, for a first edge node of a plurality of edge nodes in a federation in a distributed computing framework, receiving, by one or more processors, a request to be sent to a central node in the distributed computing framework. The method further includes determining, by the one or more processors, whether the federation is connected to the central node. The method further includes, in response to determining that the federation is not connected to the central node, determining, by the one or more processors, whether a controller capable of processing the request is available in the federation. The method further includes, in response to determining that the controller capable of processing the request is available in the federation, notifying, by the one or more processors, the controller to process the request.

In the computer-implemented method, a plurality of customer resource definitions are installed in the first edge node, each of the plurality of controller resource definitions is associated with a controller arranged in the federation. For determining whether the controller capable of processing the request is available in the federation, the method further includes: identifying, by the one or more processors, a controller resource definition which is modified according to the request; determining, by the one or more processors, whether the controller resource definition is contained in the plurality of the customer resource definitions; and, in response to determining that the controller resource definition is contained in the plurality of the customer resource definitions, determining, by the one or more processors, that the controller capable of processing the request is available in the federation. For determining the controller in the federation, the method further includes determining, by the one or more processors, a controller associated with the controller resource definition as the controller capable of processing the request.

In the computer-implemented method, the first edge node comprises a message queuing telemetry transport (MQTT) module. The method further includes: during a disconnection period in which the federation is not connected to the central node, receiving, by the one or more processors, a plurality of requests in sequence; pushing, by the one or more processors, the plurality of the requests into the MQTT module in sequence; in response to a reconnection between the federation and the central node after the disconnection period, sending, by the one or more processors, the plurality of the requests in the MQTT module to the central node in sequence.

In the computer-implemented method, the first edge node is connected to the central node via a network connection, and each of other edge nodes in the federation is configured with configuration data of the first edge node. In the method, a second edge node is joined into the federation by: sending a joining request to the central node, receiving from the central node a list of edge nodes connected to the central node, selecting one of the edge nodes from the list, and resetting configuration data with configuration data of the one of the edge nodes, such that the second edge node is joined into the federation comprising the one of the edge nodes.

The method further includes determining, by the one or more processors, whether the first edge node is connected to the central node. The method further includes, in response to determining that the first edge node is not connected to the central node, determining, by the one or more processors, whether there are one or more edge nodes capable of connecting to the central node in the federation. The method further includes, in response to determining that there are the one or more edge nodes capable of connecting to the central node in the federation, causing, by the one or more processors, one of the one or more edge nodes to connect to the central node such that the federation is connected to the central node. In the method, data stored in the first edge node are synchronized to the one of the one or more edge nodes.

In another aspect, an apparatus for edge node autonomy is provided. The apparatus comprises one or more processors, one or more computer readable tangible storage devices, and program instructions stored on at least one of the one or more computer readable tangible storage devices for execution by at least one of the one or more processors. The program instructions are executable to: for a first edge node of a plurality of edge nodes in a federation in a distributed computing framework, receive a request to be sent to a central node in the distributed computing framework; determine whether the federation is connected to the central node; in response to determining that the federation is not connected to the central node, determine whether a controller capable of processing the request is available in the federation; and in response to determining that the controller capable of processing the request is available in the federation, notify the controller to process the request.

In yet another aspect, a computer program product for edge node autonomy is provided. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, and the program instructions are executable by one or more processors. The program instructions are executable to, for a first edge node of a plurality of edge nodes in a federation in a distributed computing framework, receive a request to be sent to a central node in the distributed computing framework. The program instructions are further executable to determine whether the federation is connected to the central node. The program instructions are further executable to, in response to determining that the federation is not connected to the central node, determine whether a controller capable of processing the request is available in the federation. The program instructions are further executable to, in response to determining that the controller capable of processing the request is available in the federation, notify the controller to process the request.

DETAILED DESCRIPTION

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

In a distributed computing frame, if an edge node is under a weak network environment, it may be disconnected from the central node. In such circumstances, an autonomy method for the edge node may be implemented, such that local containers on the edge node can still work normally. Thus, the edge node may become an autonomy area. However, resources on the autonomy area may be limited.

In some embodiments of the present disclosure, two or more edge nodes may be connected together to form an autonomy federation. Compared with the autonomy area described above, the autonomy federation may be more robust, as more resources may be employed by the respective edge nodes. The autonomy federation may be described below in connection with a distributed computing frame according to embodiments of the present disclosure.

FIG.4depicts a schematic block diagram of a distributed computing framework400according to embodiments of the present disclosure.

As shown inFIG.4, the distributed computing framework400comprises a central node410and a plurality of federations, such as a first federation420, a second federation430, a third federation440, and/or the like. For example, the first federation420may comprise the edge node422and edge node424. The second federation430may comprise edge node432, edge node434, and edge node436. The third federation440may comprise edge node442and edge node444. It can be noted that, the number of edge nodes in each federation may be varied based on actual needs, and not be limited herein.

In some embodiments, the central node410may be a cloud computing node, for example, the cloud computing node10shown inFIG.1. Moreover, the central node410may be provided with an Application Programming Interface (API) server, for example, a Kubernetes API server (KAS)412. The KAS412may be a hub for data interaction and communication in the distributed computing framework400. Thus, the respective federations may interact with the KAS412to access data in the central node.

The respective federations may comprise a number of edge nodes. In some embodiments, the edge nodes may be federated based on certain rules. For example, in each federation, the edge nodes may be located in a predetermined region (or zone). Moreover, the edge nodes may also be arranged in the same federation based on user preference.

Typically, within the federation, the respective edge nodes may be connected under a same local area network. Thus, the respective edge nodes may communicate to each other via an internal network. In some embodiments, each of the edge nodes may be a local computing device, and for example, may be implemented with the computer system/server12shown inFIG.1.

In some embodiments, the edge nodes in each federation may be configured with a role, for example, a main or a sub. Specifically, there may be only one master edge node (also can be referred to as a first edge node), and other edge nodes besides the main edge node may be sub edge nodes (also can be referred to as second edge nodes). The main edge node (for example, the edge node422, edge node432, and edge node442) may be connected to the central node410directly via a network connection, for example, via a public network. In some embodiments, the main edge node may be provided with a proxy. The proxy may be implemented with a lite KAS, which may be used to communicate to the KAS412. Specific details for the lite KAS may be described hereinafter, for example, with respect to a lite KAS5102inFIG.5.

Generally, the sub edge nodes may not be connected to the central node directly, though some of them may have the ability to connect to the central node. In some embodiments, the sub edge nodes (for example, the edge node424, edge node434, edge node436, and edge node444) may be communicated with the main edge node, for example, through internal networks. Then, the respective sub edge node may access to the proxy (e.g., the lite KAS) of the main edge node in the federation, and communicate with the central node410via the proxy of the main edge node.

As some of the sub edge nodes may have the ability to connect with the central node, the federation may employ such sub edge node to connect to the central node, if the main edge node is disconnected to the central node. It can be noted that, the disconnection may indicate that the network therebetween is unstable or completely broken. In some embodiments, the role of the edge nodes may be changed. For example, one of the sub edge nodes capable of connecting to the central node may be switched to the main edge node, while the original main edge node may be switched to the sub edge node. In this way, the network between the federation (i.e., the new main edge node) and the central node may be maintained, thereby improving the robustness of the federation. Meanwhile, the autonomy may not occur. Detail descriptions will be described hereinafter.

In some embodiments, the edge node which firstly existed in the federation may be configured as the main edge node. It can be understood that the main edge node may also be determined based on other strategies, for example, network signal strength.

It can be understood that, the central node410may also be connected to an individual edge node, besides the federations.

FIG.5depicts a schematic block diagram of a federation500in a distributed computing framework according to embodiments of the present disclosure. For example, the federation500may be implemented as the federation420, federation430, and federation440inFIG.4.

As shown inFIG.5, the federation500comprises a main edge node510and one or more sub edge nodes, for example, a sub edge node520. It can be understood that, the main edge node510may be similar as the edge node422, edge node432, and edge node442, and the sub edge node520may be similar as the edge node424, edge node434, edge node436, and edge node444. Thus, repeated descriptions will be omitted.

As shown inFIG.5, the main edge node510may comprise a lite KAS5102, a cache5104, a Message Queuing Telemetry Transport (MQTT) module5106, one or more components (such as, KUBELET, pod)5108, one or more controllers5110, and/or the like. The sub edge node520may comprise a lite KAS5202, a cache5204, a MQTT module5206, one or more components (such as, KUBELET, pod)5208, one or more controllers5210, and/or the like. Arrow lines are shown to present connections between certain means.

In some embodiment, the lite KAS5102is a lightweight API server running on the main edge node510. When a network connection between the central node (for example, the central node410) and the main edge node is normal (also referred to as a normal scenario), the lite KAS5102functions as a proxy for all requests to the central KAS412from the components (for example, the component5108and the component5208) running on the edge nodes (the main edge node510and the sub edge node520) in the federation. That is, the sub edge node520may also use the lite KAS5102as the proxy (for example, by setting its configuration data with configuration data of the lite KAS5102).

On the other hand, when the network connection is unstable or broken (also referred to as an autonomy scenario), the lite KAS5102may become a function limited KAS. Specific details will be described below.

The cache5104may comprise an etcd, which is an open source distributed key-value store used to hold and manage the critical information that the distributed computing framework need to keep running. For example, the etcd may store cluster configuration and state data, such as the number of pods, their state, namespace, etc. It may also store the Kubernetes API objects and service discovery details.

In some instances, the cache5104may store the data (for example, a response) which is received by the lite KAS5102from the central node (for example, the KAS412) when the network connection is normal. In some embodiments, such data may be used by the lite KAS5102for generating response to requests, such as QUERY request, when the network connection is broken.

Moreover, the data stored in the cache5104of the main edge node510may be synchronized to the cache5204of the sub edge node520. Thus, the sub edge node520may potentially be the main edge node. As described above, the role of the edge nodes in the same federation may be switched. For example, if the main edge node5102is disconnected to the central node, the lite KAS5102may determine whether there is a sub edge node capable of connecting to the central node. If the lite KAS5102determines the sub edge node520is able to connect to the central node, and all critical information stored in the cache5104are synchronized to the cache5204, the sub edge node520may be switched to be the main edge node, while the main edge node510may be switched to be the sub edge node. In such case, the lite KAS5202may be the new proxy for the edge nodes in the federation520, such that it can perform the same operations as the lite KAS5102originally did, as described above. In some embodiments, the switching of roles may be achieved by amending the configuration data (for example, KUBECONFIG) for each edge node. For example, the IP address of proxy, which is originally pointing to the lite KAS5102, for each edge node may be reset to the IP address of the lite KAS5202.

Moreover, the cache5204is similar as the cache5104. Repeated descriptions will be omitted for brevity. The data stored in the cache5204may also be synchronized to the cache5104.

In the main edge node, the Message Queuing Telemetry Transport (MQTT) module5106may be implemented with a message queueing telemetry transport protocol. In the autonomy scenario, the lite KAS5102may receive a plurality of requests sequentially, for example, from the component5108and component5208. The lite KAS5102may push the received requests into the MQTT module5106by order. When the network connection restores, the lite KAS5102may send the requests in the MQTT module5102to the central KAS by order. Thus, it is benefit for maintaining the sequence of the requests.

It can be noted that the MQTT module5206of the sub edge node520may also be used when the sub edge node520is switched to function as the main edge node. Similar description may be omitted herein.

Furthermore, the component5108and component5208may be the KUBELET or any pod running an application or microservice. The component5108(or component5208) may send a request, which may be received and/or identified by the lite KAS5102. The lite KAS5102may redirect the request to the KAS412(shown inFIG.4) to obtain a response. The component5108(or component5208) may then receive the response from the lite KAS5102. In some embodiments, the request may cause a Customer Resource Definition (CRD) in the component5108(and/or component5208) modified.

The controller5110(and/or controller5210) may be also referred to as a customer controller, which may be implemented as a function plug-in. The customer controller may manage a customer resource, for example, update a state of the customer resource to a desired state, and then maintain and change the state by a sequence of operations. The customer resource may be an object described/defined by a Customer Resource Definition (CRD). That is, the customer controller may provide management to the object of the CRD. In some embodiments, the CRDs associated with the controllers deployed in the edge nodes in the federation may be stored/installed in the lite KAS5102.

Moreover, in the autonomy scenario, the lite KAS5102may determine whether the modified CRD (due to a request) in the component is contained in the installed CRDs, so as to determine whether there is a controller capable of processing the request available in the federation. Thus, the request may be processed by the corresponding controller without connecting to the central node, such that a federation autonomy may be implemented. The request may comprise CREATE, DELETE, UPDATE, and/or the like.

Embodiments of the present disclosure may also provide a method for an edge node joining into a federation according to embodiments of the present disclosure.FIG.6depicts an illustrative process600of an edge node joining into a federation according to embodiments of the present disclosure.

As shown inFIG.6, for example, a first edge node602may send a joining request to the central KAS (for example, KAS412shown inFIG.4) on the central node604(for example, the central node410shown inFIG.4) at operation610. The central KAS on the central node604may send a list of existed edge nodes (i.e., the main edge nodes, for example, the main edge node510shown inFIG.5) connected to the central node604and an IP addresses of the corresponding lite KAS (for example, the lite KAS5102shown inFIG.5), to the first edge node602at operation620. Accordingly, the first edge node602may receive the list from the central node604.

At operation630, the first edge node602may choose one edge node (i.e., the second edge node606(for example, the main edge node510shown inFIG.5) from the list by some strategy, for example, based on region, zone, user preference, and/or the like, so as to join the federation comprising the second edge node606. In this case, the first edge node602may reset its configuration data with the IP address of the lite KAS of the second edge node606. Therefore, the lite KAS of the second edge node606may function as the proxy for the first edge node602. As a result, the first edge node602joins into the federation in which the second edge node606is the main edge node. It can be understood that, the first edge node602may become the sub edge node in the federation.

Thus, the first edge node602may connect to the second edge node606at operation640. In this situation, the first edge node602and the second edge node606may share data.

It can be appreciated that, the above process may also be implemented for establishing a federation. For example, in a case that the second edge node606is individually connected to the central node604without being federated with other edge nodes, a federation may be established to include both the first edge node602and the second edge node606, after that the first edge node602resets its IP address of proxy to an IP address of a lite KAS of the second edge node606.

Moreover, after the first edge node602joined, the second edge node606may determine/identify the controllers deployed in the first edge node602, for example, by detecting list/watch links. Each of the controllers may manage a customer resource, and may then be associated with a customer resource definition of the corresponding customer resource (i.e., CRD). In some embodiments, the second edge node606(for example, the lite KAS thereof) may install the CRDs related to the controllers. The installed CRDs may then be used for determining whether the federation autonomy may be implemented successfully. Detailed processes will be described below.

Furthermore, after the first edge node602joined the federation, data stored on the second edge node606may be synchronized to the first edge node602, such that, the first edge node602may potentially become the main edge node to replace the second edge node606in certain circumstances.

As described above, the network connection between the main edge node and the central node may be unstable, or even broken. Embodiments of the present disclosure further provides a method for autonomy of edge nodes in the federation.

FIG.7depicts an illustrative flowchart diagram of a method700for autonomy of edge nodes in a federation (for example, the federation420, federation430, federation440, or federation500, shown inFIG.4andFIG.5) in a distributed computing framework (for example, the distributed computing framework400shown inFIG.4) according to embodiments of the present disclosure.

In some embodiments, the method700may be implemented by a computing device, for example, the computer system/server12shown inFIG.1. Specifically, the method700may be implemented by a lite API server (for example, the KAS5102shown inFIG.5) of a master edge node (for example, the main edge node510shown inFIG.5).

At step710, the lite KAS of the main edge node (referred to as a main lite KAS hereinafter) receives a request to be sent to the central node.

In some embodiments, the request may be sent, for example, from a component on one of the edge nodes (i.e., the main edge node and the sub edge nodes) in the federation. In some embodiments, the request may be related to a function, such as, GET, CREATE, UPDATE, DELETE, and/or the like.

At step720, the main lite KAS determines whether the federation is connected to the central node.

In some embodiments, the main lite KAS may determine whether the main edge node is connected to the central node. In response to a connection between the main edge node and the central edge node (such situation may also be referred to as a normal scenario), the main lite KAS may determine the federation is connected to the central node. In such cases, the main lite KAS may send the request to the central node and receive a response from the central node accordingly. Further, the main lite KAS may send the response back to the component sending the request at step710.

Specifically, in the normal scenario, the main lite KAS may function as a proxy for redirecting the request from the component on the edge nodes to the KAS on the central node, and return the response to the component. Therefore, an application or microservice may operate in the component (for example, a container in a pod) according to the response. Moreover, the main lite KAS may cache the response, which may then be used for a future request (for example, a QUERY request, such as a GET function) when the connection is broken (i.e., in an autonomy scenario).

In some other embodiments, if the main lite KAS determines that the main edge node is disconnected to the central node, it can further determine whether there are one or more other edge nodes (sub edge nodes) capable of connecting to the central node in the federation. If so, the main lite KAS may cause one of the one or more edge nodes capable of connecting to the central node to connect to the central node. Therefore, the main lite KAS may further determine that the federation is still connected to the central node. In some embodiments, the sub edge node caused to connect to the central node may be selected by the main lite KAS based on certain rules, for example, a network signal strength. Accordingly, such sub edge node may become the main edge node, while the original main edge node may become the sub edge node in the federation. In this way, the federation may still connect to the central node via the new main edge node, and the normal scenario may maintain.

Moreover, data stored in the original main edge node may be synchronized to the sub edge nodes in advance, typically when the sub edge node is caused to connect to the central node.

On the other hand, if the main edge node determines that there is no edge node capable of connecting to the central node, it may determine that the federation is disconnected to the central node. Thus, an autonomy scenario may occur. That is, only if none of the edge nodes in the federation could be connected to the central node, the federation enters the autonomy scenario.

At step730, in response to determining the federation is disconnected to the central node, the lite KAS determines whether a controller capable of processing the request is available in the federation.

In some embodiments, the main lite KAS may identify a customer resource definition which is modified according to the request. Specifically, the etcd stored in the cache of the main edge node may be changed when the CRD is modified in the component. As described above, a plurality of CRDs, each associated with a controller in the federation, may be installed in the main lite KAS. Thus, the main lite KAS may determine whether the identified customer resource definition is contained in the installed customer resource definitions.

In response to determining that the identified customer resource definition is contained in the installed customer resource definitions, the main lite KAS may determine the controller is available in the federation. In some embodiments, the controller capable of processing the request is the controller associated with the identified customer resource definition.

At step740, in response to determining the controller capable of processing the request is available in the federation, the main lite KAS determines the controller and notifies the controller to process the request.

In some embodiments, the controller may be determined based on the identified customer resource definition. For example, the main lite KAS may determine a controller associated with the first customer resource definition as the controller capable of processing the request.

Otherwise, if the identified customer resource definition is not contained in the installed customer resource definitions, the main lite KAS may determine the controller capable of processing the request is not available in the federation.

In some further embodiments, the main lite KAS may receive the response from the controller, and send the response to the components. Thus, the application/service may be running in the component based on the response.

Moreover, the request processed by the controller may be a function of CREATE, DELETE, UPDATE, and/or the like. If the request is a query request (GET), the main lite KAS may handle the request based on data stored in the cache of the edge node (for example, the main edge node), in the autonomy scenario.

In further embodiments, a plurality of requests may be received during the autonomy scenario. The main lite KAS may push the requests into a MQTT module in the main edge node, for example, besides the query requests, in sequence. Thus, all of the requests (except the query requests) received by the lite KAS in the autonomy scenario may be recorded in the MQTT module.

Furthermore, after the federation and the central node are reconnected, the main lite KAS may send the requests in the MQTT module to the central node (for example, the KAS) by order.

Normally, when the connection restores, the KAS on the central node may notify the federation (typically, the main edge node) to change state of objects to maintain state consistence. However, as the etcd is already modified during the autonomy scenario based on the request, there is no need to perform the notification. Thus, the main lite KAS may block such notifications, and thus not notify the etcd to change for the requests processed in the autonomy scenario, thereby avoiding duplicating.

Now, description will be provided with respect to a process800in a federation (such as the federation500shown inFIG.5) in a distributed computing framework (such as the distributed computing framework400shown inFIG.4) as shown inFIG.8. The process800may be implemented by a lite KAS (such as the lite KAS5102shown inFIG.5, and also referred to as a main lite KAS) of a main edge node in a federation. In some embodiments, the process800may be performed to realize the method inFIG.7.

In some embodiments, the main lite KAS listens to ports of components on edge nodes in the federation. Thus, a request from one of the components in the federation may be passed to the main lite KAS. At step810, the main lite KAS receives the request to be sent to the KAS on the central node (referred to as the central KAS) from one of the components in the federation. At step820, the main lite KAS sends the request to the central KAS.

The main lite KAS determines whether the federation is connected to the central node, at step830. If so, the central KAS returns a corresponding response to the main lite KAS. Thus, the process continues at step832, where the main lite KAS receives the response from the central KAS. At step834, the main lite KAS sends the response to the component sending the request. Thus, the component runs the application or microservice based on the response normally.

On the other hand, if the federation is disconnected from the central node, the process continues at step840, where the main lite KAS determines whether related controller is available in the federation. Specific determination process may be implemented based on the above description with respect toFIG.7. If the related controller is available in the federation, at step842, the main lite KAS determines the controller capable of processing the request. At step844, the main lite KAS notifies the controller to process the request. Accordingly, the determined controller processes the request with related logics.

If the related controller is not available in the federation, the request is failed. The main lite KAS returns a failure response to the component sending the request, at step850.

Further, in order to improve robustness of the federation, embodiments also provide another process900in a federation (such as the federation500shown inFIG.5) in a distributed computing framework (such as the distributed computing framework400shown inFIG.4) as shown inFIG.9. The process900may be implemented by a lite KAS (such as the lite KAS5102shown inFIG.5, and also referred to as a main lite KAS) of a main edge node in a federation. In some embodiments, the process900may be performed to realize the method inFIG.7.

It can be noted that the process900is similar with the process800shown inFIG.8. Like number denotes like step. Thus, description will be given for only the different parts.

After processing the step820, at step910, the main lite KAS determines whether the main edge node is connected to the central node. If yes, the process900continues at step832.

Otherwise, if the main edge node is disconnected from the central node, the process continues at step920, where the main lite KAS determines whether there is another edge node (sub edge node) in the federation capable of connecting to the central node. If so, at step922, the main lite KAS causes such sub edge node to connect to the central node, such that the sub edge node may become the main edge node of the federation while the original main edge node may become the sub edge node. Accordingly, the federation may be still connected to the central node, the process may be continued at step832.

Moreover, if none of the edge nodes is capable of connecting to the central node, the process goes to step840. Descriptions for similar operations may be omitted herein for brevity.

According to embodiments of the present disclosure, a federation autonomy method may be provided. The federated edge nodes may provide abundant resources, which may improve stableness and robustness of the federation. It is especially benefit to the requests with value changing, such as CREATE, DELETE, UPDATE, and/or the like. Moreover, as the MQTT module is implemented, the sequences of the requests sent during the autonomy scenario may be maintained after the connection is restored.

Additionally, in some embodiments of the present disclosure, an apparatus for autonomy of edge nodes may be provided in a distributed computing framework comprising a central node and a plurality of federations. Each of the federations may comprise a plurality of edge nodes. The apparatus may be arranged in a main edge node of plurality of edge nodes and comprise one or more processors, a memory coupled to at least one of the one or more processors, and a set of computer program instructions stored in the memory. The set of computer program instructions may be executed by at least one of one or more processors to perform the above method.

In some other embodiments of the present disclosure, a computer program product for autonomy of edge nodes may be provided in a distributed computing framework comprising a central node and a plurality of federations. Each of the federations may comprise a plurality of edge nodes. The computer program product may be arranged in a main edge node of the plurality of edge nodes and comprise a computer readable storage medium having program instructions embodied therewith. The program instructions executable by one or more processors causes the processor to perform the above method.