## 3 Materials and Methods
### Kubernetes and Its Extension Methods  
This section presents the implementation of the previously described architecture. As Kubernetes is the de facto standard when it comes to container orchestration, this work proposes integrating the architecture through standard Kubernetes extension methods. Kubernetes is composed of a control plane that is responsible for managing the totality of the cluster. It is composed of four main elements: the API Server that exposes the Kubernetes API; the etcd database, a NoSQL database that provides storage to the cluster; the controller-manager (c-m) that manages the native Kubernetes resources; and the scheduler (sched) that assigns workloads to nodes. The rest of the cluster is composed of worker nodes. These nodes provide the processing capabilities to the cluster, and it is where the applications are deployed. There are two components that run on every worker node and that represent the agent deployed on a Worker Node: the kubelet that is responsible for running Pods and reporting the state of the node to the master and the kube-proxy (k-proxy) that enables Pod communication inside of the cluster. It is noticeable that some efforts have been made to develop orchestration solutions apart from the leading orchestrators [21]. However, these solutions usually fail to cover the totality of the requirements presented in the flow of application deployment and cannot compete with the coverage of state-of-the-art container orchestrators. Kubernetes, being the de facto standard in the industry, becomes the go-to solution for deploying and orchestrating applications. Kubernetes is highly configurable, providing several methods for its extension without the need to patch its open-source code [35]. Furthermore, according to [15], Kubernetes is a much more extensible container orchestrator framework than other popular solutions. Therefore, the extension capabilities offered by Kubernetes make it possible to develop independent addons or plugins that aim to cover some of the features Kubernetes is missing [12; 13; 21; 25; 26; 27; 28], or to extend some of the functionalities of  
Figure 5: HAMS vertically scaled to where N = 2 and horizontal scalability (highlighted in green) illustrated adding additional Resources and additional Applications. the Kubernetes control plane elements [20; 29; 30; 31; 32; 33; 36]. These extensions, if following standard extension methods [13; 27; 28], can be immediately applicable to already established Kubernetes production environments, making them suitable for companies to implement. Our proposal focuses on two extension methods:  
* API extensions: Kubernetes works with a set of native or built-in resources used to deploy, run and manage the required Kubernetes resources, such as, Pods, Deployments, Nodes or Services. Most of the users will have their requirements met with these. However, user-defined resources can be added to the Kubernetes API. These new resources are called Custom Resources (CRs) and are usually implemented by declaring resource types or schemas in Kubernetes through CRDs. When a new resource type is added to Kubernetes using CRDs, all of the Kubernetes tools, such as kubectl (CLI tool for Kubernetes), can be used to interact with them. From the Model-Driven Engineering (MDE) point of view, CRDs act as meta-models that define the characterization and composition rules of the different resource types, while CRs are models or instances of a certain CRD. * Controllers: By themselves, CRs only act as a recipient or model containing certain information. As these are not built-in Kubernetes resources, the orchestrator (c-m component) does not intervene in their management. Controllers are clients of the API server and are responsible for the management of their associated CRs. The composition of Controllers and custom resources constitutes what Kubernetes calls the operator pattern [37].