You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Understand the key components in Azure IoT Akri architecture.
3
+
description: Understand the key components in the Azure IoT Akri architecture and how they relate to each other. Includes some information about the CNCF version of Akri
4
4
author: dominicbetts
5
5
ms.author: dobett
6
6
ms.subservice: akri
7
-
ms.topic: concept-article
7
+
ms.topic: conceptual
8
8
ms.custom:
9
9
- ignite-2023
10
-
ms.date: 10/26/2023
10
+
ms.date: 05/13/2024
11
11
12
12
# CustomerIntent: As an industrial edge IT or operations user, I want to understand the key components in the Azure IoT Akri architecture so that I understand how it works to enable device and asset discovery for my edge solution.
This article helps you understand the Azure IoT Akri Preview architecture. By learning the core components of Azure IoT Akri, you can use it to start detecting devices and assets, and adding them to your Kubernetes cluster.
19
+
This article helps you understand the architecture of Azure IoT Akri Preview. After you learn about the core components of Azure IoT Akri, you can use it to detect devices and assets, and add them to your Kubernetes cluster.
20
+
21
+
Azure IoT Akri is a Microsoft-managed commercial version of [Akri](https://docs.akri.sh/), an open-source Cloud Native Computing Foundation (CNCF) project.
20
22
21
23
## Core components
22
-
Azure IoT Akri consists of five components: two custom resources, Discovery Handlers, an Agent (device plugin implementation), and a custom Controller.
23
24
24
-
-**Akri Configuration**. The first custom resource, Akri Configuration, is where you name a device. This configuration tells Azure Iot Akri what kind of device to look for.
25
-
-**Akri Discovery Handlers**. The Discovery Handlers look for the configured device and inform the Agent of discovered devices.
26
-
-**Akri Agent**. The Agent creates the second custom resource, the Akri Instance.
27
-
-**Akri Instance**. The second custom resource, Akri Instance, tracks the availability and usage of the device. Each Akri Instance represents a leaf device.
28
-
-**Akri Controller**. After the configured device is found, the Akri Controller helps you use it. The Controller sees each Akri Instance and deploys a broker Pod that knows how to connect to the resource and utilize it.
25
+
Azure IoT Akri consists of the following five components:
-**Akri configuration** is a custom resource where you name a device. This configuration tells Azure Iot Akri what kind of devices to look for.
28
+
-**Akri instance** is a custom resource that tracks the availability and usage of a device. Each Akri instance represents a leaf device.
29
+
-**Akri discovery handlers** look for the configured device and inform the agent about discovered devices.
30
+
-**Akri agent** creates the Akri instance custom resource.
31
+
-**Akri controller** helps you to use a configured device. The controller sees each Akri instance and deploys a broker pod that knows how to connect to and use the resource.
A Custom Resource Definition (CRD) is a Kubernetes API extension that lets you define new object types.
35
+
##Custom resource definitions
35
36
36
-
There are two Azure IoT Akri CRDs:
37
+
A custom resource definition (CRD) is a Kubernetes API extension that lets you define new object types. There are two Azure IoT Akri CRDs:
37
38
38
39
- Configuration
39
40
- Instance
40
41
41
-
### Akri Configuration CRD
42
-
The Configuration CRD is used to configure Azure IoT Akri. Users create configurations to describe what resources should be discovered and what pod should be deployed on the nodes that discover a resource. See the [Akri Configuration CRD](https://github.com/project-akri/akri/blob/main/deployment/helm/crds/akri-configuration-crd.yaml). The CRD schema specifies what components all configurations must have, including the following components:
42
+
### Akri configuration CRD
43
43
44
-
- The desired discovery protocol for finding resources. For example, ONVIF or udev.
45
-
- A capacity (`spec.capacity`) that defines the maximum number of nodes that can schedule workloads on this resource.
46
-
- A PodSpec (`spec.brokerPodSpec`) that defines the "broker" pod that is scheduled to each of these reported resources.
47
-
- A ServiceSpec (`spec.instanceServiceSpec`) that defines the service that provides a single stable endpoint to access each individual resource's set of broker pods.
48
-
- A ServiceSpec (`spec.configurationServiceSpec`) that defines the service that provides a single stable endpoint to access the set of all brokers for all resources associated with the configuration.
44
+
The configuration CRD configures Azure IoT Akri. You create configurations that describe the resources to discover and the pod to deploy on a node that discovers a resource. To learn more, see [Akri Configuration CRD](https://github.com/project-akri/akri/blob/main/deployment/helm/crds/akri-configuration-crd.yaml). The CRD schema specifies the settings all configurations must have, including the following settings:
49
45
50
-
### Akri Instance CRD
51
-
Each Azure IoT Akri Instance represents an individual resource that is visible to the cluster. For example, if there are five IP cameras visible to the cluster, there are five Instances. The Instance CRD enables Azure IoT Akri coordination and resource sharing. These instances store internal state and aren't intended for users to edit. For more information on resource sharing, see [Resource Sharing In-depth](https://docs.akri.sh/architecture/resource-sharing-in-depth).
46
+
- The discovery protocol for finding resources. For example, ONVIF or udev.
47
+
-`spec.capacity` that defines the maximum number of nodes that can schedule workloads on this resource.
48
+
-`spec.brokerPodSpec` that defines the broker pod to schedule for each of these reported resources.
49
+
-`spec.instanceServiceSpec` that defines the service that provides a single stable endpoint to access each individual resource's set of broker pods.
50
+
-`spec.configurationServiceSpec` that defines the service that provides a single stable endpoint to access the set of all brokers for all resources associated with the configuration.
51
+
52
+
### Akri instance CRD
53
+
54
+
Each Azure IoT Akri instance represents an individual resource that's visible to the cluster. For example, if there are five IP cameras visible to the cluster, there are five instances. The instance CRD enables Azure IoT Akri coordination and resource sharing. These instances store internal state and aren't intended for you to edit. To learn more, see [Resource sharing in-depth](https://docs.akri.sh/architecture/resource-sharing-in-depth).
52
55
53
56
## Agent
54
-
The Akri Agent implements [Kubernetes Device-Plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for discovered resources.
55
57
56
-
The Akri Agent performs the following workflow:
58
+
The Akri agent implements [Kubernetes Device-Plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for discovered resources. The Akri Agent performs the following tasks:
57
59
58
-
-Watch for Configuration changes to determine what resources to search for.
59
-
-Monitor resource availability to determine what resources to advertise. In an edge environment, resource availability changes often.
60
-
-Inform Kubernetes of resource health and availability as it changes.
60
+
-It watches for configuration changes to determine the resources to search for.
61
+
-It monitors resource availability to determine what resources to advertise. In an edge environment, resource availability changes often.
62
+
-It informs Kubernetes of any changes to resource health and availability.
61
63
62
-
This basic workflow combined with the state stored in the Instance, allows multiple nodes to share a resource while respecting the limitations defined by `Configuration.capacity`.
64
+
These tasks, combined with the state stored in the instance, enable multiple nodes to share a resource while respecting the limits defined by the `spec.capacity` setting.
63
65
64
-
For a more in-depth understanding, see the documentation for [Agent In-depth](https://docs.akri.sh/architecture/agent-in-depth).
66
+
To learn more, see [Agent in-depth](https://docs.akri.sh/architecture/agent-in-depth).
65
67
66
-
## Discovery Handlers
67
-
A Discovery Handler finds devices around the cluster. Devices can be connected to Nodes (for example, USB sensors), embedded in Nodes (for example, GPUs), or on the network (for example, IP cameras). The Discovery Handler reports all discovered devices to the Agent. There are often protocol implementations for discovering a set of devices, whether a network protocol like OPC UA or a proprietary protocol. Discovery Handlers implement the `DiscoveryHandler` service defined in [`discovery.proto`](https://github.com/project-akri/akri/blob/main/discovery-utils/proto/discovery.proto). A Discovery Handler is required to register with the Agent, which hosts the `Registration` service defined in [`discovery.proto`](https://github.com/project-akri/akri/blob/main/discovery-utils/proto/discovery.proto).
68
+
## Discovery handlers
68
69
69
-
To get started creating a Discovery Handler, see the documentation for [Discovery Handler development](https://docs.akri.sh/development/handler-development).
70
+
A discovery handler finds devices. Examples of device include:
70
71
71
-
## Controller
72
-
The Akri Controller serves two purposes:
72
+
- USB sensors connected to nodes.
73
+
- GPUs embedded in nodes.
74
+
- IP cameras on the network.
73
75
74
-
- Create or delete the pods & services that enable resource availability
75
-
- Ensure that Instances are aligned to the cluster state at any given moment
76
+
The discovery handler reports all discovered devices to the agent. There are often protocol implementations for discovering a set of devices, whether a network protocol like OPC UA or a proprietary protocol. Discovery handlers implement the `DiscoveryHandler` service defined in [`discovery.proto`](https://github.com/project-akri/akri/blob/main/discovery-utils/proto/discovery.proto). A discovery handler is required to register with the agent, which hosts the `Registration` service defined in [`discovery.proto`](https://github.com/project-akri/akri/blob/main/discovery-utils/proto/discovery.proto).
76
77
77
-
The Controller performs the following workflow:
78
+
To learn more, see [Custom Discovery Handlers](https://docs.akri.sh/development/handler-development).
78
79
79
-
- Watch for Instance changes to determine what pods and services should exist
80
-
- Watch for Nodes that are contained in Instances that no longer exist
80
+
## Controller
81
81
82
-
This basic workflow allows the Akri Controller to ensure that protocol brokers and Kubernetes Services are running on all nodes, and exposing desired resources, while respecting the limits defined by `Configuration.capacity`.
82
+
The goals of the Akri controller are to:
83
83
84
-
For more information, see the documentation for [Controller In-depth](https://docs.akri.sh/architecture/controller-in-depth).
84
+
- Create or delete the pods and services that enable resource availability.
85
+
- Ensure that instances are aligned to the cluster state at any given moment.
86
+
87
+
To achieve these goals, the controller:
85
88
86
-
## Related content
89
+
- Watches out for instance changes to determine what pods and services should exist.
90
+
- Watches for nodes that are contained in instances that no longer exist.
87
91
88
-
-[Azure IoT Akri overview](overview-akri.md)
92
+
These tasks enable the Akri controller to ensure that protocol brokers and Kubernetes services are running on all nodes and exposing the desired resources, while respecting the limits defined by the `spec.capacity` setting.
93
+
94
+
For more information, see the documentation for [Controller In-depth](https://docs.akri.sh/architecture/controller-in-depth).
0 commit comments