Customizing an Akri Installation
The ONVIF, udev, and OPC UA Configurations documentation explains how to deploy Akri and utilize a specific Discovery Handler using Helm (more information about the Akri Helm charts can be found in the user guide). This documentation elaborates upon them, covering the following:
Starting Akri without any Configurations
Generating, modifying and applying a Configuration
Deploying multiple Configurations
Modifying a deployed Configuration
Adding another Configuration to a cluster
Modifying a broker
Deleting a Configuration from a cluster
Applying Discovery Handlers
Starting Akri without any Configurations
To install Akri without any protocol Configurations, run this:
This will deploy the Akri Controller and deploy Akri Agents.
Generating, modifying and applying a Configuration
Helm allows us to parametrize the commonly modified fields in our Configuration templates and we have provided many (to see them, run helm inspect values akri-helm-charts/akri
). For more advanced Configuration changes that are not aided by our Helm chart, we suggest creating a Configuration file using Helm and then manually modifying it.
For example, to create an ONVIF Configuration file, run the following. (To instead create a udev Configuration, substitute onvif.configuration.enabled
with udev.configuration.enabled
and add a udev rule. For OPC UA, substitute with opcua.configuration.enabled
.)
Note, that for the broker pod image, nginx was specified. Insert your broker image instead or remove the broker pod image from the installation command to generate a Configuration without a broker PodSpec or ServiceSpecs. Once you have modified the yaml file, you can apply the new Configuration to the cluster with standard kubectl like this:
When modifying the Configuration, do not remove the resource request and limit {{PLACEHOLDER}}
. The Controller inserts the request for the discovered device/Instance here.
The following sections explain some of the ways the configuration.yaml could be modified to customize settings/fields that cannot be set with Akri's Helm Chart.
Modifying the brokerPodSpec
The brokerPodSpec
property is a full PodSpec and can be modified as such. For example, to allow the master Node to have a protocol broker Pod scheduled to it, modify the Configuration, ONVIF in this case, like so:
Modifying the brokerJobSpec
The brokerJobSpec
property is a full JobSpec and can be modified as such. Akri's Helm chart enables modifying the capacity
, parallelism
, and backoffLimit
fields of the JobSpec. Other fields of the JobSpec and the PodSpec within the JobSpec can be specified in a similar manner as described in the modifying the PodSpec section.
Modifying instanceServiceSpec or configurationServiceSpec
The instanceServiceSpec
and configurationServiceSpec
properties are full ServiceSpecs and can be modified as such. The simplest reason to modify either might be to specify different ports (perhaps 8085 and 8086):
The simple properties of instanceServiceSpec
and configurationServiceSpec
(like name, port, targetPort, and protocol) can be set using Helm's --set
command, e.g.--set onvif.instanceService.targetPort=90
.
Deploying multiple Configurations using helm install
helm install
If you want your end application to consume frames from both IP cameras and locally attached cameras, Akri can be installed from the start with both the ONVIF and udev Configurations like so:
You must specify a udev rule to successfully build the udev Configuration.
You can confirm that both a akri-onvif
and akri-udev
Configuration have been created by running:
Each Configuration could also have been deployed via separate Helm installations:
Modifying a deployed Configuration
An already deployed Configuration can be modified in one of two ways:
Using the
helm upgrade
command
Using helm upgrade
helm upgrade
A Configuration can be modified by using the helm upgrade
command. It upgrades an existing release according to the values provided, only updating what has changed. Simply modify your helm install
command to reflect the new desired state of Akri and replace helm install
with helm upgrade
. Using the ONVIF protocol implementation as an example, say an IP camera with IP address 10.0.0.1 is malfunctioning and should be filtered out of discovery, the following command could be run:
Note that the command is not simply helm upgrade --set onvif.configuration.discoveryDetails.ipAddresses.items[0]=10.0.0.1
; rather, it includes all the old settings along with the new one. Also, note that we assumed you specified a broker pod image in your original installation command, so that brokers were deployed to utilize discovered cameras.
Helm will create a new ONVIF Configuration and apply it to the cluster. When the Agent sees that a Configuration has been updated, it deletes all Instances associated with that Configuration and the controller brings down all associated broker pods. Then, new Instances and broker pods are created. Therefore, the command above will bring down all ONVIF broker pods and then bring them all back up except for the ones servicing the IP camera at IP address 10.0.0.1.
Adding another Configuration to a cluster
Another Configuration can be added to an existing Akri installation using helm upgrade
or via a new Helm installation.
Adding additional Configurations using helm upgrade
helm upgrade
Another Configuration can be added to the cluster by using helm upgrade
. For example, if you originally installed just the ONVIF Configuration and now also want to discover local cameras via udev, as well, simply run the following:
Adding additional Configurations via new Helm installations
The udev Configuration could also have been applied via a new Helm installation like so:
Modifying a broker
Want to change what broker is deployed to already discovered devices or deploy a new Job to the devices? Instead of deleting and reapplying the Configuration, you can modify the brokerSpec
of the Configuration using one of the strategies from the section on modifying a deployed Configuration.
This can be illustrated using Akri's mock debug echo Discovery Handler. The following installation deploys a BusyBox Job to each discovered mock device. That Job simply echos "Hello World".
Say you are feeling more exuberant and want the Job to echo "Hello Amazing World", you can update the brokerSpec
like so:
New Jobs will be spun up.
Note: The Agent and Controller can only gracefully handle changes to the
brokerSpec
. If any other parts of the Configuration are modified, the Agent will restart discovery, deleting and recreating the Instances.
Deleting a Configuration from a cluster
If an operator no longer wants Akri to discover devices defined by a Configuration, they can delete the Configuration and all associated broker pods will automatically be brought down. This can be done with helm upgrade
, helm delete
, or kubectl.
Deleting a Configuration using helm upgrade
helm upgrade
A Configuration can be deleted from a cluster using helm upgrade
. For example, if both ONVIF and udev Configurations have been installed in a cluster, the udev Configuration can be deleted by only specifying the ONVIF Configuration in a helm upgrade
command like the following:
Deleting a Configuration using helm delete
helm delete
If the Configuration was applied in its own Helm installation (named udev-config
in this example), the Configuration can be deleted by deleting the installation.
Deleting a Configuration using kubectl
A configuration can also be deleted using kubectl. To list all applied Configurations, run kubectl get akric
. If both udev and ONVIF Configurations have been applied with capacities of 5. The output should look like the following:
To delete the ONVIF Configuration and bring down all ONVIF broker pods, run:
Installing Discovery Handlers
The Agent discovers devices via Discovery Handlers. Akri supports an Agent image that includes all supported Discovery Handlers. This Agent will be used if agent.full=true
, like so:
By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets by specifying <discovery handler name>.discovery.enabled=true
when installing Akri. For example, Akri is installed with the OPC UA and ONVIF Discovery Handlers like so:
Last updated