Merge pull request #32094 from tengqm/zh-fix-dockershim-check

[zh] Tweak translation of dockershim check
This commit is contained in:
Kubernetes Prow Robot 2022-03-09 01:50:12 -08:00 committed by GitHub
commit 82b7401a77
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 23 deletions

View File

@ -29,7 +29,7 @@ you can take to check whether any workloads could be affected by `dockershim` de
-->
本页讲解你的集群把 Docker 用作容器运行时的运作机制,
并提供使用 `dockershim` 时,它所扮演角色的详细信息,
继而展示了一组验证步骤,可用来检查弃用 `dockershim` 对你的工作负载的影响。
继而展示了一组操作,可用来检查弃用 `dockershim` 对你的工作负载是否有影响。
<!--
## Finding if your app has a dependencies on Docker {#find-docker-dependencies}
@ -41,16 +41,16 @@ If you are using Docker for building your application containers, you can still
run these containers on any container runtime. This use of Docker does not count
as a dependency on Docker as a container runtime.
-->
虽然你通过 Docker 创建了应用容器,但这些容器却可以运行于所有容器运行时
所以这种使用 Docker 容器运行时的方式并不构成对 Docker 的依赖。
即使你是通过 Docker 创建的应用容器,也不妨碍你在其他任何容器运行时上运行这些容器
这种使用 Docker 的方式并不构成对 Docker 作为一个容器运行时的依赖。
<!--
When alternative container runtime is used, executing Docker commands may either
not work or yield unexpected output. This is how you can find whether you have a
dependency on Docker:
-->
当用了替代的容器运行时之后Docker 命令可能不工作,甚至产生意外的输出。
这才是判定你是否依赖于 Docker 的方法。
当用了别的容器运行时之后Docker 命令可能不工作,或者产生意外的输出。
下面是判定你是否依赖于 Docker 的方法。
<!--
1. Make sure no privileged Pods execute Docker commands (like `docker ps`),
@ -75,20 +75,21 @@ dependency on Docker:
cluster before migration.
-->
1. 确认没有特权 Pod 执行 Docker 命令(如 `docker ps`)、重新启动 Docker
服务(如 `systemctl restart docker.service`)或修改
Docker 配置文件 `/etc/docker/daemon.json`
服务(如 `systemctl restart docker.service`)或修改 Docker 配置文件
`/etc/docker/daemon.json`
2. 检查 Docker 配置文件(如 `/etc/docker/daemon.json`中容器镜像仓库的镜像mirror站点设置。
这些配置通常需要针对不同容器运行时来重新设置。
3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行Docker命令。
3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行 Docker 命令。
可能的情况如:
- SSH 到节点排查故障;
- 节点启动脚本;
- 直接安装在节点上的监控和安全代理。
4. 检查执行上述特权操作的第三方工具。详细操作请参考
[从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
4. 检查执行上述特权操作的第三方工具。详细操作请参考
[从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents)
5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况,不太可能影响你的应用。
一些工具很可能被配置为使用了 Docker 特性,比如,基于特定指标发警报,或者在故障排查指令的一个环节中搜索特定的日志信息。
如果你有此类配置的工具,需要在迁移之前,在测试集群上完成功能验证。
一些工具很可能被配置为使用了 Docker 特性,比如,基于特定指标发警报,
或者在故障排查指令的一个环节中搜索特定的日志信息。
如果你有此类配置的工具,需要在迁移之前,在测试集群上测试这类行为。
<!--
## Dependency on Docker explained {#role-of-dockershim}
@ -103,8 +104,7 @@ uses the container runtime interface as an abstraction so that you can use any c
container runtime.
-->
[容器运行时](/zh/docs/concepts/containers/#container-runtimes)是一个软件,用来运行组成 Kubernetes Pod 的容器。
Kubernetes 负责编排和调度 Pod在每一个节点上
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
Kubernetes 负责编排和调度 Pod在每一个节点上{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
使用抽象的容器运行时接口,所以你可以任意选用兼容的容器运行时。
<!--
@ -118,14 +118,14 @@ if Docker were a CRI compatible runtime.
在早期版本中Kubernetes 提供的兼容性支持一个容器运行时Docker。
在 Kubernetes 发展历史中,集群运营人员希望采用更多的容器运行时。
于是 CRI 被设计出来满足这类灵活性需要 - 而 kubelet 亦开始支持 CRI。
然而,因为 Docker 在 CRI 规范创建之前就已经存在Kubernetes 就创建了一个适配器组件`dockershim`
dockershim 适配器允许 kubelet 与 Docker交互就好像 Docker 是一个 CRI 兼容的运行时一样。
然而,因为 Docker 在 CRI 规范创建之前就已经存在Kubernetes 就创建了一个适配器组件 `dockershim`
dockershim 适配器允许 kubelet 与 Docker 交互,就好像 Docker 是一个 CRI 兼容的运行时一样。
<!--
You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post.
-->
你可以阅读博文
[Kubernetes 容器集成功能的正式发布](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)
[Kubernetes 正式支持集成 Containerd](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)
<!-- Dockershim vs. CRI with Containerd -->
![Dockershim 和 Containerd CRI 的实现对比图](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png)
@ -138,8 +138,8 @@ So any Docker tooling or fancy UI you might have used
before to check on these containers is no longer available.
-->
切换到容器运行时 Containerd 可以消除掉中间环节。
所有以前遗留的容器可由 Containerd 这类容器运行时来运行和管理,操作体验也和以前一样
但是现在,由于直接用容器运行时调度容器,所以它们对 Docker 来说是不可见的。
所有相同的容器都可由 Containerd 这类容器运行时来运行
但是现在,由于直接用容器运行时调度容器,它们对 Docker 是不可见的。
因此,你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。
<!--
@ -156,10 +156,9 @@ the Kubernetes API rather than directly through the container runtime (this advi
for all container runtimes, not only Docker).
-->
{{< note >}}
如果你用 Kubernetes 运行工作负载,最好通过 Kubernetes API停止容器而不是通过容器运行时
如果你在用 Kubernetes 运行工作负载,最好通过 Kubernetes API 停止容器,
而不是通过容器运行时来停止它们
(此建议适用于所有容器运行时,不仅仅是针对 Docker
{{< /note >}}
<!--
@ -170,4 +169,5 @@ by Kubernetes.
-->
你仍然可以下载镜像,或者用 `docker build` 命令创建它们。
但用 Docker 创建、下载的镜像,对于容器运行时和 Kubernetes均不可见。
为了在 Kubernetes 中使用需要把镜像推送push到某注册中心。
为了在 Kubernetes 中使用需要把镜像推送push到某镜像仓库。