Skip to content

Commit 9e71e76

Browse files
author
Jorge O. Castro
authored
Initial commit to explain the dockershim deprecation (#25359)
* Initial commit to explain the dockershim deprecation Signed-off-by: Jorge O. Castro <[email protected]> * Fix overly long links so they render correctly Signed-off-by: Jorge O. Castro <[email protected]> * Add author byline Signed-off-by: Jorge O. Castro <[email protected]>
1 parent 29801cc commit 9e71e76

File tree

1 file changed

+102
-0
lines changed

1 file changed

+102
-0
lines changed
Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
---
2+
layout: blog
3+
title: "Don't Panic: Kubernetes and Docker"
4+
date: 2020-12-02
5+
slug: dont-panic-kubernetes-and-docker
6+
---
7+
8+
**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
9+
10+
Kubernetes is [deprecating
11+
Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
12+
as a container runtime after v1.20.
13+
14+
**You do not need to panic. It’s not as dramatic as it sounds.**
15+
16+
tl;dr Docker as an underlying runtime is being deprecated in favor of runtimes
17+
that use the [Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
18+
created for Kubernetes. Docker-produced images will continue to work in your
19+
cluster with all runtimes, as they always have.
20+
21+
If you’re an end-user of Kubernetes, not a whole lot will be changing for you.
22+
This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or
23+
shouldn’t, use Docker as a development tool anymore. Docker is still a useful
24+
tool for building containers, and the images that result from running `docker
25+
build` can still run in your Kubernetes cluster.
26+
27+
If you’re using a managed Kubernetes service like GKE or EKS, you will need to
28+
make sure your worker nodes are using a supported container runtime before
29+
Docker support is removed in a future version of Kubernetes. If you have node
30+
customizations you may need to update them based on your environment and runtime
31+
requirements. Please work with your service provider to ensure proper upgrade
32+
testing and planning.
33+
34+
If you’re rolling your own clusters, you will also need to make changes to avoid
35+
your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
36+
When Docker runtime support is removed in a future release (currently planned
37+
for the 1.23 release in late 2021) of Kubernetes it will no longer be supported
38+
and you will need to switch to one of the other compliant container runtimes,
39+
like containerd or CRI-O. Just make sure that the runtime you choose supports
40+
the docker daemon configurations you currently use (e.g. logging).
41+
42+
## So why the confusion and what is everyone freaking out about?
43+
44+
We’re talking about two different environments here, and that’s creating
45+
confusion. Inside of your Kubernetes cluster, there’s a thing called a container
46+
runtime that’s responsible for pulling and running your container images. Docker
47+
is a popular choice for that runtime (other common options include containerd
48+
and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and
49+
that causes a problem.
50+
51+
You see, the thing we call “Docker” isn’t actually one thing -- it’s an entire
52+
tech stack, and one part of it is a thing called “containerd,” which is a
53+
high-level container runtime by itself. Docker is cool and useful because it has
54+
a lot of UX enhancements that make it really easy for humans to interact with
55+
while we’re doing development work, but those UX enhancements aren’t necessary
56+
for Kubernetes, because it isn’t a human.
57+
58+
As a result of this human-friendly abstraction layer, your Kubernetes cluster
59+
has to use another tool called Dockershim to get at what it really needs, which
60+
is containerd. That’s not great, because it gives us another thing that has to
61+
be maintained and can possibly break. What’s actually happening here is that
62+
Dockershim is being removed from Kubelet as early as v1.23 release, which
63+
removes support for Docker as a container runtime as a result. You might be
64+
thinking to yourself, but if containerd is included in the Docker stack, why
65+
does Kubernetes need the Dockershim?
66+
67+
Docker isn’t compliant with CRI, the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/).
68+
If it were, we wouldn’t need the shim, and this wouldn’t be a thing. But it’s
69+
not the end of the world, and you don’t need to panic -- you just need to change
70+
your container runtime from Docker to another supported container runtime.
71+
72+
One thing to note: If you are relying on the underlying docker socket
73+
(/var/run/docker.sock) as part of a workflow within your cluster today, moving
74+
to a different runtime will break your ability to use it. This pattern is often
75+
called Docker in Docker. There are lots of options out there for this specific
76+
use case including things like
77+
[kaniko](https://github.com/GoogleContainerTools/kaniko),
78+
[img](https://github.com/genuinetools/img), and
79+
[buildah](https://github.com/containers/buildah).
80+
81+
## What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker?
82+
83+
This change addresses a different environment than most folks use to interact
84+
with Docker. The Docker installation you’re using in development is unrelated to
85+
the Docker runtime inside your Kubernetes cluster. It’s confusing, I know. As a
86+
developer, Docker is still useful to you in all the ways it was before this
87+
change was announced. The image that Docker produces isn’t really a
88+
Docker-specific image -- it’s an OCI ([Open Container Initiative](https://opencontainers.org/)) image.
89+
Any OCI-compliant image, regardless of the tool you use to build it, will look
90+
the same to Kubernetes. Both [containerd](https://containerd.io/) and
91+
[CRI-O](https://cri-o.io/) know how to pull those images and run them. This is
92+
why we have a standard for what containers should look like.
93+
94+
So, this change is coming. It’s going to cause issues for some, but it isn’t
95+
catastrophic, and generally it’s a good thing. Depending on how you interact
96+
with Kubernetes, this could mean nothing to you, or it could mean a bit of work.
97+
In the long run, it’s going to make things easier. If this is still confusing
98+
for you, that’s okay -- there’s a lot going on here, Kubernetes has a lot of
99+
moving parts, and nobody is an expert in 100% of it. We encourage any and all
100+
questions regardless of experience level or complexity! Our goal is to make sure
101+
everyone is educated as much as possible on the upcoming changes. `<3` We hope
102+
this has answered most of your questions and soothed some anxieties!

0 commit comments

Comments
 (0)