One of the awkward problems in edge IoT deployments is that Kubernetes doesn’t naturally know about your physical devices. It knows about nodes, pods, and services. It doesn’t know there’s a camera attached to a factory floor node, or that a USB sensor plugged into an edge gateway is available for workloads that need it. You end up either writing custom resource management code or handling device allocation outside Kubernetes entirely. Akri was created specifically to solve this gap.

Akri (A Kubernetes Resource Interface) is a CNCF sandbox project originally developed at Microsoft and contributed to the community. The basic idea: it discovers devices on your edge network, advertises them to the Kubernetes control plane as custom resources, and lets your scheduler assign workloads to pods that need specific device access. Device discovery becomes part of your Kubernetes infrastructure rather than a separate system you have to maintain.

How Akri Actually Works

Akri installs as a Helm chart and runs two main components. The Agent runs as a DaemonSet on every node and continuously scans for devices using discovery handlers. The Controller watches for device instances and creates the Kubernetes resources that represent them.

When the Agent finds a device, it creates an Instance custom resource that describes what’s available: where the device is, how to access it, what protocol it speaks. The Controller then creates a service pointing to the node where the device is accessible. Pods that need camera access, for example, can request it through a standard Kubernetes resource request.

Discovery handlers define how Akri looks for devices. Out of the box there’s ONVIF for IP cameras, OPC-UA for industrial automation equipment, and udev for USB-attached devices. The protocol list has expanded with community contributions. If your device uses something more exotic, you can write a custom discovery handler in Rust or any language that implements the gRPC interface Akri defines.

The ONVIF Camera Use Case

IP cameras are the clearest example of where Akri earns its place. A factory floor with forty cameras spread across five edge nodes is a real configuration management headache without some form of device abstraction. You need to know which cameras are connected to which nodes, whether any have gone offline, and how to route computer vision workloads to pods that can actually reach the camera they need.

With Akri, each camera shows up as a custom resource. The Akri Controller keeps the resource list updated as cameras connect and disconnect. A computer vision workload that needs to process a specific camera’s stream requests the appropriate Akri resource, and Kubernetes schedules the pod to the node where that camera is accessible. The workload doesn’t need to know the camera’s IP address or which physical node it’s on.

This is particularly useful for AI vision workloads at the edge. An anomaly detection model that needs to process a production line camera can be scheduled automatically to wherever that camera’s feed is accessible, without manual configuration on each node.

OPC-UA and Industrial Automation

The OPC-UA discovery handler makes Akri useful in industrial settings where PLCs and industrial sensors publish data over OPC-UA. Akri discovers OPC-UA servers on the network and creates Kubernetes resources representing each endpoint. Workloads that need to read sensor data or monitor equipment can request these resources through standard Kubernetes primitives.

This is still more niche than the camera use case, but it’s valuable for operations where you want to unify your IoT data collection under the same orchestration layer as your compute workloads. Running data ingestion and preprocessing containers that automatically discover and connect to the available OPC-UA servers on a node is a cleaner model than manually configuring each container with connection strings.

Integrating with k3s at the Edge

Akri works with standard Kubernetes but is particularly well-suited to k3s, the lightweight Kubernetes distribution most commonly used at industrial edge sites and IoT gateways. k3s runs comfortably on hardware like Raspberry Pi 5, NVIDIA Jetson devices, and industrial x86 gateways where full Kubernetes would be resource-prohibitive.

The combination of k3s for orchestration and Akri for device management gives you a complete edge platform that can handle device discovery, workload scheduling, and over-the-air updates through standard Kubernetes tooling. It’s a meaningful improvement over managing each edge node manually or building custom device management layers.

Limitations to Know About

Akri is still a sandbox project and the discovery handler ecosystem, while growing, is limited compared to mature IoT platforms like Azure IoT Edge or AWS Greengrass. If your device uses a proprietary protocol or a transport that doesn’t have an existing Akri handler, you’ll need to write your own, which requires Rust knowledge or comfort with gRPC protocol buffers.

The project also assumes you’re already using Kubernetes at the edge. If you’re not, Akri doesn’t help and you’d be better served by evaluating whether k3s or k0s is the right starting point before looking at device management abstractions on top.

For teams that are already running Kubernetes or k3s at edge sites and are struggling with device management, Akri is worth evaluating seriously. It fills a genuine gap in the ecosystem and integrates cleanly with existing Kubernetes tooling, which is more than you can say for most IoT device management solutions.

Getting Started

The Akri documentation is good and the Helm chart installation is straightforward. Start with the ONVIF configuration if you have IP cameras, since it’s the most mature handler and there are working examples in the documentation that you can adapt directly.

helm repo add akri-helm-charts https://project-akri.github.io/akri/
helm repo update
helm install akri akri-helm-charts/akri \
  --set onvif.discovery.enabled=true

From there, check the custom resources Akri creates to see how your cameras appear as Kubernetes resources, then write a simple pod spec that requests the camera resource to see the scheduling in action.