The RAINBOW Sidecar Proxy is a component that is responsible for handling several aspects of the IoT edge stack. First and foremost, each edge node will be seamlessly connected to a logical Kubernetes cluster, managed by the RAINBOW Orchestrator. Hence, a Kubernetes cluster comprises stationary resources (Data Center oriented) and IoT/Fog resources that connect to the logically centralized Kubernetes, i.e., the RAINBOW Orchestrator, upon their onboarding on a mesh network. This is a huge differentiation from the orchestration point of view since for the mesh resources there is no direct physical connection from each node to a Kubernetes server. Upon joining a mesh and connecting to the RAINBOW Orchestrator, newly developed Kubernetes custom resources will undertake the task of managing the lifecycle of the deployed applications. It goes without saying that lifecycle management employs additional layer-7 programmability that can be performed transparently to the deployed applications.
Under this context the Sidecar Proxy is a one-stop-shop endpoint that handles all edge-related operations of a node from the very beginning (i.e., when this node is not connected to a logical Kubernetes server) to the very end (i.e., when the node is decommissioned from the cluster). Functionality-wise, the proxy consists of five sub-modules. These sub-modules are:
- Device Management
- Mesh Overlay Management,
- Kubelet Control Plane Management
- Attestation Handler
- Layer-7 instance Control Plane Management.
The Device Management module is responsible for probing the capabilities of the fog node and reporting its readiness level regarding its participation in an overlay and subsequently to Kubernetes cluster. As a result, several binary artefacts that must exist in a RAINBOW Node are verified by the Device Management capabilities. These binaries refer mainly to the modified CJDNS mesh stack and the physical or virtual TPM resource manager.
The Mesh Overlay Management Module undertakes the task of joining a mesh overlay. This is an essential operation, since through a cluster-head that will be selected based on criteria, such as its hardware capabilities, network connection, and battery life, a fog node can be routed to a logical Kubernetes cluster.
The kubelet Control Plane Management module is responsible for joining a “logically centralized” Kubernetes server. This participation is very crucial, because the RAINBOW Orchestrator, as well as all Service Level Objectives that are handled during runtime, assume that everything in the platform is expressed as Kubernetes resources. Hence, joining a cluster as a “labelled” resource is the master prerequisite for accepting deployment requests.
The Layer-7 instance Control Plane Management module is responsible for managing the transparent proxy that is installed on top of each container deployment. It has to be clarified that RAINBOW will not implement a new transparent proxy; instead, it reuses the control plane API of existing ones (e.g., Envoy).
