Page 46 - Kaleidoscope Academic Conference Proceedings 2021

In brief, Qinling is responsible for creating the environment WAMP control WebSocket
channel tunnel
where users’ functions should be executed. Specifically, when MPU-powered IoT node
Docker
Qinling receives a request to create the runtime for a function, MPU Comtaier
engine
Container
it instantiates (using Zun) the containers (i.e., the capsule9) Reverse Docker
proxy engine
needed for the function execution. In particular, the Qinling s4t wstunnel client
Zun
capsule is composed of three containers used for different plugin compute
purposes: s4t WAMP lib Lightning-Rod s4t plugin agent
loader
engine
WAMP control REST OS tools sensors
channel IoTronic communication and
AMQP (pub/sub, RPC)
Virtual
service • Runtime container: is the isolated environment where Lightning-Rod Board FileSystem actuators
forwarding Networking other
communication
the users’ functions get executed. Qinling supports three
Edge/Fog node GPIO
runtimes, namely Python2, Python3, and Node.js. REST communication
(MPU+MCU)
MPU Capsule AMQP (pub/sub, RPC)
Capsule
Capsule
other communication
• Sidecar container: is the environment where
reverse
required
the
s4t wstunnel plugin proxy packages for Zun the functions are Figure 2 – The device-side deviceless system architecture.
compute
agent
downloaded/stored. This container is used to provide compute node (i.e., an IoT node in our case) can be integrated
plugin
s4t WAMP lib lightning-rod s4t plugin tools Docker board automatically in the COEs’ cluster.
the required packages for the runtime container.
s4t
loader
engine
OS
pins
engine
• Pause container: ensures network reachability for the
sensors
MCU
The
and second aspect that has been extended in Zun is related to
capsule as it is the only one attached to the network. ... actuators
Low-level
I/O the reachability of the containers. Indeed, if we consider
s4t lightning-rod primitives ...
a typical OpenStack deployment, containers reachability
4. DEVICELESS SYSTEM ARCHITECTURE
within a datacenter is assured by the overlay networking
services provided by the OpenStack networking subsystem
In this section, we describe the architecture of the deviceless
Neutron. Nevertheless, for containers deployed outside
system. The system is based on IoTronic/LR and the two
OpenStack cloud-oriented subsystems Zun and Qinling, that datacenters, their reachability can not be handled by usual
have been customized to extend their capabilities and deal cloud mechanisms [20]. For this purpose, we developed
with the particularity of IoT deployments. When compared for Zun a new networking driver that uses IoTronic in order
to make the remote containers reachable. Specifically, the
to typical cloud-based serverless deployments, a major
new driver uses WebSocket as a transport channel with a
modification is that, in our case, we split the Zun components
port forwarding capability provided by the cloud. Therefore,
between the cloud and the nodes deployed at the network edge.
requests reaching the cloud on a specific port will be
In our approach, we consider the (remote) IoT nodes as a
forwarded through the WS tunnel to an associated container
computing infrastructure instead of the cloud-based compute
(i.e., each port is associated with a remote container).
nodes. Therefore, to make this infrastructure reachable by the
cloud subsystems, we used suitable mechanisms to deal with
Besides, we also extended the Zun scheduler. In our
NATs and firewalls traversal (i.e., Websocket tunnels with a
deviceless view, a user will request the setup of a runtime
reversing mechanism). Zun and Qinling can then manage
then the execution of a function on a specific IoT node to get,
the containers and functions deployed at the network edge.
for example, the value of a sensor (or even do a preprocessing
In the following, we report details about the integration of
of this value). The standard Zun scheduling policies do not
Zun and Qinling with IoTronic to cope with IoT environment
provide this kind of control to specify a particular compute
constraints.
node to instantiate a container (a set of filters instead are used
such as RAMFilter, CPUFilter, LabelFilter, etc.). We then
4.1 Deviceless container orchestration
added a new policy based on the name/id of the compute
node called HostnameFilter.
In typical OpenStack serverless deployments, Qinling uses
non-compatible OpenStack COEs (e.g., Kubernetes and
4.2 Deviceless functions execution
Docker Swarm). In such deployments, integrating Zun
compute nodes as part of Kubernetes/Docker Swarm clusters
To create a runtime on a specific IoT node or group of nodes
is not straightforward and requires an intervention by the
and then execute functions on that/those runtime(s), the user
administrator. However, a manual configuration in an IoT
interacts with Qinling through the API. Qinling, afterward,
context is significantly hard because of the large number of
uses Zun and IoTronic to create the containers and ensure
IoT devices that should be managed and the high dynamicity
their network reachability. To enable the selection of the
of IoT deployments (i.e., adding new devices to deployments
IoT nodes or group of nodes on which the runtimes should
or removing others). In such a situation, having an automated
be created, we added a new selection parameter for Qinling
mechanism to include/remove into/from the COE cluster
called NodeName (for a single node) and nodeSelector (for
can bring more flexibility for the system. To deal in our
a group of nodes). The Qinling uses the hostname/id and
situation with this limitation, we have designed for Qinling
labels to send the request to Zun that uses in its turn, the
an OpenStack-compliant COE based on Zun; therefore, a
HostnameFilter and LabelFilter filtering rules, respectively
9 The capsule concept in Qinling is equivalent to the pod concept in (see the previous subsection).
Kubernetes Yet, if an IoT node hosts several runtimes/containers, the
– xlii –