Customizing an Akri Installation
Last updated
Was this helpful?
Last updated
Was this helpful?
The , , and 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 ). 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
To install Akri without any protocol Configurations, run this:
This will deploy the Akri Controller and deploy Akri Agents.
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:
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.
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 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:
An already deployed Configuration can be modified in one of two ways:
Using the helm upgrade
command
Note: Only the broker properties and capacity of an applied configuration should be modified, for any other modification, you need to delete and reapply the Configuration.
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 you want to set the capacity of discovered cameras to 3:
Note that the command is not simply helm upgrade --set onvif.configuration.capacity=3
; 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 updates all Instances associated with that new Configuration.
Another Configuration can be added to an existing Akri installation using helm upgrade
or via a new Helm installation.
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:
The udev Configuration could also have been applied via a new Helm installation like so:
Currently, to modify a broker (be it a Job or Pod), you need to delete and re-apply the Configuration.
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.
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:
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.
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:
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:
The brokerPodSpec
property is a full 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:
The brokerJobSpec
property is a full 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 .
The instanceServiceSpec
and configurationServiceSpec
properties are full and can be modified as such. The simplest reason to modify either might be to specify different ports (perhaps 8085 and 8086):