-
Notifications
You must be signed in to change notification settings - Fork 40.2k
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
Deprecate Dockershim #94624
Deprecate Dockershim #94624
Conversation
/assign @dchen1107 @derekwaynecarr @dashpole |
As far as I can tell the only CI job is for typecheck, it's not tested with a built configuration, but I can't see how building without the code would break anything. |
The first containerd release with Windows support was 1.4.0 and just released in Aug 2020. I'm concerned that marking dockershim as deprecated before ContainerD on Windows has had time to get any real adoption might cause some users to question Windows support in Kubernetes. I'm in favor of deprecating dockershim and also removing that code from a Windows standpoint, I just think it might be better to do this in 1.21. /cc @michmike |
Is there a CRI-based implementation for docker? I haven't been able to find any guides on how to migrate to that - could someone link me to docs around that? |
100% agree with Mark. we need to wait for containerd support in windows to stabilize and iron out any kinks. 1.21 is the right timeframe |
possibly requires some clarification - are we removing it entirely or just from the kubelet? moving dockershim outside of the kubelet to a community maintained repository seems the right action here. survey from KubeCon EU (this year) performed by SIG Cluster Lifecycle: search for "What is your preferred container runtime (CRI)?". Docker still has majority but containerd is gaining traction slowly. |
@MHBauer we had added a kind CI job that used the |
as mentioned, i don't entirely agree with the plan here...this PR effectively deprecates Docker support in Kubernetes, but the release note does not communicate this clearly. what would be guide to explain to the users how to move their cluster from docker to e.g. containerd? my proposal:
and the "this guide" document has to be created, before we apply this deprecation. |
@neolit123 i'd prefer the community to write the "guide". I am just interested in starting the clock in this PR. I updated the release note with the rest of your text. |
/retest Review the full test history for this PR. Silence the bot with an |
1 similar comment
/retest Review the full test history for this PR. Silence the bot with an |
A number of folks have commented about still relying on |
Good day, In simple/layperson terms, does this mean that Docker containers will not be supported at all in the future? For example, Docker's landing page notes that it uses
If the above assumptions are correct, are there de-facto (i.e. most commonly used in the K8S community, or recommended by K8S developers and maintainers) replacements for Docker (i.e. in terms of tooling, publishing, etc.) so individuals/teams can migrate effectively? Thank you.
|
In simple terms (I hope, can further clarify if needed): docker containers / images will absolutely be supported. docker may not be the tool Kubernetes uses to run them, but the same Kubernetes YAML, docker images, etc. will continue to work with other container runtimes. Images use an open format common to all runtimes, you don't need to change image builds. It should be a drop in replacement. Our (Kubernetes) CI uses them interchangably. If you've ever used microk8s, k3s, or KIND then you've already used containerd to run Kubernetes workloads. This should only affect cluster operators / implementors. |
Thank you very much. This is indeed helpful. |
@dims i'd add a message in the release note that this is not deprecating support for Docker containers...(given the high number of questions about this). proposing the following update:
EDIT: might be a good idea to link to the KEP under this too:
https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim EDIT/META: possibly link to the new blog post too. |
A happy update: Mirantis and Docker have partnered on supporting the dockershim as a standalone component outside of Kube. You can read more about it here: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/. Hopefully this will put any remaining lingering concerns to rest. |
@adamparco thanks for the good news, let's chat about a migration plan and testing strategies to make sure we are able to support folks who will want to stick to using docker in the future. For those who will check on this KEP, the plan is still in progress :) i.e, investigate and switch over to a CRI implementation that's available in the community (containerd, cri-o etc). If you want to continue to use docker, You will need to switch to new stuff that will show up in https://github.com/Mirantis/cri-dockerd as we will drop dockershim per the timetable in the KEP. Thanks! |
@dims Is it needed to install docker-ce when install kubernetes, if docker-shim been deprecated . |
/cc |
Please see https://github.com/Mirantis/cri-dockerd |
See KEP in progress - kubernetes/enhancements#1985
dockershim has been part of kubelet for far too long. we vendor in a whole bunch of stuff from moby/moby to make things work. The correct split/architecture is to follow the same design as with containerd and cri-o namely a separate process that kubelet talks to via grpc that in turn talks to a runtime. If folks are interested to do this, please do. An example of such a split is https://github.com/dims/cri-dockerd (NO! i am not maintaining that, nice try).
In this PR, we start the clock on removing dockershim in a subsequent release. We already have
dockerless
tag and CI jobs to ensure that we don't break anything when we eventually drop the built-in dockershim.Signed-off-by: Davanum Srinivas davanum@gmail.com
What type of PR is this?
/kind cleanup
/kind deprecation
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: