Skip to content

Commit 837ae37

Browse files
zhiguo-luzhiguo-lu
committed
[zh] translate blog Don't Panic: Kubernetes and Docker
1 parent 688fa0c commit 837ae37

File tree

1 file changed

+210
-0
lines changed

1 file changed

+210
-0
lines changed

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

Lines changed: 210 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,210 @@
1+
---
2+
layout: blog
3+
title: "别慌: Kubernetes 和 Docker"
4+
date: 2020-12-02
5+
slug: dont-panic-kubernetes-and-docker
6+
---
7+
<!--
8+
layout: blog
9+
title: "Don't Panic: Kubernetes and Docker"
10+
date: 2020-12-02
11+
slug: dont-panic-kubernetes-and-docker
12+
-->
13+
14+
**作者：** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
15+
16+
<!--
17+
Kubernetes is [deprecating
18+
Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
19+
as a container runtime after v1.20.
20+
-->
21+
Kubernetes 从版本 v1.20 之后，[弃用 Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
22+
这个容器运行时。
23+
24+
<!--
25+
**You do not need to panic. It’s not as dramatic as it sounds.**
26+
-->
27+
**不必慌张，这件事并没有听起来那么吓人。**
28+
29+
<!--
30+
TL;DR Docker as an underlying runtime is being deprecated in favor of runtimes
31+
that use the [Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
32+
created for Kubernetes. Docker-produced images will continue to work in your
33+
cluster with all runtimes, as they always have.
34+
-->
35+
弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的
36+
[Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
37+
的运行时。
38+
Docker 构建的镜像，将在你的集群的所有运行时中继续工作，一如既往。
39+
40+
<!--
41+
If you’re an end-user of Kubernetes, not a whole lot will be changing for you.
42+
This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or
43+
shouldn’t, use Docker as a development tool anymore. Docker is still a useful
44+
tool for building containers, and the images that result from running `docker
45+
build` can still run in your Kubernetes cluster.
46+
-->
47+
如果你是 Kubernetes 的终端用户，这对你不会有太大影响。
48+
这事并不意味着 Dockder 已死、也不意味着你不能或不该继续把 Docker 用作开发工具。
49+
Docker 仍然是构建容器的利器，使用命令 `docker build` 构建的镜像在 Kubernetes 集群中仍然可以运行。
50+
51+
<!--
52+
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
53+
make sure your worker nodes are using a supported container runtime before
54+
Docker support is removed in a future version of Kubernetes. If you have node
55+
customizations you may need to update them based on your environment and runtime
56+
requirements. Please work with your service provider to ensure proper upgrade
57+
testing and planning.
58+
-->
59+
如果你正在使用 GKE、EKS、或 AKS
60+
([默认使用 containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16))
61+
这类托管 Kubernetes 服务，你需要在 Kubernetes 后续版本移除对 Docker 支持之前，
62+
确认工作节点使用了被支持的容器运行时。
63+
如果你的节点被定制过，你可能需要根据你自己的环境和运行时需求更新它们。
64+
请与你的服务供应商协作，确保做出适当的升级测试和计划。
65+
66+
<!--
67+
If you’re rolling your own clusters, you will also need to make changes to avoid
68+
your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
69+
When Docker runtime support is removed in a future release (currently planned
70+
for the 1.22 release in late 2021) of Kubernetes it will no longer be supported
71+
and you will need to switch to one of the other compliant container runtimes,
72+
like containerd or CRI-O. Just make sure that the runtime you choose supports
73+
the docker daemon configurations you currently use (e.g. logging).
74+
-->
75+
如果你正在运营你自己的集群，那还应该做些工作，以避免集群中断。
76+
在 v1.20 版中，你仅会得到一个 Docker 的弃用警告。
77+
当对 Docker 运行时的支持在 Kubernetes 某个后续发行版（目前的计划是 2021 年晚些时候的 1.22 版）中被移除时，
78+
你需要切换到 containerd 或 CRI-O 等兼容的容器运行时。
79+
只要确保你选择的运行时支持你当前使用的 Docker 守护进程配置（例如 logging）。
80+
81+
<!--
82+
## So why the confusion and what is everyone freaking out about?
83+
-->
84+
## 那为什么会有这样的困惑，为什么每个人要害怕呢？{#so-why-the-confusion-and-what-is-everyone-freaking-out-about}
85+
86+
<!--
87+
We’re talking about two different environments here, and that’s creating
88+
confusion. Inside of your Kubernetes cluster, there’s a thing called a container
89+
runtime that’s responsible for pulling and running your container images. Docker
90+
is a popular choice for that runtime (other common options include containerd
91+
and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and
92+
that causes a problem.
93+
-->
94+
我们在这里讨论的是两套不同的环境，这就是造成困惑的根源。
95+
在你的 Kubernetes 集群中，有一个叫做容器运行时的东西，它负责拉取并运行容器镜像。
96+
Docker 对于运行时来说是一个流行的选择（其他常见的选择包括 containerd 和 CRI-O），
97+
但 Docker 并非设计用来嵌入到 Kubernetes，这就是问题所在。
98+
99+
<!--
100+
You see, the thing we call “Docker” isn’t actually one thing&mdash;it’s an entire
101+
tech stack, and one part of it is a thing called “containerd,” which is a
102+
high-level container runtime by itself. Docker is cool and useful because it has
103+
a lot of UX enhancements that make it really easy for humans to interact with
104+
while we’re doing development work, but those UX enhancements aren’t necessary
105+
for Kubernetes, because it isn’t a human.
106+
-->
107+
你看，我们称之为 “Docker” 的物件实际上并不是一个物件——它是一个完整的技术堆栈，
108+
它其中一个叫做 “containerd” 的部件本身，才是一个高级容器运行时。
109+
Docker 既酷炫又实用，因为它提供了很多用户体验增强功能，而这简化了我们做开发工作时的操作，
110+
Kubernetes 用不到这些增强的用户体验，毕竟它并非人类。
111+
112+
<!--
113+
As a result of this human-friendly abstraction layer, your Kubernetes cluster
114+
has to use another tool called Dockershim to get at what it really needs, which
115+
is containerd. That’s not great, because it gives us another thing that has to
116+
be maintained and can possibly break. What’s actually happening here is that
117+
Dockershim is being removed from Kubelet as early as v1.23 release, which
118+
removes support for Docker as a container runtime as a result. You might be
119+
thinking to yourself, but if containerd is included in the Docker stack, why
120+
does Kubernetes need the Dockershim?
121+
-->
122+
因为这个用户友好的抽象层，Kubernetes 集群不得不引入一个叫做 Dockershim 的工具来访问它真正需要的 containerd。
123+
这不是一件好事，因为这引入了额外的运维工作量，而且还可能出错。
124+
实际上正在发生的事情就是：Dockershim 将在不早于 v1.23 版中从 kubelet 中被移除，也就取消对 Docker 容器运行时的支持。
125+
你心里可能会想，如果 containerd 已经包含在 Docker 堆栈中，为什么 Kubernetes 需要 Dockershim。
126+
127+
<!--
128+
Docker isn’t compliant with CRI, the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/).
129+
If it were, we wouldn’t need the shim, and this wouldn’t be a thing. But it’s
130+
not the end of the world, and you don’t need to panic&mdash;you just need to change
131+
your container runtime from Docker to another supported container runtime.
132+
-->
133+
Docker 不兼容 CRI，
134+
[容器运行时接口](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)。
135+
如果支持，我们就不需要这个 shim 了，也就没问题了。
136+
但这也不是世界末日，你也不需要恐慌——你唯一要做的就是把你的容器运行时从 Docker 切换到其他受支持的容器运行时。
137+
138+
<!--
139+
One thing to note: If you are relying on the underlying docker socket
140+
(`/var/run/docker.sock`) as part of a workflow within your cluster today, moving
141+
to a different runtime will break your ability to use it. This pattern is often
142+
called Docker in Docker. There are lots of options out there for this specific
143+
use case including things like
144+
[kaniko](https://github.com/GoogleContainerTools/kaniko),
145+
[img](https://github.com/genuinetools/img), and
146+
[buildah](https://github.com/containers/buildah).
147+
-->
148+
要注意一点：如果你依赖底层的 Docker 套接字(`/var/run/docker.sock`)，作为你集群中工作流的一部分，
149+
切换到不同的运行时会导致你无法使用它。
150+
这种模式经常被称之为嵌套 Docker（Docker in Docker）。
151+
对于这种特殊的场景，有很多选项，比如：
152+
[kaniko](https://github.com/GoogleContainerTools/kaniko)、
153+
[img](https://github.com/genuinetools/img)、和
154+
[buildah](https://github.com/containers/buildah)。
155+
156+
<!--
157+
## What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker?
158+
-->
159+
## 那么，这一改变对开发人员意味着什么？我们还要写 Dockerfile 吗？还能用 Docker 构建镜像吗？{#what-does-this-change-mean-for-developers}
160+
161+
<!--
162+
This change addresses a different environment than most folks use to interact
163+
with Docker. The Docker installation you’re using in development is unrelated to
164+
the Docker runtime inside your Kubernetes cluster. It’s confusing, we understand.
165+
As a developer, Docker is still useful to you in all the ways it was before this
166+
change was announced. The image that Docker produces isn’t really a
167+
Docker-specific image&mdash;it’s an OCI ([Open Container Initiative](https://opencontainers.org/)) image.
168+
Any OCI-compliant image, regardless of the tool you use to build it, will look
169+
the same to Kubernetes. Both [containerd](https://containerd.io/) and
170+
[CRI-O](https://cri-o.io/) know how to pull those images and run them. This is
171+
why we have a standard for what containers should look like.
172+
-->
173+
此次改变带来了一个不同的环境，这不同于我们常用的 Docker 交互方式。
174+
你在开发环境中用的 Docker 和你 Kubernetes 集群中的 Docker 运行时无关。
175+
我们知道这听起来让人困惑。
176+
对于开发人员，Docker 从所有角度来看仍然有用，就跟这次改变之前一样。
177+
Docker 构建的镜像并不是 Docker 特有的镜像——它是一个
178+
OCI（[开放容器标准](https://opencontainers.org/)）镜像。
179+
任一 OCI 兼容的镜像，不管它是用什么工具构建的，在 Kubernetes 的角度来看都是一样的。
180+
[containerd](https://containerd.io/) 和
181+
[CRI-O](https://cri-o.io/)
182+
两者都知道怎么拉取并运行这些镜像。
183+
这就是我们制定容器标准的原因。
184+
185+
<!--
186+
So, this change is coming. It’s going to cause issues for some, but it isn’t
187+
catastrophic, and generally it’s a good thing. Depending on how you interact
188+
with Kubernetes, this could mean nothing to you, or it could mean a bit of work.
189+
In the long run, it’s going to make things easier. If this is still confusing
190+
for you, that’s okay&mdash;there’s a lot going on here; Kubernetes has a lot of
191+
moving parts, and nobody is an expert in 100% of it. We encourage any and all
192+
questions regardless of experience level or complexity! Our goal is to make sure
193+
everyone is educated as much as possible on the upcoming changes. We hope
194+
this has answered most of your questions and soothed some anxieties! ❤️
195+
-->
196+
所以，改变已经发生。
197+
它确实带来了一些问题，但这不是一个灾难，总的说来，这还是一件好事。
198+
根据你操作 Kubernetes 的方式的不同，这可能对你不构成任何问题，或者也只是意味着一点点的工作量。
199+
从一个长远的角度看，它使得事情更简单。
200+
如果你还在困惑，也没问题——这里还有很多事情；
201+
Kubernetes 有很多变化中的功能，没有人是100%的专家。
202+
我们鼓励你提出任何问题，无论水平高低、问题难易。
203+
我们的目标是确保所有人都能在即将到来的改变中获得足够的了解。
204+
我们希望这已经回答了你的大部分问题，并缓解了一些焦虑！❤️
205+
206+
<!--
207+
Looking for more answers? Check out our accompanying [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
208+
-->
209+
还在寻求更多答案吗？请参考我们附带的
210+
[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)。

0 commit comments

Comments
 (0)