## 3 Methodology  
The experiment consisted of the use of two distinct Virtual Machines (VMs) for different purposes [23; 24; 25]. The first VM was set up as a MicroK88-type K8s cluster [26], where a web application target of the experiment was deployed. This machine acted as the target environment for testing the scaling of replicas. The second VM was dedicated to running JMeter ([[https://jmeter.apache.org/index.html](https://jmeter.apache.org/index.html)]([https://jmeter.apache.org/index.html](https://jmeter.apache.org/index.html))) [27; 28; 29; 30; 31; 32]. This machine was responsible for generating HTTP traffic demands to the web application hosted on the K8s cluster. The web application deployed on K8s was developed in Java using Dropwizard version 3.1 ([[https://www.dropwizard.io/en/stable/](https://www.dropwizard.io/en/stable/)]([https://www.dropwizard.io/en/stable/](https://www.dropwizard.io/en/stable/))) [33]; it performs calculations of Fibonacci sequences of order 15 and returns this sequence as a response to the requests made by JMeter [34; 35]. The application deployed on K8s was limited to 150 millicores and 256 MB. The FHS was configured to work with \(m^{\text{cpu}}\text{max}=100\) millicores per replica, \(m^{\text{FP}}\text{max}=50\) rpm per replica, and \(m^{\text{P}}_{\text{max}}=20\) replicas. In addition to these virtual machines, the proposed FHS fuzzy controller for scaling of replicas was implemented and run on the experiment's own host. Using Matlab (596681)  
Figure 6: Mosaic-type diagram illustrating the mapping between the input and output of the FCS. as the development environment, FHS used the Java Fabric Kubernetes-Client library [36] to interact with the K8s API and perform dynamic scaling of the web application replicas. Thus, FHS acted as an external component to the cluster, making scaling decisions based on collected metrics and sending scaling requests to the Kubernetes MicroK8s cluster. Metrics were collected using Prometheus [37], which functioned as the MS (see Figure 1). The VM with the K8s cluster had 12 GB of RAM, four CPUs, and used Ubuntu 20.04 for the server, while the other VM had 12 GB of RAM, three CPUs, and used Ubuntu 22.04 for the server. The host was a machine with 128 GB of RAM and sixteen CPUs, and used Windows 10. Figure 7 illustrates the structure of the methodology used to generate the results. The results were generated from the load profile illustrated in Figure 8. This profile was constructed using the _Open Model Thread Group_, which defines the amount of virtual users created over time by JMeter to generate traffic demand on the web application being run on K8s [27]. The load profile shown in Figure 8 was chosen to simulate a realistic and variable workload scenario that reflects conditions encountered in edge computing environments. This profile includes periods of high and low demand, which allows for a comprehensive evaluation of the FHS system's ability to adjust resources in response to changing workloads. The chosen load profile helped to test the robustness and responsiveness of the FHS system, ensuring its ability to maintain performance and efficiency under various conditions. By including a range of workload intensities, the aim was to demonstrate the system's capability to handle peak loads efficiently while scaling down resource usage during periods of lower demand, thereby optimizing resource utilization and maintaining service quality. With a duration of 180 s, the user creation load profile is characterized by a ramp-up in the first 60 s until reaching a quantity of \(\beta\times 60\) users. Between 60 and 120 s, the requests remain constant at \(\beta\times 60\); after 120 s, the number of users decre  
Figure 8: Profile of virtual user creation by JMeter using _Open Model Thread Group_ for generating access to the web application. Figure 7: Architecture of the methodology used to generate the results.