Merge pull request #33138 from sftim/20220423_update_dockershim_faq_v1.24
Update dockershim blog articles with content for after v1.24 is releasedpull/33265/head
Kubernetes Prow Robot
GitHub
commit
57b58569cb
|
|
@ -3,13 +3,17 @@ layout: blog
|
|||
title: "Don't Panic: Kubernetes and Docker"
|
||||
date: 2020-12-02
|
||||
slug: dont-panic-kubernetes-and-docker
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**Update:** _Kubernetes support for Docker via `dockershim` is now removed.
|
||||
For more information, read the [removal FAQ](/dockershim).
|
||||
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
---
|
||||
|
||||
**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
|
||||
|
||||
_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
|
||||
For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
|
||||
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
Kubernetes is [deprecating
|
||||
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
|
|||
tool for building containers, and the images that result from running `docker
|
||||
build` can still run in your Kubernetes cluster.
|
||||
|
||||
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
|
||||
If you’re using a managed Kubernetes service like AKS, EkS or GKE, you will need to
|
||||
make sure your worker nodes are using a supported container runtime before
|
||||
Docker support is removed in a future version of Kubernetes. If you have node
|
||||
customizations you may need to update them based on your environment and runtime
|
||||
|
|
@ -37,8 +41,8 @@ testing and planning.
|
|||
|
||||
If you’re rolling your own clusters, you will also need to make changes to avoid
|
||||
your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
|
||||
When Docker runtime support is removed in a future release (currently planned
|
||||
for the 1.22 release in late 2021) of Kubernetes it will no longer be supported
|
||||
When Docker runtime support is removed in a future release (<del>currently planned
|
||||
for the 1.22 release in late 2021</del>) of Kubernetes it will no longer be supported
|
||||
and you will need to switch to one of the other compliant container runtimes,
|
||||
like containerd or CRI-O. Just make sure that the runtime you choose supports
|
||||
the docker daemon configurations you currently use (e.g. logging).
|
||||
|
|
|
|||
|
|
@ -7,31 +7,37 @@ slug: dockershim-faq
|
|||
aliases: [ '/dockershim' ]
|
||||
---
|
||||
|
||||
**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
|
||||
published in late 2020.**
|
||||
**This supersedes the original
|
||||
[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
|
||||
published in late 2020. The article includes updates from the v1.24
|
||||
release of Kubernetes.**
|
||||
|
||||
---
|
||||
|
||||
This document goes over some frequently asked questions regarding the
|
||||
deprecation and removal of _dockershim_, that was
|
||||
removal of _dockershim_ from Kubernetes. The removal was originally
|
||||
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/)
|
||||
as a part of the Kubernetes v1.20 release. For more detail
|
||||
on what that means, check out the blog post
|
||||
as a part of the Kubernetes v1.20 release. The Kubernetes
|
||||
[v1.24 release](/releases/#release-v1-24) actually removed the dockershim
|
||||
from Kubernetes.
|
||||
|
||||
For more on what that means, check out the blog post
|
||||
[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
|
||||
|
||||
Also, you can read [check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)
|
||||
to determine how much impact the removal of dockershim would have for you
|
||||
or for your organization.
|
||||
To determine the impact that the removal of dockershim would have for you or your organization,
|
||||
you can read [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
|
||||
|
||||
As the Kubernetes 1.24 release has become imminent, we've been working hard to try to make this a smooth transition.
|
||||
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.
|
||||
|
||||
- We've written a blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
|
||||
- We believe there are no major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
|
||||
- There is also a [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide available.
|
||||
- We've also created a page to list
|
||||
- A blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
|
||||
- Checking if there were major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
|
||||
- Adding a [migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide.
|
||||
- Creating a list of
|
||||
[articles on dockershim removal and on using CRI-compatible runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/).
|
||||
That list includes some of the already mentioned docs, and also covers selected external sources
|
||||
(including vendor guides).
|
||||
|
||||
### Why is the dockershim being removed from Kubernetes?
|
||||
### Why was the dockershim removed from Kubernetes?
|
||||
|
||||
Early versions of Kubernetes only worked with a specific container runtime:
|
||||
Docker Engine. Later, Kubernetes added support for working with other container runtimes.
|
||||
|
|
@ -49,36 +55,18 @@ In fact, maintaining dockershim had become a heavy burden on the Kubernetes main
|
|||
|
||||
Additionally, features that were largely incompatible with the dockershim, such
|
||||
as cgroups v2 and user namespaces are being implemented in these newer CRI
|
||||
runtimes. Removing support for the dockershim will allow further development in
|
||||
those areas.
|
||||
runtimes. Removing the dockershim from Kubernetes allows further development in those areas.
|
||||
|
||||
[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
|
||||
|
||||
### Can I still use Docker Engine in Kubernetes 1.23?
|
||||
### Are Docker and containers the same thing?
|
||||
|
||||
Yes, the only thing changed in 1.20 is a single warning log printed at [kubelet]
|
||||
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.
|
||||
|
||||
[kubelet]: /docs/reference/command-line-tools-reference/kubelet/
|
||||
|
||||
### When will dockershim be removed?
|
||||
|
||||
Given the impact of this change, we are using an extended deprecation timeline.
|
||||
Removal of dockershim is scheduled for Kubernetes v1.24, see [Dockershim Removal Kubernetes Enhancement Proposal][drkep].
|
||||
The Kubernetes project will be working closely with vendors and other ecosystem groups to ensure
|
||||
a smooth transition and will evaluate things as the situation evolves.
|
||||
|
||||
### Can I still use Docker Engine as my container runtime?
|
||||
|
||||
First off, if you use Docker on your own PC to develop or test containers: nothing changes.
|
||||
You can still use Docker locally no matter what container runtime(s) you use for your
|
||||
Kubernetes clusters. Containers make this kind of interoperability possible.
|
||||
|
||||
Mirantis and Docker have [committed][mirantis] to maintaining a replacement adapter for
|
||||
Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
|
||||
from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
|
||||
|
||||
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
|
||||
Docker popularized the Linux containers pattern and has been instrumental in
|
||||
developing the underlying technology, however containers in Linux have existed
|
||||
for a long time. The container ecosystem has grown to be much broader than just
|
||||
Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
|
||||
ecosystem, some replacing aspects of Docker while others enhance existing
|
||||
functionality.
|
||||
|
||||
### Will my existing container images still work?
|
||||
|
||||
|
|
@ -90,14 +78,41 @@ All your existing images will still work exactly the same.
|
|||
Yes. All CRI runtimes support the same pull secrets configuration used in
|
||||
Kubernetes, either via the PodSpec or ServiceAccount.
|
||||
|
||||
### Are Docker and containers the same thing?
|
||||
### Can I still use Docker Engine in Kubernetes 1.23?
|
||||
|
||||
Docker popularized the Linux containers pattern and has been instrumental in
|
||||
developing the underlying technology, however containers in Linux have existed
|
||||
for a long time. The container ecosystem has grown to be much broader than just
|
||||
Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
|
||||
ecosystem, some replacing aspects of Docker while others enhance existing
|
||||
functionality.
|
||||
Yes, the only thing changed in 1.20 is a single warning log printed at [kubelet]
|
||||
startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurred
|
||||
in Kubernetes 1.24.
|
||||
|
||||
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).
|
||||
(Remember, you can switch away from the dockershim if you're using any supported Kubernetes release; from release v1.24, you
|
||||
**must** switch as Kubernetes no longer incluides the dockershim).
|
||||
|
||||
[kubelet]: /docs/reference/command-line-tools-reference/kubelet/
|
||||
|
||||
### Which CRI implementation should I use?
|
||||
|
||||
That’s a complex question and it depends on a lot of factors. If Docker Engine is
|
||||
working for you, moving to containerd should be a relatively easy swap and
|
||||
will have strictly better performance and less overhead. However, we encourage you
|
||||
to explore all the options from the [CNCF landscape] in case another would be an
|
||||
even better fit for your environment.
|
||||
|
||||
[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
|
||||
|
||||
#### Can I still use Docker Engine as my container runtime?
|
||||
|
||||
First off, if you use Docker on your own PC to develop or test containers: nothing changes.
|
||||
You can still use Docker locally no matter what container runtime(s) you use for your
|
||||
Kubernetes clusters. Containers make this kind of interoperability possible.
|
||||
|
||||
Mirantis and Docker have [committed][mirantis] to maintaining a replacement adapter for
|
||||
Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
|
||||
from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
|
||||
|
||||
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.
|
||||
|
||||
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
|
||||
|
||||
### Are there examples of folks using other runtimes in production today?
|
||||
|
||||
|
|
@ -135,16 +150,6 @@ provide an end-to-end standard for managing containers.
|
|||
[runc]: https://github.com/opencontainers/runc
|
||||
[containerd]: https://containerd.io/
|
||||
|
||||
### Which CRI implementation should I use?
|
||||
|
||||
That’s a complex question and it depends on a lot of factors. If Docker is
|
||||
working for you, moving to containerd should be a relatively easy swap and
|
||||
will have strictly better performance and less overhead. However, we encourage you
|
||||
to explore all the options from the [CNCF landscape] in case another would be an
|
||||
even better fit for your environment.
|
||||
|
||||
[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
|
||||
|
||||
### What should I look out for when changing CRI implementations?
|
||||
|
||||
While the underlying containerization code is the same between Docker and most
|
||||
|
|
@ -153,24 +158,25 @@ common things to consider when migrating are:
|
|||
|
||||
- Logging configuration
|
||||
- Runtime resource limitations
|
||||
- Node provisioning scripts that call docker or use docker via it's control socket
|
||||
- Kubectl plugins that require docker CLI or the control socket
|
||||
- Node provisioning scripts that call docker or use Docker Engine via its control socket
|
||||
- Plugins for `kubectl` that require the `docker` CLI or the Docker Engine control socket
|
||||
- Tools from the Kubernetes project that require direct access to Docker Engine
|
||||
(for example: the deprecated `kube-imagepuller` tool)
|
||||
- Configuration of functionality like `registry-mirrors` and insecure registries
|
||||
- Configuration of functionality like `registry-mirrors` and insecure registries
|
||||
- Other support scripts or daemons that expect Docker Engine to be available and are run
|
||||
outside of Kubernetes (for example, monitoring or security agents)
|
||||
- GPUs or special hardware and how they integrate with your runtime and Kubernetes
|
||||
|
||||
If you use Kubernetes resource requests/limits or file-based log collection
|
||||
DaemonSets then they will continue to work the same, but if you’ve customized
|
||||
DaemonSets then they will continue to work the same, but if you've customized
|
||||
your `dockerd` configuration, you’ll need to adapt that for your new container
|
||||
runtime where possible.
|
||||
|
||||
Another thing to look out for is anything expecting to run for system maintenance
|
||||
or nested inside a container when building images will no longer work. For the
|
||||
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
|
||||
latter you can use newer container build options like [img], [buildah],
|
||||
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 latter you can use newer container build options like [img], [buildah],
|
||||
[kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
|
||||
|
||||
[cr]: https://github.com/kubernetes-sigs/cri-tools
|
||||
|
|
@ -204,7 +210,7 @@ discussion of the changes.
|
|||
|
||||
[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
|
||||
|
||||
### Is there any tooling that can help me find dockershim in use
|
||||
### Is there any tooling that can help me find dockershim in use?
|
||||
|
||||
Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
|
||||
install and then use to check your cluster. DDS can detect if active Kubernetes workloads
|
||||
|
|
|
|||
Loading…
Reference in New Issue