Skip to content

Commit 0295195

Browse files
committed
[zh] translate check if dockershim affects you
fix according to sftim and tengqm
1 parent 9cff3a5 commit 0295195

File tree

1 file changed

+164
-0
lines changed

1 file changed

+164
-0
lines changed
Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
---
2+
title: 检查弃用 Dockershim 对你的影响
3+
content_type: task
4+
weight: 20
5+
---
6+
<!--
7+
title: Check whether Dockershim deprecation affects you
8+
content_type: task
9+
reviewers:
10+
- SergeyKanzhelev
11+
weight: 20
12+
-->
13+
14+
<!-- overview -->
15+
16+
<!--
17+
The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's
18+
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
19+
Kubernetes' built-in `dockershim` component was deprecated in release v1.20.
20+
-->
21+
Kubernetes 的 `dockershim` 组件使得你可以把 Docker 用作 Kubernetes 的
22+
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。
23+
在 Kubernetes v1.20 版本中,内建组件 `dockershim` 被弃用。
24+
25+
<!--
26+
This page explains how your cluster could be using Docker as a container runtime,
27+
provides details on the role that `dockershim` plays when in use, and shows steps
28+
you can take to check whether any workloads could be affected by `dockershim` deprecation.
29+
-->
30+
本页讲解你的集群把 Docker 用作容器运行时的运作机制,
31+
并提供使用 `dockershim` 时,它所扮演角色的详细信息,
32+
继而展示了一组验证步骤,可用来检查弃用 `dockershim` 对你的工作负载的影响。
33+
34+
<!--
35+
## Finding if your app has a dependencies on Docker {#find-docker-dependencies}
36+
-->
37+
## 检查你的应用是否依赖于 Docker {#find-docker-dependencies}
38+
39+
<!--
40+
If you are using Docker for building your application containers, you can still
41+
run these containers on any container runtime. This use of Docker does not count
42+
as a dependency on Docker as a container runtime.
43+
-->
44+
虽然你通过 Docker 创建了应用容器,但这些容器却可以运行于所有容器运行时。
45+
所以这种使用 Docker 容器运行时的方式并不构成对 Docker 的依赖。
46+
47+
<!--
48+
When alternative container runtime is used, executing Docker commands may either
49+
not work or yield unexpected output. This is how you can find whether you have a
50+
dependency on Docker:
51+
-->
52+
当用了替代的容器运行时之后,Docker 命令可能不工作,甚至产生意外的输出。
53+
这才是判定你是否依赖于 Docker 的方法。
54+
55+
<!--
56+
1. Make sure no privileged Pods execute Docker commands.
57+
2. Check that scripts and apps running on nodes outside of Kubernetes
58+
infrastructure do not execute Docker commands. It might be:
59+
- SSH to nodes to troubleshoot;
60+
- Node startup scripts;
61+
- Monitoring and security agents installed on nodes directly.
62+
3. Third-party tools that perform above mentioned privileged operations. See
63+
[Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
64+
for more information.
65+
4. Make sure there is no indirect dependencies on dockershim behavior.
66+
This is an edge case and unlikely to affect your application. Some tooling may be configured
67+
to react to Docker-specific behaviors, for example, raise alert on specific metrics or search for
68+
a specific log message as part of troubleshooting instructions.
69+
If you have such tooling configured, test the behavior on test
70+
cluster before migration.
71+
-->
72+
1. 确认没有特权 Pod 执行 docker 命令。
73+
2. 检查 Kubernetes 基础架构外部节点上的脚本和应用,确认它们没有执行 Docker 命令。可能的命令有:
74+
- SSH 到节点排查故障;
75+
- 节点启动脚本;
76+
- 直接安装在节点上的监视和安全代理。
77+
3. 检查执行了上述特权操作的第三方工具。详细操作请参考:
78+
[从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
79+
4. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况,不太可能影响你的应用。
80+
一些工具很可能被配置为使用了 Docker 特性,比如,基于特定指标发警报,或者在故障排查指令的一个环节中搜索特定的日志信息。
81+
如果你有此类配置的工具,需要在迁移之前,在测试集群上完成功能验证。
82+
83+
84+
<!--
85+
## Dependency on Docker explained {#role-of-dockershim}
86+
-->
87+
## Docker 依赖详解 {#role-of-dockershim}
88+
89+
<!--
90+
A [container runtime](/docs/concepts/containers/#container-runtimes) is software that can
91+
execute the containers that make up a Kubernetes pod. Kubernetes is responsible for orchestration
92+
and scheduling of Pods; on each node, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
93+
uses the container runtime interface as an abstraction so that you can use any compatible
94+
container runtime.
95+
-->
96+
[容器运行时](/zh/docs/concepts/containers/#container-runtimes)是一个软件,用来运行组成 Kubernetes Pod 的容器。
97+
Kubernetes 负责编排和调度 Pod;在每一个节点上,
98+
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
99+
使用抽象的容器运行时接口,所以你可以任意选用兼容的容器运行时。
100+
101+
<!--
102+
In its earliest releases, Kubernetes offered compatibility with just one container runtime: Docker.
103+
Later in the Kubernetes project's history, cluster operators wanted to adopt additional container runtimes.
104+
The CRI was designed to allow this kind of flexibility - and the kubelet began supporting CRI. However,
105+
because Docker existed before the CRI specification was invented, the Kubernetes project created an
106+
adapter component, `dockershim`. The dockershim adapter allows the kubelet to interact with Docker as
107+
if Docker were a CRI compatible runtime.
108+
-->
109+
在早期版本中,Kubernetes 提供的兼容性只支持一个容器运行时:Docker。
110+
在 Kubernetes 发展历史中,集群运营人员希望采用更多的容器运行时。
111+
于是 CRI 被设计出来满足这类灵活性需要 - 而 kubelet 亦开始支持 CRI。
112+
然而,因为 Docker 在 CRI 规范创建之前就已经存在,Kubernetes 就创建了一个适配器组件:`dockershim`
113+
dockershim 适配器允许 kubelet 与 Docker交互,就好像 Docker 是一个 CRI 兼容的运行时一样。
114+
115+
<!--
116+
You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post.
117+
-->
118+
你可以阅读博文
119+
[Kubernetes 容器集成功能的正式发布](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)
120+
121+
<!-- Dockershim vs. CRI with Containerd -->
122+
![Dockershim 和 Containerd CRI 的实现对比图](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png)
123+
124+
<!--
125+
Switching to Containerd as a container runtime eliminates the middleman. All the
126+
same containers can be run by container runtimes like Containerd as before. But
127+
now, since containers schedule directly with the container runtime, they are not visible to Docker.
128+
So any Docker tooling or fancy UI you might have used
129+
before to check on these containers is no longer available.
130+
-->
131+
切换到容器运行时 Containerd 可以消除掉中间环节。
132+
所有以前遗留的容器可由 Containerd 这类容器运行时来运行和管理,操作体验也和以前一样。
133+
但是现在,由于直接用容器运行时调度容器,所以它们对 Docker 来说是不可见的。
134+
因此,你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。
135+
136+
<!--
137+
You cannot get container information using `docker ps` or `docker inspect`
138+
commands. As you cannot list containers, you cannot get logs, stop containers,
139+
or execute something inside container using `docker exec`.
140+
-->
141+
你不能再使用 `docker ps``docker inspect` 命令来获取容器信息。
142+
由于你不能列出容器,因此你不能获取日志、停止容器,甚至不能通过 `docker exec` 在容器中执行命令。
143+
144+
<!--
145+
If you're running workloads via Kubernetes, the best way to stop a container is through
146+
the Kubernetes API rather than directly through the container runtime (this advice applies
147+
for all container runtimes, not just Docker).
148+
-->
149+
{{< note >}}
150+
151+
如果你用 Kubernetes 运行工作负载,最好通过 Kubernetes API停止容器,而不是通过容器运行时
152+
(此建议适用于所有容器运行时,不仅仅是针对 Docker)。
153+
154+
{{< /note >}}
155+
156+
<!--
157+
You can still pull images or build them using `docker build` command. But images
158+
built or pulled by Docker would not be visible to container runtime and
159+
Kubernetes. They needed to be pushed to some registry to allow them to be used
160+
by Kubernetes.
161+
-->
162+
你仍然可以下载镜像,或者用 `docker build` 命令创建它们。
163+
但用 Docker 创建、下载的镜像,对于容器运行时和 Kubernetes,均不可见。
164+
为了在 Kubernetes 中使用,需要把镜像推送(push)到某注册中心。

0 commit comments

Comments
 (0)