IEEE Consumer Electronics Magazine - May/June 2023 - 56

Edge Computing
container images over the network during the
deployment. To test the scalability, we consider
an increasing number of compute nodes (from
10 to 100 with a step of 10 nodes) while on each
node an increasing number of services being
deployed (from 1 to 10 with a step of 1 service).
Each test is then performed 10 times. Given that
the communication between compute nodes and
controller is based on TCP, introducing latency,
jitter, packet-loss, or bandwidth limitation,
between the operative limits of TCP will not
affect the communication between the nodes.
However, in a real-world scenario, where the
images are not prefetched, having latency, jitter,
packet-loss, and bandwidth limitation has a
huge impact in the application instantiation time
because the instantiation time will be dominated
by the image fetching time.
Results
FIGURE 3. Illustration of the experimental testbed.
Cortex-A72, 8 GB of RAM, 128 GB of storage, and
1GbE connectivity that acts as a controller. A
rack-mounted server equipped with a Dual Intel
Xeon-6130 16 Cores with HyperThreading,
512 GB of RAM, 1 TB of SSD storage, is then used
to emulate and virtualize 100 compute. Each
compute node is virtualized as a VM provisioned
with 1vCPU, 2 GB of RAM, and 16 GB of storage,
and Ubuntu 20.04 LTS as the operating system.
The selected configuration for the virtualized
node is a representative of the computing module
present inside robots and drones, where typically
far-Edge applications will be instantiated.
Leveraging on network virtualization technologies,
our testbed can also introduce arbitrary
latency, jitter, and packet-loss between each
compute node and the controller.
The objective is to measure (i) the time
required to instantiate a given service and (ii)
the resources utilized by the controller node to
keep the service up and running. This will provide
us an indication of how many compute
nodes and services can be simultaneously managed
in the far-Edge. To that end, we used a reference
lightweight service composed of an
Alpine-based container running an NGINX web
server, which is provisioned before-hand on the
compute nodes so as to avoid copying the
56
Figure 4 illustrates and defines (in the caption)
the RAM load factor measured in the controller
node at the variation of compute nodes
and containers/node. This metric provides the
amount of memory variation between a baseline
(i.e., an empty cluster) while increasing the number
of machines controlled, and the number of
applications running in the cluster in order to
facilitate the comparison between the different
solutions. While each solution presents different
absolute values of RAM usage, we remark that in
every case, the 5th-95th percentiles never
exceed2% of their corresponding median.
In Figure 4, we can see that for a cluster of 10
nodes with 0 containers, Kubernetes uses 27%
more RAM compared with K3s, and 9% more
compared with KubeEdge, while KubeEdge uses
17% more RAM than K3s. If we increase the number
of nodes in the system to 100 with 0 containers,
we can notice that Kubernetes uses 91%
more RAM compared with K3s, and 143% more
than KubeEdge. In such a scenario, Kubernetes,
K3s, and KubeEdge show, respectively, an
increase of RAM usage of 218%, 110%, and 42%
compared with an empty cluster (0 nodes with 0
containers).
We observe that the number of nodes composing
the cluster is the major factor impacting
the overall memory utilization. This is due to
need of the controller to store large amount of
IEEE Consumer Electronics Magazine
IEEE Consumer Electronics Magazine - May/June 2023

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - May/June 2023
