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

ContainerD Support #18

Open
ncresswell opened this issue Aug 21, 2023 · 5 comments
Open

ContainerD Support #18

ncresswell opened this issue Aug 21, 2023 · 5 comments

Comments

@ncresswell
Copy link
Member

K2D is based on translating Kubernetes APIs to Docker APIs, which makes Docker a must. It should be possible, in the future, to not require docker, by embedding contained as part of the k2d image. This would lower the memory footprint and increase security by removing unneeded docker features.

@deviantony
Copy link
Member

We are using a Docker-based implementation, so it would require either a rewrite or the addition of a specific containerd interface. It's also rare to see containerd being used directly; its purpose is to be embedded into other systems. We could look to embed it directly into k2d.

@m0ssc0de
Copy link

If k2d needs to support more container runtimes that are within the range of runtimes supported by k8s, maybe the Container Runtime Interface (CRI) could be considered.

@olljanat
Copy link

Honestly, I don't think that this is good idea because if you start embedding containerd directly to k2d binary and start utilize CRI, then you are re-creating k3s but still missing orchestrator features and end up to trouble that what to do with Docker support? Remove it completely or support two different ways?

Also it would mean that you cannot implement Ingress support #16 by utilizing Traefik because it have existing provider for Docker but not for containerd. That provider btw most probably works already now with Alpha if user just define those container labels which it is looking for.

If you other hand support Docker only then it would be possible to do it like I proposed #11 (comment)

If you think that Docker memory footprint is too big then it is probably better idea to contribute to Moby and try reduce it. Now it is possible again when they moved to faster release cycle. Also, Docker memory footprint most probably will reduce anyway in future after they are ready with containerd migration as currently they need support both old and new way.

@ncresswell
Copy link
Member Author

right now we are parking this request... it came from community feedback off the back of the Alpha, so I captured it... but for now, we will stick with Docker as the back end API that K2D translates into.

@rothgar
Copy link

rothgar commented Mar 26, 2024

I don't see a way to subscribe to notifications on this issue so I'll comment and say my use case.
If k2d is meant for edge deployments then it would probably fit really good with https://talos.dev/ which has an extremely small footprint, API management, and wireguard connectivity.
Unfortunately, it only has containerd so I can't try k2d with it. Just something to consider. I believe other container/kubernetes minimal operating systems bundle containerd and runtimes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants