Note: See the cluster setup steps for information on how to set the crictl configuration variableAKRI_HELM_CRICTL_CONFIGURATION
--set useLatestContainers=true
when installing Akri like so:<discovery handler name>.discovery.enabled=true
when installing Akri, as explained in the user flow. To instead use the previous strategy of an Agent image with embedded udev, OPC UA, and ONVIF Discovery Handlers, set agent.full=true
.helm inspect chart akri-helm-charts/akri
and helm inspect chart akri-helm-charts/akri-dev
, respectively.helm repo update
.kubectl
and Helm
installed. Reference our cluster setup documentation to set up a cluster or adapt your currently existing cluster. Akri currently supports Linux Nodes on amd64, arm64v8, or arm32v7.helm upgrades
. This section will focus on the latter strategy, helping you construct your Akri installation command, assuming you have already decided what you want Akri to discover.Note: To use Akri's latest dev releases, specifyakri-helm-charts/akri
<discovery handler name>.discovery.enabled
is set.Note: To install a full Agent with embedded udev, OPC UA, and ONVIF Discovery Handlers, setagent.full=true
instead of enabling the Discovery Handlers. Note, this we restart the Agent Pods.1helm upgrade akri akri-helm-charts/akri \2$AKRI_HELM_CRICTL_CONFIGURATION3--set agent.full=trueCopied!
<discovery handler name>.configuration.enabled
. While some Configurations may not require any discovery details to be set, oftentimes setting details is preferable for narrowing the Discovery Handlers' search. These are set under <discovery handler name>.configuration.discoveryDetails
. For example, udev rules are passed to the udev Discovery Handler to specify which devices in the Linux device file system it should search for by setting udev.configuration.discoveryDetails.udevRules
. Akri can be instructed to automatically deploy workloads called "brokers" to each discovered device by setting a broker Pod image in a Configuration via --set <protocol>.configuration.brokerPod.image.repository=<your broker image>
. Learn more about creating brokers in the broker development document.Note: set<discovery handler name>.brokerPod.image.tag
to specify an image tag (defaults tolatest
).
brokerJob
instead of the brokerPod
.kubectl get crd
, and you should see Akri's two CRDs listed.kubectl get pods -o wide
, and you should see the Akri Controller, Agent, and (if specified) broker pods.kubectl get akric
, and you should see the Configuration for the protocol you specified.kubectl get akrii
and further inspected by running kubectl get akrii <discovery handler name>-<ID> -o yaml
.--set controller.allowOnControlPlane=false
to your install command below. Conversely, if you only want the Controller to run on control plane nodes, add --set controller.onlyOnControlPlane=true
. This will guarantee the Controller only runs on nodes with the label (key, value) of (node-role.kubernetes.io/master
, ""), which is the default label for the control plane node for Kubernetes.kubectl label node ${HOSTNAME,,} node-role.kubernetes.io/master=--overwrite=true
. Or alternatively, in K3s, you can keep the default label value on the master and set controller.nodeSelectors."node-role\.kubernetes\.io/master"=true
.