## 4 Results
Affected resources are passed to the _Reconcile Spec Status()_ function that reads the current object status, compares it to the desired spec in the CR body and accordingly acts. * _Deleted events_ are raised by Deleted resources. The resource is passed to the _Delete Lower Resources()_ function that decommissions all the lower-level resources that compose a given CR. Figure 11: CRD body example. Figure 12: Default state machine of a given level controller. Controllers are designed to stay in the running state as long as the platform is deployed and running. When the controller is decommissioned, it transitions from the running state to the Decommissioning state. The watcher is stopped, the Kubernetes client is deleted and the controller is stopped. Kubernetes bases the access to its API resources on a Role-Based Access Control method (RBAC). In our case, we utilize the Kubernetes ClusterRole resource to provide cluster-wide access to a controller for a given resource. This way, there is a certain separation of concerns when it comes to the responsibilities of each controller. This ensures that no resource is modified by any process that should not alter it and that no process has access to information it should not handle. For example, in Appendix A, Figure A1a shows the body of a ClusterRole resource for a controller. Here, the resources to be accessed are defined and the <VERB_LIST> specifies the HTTP verbs allowed for the HTTP calls made by the user that has this ClusterRole assigned. Furthermore, Kubernetes requires these roles to be explicitly assigned to a ServiceAccount. This is performed by using ClusterRoleBinding resources; Figure A1b shows the body of an example ClusterRoleBinding. The roleRef is assigned to the defined subjects; in this case, the developed SeviceAccounts. The platform is distributed as a Kubernetes operator containing the YAML files required to deploy the DAG levels. In addition, an Application Structure Generator is provided as a Python script for users to determine the application structure desired. This tool automatically creates all the necessary HAMS implementation files to create a functional application structure ready to be deployed on Kubernetes. The generator also parameterizes the Application Controller if there is a level above it. Each level consists of five YAML files to be deployed in Kubernetes: the CRD, the controller Deployment and three YAML files to enable RBAC (a ServiceAccount, a ClusterRole and a ClusterRoleBinding). The operator code and the generator files can be found in the Data Availability section. Controllers can be implemented in any programming language that can communicate with the Kubernetes API. We selected Python as the programming language due to its extensive library pool and ease of implementation. The controller code must be packaged in a container image and must run inside a Kubernetes Pod declared in a Kubernetes Deployment. The HAMS controllers are implemented based on the same generic controller container image that is parameterized by the Application Structure Generator. The following subsections describe how these extension methods are applied to include the different levels of the proposed application structure into the native Kubernetes to obtain an application-aware platform.