Bug Bash
The goal of this bug bash is to discover any bugs before Akri creates a new release. This release contains the following major changes:
Please leave a comment in the scenario outcomes section with the scenario's you tested and whether it was successful. If you find issues, please create an issue on Akri's GitHub and comment it in the discovered issues section.
As always, feel free to post any questions on Akri's Slack.
Akri is an Open Source project that automates the discovery and usage of IoT devices around Kubernetes clusters on the Edge. Akri can automatically deploy user-provided workloads to the discovered devices. It handles device appearance and disappearance, allowing device deployments to expand and contract and enabling high resource utilization.
Akri is regularly tested on K3s, MicroK8s, and standard Kubernetes clusters versioned 1.16-1.21 (see previous release for list of exact versions tested) with Ubuntu 20.04 node. While we only test on these K8s distributions, feel free to try it out on the distribution and Linux OS of your choice.
Choose any of the following scenarios (none are pre-requisite of the others). The first is the most structured scenario. Make sure to use the akri-dev chart (helm install akri akri-helm-charts/akri-dev
) when installing Akri with Helm. If you have previously installed akri, be sure to run helm repo update
.
Akri depends on crictl to track whether Pods deployed by the Akri controller are still running. This release adds new functionality such that crictl is pre-installed in the Agent container so that it does not need to be installed on each node. However, some user configuration is still needed, namely telling the agent where the container runtime socket lives so it can successfully execute crictl. This scenario should check that the embedded crictl is working as expected, given the user appropriately sets the runtime socket location as explained in the Akri configure crictl documentation. After setting up your cluster, set AKRI_HELM_CRICTL_CONFIGURATION
env var as explained in the Akri configure crictl documentation. Install Akri with the debug echo discovery handler and configuration:
Assert that crictl calls are successful – be sure to wait 30 seconds after the Agent is running to make sure an initial
check has happened.
If there is no output, check for a reported error in the logs and report it.
Multiple configurations should be able to be applied that use the same DiscoveryHandler in order to support deploying different types of brokers to devices and discovering different sets of devices. For example, you may want to deploy two Configurations that use the udev Discovery Handler as follows: one that discovers USB cameras and deploys a broker that grabs frames from the camera and another that discovers GPUs and deploys inferencing pods. This scenario will check that two DebugEcho configurations can be applied. To extend this scenario, see the Akri documentation on the debug echo testing Discovery Handler.
Now Akri has support for deploying Jobs to devices discovered by the Akri Agent. Previously, Akri only supported deploying Pods that were not intended to terminate (and would be restarted if they did). Adding Jobs will enable more scenarios with Akri such as device management scenarios. More background can be found in the Jobs proposal.
https://github.com/project-akri/akri/issues/447
https://github.com/project-akri/akri/issues/448
https://github.com/project-akri/akri/issues/450
Environment | Scenario | Success/Issue |
---|---|---|
KinD (0.11.1) with K8s v1.21.2 | A, B, C | Success |
MicroK8s on Windows K8s 1.18.20 | A, B, C | Success |
Kubernetes Playground (K8s version 1.18) | A, B, C | Success |
K3s 1.22.6 Ubuntu 20.04 Hyper-V | A, B, C | Success |
AKS 1.21.9 | A | Success. Note, needed to configure crictl for containerd (export AKRI_HELM_CRICTL_CONFIGURATION="--set agent.host.containerRuntimeSocket=/run/containerd/containerd.sock ) |