Akri
main
main
  • 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
    • Discovering and Using Authentication-Enabled Onvif Cameras
    • Introduction and Demo Videos
  • Architecture
    • Overview
    • Resource Sharing
    • Controller
    • Agent
    • Configuration-Level Resources
  • 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
On this page
  • Enabling cluster access to resources
  • Handling node disappearances

Was this helpful?

  1. Architecture

Controller

PreviousResource SharingNextAgent

Last updated 3 years ago

Was this helpful?

The Akri Controller executes on the master Node in the cluster. It is primarily tasked with:

  1. Enabling cluster access to leaf devices

  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 . 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. Ensure that the protocol broker Pod based on Configuration.brokerPodSpec is created

  2. Ensure that the broker Service based on Configuration.instanceServiceSpec is created

  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. Ensure that the protocol broker Pod based on Configuration.brokerPodSpec is removed

  2. Ensure that the protocol broker Service based on Configuration.instanceServiceSpec is removed

  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.

Akri Agent