# Akri lets you name an edge device and have Kubernetes schedule against it

> Akri is a CNCF Sandbox project in Rust that exposes leaf devices such as IP cameras and USB hardware as Kubernetes resources, by extending the device plugin framework to handle devices that appear and disappear. You write an Akri Configuration, a Discovery Handler finds the device, and a broker pod is deployed to use it.

**project-akri/akri** — A Kubernetes Resource Interface for the Edge

- Repository: https://github.com/project-akri/akri
- Website: https://docs.akri.sh/
- Stars: 1,265 · Forks: 169
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/project-akri-akri

## Naming a device and having the cluster find it

Akri is a Cloud Native Computing Foundation Sandbox project, and the one line summary is the best description of it. You name it, Akri finds it, you use it.

The problem it addresses is at the edge. There are a variety of sensors, controllers and microcontroller class devices producing data and performing actions, and for Kubernetes to be a viable edge computing solution these heterogeneous leaf devices need to be easily used by Kubernetes clusters.

The obstacle is size. Many of these leaf devices are too small to run Kubernetes themselves, so something else has to represent them to the cluster. That is what Akri does: it exposes them as resources in a Kubernetes cluster, and it also supports the exposure of embedded hardware resources such as GPUs and FPGAs.

The implementation is Rust, the licence is Apache-2.0, the documentation is at docs.akri.sh, and the last push was on 2026-10-11 with the v0.14.0 release on 2026-09-01. The v0.13.8 release before it is from November 2024, so the recent history is a jump from a long quiet period to a faster one.

The badges set the floor, and they are worth reading as requirements. Rust 1.88.0, Kubernetes 1.33 or newer, and coverage tracked through codecov, with the OpenSSF best practices badge alongside.

## Why the device plugin framework was not enough

The Why Akri section is where the technical argument is, and it is a good one.

Akri leverages and extends the Kubernetes device plugin framework, which was created with the cloud in mind and focuses on advertising static resources such as GPUs and other system hardware. Akri took this framework and applied it to the edge, where there is a diverse set of leaf devices with unique communication protocols and intermittent availability.

That is the crux. A GPU is plugged into the machine and stays there, so the device plugin model, where a node advertises what it has, works fine. A camera on a road junction can be unplugged, a USB sensor can fail, and a device that is present today can be gone tomorrow. A static advertisement becomes wrong the moment the hardware changes, and the cluster has no way to know.

Akri is made for the edge, handling the dynamic appearance and disappearance of leaf devices. The discovery mechanism is the part that answers it, and the design is described as an abstraction layer similar to CNI, except that instead of abstracting the underlying network details, it removes the work of finding, utilising and monitoring the availability of the leaf device.

That analogy is instructive. CNI solved the same class of problem for networking, where a device can appear on any node at any time, and the solution was an abstraction plus a controller. Akri is applying a known shape to a different resource type.

## Five components and a three step flow

The architecture is made up of five key components: two custom resources, Discovery Handlers, an Agent, and a custom Controller. The How Akri Works section walks through them in the order they act.

The first custom resource is the Akri Configuration, which is where you name it. This tells Akri what kind of device it should look for, and the operator applies it to a cluster specifying the Discovery Handler to use, for example ONVIF, and the Pod that should be deployed upon discovery, for example a video frame server.

Then Akri finds it. The Discovery Handlers look for the device and inform the Agent of discovered devices, and the Agent then creates the second custom resource, the Akri Instance, to track the availability and usage of the device.

Finally the Akri Controller helps you use it. It sees each Akri Instance, which represents a leaf device, and deploys a broker Pod that knows how to connect to the resource and utilise it.

So the flow is Configuration, then Instance, then broker, with the Discovery Handler as the thing that actually talks to the hardware and the Agent as the node-local component that reports what it found.

That separation is what makes the system work at the edge. The device is discovered by a handler that speaks its protocol, the availability is recorded as a cluster object, and the workload is scheduled against that object by a controller, so the same pattern works whether the device is an ONVIF camera or a udev device.

## High availability and a service per device type

Two features come out of the design rather than being added to it, and both solve problems that edge deployments hit immediately.

The first is high availability. An operator can allow multiple nodes to utilise a leaf device, thereby providing high availability in the case where a node goes offline. That is a direct consequence of the device being represented as a cluster object rather than being bound to the node it is plugged into. The scheduler can place a second copy elsewhere and the workload keeps running.

The second is that Akri will automatically create a Kubernetes service for each type of leaf device, or each Akri Configuration, removing the need for an application to track the state of pods or nodes.

That second one is the bigger ergonomic win. Without it, an application that wants to talk to a camera has to know which node the camera is attached to and which pod is currently bound to it, and that information changes. With the service, the application connects to a stable name and the service tracks the moving parts underneath.

It also explains the broker pod in the architecture. The broker is the thing that knows how to connect to the device, and the service puts a stable address in front of it, so the application never has to know the protocol.

## The Discovery Handlers are the extension point

Akri was built to be extensible, and the readme says so in bold, which tells you where the project wants contributions.

Akri currently ships ONVIF, udev, OPC UA and debug-echo Discovery Handlers, and more can be easily added by community members. The more protocols Akri can support, the wider an array of leaf devices it can discover.

ONVIF is the video surveillance protocol, so cameras are the worked example, and the quick start demo uses mock video cameras with a streaming app displaying the footage, with a separate Raspberry Pi 4 demo if you want to try it on real hardware. udev is the Linux device database, so it covers generic USB and pluggable hardware. OPC UA is the industrial protocol for factory automation. And debug-echo is the protocol you implement first when you are building a handler, because it does nothing but echo.

