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
Describe the bug
A clear and concise description of what the bug is.
Akri's workflow to test Akri on K3s, Kubernetes, and MicroK8s periodically fails due to GitHub Runners running out of compute resources and the kubelet evicting Pods. The failure rate has been reduced by using release builds in PRs (#301), reducing the size of Debug Echo brokers by using nginx:stable-alpine (#301), reducing compute resource eviction limits in the MicroK8s kubelet (#301) and the K3s kubelet (#313).
Also, tests are being done with unshared debug echo devices to reduce the length of time the tests run by 5 minutes (shared devices get a 5 min offline grace period) and therefore the chance of failure. This should be changed back to using shared once the failures are resolved as it is the more complex scenario.
Potential solution
Akri should host its own workflow runners that have more disk and RAM.
Issue has been automatically marked as stale due to inactivity for 45 days. Update the issue to remove label, otherwise it will be automatically closed.
Describe the bug
A clear and concise description of what the bug is.
Akri's workflow to test Akri on K3s, Kubernetes, and MicroK8s periodically fails due to GitHub Runners running out of compute resources and the kubelet evicting Pods. The failure rate has been reduced by using release builds in PRs (#301), reducing the size of Debug Echo brokers by using
nginx:stable-alpine
(#301), reducing compute resource eviction limits in the MicroK8s kubelet (#301) and the K3s kubelet (#313).Also, tests are being done with unshared debug echo devices to reduce the length of time the tests run by 5 minutes (shared devices get a 5 min offline grace period) and therefore the chance of failure. This should be changed back to using shared once the failures are resolved as it is the more complex scenario.
Potential solution
Akri should host its own workflow runners that have more disk and RAM.
GitHub runners have the following hardware specifications for Linux virtual machines:
2-core CPU
7 GB of RAM memory
14 GB of SSD disk space
However, MicroK8's documentation states that "At least 20G of disk space and 4G of memory are recommended."
The text was updated successfully, but these errors were encountered: