-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
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. |
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. |
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. |
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. |
I don't see a way to subscribe to notifications on this issue so I'll comment and say my use case. |
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.
The text was updated successfully, but these errors were encountered: