# Akri <> ioFog

Akri currently runs on top of Kubernetes. Akri is made out of two runtime components, Akri Agent and Akri Controller. Akri Agent has dependencies on CRDs[^CRDs] for its state storage and the DevicePlugin interface to mount[^mount] discovered leaf devices into containers[^crictl]. Akri Controller shares state with Akri Agent through CRDs and further leverages ApiServer to schedule pods based on requested deployment strategy. Besides platform dependencies, Akri leverages its own plugins to perform discovery of leaf devices. These are referred to as Discovery Handlers. Discovery Handlers could run both in-proc and out-of-proc. Either way, Discovery Handlers implement Akri Agent specific interface for communication with Akri Agent. Akri also leverages Brokers, which are the containers that can be automatically deployed by Akri Controller when a new device is discovered. Brokers are provisioned[^mount] with discovered devices. Brokers are only loosely tied to Akri at the moment. A Broker needs to understand what environment variable/dev node Akri mounts into the container in order for the Broker to take advantage of it. Out-of-proc Discovery Handlers and Brokers can be written in any language.

We envision the following possible integration points between Akri and ioFog:
1) *Akri running on ioFog*. In this mode, ioFog replaces the Kubernetes runtime and associated interfaces under Akri. Akri Agent is extended to allow storing its state in ioFog control plane. ioFog Agent is extended to expose DevicePluginManager interface to Akri Agent[^api]. TBD Akri Controller integration with ioFog control plane to leverage the automatic scheduling logic of Akri.

2) *Akri exposes ioFog to Kubernetes*. Akri can detect various devices and can be extended with a Discovery Handler that can discover ioFog nodes or application level services (be it control plane or data plane) running on top of ioFog. This can be then exposed to the Kubernetes cluster so that workloads running on Kubernetes cluster can take advantage of ioFog capabilities.
3) *ioFog Operator replaces Akri Controller*. The ioFog Operator is capable of performing the role of the Akri Controller and acting as the integration point between ioFog Controller and Akri CRs. ioFog Operator would translate Akri CR changes to ioFog Controller API actions. ioFog Controller would schedule Broker Microservices on ioFog Agents.

[^CRDs]: Akri uses two CRDs: Akri Configuration and Akri Instance. Akri Configuration defines which leaf devices are to be discovered through using which Discovery Handler and which Broker to be deployed to handle such devices. Akri Instance is used to represent discovered leaf devices.

[^mount]: Mount dev nodes directly into the containers or pass environment variables with connection information into the containers.

[^crictl]: At the moment, there is also a dependency of Akri Agent on crictl directly, as DevicePlugin is missing cleanup support, however there is a PR against K8s to address this deficiency which will allow us to remove this dependency.

[^api]: The Device Plugin Manager implements the Registration service defined in the [Device Plugin API](https://github.com/kubernetes/kubernetes/blob/cea1d4e20b4a7886d8ff65f34c6d4f95efcb4742/staging/src/k8s.io/kubelet/pkg/apis/deviceplugin/v1alpha/api.proto#L23). For reference, Kubernete's Device Plugin Manager can be found [here](https://github.com/kubernetes/kubernetes/tree/cea1d4e20b4a7886d8ff65f34c6d4f95efcb4742/pkg/kubelet/cm/devicemanager).