## 4 Results
### Tests Results
It should be noted that the performance difference between Kubernetes and other solutions decreased, showing a trend that suggests that Kubernetes can perform well in the long term. With these graphs, we can see that the use of Docker Compose with Podman performs better on all levels in the context of using only a few containers over a moderate period of time. For the I/O disk performance graphs over 1 min (see Figure 5), we can see that Docker Compose acts as a better container manager in our case, being 40% more efficient on average. This can be explained because Podman does not use a daemon for managing containers. Thus, there is no overload with this and with complex network services. In addition, Kubernetes is very complex in terms of components; it needs a Kuberlet, an API server, a controller manager, etc. For this reason, Kubernetes and Docker Engine are less likely to have better results than Docker Compose and Podman. The results for the I/O disk performance graph for ten minutes (see Figure 6) show the same trend as for CPU performance; Kubernetes' results are still worse than the others,  
Figure 5: I/O disk performance difference in percent for 1 min. Figure 6: I/O disk performance difference in percent for 10 min. Figure 7: Memory performance difference in percent for 1 min. but they significantly increased. This trend supports the hypothesis about the long-term efficiency of Kubernetes. For the memory part (see Figure 7), the difference is less significant than CPU consumption or I/O operations. This difference can be explained by the same argument used for the I/O disk performance: the complexity of Kubernetes is more resource-consuming than the lightweight container manager Docker Compose. We can then recommend using Docker Compose and Podman in an environment that requires resource efficiency on a one-time basis and not for a long-term service. For example, to train artificial intelligence (AI) on a model with large amounts of data, we can use Docker Compose and Podman. In the case of a complex architecture with a need for redundancy and error management or a service/application, we recommend Kubernetes, which will meet these needs adequately. Figure 8 summarizes the whole range of tests performed in the different virtualized and containerized architectures. This figure shows that the use of Kubernetes with the Podman backend demonstrates the advantage of utilizing Kubernetes with the more popular Docker Engine; furthermore, the true extent of x86's virtualization inefficiency is revealed. Figure 9 summarizes the same set of tests as before but on a 20 min timescale instead of 5 min. This figure shows that the power efficiency of Kubernetes exceeds that of Docker when run for longer periods. The widespread adoption of Kubernetes has fostered an extensive ecosystem of Kubernetes-compatible containers and tools, along with a supportive community of developers and users. This environment provides organizations with a powerful suite of tools, which encourages both new and existing users to engage with Kubernetes-based solutions. As a result, individuals and organizations often prefer Kubernetes-compatible solutions, even when theoretically superior alternatives may be available. Although Kubernetes was originally designed for clustered deployments, single-node Kubernetes cluster solutions have gained substantial popularity due to their reduced resource requirements and improved performance. For instance, Canonical's MicroK8s operates as a single-node cluster by default, catering to small production environments and development needs. Similarly, Rancher Labs' K3s is optimized as a single-node solution specifically for Edge Computing and IoT applications. This trend highlights the flexibility and adaptability of the Kubernetes ecosystem in addressing modern deployment requirements. Figure 8: Comparison of all 25 tests (5 min) performed on the Raspberry Pi testbed.