## 4 Results  
This section explains how the proposed architecture and application management hierarchy are implemented in Kubernetes utilizing the materials and methods presented in the previous section, resulting in an application-aware orchestration platform, which is also OpenFog compliant. The set of components detailed in this section comprise the Supervision Infrastructure Components of the platform. They manage the resources that are dynamically created and decommissioned in the system. Kubernetes states that _\"Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of Pods\"_[34]. These Pods are then managed by the so-called workload resources that manage sets of Pods. These workload resources establish controllers and behaviors additional to those provided by Kubernetes that can be implemented by using CRDs. Therefore, to include Kubernetes at all levels of the application structure, i.e., every level of the HAMS as well as the two levels identified for DAGs, we propose to implement a CRD, a controller and the necessary access control files for each of the levels. The CRD is a generic definition or meta model of a type of resource. It is written in YAML (a subset of JSON) and its structure is pre-established by Kubernetes, divided into different sections: apiVersion, Kind, metadata, spec and status. The most important section is the spec field (see Figure 11). It defines the structure that every instantiated CR must follow based on its related CRD. It is divided into two subsections, namely spec and status. The spec subsection is generated based on the openAPIv3 specification. It is separated into optional and required fields, which are checked by Kubernetes against the CRD when a related CR is instantiated. The status subsection is used to store state information of the resources so the controllers can compare the actual status of the deployed object and the desired state stored as a specification in the spec section. The status subsection must be enabled in the subresources section. In addition, AdditionalPrinterColumns are used to determine the field parameters when utilizing the CLI to interact with the object, providing additional information about the state of the resources to the cluster administrator. Additionally, it is compulsory to define the names used to interact with the instantiated CRs by the users from the CLI or by Kubernetes itself, in the names subsection. Each CRD is accompanied by a controller, implementing the operator concept and achieving a fully declarative API. Each controller, acting as a Supervision Infrastructure Component, has been designed to manage the resources of its level during their lifecycle and to create and decommission the resources of its lower level. The state machine in Figure 12 depicts the lifecycle proposed for a controller at any application structure level. When the controller is initiated, it transitions to the Starting state in which the controller reads the cluster configuration and connects to the Kubernetes API as a client. When the controller is started, i.e., the client is created, it transitions to the Running state. Here, the controller activates a watcher that must be aware of the resources of its level and the events they generate to process them. Events represent the change in the state of a certain resource inside the cluster. Our controllers distinguish three Kubernetes event types: added,  
Figure 10: Additional asset added in the assembly line. The component _Process_ is used in both Processing applications. modified and deleted. The watcher has been designed to process them through several functions (right part of Figure 12):  
* _Added events_ represent events related to a resource that has been instantiated for the first time in the system. The resource is passed to the _Create Lower Resources()_ function, which instantiates the individual resources that compose the newly instantiated CR. * _Modified events_ reflect that the related resource has been somehow modified.