## 2 Related Work
### Kubernetes Extensions  
The management of applications or their components in distributed environments such as the Fog has been discussed in Section 1. Kubernetes is the leading tool when it comes to container orchestration. As such, many authors inspect the capabilities that Kubernetes offers when considering its extension to accommodate any custom logic that might want to be implemented in the orchestrator. KubeEdge [25] is an Edge infrastructure built on top of Kubernetes that aims to provide RPC-based communications between microservices deployed at the Edge and the Cloud. A Kubernetes controller is deployed on the Cloud (_EdgeController_) to remotely manage edge nodes, and to allow remote deployment on the Edge from the Cloud. The state of the cluster is synced between the Cloud and the Edge through a sync service and the workloads are managed by a _EdgeCore_ agent running on the Edge nodes. The authors in [12] proposed a hierarchical Kubernetes extension (_Me-kube_) to manage the elasticity of microservice-based applications. Their approach is based on Monitor, Analyze, Plan and Execute (MAPE) control loops: one MAPE loop for each microservice, acting as a Microservice Manager, and one loop for each application, acting as an Application Manager. This allows for the definition of global policies for the management of Applications and different local policies for their microservices. Application Managers determinethe scaling actions to be implemented based on microservice metrics and communicate decisions to the Microservice Managers that execute decisions through the Kubernetes API. The work in [26] presented a Kubernetes controller (High Availability State Controller) to address availability issues that emerge with the default high availability Kubernetes services to restore Pods. The controller reacts to Pod scaling events and selects an active Pod in charge of providing a certain service, while another Pod is identified as a standby Pod, aware of the active's state and ready to intervene given that the active Pod fails. In [27], the authors utilized Kubernetes extensions to introduce a new concept (_Dataset_) on Kubernetes, managed by the _Datashim_ framework. The Dataset is implemented as a Custom Resource Definition (CRD), and each of these resources acts as a pointer to some data source implemented as a Persistent Volume Claim. They construct a Dataset operator to manage the Dataset resources using the operator-sdk toolkit. This controller then creates a Persistent Volume Claim and a Secret for every Dataset resource. The authors in [28] presented a management model for the Cloud Native Network Function. The Kubernetes Master Node is extended with a Network Management Controller (a Kubernetes controller) and a Network Management Resource Definition component (a Kubernetes CRD). Kubernetes Worker Nodes, on the other hand, are extended through the _sidear_ concept where two containers are deployed inside a Pod, one of them acts as a proxy (Management Agent) while the other container implements the application logic. The authors of ACOA [13] implemented their generic architecture over Kubernetes, utilizing the standard Kubernetes extension methods. They implemented an Application Controller and a Component Controller to manage applications and components, enabling an application-centric scheduling approach. The work in [21] presented the _orcon_ orchestrator, built as a Kubernetes extension. They introduced the concepts of relationships, interfaces and roles to the Kubernetes API, implemented as annotations in Kubernetes objects to which orcon services react. To extend the definition of the roles, two CRDs are implemented: ProviderConfig and ConsumerConfig. These resources are managed by the Relations Controller, implementing the Kubernetes Controller pattern. Other works such as [20; 29; 30; 31; 32; 33] developed different Kubernetes scheduler extensions, by modifying one of the tasks of the scheduler or even entirely replacing it.