K3s: arm64 image downloading broken by current containerd

[ubergeek801]

Describe the bug
On an arm64 system, after specifying the pause image as described in issue #176, additional image downloads (e.g. coredns, traefik) fail with a similar "no match for platform in manifest" error.

To Reproduce

1. Install k3s on an arm64 system
2. Run k3s in "server" mode
3. Observe error messages in /var/log/k3s-service.log

Expected behavior
k3s should download the required images and recognize them as matching the current platform.

Screenshots
n/a

Additional context
The specific device in this case is an Odroid N2. k3s was not installed directly, but embedded in k3os 0.2.1, using the overlay installation method over the stock Ubuntu OS and kernel image.

In researching this issue, various comments led me to the root cause in containerd. A commit from May 2019 entitled "Improve ARM platform matching" appears to address this. While I am not at all familiar with the k3s build process, I was able to hack together a build using the latest containerd source, and replace the existing k3s binary in my k3os image. Upon booting with the updated image, the previously broken processes appear to be operating normally, allowing the various kube-system pods to reach Running status.

Unfortunately the aforementioned commit does not appear to have been included in any of the subsequent containerd releases, but it does appear on the master branch.

[erikwilson]

Many thanks for taking the time to file this bug and providing an exact commit which fixes the issue! We have updated containerd to 1.2.7 and cherry-picked that commit to be a part of our arm updates.

This should be fixed as part of #623 and available in https://github.com/rancher/k3s/releases/tag/v0.7.0-rc5 for testing. Thanks again @ubergeek801!

[ubergeek801]

Outstanding! Hope to also see it in a k3os release soon :-)

[erikwilson]

Closing, should be fixed when v0.7.0 is released, please re-open if still an issue @ubergeek801