The following detail a couple of the larger goals of Akri: to discover more devices and provide more deployment strategies.
There are endless sensors, controllers, and MCU class devices on the edge and each type of device has a different discovery protocol. Akri is an interface for helping expose those devices as resources to your Kubernetes cluster on the edge. Before it can add a device as a cluster resource, Akri must first discover the device using the appropriate Discovery Handler. Akri currently supports several Discovery Handlers and was built in a modular way so as to continually support more. The question is, which protocols should Akri prioritize? We are looking for community feedback to make this decision. If there is a protocol that you would like implemented, check our Issues to see if that protocol has been requested, and thumbs up it so we know you, too, would like it implemented. If there is no existing request for your protocol, create a new feature request. Rather than waiting for it to be prioritized, you could implement a Discovery Handler for that protocol. See the Discovery Handler development document for more details.
- 1.ONVIF (to discover IP cameras)
- 2.udev (to discover anything in the Linux device file system)
- 3.OPC UA (to discover OPC UA Servers)
Currently, Akri supports two strategies for automatically deploying workloads ("brokers") to discovered devices:
- 1.(Original strategy) For every leaf device that is discovered by a node's Akri Agent, a single non-terminating Pod is deployed to that node -- how many nodes get the broker is limited by capacity.
These are fairly specific implementations that do not support all users' scenarios. A proposal is in progress that brainstorms ways the Akri Controller and Agent could be extended to allow for other broker deployment strategies.