## 4 Results
### DAG Levels
#### 4.1.2 Application Level  
The upper level refers to the DAG elements. Figure A3, shown in Appendix A, shows how the generic CRD (see Figure 11) is customized for the application resources. In contrast to components, the fields that define an application's spec are all required:  
* name: Name of the application resource. It must be unique in the system and, thus, they are named as a composition of the upper resource name and the application name. * components: As applications are composed of a set of components, this field is an array of component definitions that follow the specification shown in Figure A2. * replicas: The purpose of this field is to specify the number of active replicas desired for a given application. This is then translated into as many components as the number of replicas desired. * deploy: This parameter is used to indicate whether to deploy the application as soon as the resource is declared on Kubernetes or whether to store the application resource defined and decide afterward to deploy the application. It is useful to define several applications in the cluster that are expected to be run afterward. As for the status subsection, it is used to track the actual state of the application resources and is divided into several fields as follows:
* replicas: This field is used to track the number of application replicas that are running at a given time. * components: Used to track the status of the different components that form the application. For each component, its name and its situation, specifically, the status.situation of the component, are stored. The Application controller reacts to the change in its component's status and accordingly updates the whole application's status. * ready: It is an enumerated parameter that stores the actual application state (deploying or running). When all the components that form an application transition to a running state, this parameter is changed from deploying to running. The sequence diagram in Figure 13 illustrates the high-level interactions between the two DAG level controllers (management plane) and the Kubernetes control plane elements. The initial state is a Kubernetes cluster that has been extended by deploying the Application and Component CRDs, the ServiceAccounts, ClusterRoles and ClusterRoleBindings and the Application and Component Controllers (which are already in their Running states). Our controllers are highlighted in blue to distinguish them from the Kubernetes control plane elements. The overall sequence diagram can be divided into three sections that are coherent with the functions presented in the watcher flowchart of the controller:
* The creation of resources is initiated by an external user. An application CR is created following its corresponding CRD metamodel, which results in a YAML file. Then, the user declares the application in the cluster by posting the YAML file using the kubctl CLI, and it is stored in the etcd. Then, the Application Controller watcher detects the  
Figure 13: Sequence diagram of the high-level interactions between the Application (App) and Component (Comp) controllers with the Kubernetes control plane. The creation of resources is highlighted in a blue section, the conciliation of the desired spec and the current status is highlighted in green and the deletion of resources is highlighted in red. The right side represents the addition (in blue and with a ‘+’ sign) and subtraction (in red and with a ‘\(-\)’ sign) of resources that dynamically occur over the etcd. creation of the application resource and creates the Component CRs. Accordingly, the Component Controller watcher detects the creation of the components and creates the Deployment resources. * The controllers then seek the conciliation of the desired spec definition and the current status of the resources. After the Deployments have been instantiated, the Component Controller reacts to the changes that reflect the status of the components and updates them in the database.