Tracking issue for updating k0s to containerd 2.0. The containerd RCs are already available.

Upgrading to 2.0 is not so simple. Both hcsshim and Helm also depend on containerd 1.x and will continue to pull it in as a transitive dependency. This is unfortunate, because containerd 2.x introduces the new containerd 1.8 API as a standalone go submodule, causing ambiguity errors in Go's dependency resolution: Go doesn't know whether it should pick github.com/containerd/containerd/api/... packages from the old github.com/containerd/containerd v1.7.x module or from the new github.com/containerd/containerd/api v1.8.x module.

Helm has only a single dependency on containerd 1.x, but this is part of the public API and thus could only be formally correctly removed in Hem v4. See helm/helm#12310 for more details.

The HCS shim mainly depends on containerd for its containerd shim binary. I've asked if it would be possible to separate the library and binary dependencies in microsoft/hcsshim#2163.

However, I see these things being sorted out upstream only in the long term, if at all. The only option left for k0s is to drop both hcsshim and Helm as compile-time Go dependencies. For hcsshim, there might be an escape hatch via shelling out to PowerShell (though this goes against k0s' zero-dependency principle). Embedding Helm as a binary is probably not an option, as it would increase the size of the k0s binary in an unacceptable way. K0s could externalize the Helm chart reconciler into its own tiny operator, and instead of running Helm chart reconciliation in k0s itself, delegate it to a pod that runs the reconciler separately. The upside would be a smaller k0s core, and the ability to have a separate release/patch cycle for the Helm operator. The downside is that chart reconciliation would start to require clusters that actually have healthy workers. So, for example, deploying a custom CNI through the Helm reconciler might no longer be possible.