Chapter 2
Akri System Architecture and Components
Peel back the layers of Akri and discover how its architecture turns Kubernetes into a powerful platform for seamless edge device discovery and abstraction. This chapter provides the technical blueprint for Akri's core components and extensibility, revealing how modularity, security, and design patterns converge to orchestrate resources beyond native Kubernetes capabilities.
2.1 Akri Core Concepts: Agents, Controllers, Brokers
Akri's architecture fundamentally hinges on three core components: Agents, Controllers, and Brokers. Together, they form a resilient system that enables seamless discovery, orchestration, and consumption of heterogeneous edge devices in Kubernetes clusters. Understanding these building blocks, their distinct responsibilities, and their interactions is essential for comprehending how Akri operates effectively at scale.
Agents: Device Discovery and State Reporting
Agents are the primary interface between Akri and the physical edge devices deployed across the infrastructure. Each Agent is a lightweight process typically running on a Kubernetes node, responsible for the active discovery and monitoring of local devices. Agents implement device-specific discovery protocols and maintain continual awareness of device states.
The discovery process executed by an Agent involves probing hardware interfaces, networked peripherals, or other system resources using a device-specific mechanism encapsulated as a discovery handler. For example, USB devices might be detected via udev events on Linux nodes, while network cameras may be discovered using multicast DNS or proprietary protocols. Once a device is detected, the Agent constructs a detailed device descriptor containing metadata such as device identifiers, capabilities, health status, and availability.
Agents continuously monitor discovered devices to detect state changes, such as device disconnections, failures, or resource updates. These changes are promptly reported to the cluster's central control plane, ensuring that the Akri system maintains a current and accurate device inventory. Importantly, Agents operate asynchronously and independently on each node, distributing the discovery workload and reducing centralized bottlenecks.
Controllers: State Coordination and Resource Representation
The Controllers serve as the logical orchestrators within the Akri ecosystem, primarily functioning inside the Kubernetes control plane. They consume the device state data reported by Agents and reconcile it against the desired state defined by Akri custom resources. Controllers are implemented as Kubernetes controllers adhering to the Operator pattern, reacting to events and changes via the Kubernetes API.
Each Controller manages one or more Akri resource types, notably the Discovery and Instance custom resources. A Discovery resource declares the desired criteria to find devices across the cluster-such as specific model types, vendor IDs, or device capabilities. Using the data supplied by Agents, Controllers evaluate which devices match these criteria.
Matched devices result in the creation or updating of Instance resources that represent bindings between discovered devices and the consumers requesting their usage. Instances encapsulate device access endpoints, permissions, and lifecycle metadata. Controllers continuously reconcile these resources to handle dynamic device availability, enforcing synchronization between actual devices and Kubernetes resource objects.
Besides state maintenance, Controllers implement policy logic related to resource allocation, usage quotas, and prioritization in multi-tenant environments. They also drive the propagation of device information to other Akri components, notably Brokers, ensuring downstream systems consume consistent device state.
Brokers: Mediating Resource Access and Consumption
Brokers act as intermediaries that mediate resource consumption by exposing discovered devices to workloads and services running within the cluster. Unlike Agents and Controllers, Brokers often operate as sidecar containers, gateway services, or custom networking proxies that provide uniform access endpoints to heterogeneous devices.
Given that devices discovered may vary significantly in protocols, naming conventions, and connectivity semantics, Brokers perform essential translation and multiplexing duties. They abstract device heterogeneity by presenting standardized APIs or interfaces to clients. This abstraction simplifies developer interaction, removes the need for specialized drivers, and enables transparent access regardless of underlying device specifics.
Brokers leverage the Instance resources maintained by Controllers to establish and manage device bindings. When a workload requires device access, it communicates with the Broker, which proxies requests to the correct device endpoints. Brokers also enforce access control, handle concurrent connections, and maintain operational state such as connection health or session persistence.
The Broker layer is designed to be scalable and fault-tolerant, often capable of running replicated instances across the cluster. This ensures continuous mediation of device access despite node failures or network partitions. Additionally, Brokers facilitate device usage auditing and telemetry by recording access patterns and performance metrics.
Interaction and State Flow Among Components
The interplay between Agents, Controllers, and Brokers is orchestrated through Kubernetes' native API mechanisms and event-driven communication. Initially, Agents detect and report devices, creating a real-time, distributed device inventory. Controllers ingest this inventory to update the cluster resources, performing dynamic reconciliation to reflect device availability and binding instances.
Once devices are formalized as Instance resources, Brokers establish access pathways for workloads. Brokers monitor the Instance resources for changes, reacting to instance creations or deletions by adjusting the exposure of devices accordingly. Through this loop, Akri achieves a continuous feedback cycle in which device discovery, resource representation, and access mediation remain synchronized.
This architecture supports decentralized discovery while providing centralized coordination and controlled consumption. The system gracefully manages device churn and scaling by consolidating knowledge in the Controllers and enabling Brokers to provide high-level operational interfaces. The design also facilitates extensibility: new Agents can be introduced to support additional device types, Controllers may implement advanced policies, and Brokers can evolve to support novel access paradigms without disrupting the core discovery infrastructure.
Summary of Responsibilities and Workflow
- Agents: Detect local devices, track device status changes, and report detailed descriptors upstream.
- Controllers: Coordinate cluster-wide device state, maintain Kubernetes custom resources reflecting device availability, and implement resource allocation logic.
- Brokers: Abstract and mediate device access for consumers, transform heterogeneous protocols into standardized interfaces, and manage runtime connections.
This triad of components collectively transforms ephemeral, distributed physical devices into manageable, consumable Kubernetes resources, thereby extending the orchestration paradigm from pure compute and storage to the edge device domain. This extension lays the foundation for greater integration between cloud-native applications and the physical world, opening avenues for advanced edge computing scenarios.
2.2 Discovery Handlers and Protocol Abstraction
Akri's capacity to interact with a broad spectrum of devices, ranging from complex industrial sensors to diverse consumer Internet of Things (IoT) endpoints, relies fundamentally on its protocol-agnostic discovery framework. This framework is realized through a design that prioritizes extensibility and modularity via pluggable discovery handlers, fostering seamless integration across heterogeneous environments. In this section, the architecture and operational dynamics of Akri's discovery handlers are examined in detail, elucidating how protocol abstraction underpins scalability and adaptability.
At the core of Akri's discovery mechanism lies the concept of discovery handlers, modular components responsible for actively or passively identifying devices in the network environment. Unlike monolithic implementations that hardcode protocol specifics, Akri employs a pluggable handler model, where each handler encapsulates the logic to detect devices according to a single or family of protocols. This segregation of concerns mitigates complexity by isolating protocol-specific implementations from the broader system, enabling incremental support for emerging or proprietary protocols without disrupting established operations.
Discovery handlers...