The Roadmap section turns that into a process. There is a Discovery Handler implementation roadmap to prioritise development, and the invitation is to create an issue if there is a protocol that should be prioritised, or better yet to contribute the implementation.

Two other extension points are documented. There is a guide to how to extend Akri for protocols that have not been supported yet, and a guide to how to create a broker to leverage discovered devices. So the extension surface is a matched pair: a handler to find the device, and a broker to use it.

## A Rust workspace with a patched dependency and a Python side

The repository is a Cargo workspace with a dozen members and a pyproject file, so the project is not purely Rust.

The Cargo workspace members are shared, agent, controller, webhooks/validating/configuration, discovery-utils, and then the four discovery handlers and their four modules, one each for debug-echo, onvif, opcua and udev. The workspace package version is 0.14.0, the edition is 2024, the licence is Apache-2.0 and the rust-version is 1.88.

The most interesting part of the Cargo file is the patch section.

```toml
[patch.crates-io]
h2 = { git = 'https://github.com/project-akri/h2', rev = 'e01e8842a37bc3590228e9ab408fc1710018c031'}
```

The comment above it explains the reasoning. The patch is still needed, using one from an upstream pull request for now, hosted on a fork of the project's own to help with supply chain integrity, and the revision is pinned by commit so a future cargo update cannot silently move the patch, which is how it previously went stale.

That is a good practice and a good warning. A git patch to a widely used HTTP/2 library is a supply chain decision, and pinning the revision is what makes it reviewable. The comment also admits the patch exists because an upstream change has not landed, which is a maintenance liability the project is carrying openly.

The Python side is smaller. The pyproject file names the project akri, requires Python 3.10 or newer, and depends on pytest, the Kubernetes Python client at version 32.0.1 and pyyaml, with poetry-core as the build backend. That is the testing and tooling side rather than the runtime.

## Multi-arch images, a version file and three CI workflows

The Makefile shows how the container images are produced, and the details matter for a project that ships to ARM devices.

The default platform set is amd64, arm64 and arm/v7, which is the interesting line. An edge project that has to run on a Raspberry Pi 4 needs arm/v7, which is a 32 bit ARM target, and most projects that claim ARM support mean only arm64. The DOCKER_PLATFORMS variable turns the list into linux/ prefixed platform strings for the build, and a build can be loaded locally into the Docker daemon or pushed to a registry, with a check that a local load cannot be requested for more than one platform.

The Agent build is configurable per feature set, with AGENT_FEATURES taking names like onvif-feat, opcua-feat and udev-feat to choose which Discovery Handlers get embedded in the Agent binary.

The version comes from a file, with VERSION evaluated by reading version.txt, and the build label combines it with a timestamp so each image is identifiable. The Makefile includes the container definitions from build/intermediate-containers.mk and build/akri-containers.mk, and the default target builds both akri and an opencv base image, which is what the vision handlers need.

The CI workflows in the badges match that. There is a Check Rust workflow for formatting and linting, a Tarpaulin code coverage workflow for the Rust code, and a test workflow that runs against K3s, Kubernetes and MicroK8s, which is the only way to be confident about a project that only really exists inside a cluster.

## Conclusion

Adopt Akri when you run Kubernetes at the edge and have devices that come and go, cameras or USB sensors that a static device plugin cannot describe, and you want the scheduling handled for you. Do not adopt it for a data centre workload with stable GPUs, because that is what the upstream device plugin framework already does. Verify first that a Discovery Handler exists for your protocol or that you are prepared to write one, since the shipped set is ONVIF, udev, OPC UA and a debug echo, and that the Kubernetes version in your cluster is 1.33 or newer.

## FAQ

### What is Akri?

It is a Cloud Native Computing Foundation Sandbox project that lets you expose heterogeneous leaf devices, such as IP cameras and USB devices, as resources in a Kubernetes cluster, while also supporting the exposure of embedded hardware resources such as GPUs and FPGAs. It continually detects nodes with access to those devices and schedules workloads based on them.

### How does Akri find a device?

Through Discovery Handlers. You apply an Akri Configuration naming the handler to use, the handler looks for the device and informs the Agent, the Agent creates an Akri Instance to track its availability and usage, and the Controller deploys a broker pod that knows how to connect to it.

### Which protocols does Akri support out of the box?

ONVIF, udev, OPC UA and a debug-echo handler. The project ships a Discovery Handler implementation roadmap, and asks for issues or contributions for protocols that should be added.

### Why not just use the Kubernetes device plugin framework?

That framework was created with the cloud in mind and focuses on advertising static resources such as GPUs. Akri applies it to the edge, where leaf devices have unique communication protocols and intermittent availability, so the dynamic appearance and disappearance of devices is handled.

### How does Akri handle a node failure with a device attached?

An operator can allow multiple nodes to utilise a leaf device, which provides high availability when a node goes offline. Akri also automatically creates a Kubernetes service for each type of leaf device, so an application does not need to track the state of pods or nodes.

### What are the requirements for Akri?

The badges state Rust 1.88.0 and Kubernetes 1.33 or newer, and the Cargo workspace pins rust-version 1.88 with edition 2024. The images are built for amd64, arm64 and arm/v7, so a Raspberry Pi 4 is supported.

## Sources

- [License: Apache-2.0](https://github.com/project-akri/akri/blob/main/LICENSE)
- [project-akri/akri on GitHub](https://github.com/project-akri/akri)
- [Project website](https://docs.akri.sh/)
- [README](https://github.com/project-akri/akri/blob/main/README.md)
- [Releases](https://github.com/project-akri/akri/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/project-akri-akri