Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to containerd 2.0 #4581

Open
twz123 opened this issue Jun 10, 2024 · 1 comment
Open

Update to containerd 2.0 #4581

twz123 opened this issue Jun 10, 2024 · 1 comment

Comments

@twz123
Copy link
Member

twz123 commented Jun 10, 2024

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.

Copy link
Contributor

The issue is marked as stale since no activity has been recorded in 30 days

@github-actions github-actions bot added the Stale label Jul 10, 2024
@twz123 twz123 removed the Stale label Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant