Update to containerd 2.0 #4581
Comments
|
The issue is marked as stale since no activity has been recorded in 30 days |
|
The issue is marked as stale since no activity has been recorded in 30 days |
|
The issue is marked as stale since no activity has been recorded in 30 days |
hmm, looking at the code we use hcsshim only in https://github.com/k0sproject/k0s/blob/main/pkg/component/worker/containerd/utils_windows.go#L60. Looking deeper we do NOT seems to call that func from anywhere?!? So it seems we could just get rid of the whole dependency by removing the code using it. Although this feels bit too easy solution, I must be missing something... 😂 |
|
The issue is marked as stale since no activity has been recorded in 30 days |
|
The issue is marked as stale since no activity has been recorded in 30 days |
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 oldgithub.com/containerd/containerd v1.7.xmodule or from the newgithub.com/containerd/containerd/api v1.8.xmodule.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.
The text was updated successfully, but these errors were encountered: