Skip to content

Commit 57b5856

Browse files
authored
Merge pull request #33138 from sftim/20220423_update_dockershim_faq_v1.24
Update dockershim blog articles with content for after v1.24 is released
2 parents cf42bdb + 8ec031c commit 57b5856

File tree

2 files changed

+75
-65
lines changed

2 files changed

+75
-65
lines changed

content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -3,13 +3,17 @@ layout: blog
33
title: "Don't Panic: Kubernetes and Docker"
44
date: 2020-12-02
55
slug: dont-panic-kubernetes-and-docker
6+
evergreen: true
7+
---
8+
9+
**Update:** _Kubernetes support for Docker via `dockershim` is now removed.
10+
For more information, read the [removal FAQ](/dockershim).
11+
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
12+
613
---
714

815
**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
916

10-
_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
11-
For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
12-
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
1317

1418
Kubernetes is [deprecating
1519
Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
@@ -28,7 +32,7 @@ shouldn’t, use Docker as a development tool anymore. Docker is still a useful
2832
tool for building containers, and the images that result from running `docker
2933
build` can still run in your Kubernetes cluster.
3034

31-
If you’re using a managed Kubernetes service like GKE, EKS, or AKS (which [defaults to containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) you will need to
35+
If you’re using a managed Kubernetes service like AKS, EkS or GKE, you will need to
3236
make sure your worker nodes are using a supported container runtime before
3337
Docker support is removed in a future version of Kubernetes. If you have node
3438
customizations you may need to update them based on your environment and runtime
@@ -37,8 +41,8 @@ testing and planning.
3741

3842
If you’re rolling your own clusters, you will also need to make changes to avoid
3943
your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
40-
When Docker runtime support is removed in a future release (currently planned
41-
for the 1.22 release in late 2021) of Kubernetes it will no longer be supported
44+
When Docker runtime support is removed in a future release (<del>currently planned
45+
for the 1.22 release in late 2021</del>) of Kubernetes it will no longer be supported
4246
and you will need to switch to one of the other compliant container runtimes,
4347
like containerd or CRI-O. Just make sure that the runtime you choose supports
4448
the docker daemon configurations you currently use (e.g. logging).

content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md

Lines changed: 65 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -7,31 +7,37 @@ slug: dockershim-faq
77
aliases: [ '/dockershim' ]
88
---
99

10-
**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
11-
published in late 2020.**
10+
**This supersedes the original
11+
[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
12+
published in late 2020. The article includes updates from the v1.24
13+
release of Kubernetes.**
14+
15+
---
1216

1317
This document goes over some frequently asked questions regarding the
14-
deprecation and removal of _dockershim_, that was
18+
removal of _dockershim_ from Kubernetes. The removal was originally
1519
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/)
16-
as a part of the Kubernetes v1.20 release. For more detail
17-
on what that means, check out the blog post
20+
as a part of the Kubernetes v1.20 release. The Kubernetes
21+
[v1.24 release](/releases/#release-v1-24) actually removed the dockershim
22+
from Kubernetes.
23+
24+
For more on what that means, check out the blog post
1825
[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
1926

20-
Also, you can read [check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)
21-
to determine how much impact the removal of dockershim would have for you
22-
or for your organization.
27+
To determine the impact that the removal of dockershim would have for you or your organization,
28+
you can read [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
2329

24-
As the Kubernetes 1.24 release has become imminent, we've been working hard to try to make this a smooth transition.
30+
In the months and days leading up to the Kubernetes 1.24 release, Kubernetes contributors worked hard to try to make this a smooth transition.
2531

26-
- We've written a blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
27-
- We believe there are no major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
28-
- There is also a [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide available.
29-
- We've also created a page to list
32+
- A blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
33+
- Checking if there were major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
34+
- Adding a [migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide.
35+
- Creating a list of
3036
[articles on dockershim removal and on using CRI-compatible runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/).
3137
That list includes some of the already mentioned docs, and also covers selected external sources
3238
(including vendor guides).
3339

34-
### Why is the dockershim being removed from Kubernetes?
40+
### Why was the dockershim removed from Kubernetes?
3541

3642
Early versions of Kubernetes only worked with a specific container runtime:
3743
Docker Engine. Later, Kubernetes added support for working with other container runtimes.
@@ -49,26 +55,52 @@ In fact, maintaining dockershim had become a heavy burden on the Kubernetes main
4955

5056
Additionally, features that were largely incompatible with the dockershim, such
5157
as cgroups v2 and user namespaces are being implemented in these newer CRI
52-
runtimes. Removing support for the dockershim will allow further development in
53-
those areas.
58+
runtimes. Removing the dockershim from Kubernetes allows further development in those areas.
5459

5560
[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
5661

62+
### Are Docker and containers the same thing?
63+
64+
Docker popularized the Linux containers pattern and has been instrumental in
65+
developing the underlying technology, however containers in Linux have existed
66+
for a long time. The container ecosystem has grown to be much broader than just
67+
Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
68+
ecosystem, some replacing aspects of Docker while others enhance existing
69+
functionality.
70+
71+
### Will my existing container images still work?
72+
73+
Yes, the images produced from `docker build` will work with all CRI implementations.
74+
All your existing images will still work exactly the same.
75+
76+
#### What about private images?
77+
78+
Yes. All CRI runtimes support the same pull secrets configuration used in
79+
Kubernetes, either via the PodSpec or ServiceAccount.
80+
5781
### Can I still use Docker Engine in Kubernetes 1.23?
5882

5983
Yes, the only thing changed in 1.20 is a single warning log printed at [kubelet]
60-
startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurs in Kubernetes 1.24.
84+
startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurred
85+
in Kubernetes 1.24.
86+
87+
If you're running Kubernetes v1.24 or later, see [Can I still use Docker Engine as my container runtime?](#can-i-still-use-docker-engine-as-my-container-runtime).
88+
(Remember, you can switch away from the dockershim if you're using any supported Kubernetes release; from release v1.24, you
89+
**must** switch as Kubernetes no longer incluides the dockershim).
6190

6291
[kubelet]: /docs/reference/command-line-tools-reference/kubelet/
6392

64-
### When will dockershim be removed?
93+
### Which CRI implementation should I use?
6594

66-
Given the impact of this change, we are using an extended deprecation timeline.
67-
Removal of dockershim is scheduled for Kubernetes v1.24, see [Dockershim Removal Kubernetes Enhancement Proposal][drkep].
68-
The Kubernetes project will be working closely with vendors and other ecosystem groups to ensure
69-
a smooth transition and will evaluate things as the situation evolves.
95+
That’s a complex question and it depends on a lot of factors. If Docker Engine is
96+
working for you, moving to containerd should be a relatively easy swap and
97+
will have strictly better performance and less overhead. However, we encourage you
98+
to explore all the options from the [CNCF landscape] in case another would be an
99+
even better fit for your environment.
100+
101+
[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
70102

71-
### Can I still use Docker Engine as my container runtime?
103+
#### Can I still use Docker Engine as my container runtime?
72104

73105
First off, if you use Docker on your own PC to develop or test containers: nothing changes.
74106
You can still use Docker locally no matter what container runtime(s) you use for your
@@ -78,26 +110,9 @@ Mirantis and Docker have [committed][mirantis] to maintaining a replacement adap
78110
Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
79111
from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
80112

81-
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
82-
83-
### Will my existing container images still work?
84-
85-
Yes, the images produced from `docker build` will work with all CRI implementations.
86-
All your existing images will still work exactly the same.
87-
88-
#### What about private images?
113+
You can install `cri-dockerd` and use it to connect the kubelet to Docker Engine. Read [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) to learn more.
89114

90-
Yes. All CRI runtimes support the same pull secrets configuration used in
91-
Kubernetes, either via the PodSpec or ServiceAccount.
92-
93-
### Are Docker and containers the same thing?
94-
95-
Docker popularized the Linux containers pattern and has been instrumental in
96-
developing the underlying technology, however containers in Linux have existed
97-
for a long time. The container ecosystem has grown to be much broader than just
98-
Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
99-
ecosystem, some replacing aspects of Docker while others enhance existing
100-
functionality.
115+
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
101116

102117
### Are there examples of folks using other runtimes in production today?
103118

@@ -135,16 +150,6 @@ provide an end-to-end standard for managing containers.
135150
[runc]: https://github.com/opencontainers/runc
136151
[containerd]: https://containerd.io/
137152

138-
### Which CRI implementation should I use?
139-
140-
That’s a complex question and it depends on a lot of factors. If Docker is
141-
working for you, moving to containerd should be a relatively easy swap and
142-
will have strictly better performance and less overhead. However, we encourage you
143-
to explore all the options from the [CNCF landscape] in case another would be an
144-
even better fit for your environment.
145-
146-
[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
147-
148153
### What should I look out for when changing CRI implementations?
149154

150155
While the underlying containerization code is the same between Docker and most
@@ -153,24 +158,25 @@ common things to consider when migrating are:
153158

154159
- Logging configuration
155160
- Runtime resource limitations
156-
- Node provisioning scripts that call docker or use docker via it's control socket
157-
- Kubectl plugins that require docker CLI or the control socket
161+
- Node provisioning scripts that call docker or use Docker Engine via its control socket
162+
- Plugins for `kubectl` that require the `docker` CLI or the Docker Engine control socket
158163
- Tools from the Kubernetes project that require direct access to Docker Engine
159164
(for example: the deprecated `kube-imagepuller` tool)
160-
- Configuration of functionality like `registry-mirrors` and insecure registries
165+
- Configuration of functionality like `registry-mirrors` and insecure registries
161166
- Other support scripts or daemons that expect Docker Engine to be available and are run
162167
outside of Kubernetes (for example, monitoring or security agents)
163168
- GPUs or special hardware and how they integrate with your runtime and Kubernetes
164169

165170
If you use Kubernetes resource requests/limits or file-based log collection
166-
DaemonSets then they will continue to work the same, but if youve customized
171+
DaemonSets then they will continue to work the same, but if you've customized
167172
your `dockerd` configuration, you’ll need to adapt that for your new container
168173
runtime where possible.
169174

170175
Another thing to look out for is anything expecting to run for system maintenance
171176
or nested inside a container when building images will no longer work. For the
172-
former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
173-
latter you can use newer container build options like [img], [buildah],
177+
former, you can use the [`crictl`][cr] tool as a drop-in replacement (see
178+
[mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))
179+
and for the latter you can use newer container build options like [img], [buildah],
174180
[kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
175181

176182
[cr]: https://github.com/kubernetes-sigs/cri-tools
@@ -204,7 +210,7 @@ discussion of the changes.
204210

205211
[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
206212

207-
### Is there any tooling that can help me find dockershim in use
213+
### Is there any tooling that can help me find dockershim in use?
208214

209215
Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
210216
install and then use to check your cluster. DDS can detect if active Kubernetes workloads

0 commit comments

Comments
 (0)