Roadmap
Last updated
Was this helpful?
Last updated
Was this helpful?
Akri uses a to track issues. The board illustrates what features are requested by community members, currently being investigated, and under development. We review the project board each to make sure all issues are addressed and categorized. Additionally, Akri is currently working towards a full-feature stable v1.0
release. Reference the to see what exciting features and milestones are coming to Akri v1.0
.
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 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 . Rather than waiting for it to be prioritized, you could implement a Discovery Handler for that protocol. See for more details.
ONVIF (to discover IP cameras)
udev (to discover anything in the Linux device file system)
OPC UA (to discover OPC UA Servers)
Bluetooth
CoAP -
Simple scan for IP/MAC addresses
LoRaWAN
Zeroconf -
acpid -
MQTT? -
Looking for community feedback for more!
Currently, Akri supports two strategies for automatically deploying workloads ("brokers") to discovered devices:
(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.
(Job brokers) For every leaf device that is discovered (by any Agent), a single terminating Kubernetes Job is deployed.
These are fairly specific implementations that do not support all users' scenarios. A that brainstorms ways the Akri Controller and Agent could be extended to allow for other broker deployment strategies.