Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
+6
-1
@@ -4,7 +4,12 @@ date: 2017-11-02
|
||||
slug: containerd-container-runtime-options-kubernetes
|
||||
url: /blog/2017/11/Containerd-Container-Runtime-Options-Kubernetes
|
||||
---
|
||||
**_Editor's note: Today's post is by Lantao Liu, Software Engineer at Google, and Mike Brown, Open Source Developer Advocate at IBM._**
|
||||
|
||||
**Authors:** Lantao Liu (Google), and Mike Brown (IBM)
|
||||
|
||||
_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)._
|
||||
|
||||
A _container runtime_ is software that executes containers and manages container images on a node. Today, the most widely known container runtime is [Docker](https://www.docker.com/), but there are other container runtimes in the ecosystem, such as [rkt](https://coreos.com/rkt/), [containerd](https://containerd.io/), and [lxd](https://linuxcontainers.org/lxd/). Docker is by far the most common container runtime used in production Kubernetes environments, but Docker’s smaller offspring, containerd, may prove to be a better option. This post describes using containerd with Kubernetes.
|
||||
|
||||
|
||||
@@ -360,7 +360,7 @@ So let's fix the issue by installing the missing package:
|
||||
sudo apt install -y conntrack
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
Let's try to launch it again:
|
||||
|
||||
|
||||
@@ -7,6 +7,10 @@ slug: dont-panic-kubernetes-and-docker
|
||||
|
||||
**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)
|
||||
as a container runtime after v1.20.
|
||||
|
||||
@@ -5,13 +5,20 @@ date: 2021-11-12
|
||||
slug: are-you-ready-for-dockershim-removal
|
||||
---
|
||||
|
||||
**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
|
||||
**Authors:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
|
||||
|
||||
{{% alert color="info" title="Poll closed" %}}
|
||||
This poll closed on January 7, 2022.
|
||||
{{% /alert %}}
|
||||
|
||||
Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
|
||||
Last year we [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
that Kubernetes' dockershim component (which provides a built-in integration for
|
||||
Docker Engine) is deprecated.
|
||||
|
||||
_Update: There's a [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)
|
||||
with more information, and you can also discuss the deprecation via a dedicated
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
Our current plan is to remove dockershim from the Kubernetes codebase soon.
|
||||
We are looking for feedback from you whether you are ready for dockershim
|
||||
removal and to ensure that you are ready when the time comes.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "Updated: Dockershim Removal FAQ"
|
||||
linkTitle: "Dockershim Removal FAQ"
|
||||
date: 2022-02-17
|
||||
slug: dockershim-faq
|
||||
aliases: [ '/dockershim' ]
|
||||
@@ -184,7 +185,7 @@ options are available as you migrate things over.
|
||||
[documentation]: https://github.com/containerd/cri/blob/master/docs/registry.md
|
||||
|
||||
For instructions on how to use containerd and CRI-O with Kubernetes, see the
|
||||
Kubernetes documentation on [Container Runtimes]
|
||||
Kubernetes documentation on [Container Runtimes].
|
||||
|
||||
[Container Runtimes]: /docs/setup/production-environment/container-runtimes/
|
||||
|
||||
@@ -192,7 +193,10 @@ Kubernetes documentation on [Container Runtimes]
|
||||
|
||||
If you use a vendor-supported Kubernetes distribution, you can ask them about
|
||||
upgrade plans for their products. For end-user questions, please post them
|
||||
to our end user community forum: https://discuss.kubernetes.io/.
|
||||
to our end user community forum: https://discuss.kubernetes.io/.
|
||||
|
||||
You can discuss the decision to remove dockershim via a dedicated
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917).
|
||||
|
||||
You can also check out the excellent blog post
|
||||
[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
|
||||
@@ -200,6 +204,15 @@ 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
|
||||
|
||||
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
|
||||
are mounting the Docker Engine socket (`docker.sock`) as a volume.
|
||||
Find more details and usage patterns in the DDS project's [README][dds].
|
||||
|
||||
[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket
|
||||
|
||||
### Can I have a hug?
|
||||
|
||||
Yes, we're still giving hugs as requested. 🤗🤗🤗
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "Dockershim: The Historical Context"
|
||||
date: 2022-05-03
|
||||
slug: dockershim-historical-context
|
||||
---
|
||||
|
||||
**Author:** Kat Cosgrove
|
||||
|
||||
|
||||
Dockershim has been removed as of Kubernetes v1.24, and this is a positive move for the project. However, context is important for fully understanding something, be it socially or in software development, and this deserves a more in-depth review. Alongside the dockershim removal in Kubernetes v1.24, we’ve seen some confusion (sometimes at a panic level) and dissatisfaction with this decision in the community, largely due to a lack of context around this removal. The decision to deprecate and eventually remove dockershim from Kubernetes was not made quickly or lightly. Still, it’s been in the works for so long that many of today’s users are newer than that decision, and certainly newer than the choices that led to the dockershim being necessary in the first place.
|
||||
|
||||
So what is the dockershim, and why is it going away?
|
||||
|
||||
In the early days of Kubernetes, we only supported one container runtime. That runtime was Docker Engine. Back then, there weren’t really a lot of other options out there and Docker was the dominant tool for working with containers, so this was not a controversial choice. Eventually, we started adding more container runtimes, like rkt and hypernetes, and it became clear that Kubernetes users want a choice of runtimes working best for them. So Kubernetes needed a way to allow cluster operators the flexibility to use whatever runtime they choose.
|
||||
|
||||
The [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (CRI) was released to allow that flexibility. The introduction of CRI was great for the project and users alike, but it did introduce a problem: Docker Engine’s use as a container runtime predates CRI, and Docker Engine is not CRI-compatible. To solve this issue, a small software shim (dockershim) was introduced as part of the kubelet component specifically to fill in the gaps between Docker Engine and CRI, allowing cluster operators to continue using Docker Engine as their container runtime largely uninterrupted.
|
||||
|
||||
However, this little software shim was never intended to be a permanent solution. Over the course of years, its existence has introduced a lot of unnecessary complexity to the kubelet itself. Some integrations are inconsistently implemented for Docker because of this shim, resulting in an increased burden on maintainers, and maintaining vendor-specific code is not in line with our open source philosophy. To reduce this maintenance burden and move towards a more collaborative community in support of open standards, [KEP-2221 was introduced](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim), proposing the removal of the dockershim. With the release of Kubernetes v1.20, the deprecation was official.
|
||||
|
||||
We didn’t do a great job communicating this, and unfortunately, the deprecation announcement led to some panic within the community. Confusion around what this meant for Docker as a company, if container images built by Docker would still run, and what Docker Engine actually is led to a conflagration on social media. This was our fault; we should have more clearly communicated what was happening and why at the time. To combat this, we released [a blog](/blog/2020/12/02/dont-panic-kubernetes-and-docker/) and [accompanying FAQ](/blog/2020/12/02/dockershim-faq/) to allay the community’s fears and correct some misconceptions about what Docker is and how containers work within Kubernetes. As a result of the community’s concerns, Docker and Mirantis jointly agreed to continue supporting the dockershim code in the form of [cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/), allowing you to continue using Docker Engine as your container runtime if need be. For the interest of users who want to try other runtimes, like containerd or cri-o, [migration documentation was written](docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
|
||||
|
||||
We later [surveyed the community](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) and [discovered that there are still many users with questions and concerns](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim). In response, Kubernetes maintainers and the CNCF committed to addressing these concerns by extending documentation and other programs. In fact, this blog post is a part of this program. With so many end users successfully migrated to other runtimes, and improved documentation, we believe that everyone has a paved way to migration now.
|
||||
|
||||
Docker is not going away, either as a tool or as a company. It’s an important part of the cloud native community and the history of the Kubernetes project. We wouldn’t be where we are without them. That said, removing dockershim from kubelet is ultimately good for the community, the ecosystem, the project, and open source at large. This is an opportunity for all of us to come together to support open standards, and we’re glad to be doing so with the help of Docker and the community.
|
||||
Reference in New Issue
Block a user