diff --git a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md index 8439f0bbd2..2312157dda 100644 --- a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -7,31 +7,35 @@ slug: dockershim-faq aliases: [ '/dockershim' ] --- -**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article, +**This supersedes the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article, published in late 2020.** +--- + 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 +53,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 +76,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 +148,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 +156,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 +208,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