Akri
GitHubSlack
Search…
Home
Using Akri
Getting Started
Kubernetes Cluster Setup
Customizing an Akri Installation
Requesting Akri Resources
Monitoring with Prometheus
Discovery Handlers
ONVIF for IP Cameras
OPC UA
udev
Demos
Discovering and Using USB Cameras
Discovering and Using USB Cameras on Raspberry Pi 4
Discovering and Using OPC UA Thermometers
Architecture
Overview
Resource Sharing
Controller
Agent
Developing for Akri
Developer Guide
Building Containers
Custom Discovery Handlers
Custom Brokers
Mock Discovery Handler for Testing
Walkthrough of Implementing a Custom Discovery Handler and Broker
End to End Test Workflow
Community
Roadmap
Contributing
Powered By GitBook
Controller
The Akri Controller executes on the master Node in the cluster. It is primarily tasked with:
  1. 1.
    Enabling cluster access to leaf devices
  2. 2.
    Handling node disappearances
These tasks enable Akri to provide resources with high availability, while allowing the Kubernetes application to be agnostic about what specific Nodes or Pods are executing at any given moment.

Enabling cluster access to resources

The first step to enable cluster access to resources (leaf devices) is, of course, finding them. The work of discovering resources and making them known to the Kubernetes cluster is handled by the Akri Agent. The Akri Agents ensure that Instances are created and updated to enforce capability sharing.
Once a capability has been discovered and Instances are created, it is up to the Akri Controller to provide cluster access.
To provide access to discovered resources, the Akri Controller works to ensure that the Pods and Services described in the relevant Configuration are running. This is accomplished by listening for changes, additions, and deletions of Instances.
When an instance is created or updated, the Akri Controller needs to do several things:
  1. 1.
    Ensure that the protocol broker Pod based on Configuration.brokerPodSpec is created
  2. 2.
    Ensure that the broker Service based on Configuration.instanceServiceSpec is created
  3. 3.
    Ensure that the capability Service based on Configuration.configurationServiceSpec is created
When an instance is deleted, the Akri Controller needs to do several things:
  1. 1.
    Ensure that the protocol broker Pod based on Configuration.brokerPodSpec is removed
  2. 2.
    Ensure that the protocol broker Service based on Configuration.instanceServiceSpec is removed
  3. 3.
    Ensure that the capability Service based on Configuration.configurationServiceSpec is removed, if there are no Pods supporting the Service (note that many instances can contribute supporting Pods to a given configuration)

Handling node disappearances

One of the conditions we need to be aware of is node disappearance. In this case, we cannot depend on the disappeared node's Akri Agent to modify the relevant Instance. To free up any Configuration.capacity that a node was using prior to disappearing, the Akri Controller watches for Node disappearance events and cleans up any lingering node references in any Instance.nodes and Instance.deviceUsage.
Architecture - Previous
Resource Sharing
Next - Architecture
Agent
Last modified 3mo ago
Copy link
Contents
Enabling cluster access to resources
Handling node disappearances