Optimizing OpenFaaS on Kubernetes: Comparative Analysis of Language Runtimes and Cluster Distributions Ehsan Ataie*, Mohammadreza Pooshani, Hossein Aqasizade Department of Computer Engineering, University of Mazandaran, Babolsar, Iran
PAPER INFO Paper history: Received: Received in revised form Accepted
Keywords: Serverless Computing Function-as-a-Service Kubernetes OpenFaaS Language runtime
A B S T R A C T Serverless computing, particularly Function-as-a-Service (FaaS), has revolutionized cloud computing by abstracting infrastructure management and enabling dynamic resource allocation. This paper examines the performance and compatibility of OpenFaaS, an open-source serverless platform, when deployed on various Kubernetes distributions, including Kubeadm, K3s, MicroK8s, and K0s. Moreover, leveraging the CloudLab infrastructure, this study examines the impact of Python, Go, and Node.js programming languages on the performance of Kubernetes-enabled OpenFaaS, specifically when these languages are used to develop functions deployed on the platform. The performance is evaluated and analyzed under various levels of concurrent invocations using several usage-level metrics, such as throughput and CPU usage, as well as responsiveness metrics, such as delay. According to our findings, Go consistently outperforms Python and Node.js in terms of throughput and CPU usage, making it the ideal runtime for serverless applications. Among the Kubernetes distributions, K3s and Kubeadm exhibit superior performance, with Kubeadm maintaining low latency and efficient CPU usage, and K3s demonstrating high throughput. This study provides valuable insights into optimizing the Kubernetes-enabled OpenFaaS platform, highlighting the strengths and trade-offs of different Kubernetes distributions and language runtimes. DOI: XXX/XXXX
Graphical Abstract
سط
\1 سسس لللللسرزیشرز
* Corresponding Author Email: [email protected] (Ehsan Ataie)
1. INTRODUCTION Cloud computing has transformed a significant portion of the IT industry by making software as a service more appealing and changing how hardware is designed and purchased (1-5). Cloud computing is evolving into a more powerful paradigm, with serverless computing emerging as a powerful way to deploy applications and services. Serverless computing is usually based on Function-as-a-Service (FaaS), a model that does not require underlying virtualization to be managed by application developers (6,7). Additionally, it allows developers to provision virtual infrastructure and allocate resources efficiently (8,9). Using this approach provides unparalleled scalability because resources are dynamically allocated according to workload demands, resulting in cost savings and higher resource utilization (10). Conducting a comprehensive assessment of serverless computing systems is fundamental to sustaining service reliability, optimizing operational indicators, and controlling execution costs within acceptable thresholds (11,12). Moreover, such evaluations enable service providers to refine workload scheduling and resource utilization strategies, which can in turn decrease overall infrastructure expenditure and energy consumption. This type of analysis is particularly critical because serverless environments are often intertwined with multiple underlying subsystems, including container orchestration frameworks responsible for managing function instances, and programming language runtimes that execute the deployed functions across the platform. Various serverless platforms are available, ranging from industry leaders' products, such as AWS Lambda (13), Microsoft Azure Functions (AZF) (14), Google Cloud Functions (GCF) (15), and IBM Cloud Functions (ICF) (16), to many open-source alternatives, including OpenFaaS (17), OpenWhisk (18), Kubeless (19), Nuclio (20), Fission (21), and Knative (22). OpenFaaS is renowned for its significant features, including active community support, high number of active developers, and potential for extensions. It can be run and managed in a cluster of computers using Kubernetes (K8s), a noted open-source container orchestration platform. K8s offers several advantages for deploying this serverless platform, including resource efficiency due to optimized resource allocation, scalability with elastic capabilities, flexibility in infrastructure selection, stability in deployment and management processes, integration with native cloud tools, and robust community support (23). Figure 1 illustrates the interdependence between K8s and OpenFaaS. K8s is available in several distributions. A K8s distribution refers to a packaged version of the K8s platform, often bundled with additional tools, configurations, and services to simplify deployment, management, and scaling of clusters.
In this study, Kubeadm (24), K3s (25), MicroK8s (26), and K0s (27) are used because of their importance and popularity in recent research (28-32). Table 1 compares these K8s distributions based on their primary features for various deployment environments.
Figure 1. Interdependence between OpenFaaS and Kubernetes
OpenFaaS accommodates a wide range of programming language runtimes, including Python, Go, Java, Ruby, Node.js, and C#. Among the programming languages supported by OpenFaaS, in this research, we consider Python, Go and Node.js, and assess their performance when they are used to implement functions deployed on the OpenFaaS platform. We use CloudLab (33), which is a cloud computing testbed for research and education and has been used as an infrastructure in several related studies (34-36). A computationally intensive function is developed and invoked at various concurrency levels using workload generation tools such as Hey (37) and K6 (38). The goal is to analyze the pros and cons of each configuration by accurately evaluating performance measures. Afterward, we analyze and evaluate K8s distributions and programming language runtimes based on various metrics, including requests per second (RPS), average delay, and CPU usage. Briefly, the key contributions of this paper are listed below: • A comprehensive analysis of OpenFaaS performance across four Kubernetes distributions(Kubeadm, K3s, MicroK8s, and K0s), highlighting their respective strengths and trade-offs. • A thorough evaluation of how three popular programming language runtimes(Python, Go, and Node.js) affect critical performance metrics such as throughput, delay, and CPU usage in serverless environments. • The use of CloudLab as a controlled, reproducible testbed combined with real-world workload simulation tools (Hey and K6) to ensure the robustness of our evaluation. • Identification of Go as the runtime delivering the highest throughput and most efficient CPU usage, alongside insights that reveal K3s and Kubeadm as leading Kubernetes distributions with K3s excelling in throughput and Kubeadm achieving low latency and efficient resource utilization. • Practical recommendations for developers and researchers, guiding the selection of the optimal
Kubernetes distribution and programming language runtime based on specific deployment requirements. The rest of the article is structured as follows: Section 2 provides an overview of the related work. Section 3 describes the architecture of the system under study and the software and hardware configurations.
Section 4 provides the experimental results, including comparisons between different types of K8s distributions and programming language runtimes. Towards the end of the study, Section 5 concludes our findings and outlines potential directions for future research.
Table 1 .Comparative analysis of Kubernetes distributions Feature
Kubeadm
K3s
MicroK8s
K0s
Maintainer
K8s SIG
Rancher Labs
Canonical
Mirantis
Resource Usage
Moderate
Low
Low
Moderate
Installation Ease
Moderate
Easy
Easy
Easy
OS Support
Linux
Linux, Windows
Linux,Windows, MacOS
Linux
Primary Use Case
General Purpose
Edge, IoT
Developers, IoT
General Purpose
Architecture
Full-scale
Lightweight
Lightweight
Lightweight
High Availability
Supported
Supported
Supported
Supported
Snapshots & Backups
External tools
Built-in
Built-in
External tools
Community Support
Strong
Growing
Strong
Growing
Container Network Interface
Calico, Flannel, Weave, Cilium
Flannel
Calico, Flannel
Calico
Container Runtime
Docker, Containerd, CRI-O, rkt
Containerd, Docker
Containerd, Docker
Containerd, Docker, CRI-O
2. RELATED WORK A review of the literature reveals that serverless computing is a topic of considerable interest to many researchers. With a focus on research relevant to this article, this section aims to provide an overview of studies on serverless computing and K8s. Aqasizade et al. (2) evaluated the performance of four Kubernetes distributions including Kubeadm, K3s, MicroK8s, and K0s. Their experiments examined two virtualization modes, HVM and PV, supported by the Xen hypervisor. Additionally, they compared two container runtimes, Docker and Containerd, assessing their performance across disk-intensive and CPUintensive workloads. After identifying the optimal Xen mode and container runtime, they evaluated the Kubernetes distributions using various performance metrics, including request rate, CPU utilization, and scaling behavior. According to Koziolek et al. (30), MicroK8s, K3s, K0s, and MicroShift are lightweight K8s distributions,
and they discovered that K3s and K0s achieved marginally higher control plane throughputs in stress scenarios, whereas MicroShift achieved higher data plane throughputs. Kjorveziroski et al. (39) have examined the performance of three K8s distributions: Kubespray, K3s, and MicroK8s using serverless benchmarks using OpenFaaS. Especially in terms of reducing deployment time and complexity, lightweight distributions like K3s and MicroK8s outperformed Kubespray. Even though there were some performance variations in extreme load tests, MicroK8s and K3s generally performed similarly. Mohanty et al. (40) carried out a comparative assessment of several open-community serverless solutions, including Kubeless, OpenFaaS, Fission, and OpenWhisk. Their investigation examined how these frameworks behave under various request loads by observing response times and reliability of task completion, thereby identifying key architectural and runtime distinctions. The study found Kubeless to deliver more stable behavior than either Fission or OpenFaaS. In a separate edge-oriented analysis focused
on IoT workloads, Palade et al. (41) explored four opensource FaaS systems—Kubeless, OpenWhisk, OpenFaaS, and Knative—using JMeter to produce traffic. Performance was measured in terms of delay, throughput limits, and success ratio while workloads fluctuated. Across these conditions, Kubeless consistently achieved the highest and most balanced results among the tested frameworks. Balla et al. (42) measured runtime durations for Python and Node.js workloads across four serverless systems—OpenFaaS, Kubeless, Fission, and Knative. Their analysis revealed workload-dependent behavior on OpenFaaS: compute-heavy tasks suffered from session timeouts that funneled all traffic into one instance, severely limiting horizontal scaling. Additionally, under high user concurrency, Python functions in Kubeless failed to respond to liveness probes, though tuning container settings resolved the issue. Li et al. (43) investigated core design traits of opensource function platforms including Nuclio, OpenFaaS, Knative, and Kubeless, with particular focus on service exposure and elastic scaling. They observed that simultaneous component queuing caused elevated response times in OpenFaaS and Knative, whereas Nuclio consistently delivered the fastest tail latency at the 99th percentile. In a high-performance computing cluster, Decker et al. (44) benchmarked OpenFaaS and Nuclio. Results showed Nuclio achieving approximately 1.5 times greater data throughput than OpenFaaS. The study concluded that current frameworks require architectural refinement to fully leverage HPC environments, and performance gains were realized by tightly coupling user code with runtime instances. Lee et al. (45) assessed serverless computing's performance in processing distributed data through parallel function invocation. Study results demonstrated the effectiveness of serverless in specific data center applications, e.g., IoT-based migration scenarios. Wen et al. (46) examined four commercial-grade serverless computing services, namely Lambda, AZF, GCF, and Alibaba CFC. Their analysis revealed that deploying an excessive number of concurrent function instances within a single virtual machine can degrade system responsiveness and overall performance. Yu et al. (47) have introduced an open-source benchmark suite named ServerlessBench to assess the efficiency of communication, launch latency, stateless overhead, and performance isolation of AWS Lambda, OpenWhisk, and Fn platforms. The authors then examined the impact of the introduced benchmark on AWS Lambda, OpenWhisk, and Fn platforms. According to Wang et al. (48), three platforms, Lambda, GCF, and AZF, were compared for cold start latency by measuring the time difference between function invocation and function initiation. Also, the authors investigated how
programming language, memory, and the number of function instances affect cold start latency. It was found that memory and programming language runtime had a significant effect on cold start latency. Among the languages tested on the AWS Lambda platform, Python has the lowest average cold start latency, while Java functions have higher latency. Figiela et al. (49) have conducted an evaluation of the ICF, AZF, GCF, and Lambda platforms. They introduced a new benchmarking framework that uses both the Serverless framework and HyperFlow. Among cloud service providers, significantly different execution patterns were found. AWS Lambda execution was related to memory but slower at times. Google Cloud Function execution performed better with more memory. Javed et al. (50) evaluated multiple serverless platforms, including OpenWhisk, Greengrass, and OpenFaaS, when installed on edge systems with ARM architecture, specifically Raspberry Pis, versus public cloud platforms like Azure Functions and Amazon Lambda, when set up on the edge. Ataie et al. (51) investigated the performance of Nuclio, OpenFaaS, and Fission in terms of programming languages. They focused on Python and Node.js functions, evaluating the platforms based on total data exchanged, response time, and throughput. The results indicated that Python was the better choice for OpenFaaS, while Node.js performed better on Fission, especially under high concurrency. In contrast, Nuclio outperformed both platforms regardless of the programming language used. Goethals et al. (52) introduced FLEDGE, a Kubernetes-compatible edge container orchestrator designed for low-resource environments. They examined several key factors for efficient container orchestration, including the choice of container runtime and the implementation of container networking. Additionally, they conducted multiple evaluations, comparing FLEDGE with K3s and Kubernetes. Böhm et al. (53) evaluated lightweight Kubernetes distributions, MicroK8s and K3s, which aim to simplify K8s deployment in resource-constrained environments. Their experiment compared resource usage and time consumption during key lifecycle operations like starting, stopping, and adding nodes. The results showed that K3s had similar resource consumption to K8s but performed better when starting and adding nodes. MicroK8s, however, showed higher resource usage and longer operation times. Koukis et al. (54) evaluated the networking performance of four Kubernetes implementations including vanilla K8s, K3s, K0s, and MicroK8s and focusing on five Container Network Interface (CNI) plugins such as Flannel, Calico, Cilium, Kube-router, and Kube-ovn. Their assessment revealed that lightweight K8s distributions do not always lead to
resource savings in terms of CPU, memory, or throughput, even with different CNI plugins. Tzenetopoulos et al. (55) introduced a structured methodology to assess serverless frameworks operating within hybrid edge–cloud environments. Their study emphasized critical performance dimensions of serverless architectures and performed systematic experiments on OpenFaaS, OpenWhisk, and Lean OpenWhisk platforms. Ustiugov et al. (56) presented STeLLAR, a specialized benchmark suite designed for analyzing serverless performance. In their evaluation of Lambda, GCF, and AZF, they identified irregular storage access patterns and sudden traffic surges as major sources of latency fluctuation. Notably, differences among language runtimes produced minimal influence on observed delay. Trieu et al. (57) further performed an extensive assessment of a serverless edgecomputing setup employing widely used frameworks, including Kubeless, OpenFaaS, Fission, and funcX. They evaluated various programming languages, workloads, and concurrent user counts, particularly focusing on machine learning workloads. In contrast to earlier research, the present work concentrates on OpenFaaS compatibility and performance in relation with various K8s distributions, including Kubeadm, K3s, MicroK8s, and K0s, by using its robust container orchestration capabilities. Furthermore, this research provides valuable insights into programming language runtime performance, including Go, Python, and Node.js. The main objective is to identify which combinations of K8s distributions and language runtimes deliver the best performance for serverless applications running on OpenFaaS. Table 2 compares our work with others based on various criteria. 3. RESEARCH METHODOLOGY This section details the hardware and software configurations, workload generation methods, and K8s distributions used in this study. 3.1 Hardware The research is conducted on CloudLab, which is renowned for its robust resource allocation and clustering capabilities. CloudLab gives researchers control over a slice of the facility, allowing them to run tailored cloud software. The experiments are carried out on five c6620 machines (four nodes for OpenFaaS and one node for measurement), which are outfitted with dual Intel Xeon E5-2650v2 processors (each featuring 8 cores at 2.6 GHz), 64 GB of RAM, a 1 TB disk, and an Intel X520 PCIe dual-port 10Gb Ethernet NIC. Figure 2 and Table 3 show the deployment architecture and hardware details, respectively.
TABLE 3. Hardware specifications of CloudLab experiments Criterion
Values 5 (1 master, 3 workers, 1 measurement) Intel® Xeon® E5-2650v2 GB 64 TB 1 Intel X520 PCIe dual-port 10Gb
Number of nodes Processor Memory Disk Network Card
Figure 2. Deployment architecture
3.2 Software All experiments are conducted on Ubuntu Server 20.04 (58). Additionally, The OpenFaaS platform version 0.27.1 is installed on all K8s distributions using Helm (59) version 3.13.3. Calico (60) is the container network interface (CNI) plugin that is installed in all distributions of K8s to ensure fairness. Furthermore, we choose Python, Go, and Node.js as programming languages to be investigated for a variety of reasons, including alignment with existing research and popularity, language diversity and applicability, industry relevance, and community support. Moreover, we visualize the results using Prometheus (61) and Grafana (62), which are deployed on the measurement node. A customized query was designed to retrieve metrics associated with the OpenFaaS and OpenFaaSFn namespaces, and the corresponding implementation is available through our GitHub repository (63). Table 4 summarizes the software configurations in our experiments. TABLE 4. Software specifications of CloudLab experiments Criterion Operating System Kubernetes Version CNI Plugin OpenFaaS Version Helm Version Prometheus Version Grafana Version Programming Language Runtimes OpenFaaS Function
Values Ubuntu Server 20.04 1.27.2 Calico v3.16 0.27.1 3.13.3 2.47.0 9.5.1 Node.js, Python, Go Factorial 500
TABLE 2. Comparison of our work with related work Related Work Serverless Platform Aqasizade et al. OpenFaaS (2) Koziolek et al. N/A (30) Kjorveziroski et OpenFaaS al. (39)
Distribution Eval Metric PL Runtime Kubeadm, K3s, response time, throughput, Python MicroK8s, K0s auto-scaling, CPU usage MicroK8s, K3s, K0s, CPU, memory, disk usage N/A MicroShift KubeSpray, Container startup, Python MicroK8s, K3s application execution, response time, throughput Mohanty et al. Kubeless, OpenFaaS, GKE response time, request Go (40) Fission success rate Palade et al. Kubeless, OpenWhisk, Kubeadm response time, throughput, Node.js (41) OpenFaaS, Knative request success rate, deployment Balla et al. (42) OpenFaaS, Kubeless, Kubeadm completion time, autoPython, Node.js, Fission, Knative scaling Go Li et al. (43) Knative, Kubeless, Kubeadm response time, throughput, Python Nuclio, OpenFaaS auto-scaling, resource usage Decker et al. OpenFaaS, Nuclio Kubeadm images per second, Python, Go, C++ (44) throughput Lee et al. (45) Lambda, AZF, GCF, ICF Kubeadm response time, throughput, Python, Node.js, runtime overhead, CPU, Java, C# I/O Wen et al. (46) Lambda, AZF, GCF, public clouds cold start, resource Python, Node.js, Alibaba efficiency Java Yu et al. (47) Lambda, OpenWhisk, Fn public clouds response time, stateless Python, Node.js, overhead Ruby, C Wang et al. (48) Lambda, AZF, GCF public clouds memory, number of Python, Node.js, function instances, cold Java start Figiela et al. Lambda, AZF, GCF, ICF public clouds memory, number of Elixir, Node.js (49) function instances, cold start Javed et al. (50) Lambda, AZF, AWS Kubeadm and response time, request Node.js Greengrass, OpenWhisk, Docker Swarm success rate OpenFaaS Ataie et al. (51) OpenFaaS, Nuclio, Kubeadm response time, throughput, Python, Node.js Fission Total data Goethals et al. N/A K8s, K3s, FLEDGE Memory, storage usage N/A (52) Bohm et al. (53) N/A K8s, MicroK8s, K3s CPU, memory, disk usage N/A Koukis et al. N/A vanilla K8s, K3s, throughput, CPU, memory N/A (54) K0s, MicroK8s usage Tzenetopoulos OpenFaaS, Openwhisk, K3s Idle-state, Cold-start, Python, Node.js, et al. (55) Lean Openwhisk Concurrent Invocation, Go, Ruby Payload Transfer, autoscaling Ustiugov et al. Lambda, AZF, GCF public clouds response time, cold start, Python, Go (56) data communication delays Trieu et al. (57) Kubeless, OpenFaaS, MicroK8s response time, autoPython, Node.js Fission, funcX scaling, request success rate, training time Our Work OpenFaaS Kubeadm, K3s, response time, throughput, Python, Go, MicroK8s, K0 auto-scaling, CPU usage Node.js
Measuring K6 netdata Hey AB JMeter Hey Wrk N/A N/A TBS N/A N/A N/A JMeter Hey, Wrk df, pmap netdata N/A N/A
STeLLAR JMeter Hey, K6
3.3 Workload Generation A load test tool called Grafana K6 is used in this study in order to generate workloads on the serverless platform and clustering services. However, we repeat the experiments with Hey tool to ensure accuracy. These tools generate HTTP requests by calling functions deployed on the serverless platform. The function implemented in Python, Go and Node.js is a factorial function with parameter 500 which pressures the processor. Requests are sent at various concurrency levels, i.e., 5, 10, and 20, for three minutes. It turns out that after generating this load, it requires approximately two minutes for the input queue to clear completely. Consequently, we introduce a 5-minute delay between subsequent runs to prevent experiments from interfering with one another. To ensure maximum accuracy, all measurements are repeated independently and separately 10 times. 3.4 Kubernetes distributions Four K8s distributions are investigated and compared in this paper, namely Kubeadm, K3s, MicroK8s, and K0s, using a variety of metrics. Kubeadm is a command-line tool used to set up K8s clusters on Linux. It simplifies booting up new clusters. A lightweight distribution like K3s, on the other hand, only contains the required components with the goal of reducing CPU and memory usage. This distribution is primarily designed to operate in constrained environments, such as edge and IoT devices. The MicroK8s distribution from Canonical is lightweight and based on K3s. For development and testing, it provides a straightforward K8s distribution. K0s, the latest K8s distribution from Mirantis, simplifies and reduces orchestration complexity by utilizing K8s' standard design across both local and cloud networks. To maintain fairness, all K8s distributions are standardized to version 1.27.2.
and 20 concurrent users, all presented on a logarithmic scale.The analysis of K8s distributions performance using Python, Go, and Node.js as programming language reveals several interesting trends: In terms of RPS, Go language performs better than the other two languages regardless of K8s distribution and concurrency level. Python is second, while Node.js is third.Regardless of one exception, as concurrency increases, throughput improves for all languages and K8s distributions.It seems that Go is the most sensitive language to concurrency levels, especially when combined with K0s distribution. On the other hand, Node.js is the least sensitive when paired with K3s. Although K8s distributions perform differently depending on the language and the concurrency level, K3s ranks on average as the winner, Kubeadm comes in second, K0s comes in third, and MicroK8s comes in fourth. Based on the delay, Go once again outperforms other languages regardless of K8s distribution and concurrency level. Python is ranked second, and Node.js is ranked third. While for Node.js and Python the average delay increases when the concurrency level increases, for Go, it remains almost constant across all K8s distributions. Kubeadm absolutely provides a shorter delay in contrast to other distributions. K3s and K0s are ranked next acting almost the same, and MicroK8s is ranked fourth on average.
4. Evaluation Results This section presents the results of performance evaluation.: In Section 4.1, three programming language runtimes with four K8s distributions are assessed in terms of throughput and average delay as performance measures. Next, in Section 4.2, the CPU usage of these programming language runtimes is analyzed. Afterwards, Section 4.3 compares K8s distributions in terms of different metrics when Go is chosen as the programming language, and Section 4.4 provides a discussion of the results and their analysis. 4.1 RPS and Average Delay Figures 3 through 10 depict the RPS and average delay for various programming language runtimes on Kubeadm, K3s, MicroK8s, and K0s, tested with 5, 10,
Figure 3. Requests per second for Kubeadm
Figure 4. Average delay for Kubeadm
Figure 5. Requests per second for K3s
Figure 9. Requests per second for K0s
Figure 6. Average delay for K3s
Figure 10. Average delay for K0s
Figure 7. Requests per second for MicroK8s
Figure 8. Average delay for MicroK8s
4.2 CPU Usage In the previous part, we discussed how Go has the best performance among programming language runtimes, but what about its CPU usage Figures 11 to 14 illustrate the CPU usage of programming language runtimes for K8s distributions. Based on the data, all languages exhibit a progressive increase in CPU usage as the number of concurrent operations grows. The trend indicates that Node.js is more resource-intensive than Python and Go, with Python following in second place and Go ranked third. This result highlights Go's more efficient resource management and its ability to handle higher workloads in serverless environments without a proportionate increase in CPU load. Furthermore, no specific language appears to be more sensitive to concurrency levels than others in terms of CPU usage. From the perspective of Kubernetes distributions, regardless of the programming language or concurrency level, Kubeadm, K3s, MicroK8s, and K0s rank first to fourth in terms of CPU usage, respectively. In other words, Kubeadm consumes the least amount of CPU compared to the other distributions when integrated with OpenFaaS to run our function invocations.
Figure 11. Kubeadm CPU usage
Figure 12. K3s CPU usage
Figure 13. MicroK8s CPU usage
Figure 14. K0s CPU usage
4.3 Kubernetes Distribution A comparison of RPS, average delay, and CPU usage across K8s distributions including, Kubeadm, K3s, MicroK8s, and K0s reveals notable differences in performance and usage metrics with differences in concurrency levels. Figures 15 to 17 illustrate the difference in these performance measures between K8s distributions for Go programming language. Here, Go is considered to develop the functions deployed on OpenFaaS because it shows the best performance results in the experiments of Sections 4.1 and 4.2. Based on RPS, both Kubeadm and K3s exhibit impressive throughput capabilities, showing strong scalability as concurrency increases. With consistently high RPS without significant performance drops, they handle growing demands effectively. In other words, both Kubeadm and K3s are capable of handling multiple requests simultaneously. On the other hand, while MicroK8s and K0s exhibit slightly lower performance at lower concurrency levels, they deliver strong RPS performance at higher concurrency levels and adapt well to increasing loads.Based on delay, at a concurrency level of 5, K3s provides the best performance, with K0s in second place. However, at concurrency levels of 10 and 15, K0s takes the lead, exhibiting the lowest average delay, while K3s ranks second. Surprisingly, Kubeadm and MicroK8s perform similarly, consistently tying for third place, regardless of the number of concurrent function invocations. Based on CPU usage, Kubeadm consumes the least amount of CPU among all distributions. As concurrency rises, Kubeadm shows a moderate increase in CPU usage compared to other distributions, indicating efficient CPU management and ensuring consistent performance without straining resources. K3s ranks second, consuming 26%, 32%, and 53% more CPU than Kubeadm at concurrency levels of 5, 10, and 20, respectively. These values indicate that K3s is more sensitive to concurrency increases than Kubeadm. MicroK8s and K0s behave almost similarly, ranking third and fourth, respectively. On average, these two distributions consume 94%, 97%, and 153% more CPU than Kubeadm at concurrency levels of 5, 10, and 20, respectively, demonstrating that at higher concurrencies, they struggle to manage CPU resources efficiently. Although all four K8s distributions maintain strong performance metrics, Kubeadm and K3s generally offer a more balanced approach between resource efficiency and high throughput. MicroK8s and K0s, on the other hand, may consume more resources, affecting overall efficiency in processor-intensive scenarios. Based on specific operational requirements and resource availability, a nuanced understanding of the performance of each distribution helps determine which distribution would be most suitable for the specific task at hand.
Figure 15. Request per second for Kubernetes distributions
Figure 16. Average delay for Kubernetes distributions
Figure 17. CPU usage for Kubernetes distributions
4.4 Discussion As shown in previous sections, from a programming language perspective, Go outperforms other languages in terms of RPS and delay, regardless of the Kubernetes distribution or concurrency level. Performance trends observed in Python, Go, and Node.js on the OpenFaaS serverless platform can be attributed to several key factors inherent to these programming language runtimes and their runtime environments: Parallelism Handling: Go is known for its efficient concurrency model, utilizing lightweight threads called goroutines. Due to this feature, Go can efficiently handle a large number of concurrent processes. OpenFaaS and other serverless environments like it benefit from the memory-efficient nature of goroutines.
In Node.js, the I/O model is event-driven, non-blocking, and typically runs in a single-threaded environment. Especially on serverless platforms, Node.js can cause performance bottlenecks for CPU-intensive tasks, resulting in increased delays as concurrency increases. The Global Interpreter Lock permits only a single thread to execute Python bytecode at a time, thereby imposing constraints on overall performance. Python supports concurrency via threads and asynchronous programming. Due to this characteristic, Python cannot perform optimally in multi-threaded scenarios, crucial for serverless platforms with high concurrency levels. Optimization: On serverless platforms where efficient execution is essential, Go's compilation to machine code optimizes system resource usage. During peak demand, this efficiency allows for higher throughput and quicker average delay. As interpreted languages, Node.js and Python typically exhibit slower execution speeds than compiled languages like Go. Due to this intrinsic characteristic and their concurrency handling, a serverless platform may have increased average delay under high concurrency. Memory Management: Despite varying loads in a serverless setting, Go offers performance stability due to the advanced garbage collection and statically typed system. With Go's advanced garbage collection, unused resources are promptly released, ensuring that memory is efficiently allocated and dealt with. This prevents memory leaks and reduces the likelihood of performance degradation, resulting in stable and consistent performance even in the face of varying loads in a serverless environment. In serverless workloads with heavy and fluctuating memory usage, Node.js and Python suffer from less efficient memory management and garbage collection. Table 5 compares the performance of different K8s distributions (K3s, Kubeadm, MicroK8s, and K0s) in terms of RPS, average delay, and CPU usage at different concurrency levels. According to these rankings, each distribution excels in specific performance metrics based on its architecture, which can guide selection based on application requirements. With regards to RPS, K3s consistently leads across all concurrency levels for Python and Node.js, demonstrating exceptional efficiency when handling large volumes of requests. K3s also maintains a strong position in Go, sharing the top spot with K0s at higher concurrency levels. Kubeadm excels at maintaining low delay across all concurrency levels for Python, Go, and Node.js. This shows how Kubeadm is optimized for rapid response time, letting applications remain responsive even under heavy load. It also shares the top rank especially with K3s and K0s in some scenarios. Furthermore, Kubeadm ranks highest in CPU efficiency, ensuring low consumption of processing resources across Python, Go, and Node.js. As a result, users
benefit from high performance with minimal overhead due to Kubeadm's efficient use of computing resources.
modeling to be validated against the experimental findings provided in this study. Once validated, the proposed analytical models could be leveraged for extended analysis, including what-if scenarios.
Table 5. Winners of Kubernetes distributions by programming language and performance metrics
5. CONCLUSION AND FUTURE WORK Various Kubernetes distributions, including Kubeadm, K3s, MicroK8s, and K0s, were investigated in this paper to compare the performance of OpenFaaS serverless platform when integrated with Kubernetes and the programming language runtimes when they are used to develop functions for OpenFaas. Using Python, Go, and Node.js programming language runtimes, we analyzed these distributions based on requests per second, average delay, and CPU usage. This integrated analysis of RPS, delay, and processor usage provides valuable insights into the unique strengths of each distribution and programming language, enabling informed decisions based on the specific application requirements for each environment. Based on the experimental results, K3s and Kubeadm emerged as the leading platforms, with K3s excelling in providing high throughput and Kubeadm excelling in maintaining the lowest average delay while efficiently managing CPU resources. Among the programming language runtimes, Go delivered high performance with minimal delay and efficient CPU usage, while Python provided a moderate balance between performance and resource consumption. However, Node.js exhibited higher CPU usage and longer average delays under high concurrency. As future work, we plan to combine machine learning models with serverless platforms and container orchestration tools to adapt to varying workloads and dynamically optimize resource allocation. For instance, adjusting the number of prewarmed containers based on the historical number of concurrent invocations could help reduce cold start delays. Additionally, utilizing reinforcement learning techniques could further minimize the occurrence of cold starts. These approaches are expected to lead to better resource utilization and improved overall performance. Another potential direction for future work could be to propose analytical models, such as queueing networks or Petri nets, to model the behavior and performance of OpenFaaS when integrated with Kubernetes. This approach would allow the results of the analytical
ACKNOWLEDGEMENT This research was financed by a research grant from the University of Mazandaran. 6. REFERENCES 1.
Armbrust M, Fox A, Griffith R, Joseph AD, Katz RH, Konwinski A, Lee G, Patterson DA, Rabkin A, Stoica I, et al. Above the clouds: A Berkeley view of cloud computing. Technical Report UCB/EECS-2009-28. EECS Department, University of California; 2009.
2.
Aqasizade H, Ataie E, Bastam M. Kubernetes in action: Exploring the performance of Kubernetes distributions in the cloud. Software: Practice and Experience. 2025 Jul 2;55(10): 10.1002/spe.70000
3.
Aqasizade H, Ataie E, Bastam M. Experimental assessment of containers running on top of virtual machines. IET networks. 2025 Jan;14(1):e12138. 10.1049/ntw2.12138
4.
Hamidi H, Seyed Lotfali SH. Analysis of role of cloud computing in providing internet banking services: Case study bank melli Iran. International Journal of Engineering. 2022 May 1;35(5):1082-8. 10.5829/IJE.2022.35.05B.23
5.
Mansouri N. An efficient task scheduling based on Seagull optimization algorithm for heterogeneous cloud computing platforms. International Journal of Engineering. 2022 Feb 1;35(2):433-50. 10.5829/IJE.2022.35.02B.20
6.
Risco S, Moltó G, Naranjo DM, Blanquer I. Serverless workflows for containerised applications in the cloud continuum. Journal of Grid Computing. 2021 Sep;19(3):30. 10.1007/s10723-021-09570-2
7.
Shojaee rad Z, Ghobaei-Arani M, Ahsan R. Memory orchestration mechanisms in serverless computing: a taxonomy, review and future directions. Cluster Computing. 2024 Aug;27(5):5489-515. 10.1007/s10586-023-04251-z
8.
Scheuner J, Leitner P. Function-as-a-service performance evaluation: A multivocal literature review. Journal of Systems and Software. 2020 Dec 1;170:110708. 10.1016/j.jss.2020.110708
9.
Yussupov V, Soldani J, Breitenbücher U, Brogi A, Leymann F. Faasten your decisions: A classification framework and technology review of function-as-a-service platforms. Journal of Systems and Software. 2021 May 1;175:110906. 10.1016/j.jss.2021.110906
10. Bouizem Y, Dib D, Parlavantzas N, Morin C. Integrating request replication into FaaS platforms: an experimental evaluation. Journal of Cloud Computing. 2023 Jun 22;12(1):94. 10.1186/s13677-023-00457-z
11. Ghorbian M, Ghobaei-Arani M, Esmaeili L. A survey on the scheduling mechanisms in serverless computing: a taxonomy, challenges, and trends. Cluster Computing. 2024 Aug;27(5):5571-610. 10.1007/s10586-023-04264-8
33. Duplyakin D, Ricci R, Maricq A, Wong G, Duerig J, Eide E, Stoller L, Hibler M, Johnson D, Webb K, Akella A. The design and operation of {CloudLab}. In 2019 USENIX annual technical conference (USENIX ATC 19) 2019 (pp. 1-14).
12. Kumari A, Sahoo B. ACPM: adaptive container provisioning model to mitigate serverless cold-start. Cluster Computing. 2024 Apr;27(2):1333-60. 10.1007/s10586-023-04016-8
34. Ramanathan S, Bhattacharyya A, Kondepu K, Fumagalli A. Enabling containerized Central Unit live migration in 5G radio access network: An experimental study. Journal of Network and Computer Applications. 2024 Jan 1;221:103767. 10.1016/j.jnca.2023.103767
13. Amazon Lambda. Available from: https://aws.amazon.com/lambda. Accessed: September 2025. 14. Azure Serverless. Available from: https://azure.microsoft.com/en-us/free/serverless. Accessed: July 2025. 15. Google Cloud Functions. Available from: https://cloud.google.com/functions. Accessed: October 2025. 16. IBM Cloud Functions. Available from: https://cloud.ibm.com/functions. Accessed: October 2025. 17. OpenFaaS. Available from: Accessed: September 2025.
https://www.openfaas.com.
18. Apache OpenWhisk. Available https://openwhisk.apache.org. Accessed: August 2025.
35. Ganguly B, Hosseinalipour S, Kim KT, Brinton CG, Aggarwal V, Love DJ, Chiang M. Multi-edge server-assisted dynamic federated learning with an optimized floating aggregation point. IEEE/ACM Transactions on Networking. 2023 Apr 21;31(6):2682-97. 10.1109/TNET.2023.3262482 36. Qi S, Zeng Z, Monis L, Ramakrishnan KK. Middlenet: A unified, high-performance nfv and middlebox framework with ebpf and dpdk. IEEE Transactions on Network and Service Management. 2023 Mar 14;20(4):3950-67. 10.1109/TNSM.2023.3256891
from:
37. Hey. Available from: https://github.com/rakyll/hey. Accessed: September 2025.
19. Kubeless. Available from: https://github.com/vmwarearchive/kubeless. Accessed: July 2025.
38. Grafana k6. Available from: https://k6.io. Accessed: September 2025.
20. Nuclio. Available from: https://nuclio.io. Accessed: July 2025.
39. Kjorveziroski V, Filiposka S. Kubernetes distributions for the edge: serverless performance evaluation. The Journal of Supercomputing. 2022 Jul;78(11):13728-55. 10.1007/s11227022-04430-6
21. Fission. Available from: https://fission.io. Accessed: July 2025. 22. Knative. Available from: https://knative.dev. Accessed: July 2025. 23. Liu J, Ding Y, Liu Y. A balanced leader election algorithm based on replica distribution in Kubernetes cluster. Cluster Computing. 2024 Sep;27(6):7241-50. 10.1007/s10586-02404333-6 24. Kubeadm. Available from: https://kubernetes.io/docs/reference/setup-tools/kubeadm. Accessed: September 2025. 25. K3s lightweight kubernetes. Available from: https://www.k3s.io. Accessed: September 2025. 26. microk8s. Available September 2025.
from:
https://microk8s.io.
Accessed:
27. k0s project. Available from: https://k0sproject.io. Accessed: September 2025. 28. Chahoud M, Sami H, Mourad A, Otoum S, Otrok H, Bentahar J, Guizani M. On-demand-fl: A dynamic and efficient multicriteria federated learning client deployment scheme. IEEE Internet of Things Journal. 2023 Apr 7;10(18):15822-34. 10.1109/JIOT.2023.3265564 29. Basak S, Srirama SN. Fog computing out of the box: Dynamic deployment of fog service containers with TOSCA. International Journal of Network Management. 2024 Sep;34(5):e2246. 10.1002/nem.2246 30. Koziolek H, Eskandani N. Lightweight kubernetes distributions: A performance comparison of microk8s, k3s, k0s, and microshift. InProceedings of the 2023 ACM/SPEC International Conference on Performance Engineering 2023 Apr 15 (pp. 1729). 10.1145/3578244.3583737 31. Heckmann O, Ravindran A. Evaluating Kubernetes at the edge for fault tolerant multi-camera computer vision applications. In 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing Workshops (CCGridW) 2023 May 1 (pp. 269-271). IEEE. 10.1109/CCGridW59191.2023.00054 32. Kim B, Calin D, Tenny N, Shariat M, Fan M. Device centric distributed compute, orchestration and networking. IEEE Wireless Communications. 2023 Sep 14;30(4):6-8. 10.1109/MWC.2023.10251878
40. Mohanty SK, Premsankar G, Di Francesco M. An evaluation of open source serverless computing frameworks. In Proceedings IEEE 10th International Conference on Cloud Computing Technology and Science, CloudCom 2018. IEEE. 2018. p. 115120. 8591002 10.1109/CloudCom2018.2018.00033 41. Palade A, Kazmi A, Clarke S. An evaluation of open source serverless computing frameworks support at the edge. In 2019 IEEE world congress on services (SERVICES) 2019 Jul 8 (Vol. 2642, pp. 206-211). 10.1109/SERVICES.2019.00057 42. Balla D, Maliosz M, Simon C. Open source faas performance aspects. In 2020 43rd International Conference on Telecommunications and Signal Processing (TSP) 2020 Jul 7 (pp. 358-364). IEEE. 10.1109/TSP49548.2020.9163456 43. Li J, Kulkarni SG, Ramakrishnan KK, Li D. Analyzing opensource serverless platforms: Characteristics and performance. arXiv preprint arXiv:2106.03601. 2021 Jun 4. 10.48550/arXiv.2106.03601 44. Decker J, Kasprzak P, Kunkel JM. Performance evaluation of open-source serverless platforms for Kubernetes. Algorithms. 2022 Jul 2;15(7):234. 10.3390/a15070234 45. Lee H, Satyam K, Fox G. Evaluation of production serverless computing environments. In 2018 IEEE 11th International Conference on Cloud Computing (CLOUD) 2018 Jul 2 (pp. 442450). IEEE. 10.1109/CLOUD.2018.00062 46. Wen J, Liu Y, Chen Z, Chen J, Ma Y. Characterizing commodity serverless computing platforms. Journal of Software: Evolution and Process. 2023 Oct;35(10):e2394. 10.1002/smr.2394 47. Yu T, Liu Q, Du D, Xia Y, Zang B, Lu Z, Yang P, Qin C, Chen H. Characterizing serverless platforms with Serverlessbench. In Proceedings of the 11th ACM Symposium on Cloud Computing 2020 Oct 12 (pp. 30-44). 10.1145/3419111.3421280 48. Wang L, Li M, Zhang Y, Ristenpart T, Swift M. Peeking behind the curtains of serverless platforms. In 2018 USENIX annual technical conference (USENIX ATC 18) 2018 (pp. 133-146). 49. Figiela K, Gajek A, Zima A, Obrok B, Malawski M. Performance evaluation of heterogeneous cloud functions. Concurrency and Computation: Practice and Experience. 2018 Dec 10;30(23):e4792. 10.1002/cpe.4792
50. Javed H, Toosi AN, Aslanpour MS. Serverless platforms on the edge: a performance analysis. In New Frontiers in Cloud Computing and Internet of Things 2022 Apr 28 (pp. 165-184). Cham: Springer International Publishing. 10.1007/978-3-03105528-7_6 51. Ataie E, Pooshani M, Aqasizade H, An Empirical Study on Impact of Programming Languages on Performance of Opensource Serverless Platforms. International Journal of Engineering, 2025; 38(2): 424-435. 10.5829/ije.2025.38.02b.16 52. Goethals T, De Turck F, Volckaert B. Fledge: Kubernetes compatible container orchestration on low-resource edge devices. In International conference on internet of vehicles 2019 Nov 18 (pp. 174-189). Cham: Springer International Publishing. 10.1007/978-3-030-38651-1_16 53. Böhm S, Wirtz G. Profiling Lightweight Container Platforms: MicroK8s and K3s in Comparison to Kubernetes. In ZEUS 2021 Feb (pp. 65-73). 54. Koukis G, Skaperas S, Kapetanidou IA, Mamatas L, Tsaoussidis V. Performance evaluation of kubernetes networking approaches across constraint edge environments. In 2024 IEEE Symposium on Computers and Communications (ISCC) 2024 Jun 26 (pp. 16). IEEE. 10.1109/ISCC61673.2024.10733726 55. Tzenetopoulos A, Apostolakis E, Tzomaka A, Papakostopoulos C, Stavrakakis K, Katsaragakis M, Oroutzoglou I, Masouros D, Xydis S, Soudris D. Faas and curious: Performance implications of serverless functions on edge computing platforms. In International Conference on High Performance Computing 2021 Jun 24 (pp. 428-438). Cham: Springer International Publishing. 10.1007/978-3-030-90539-2_29 56. Ustiugov D, Amariucai T, Grot B. Analyzing tail latency in serverless clouds with stellar. In 2021 IEEE International Symposium on Workload Characterization (IISWC) 2021 Nov 7 (pp. 51-62). IEEE. 10.1109/IISWC53511.2021.00016 57. Trieu QL, Javadi B, Basilakis J, Toosi AN. Performance evaluation of serverless edge computing for machine learning applications. In 2022 IEEE/ACM 15th International Conference on Utility and Cloud Computing (UCC) 2022 Dec 6 (pp. 139144). IEEE. 10.1109/UCC56403.2022.00025 58. Enterprise Open source and Linux — Ubuntu. Available from: https://ubuntu.com. Accessed: September 2025. 59. Helm package manager. Available from: https://helm.sh. Accessed: September 2025. 60. Project Calico. Available from: https://www.tigera.io/projectcalico. Accessed: September 2025. 61. Prometheus. Available from: https://prometheus.io. Accessed: September 2025. 62. Grafana. Available September 2025.
from:
https://grafana.com.
Accessed:
63. Prometheus k8s. Available from: https://github.com/aqasiz/Prometheus-k8s. Accessed: September 2025.