whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Sync dockshim article

Browse Source
This commit is contained in:
Sean Wei
2022-05-19 14:34:00 +08:00
parent c965d048e9
commit c813ce259c
2 changed files with 167 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/blog/_posts/2020-12-02-dockershim-faq.md
+29 -9
View File
@@ -3,14 +3,12 @@ layout: blog
title: "弃用 Dockershim 的常见问题"
date: 2020-12-02
slug: dockershim-faq
aliases: [ '/zh/dockershim' ]
---
<!--
layout: blog
title: "Dockershim Deprecation FAQ"
date: 2020-12-02
slug: dockershim-faq
aliases: [ '/dockershim' ]
-->
<!--
@@ -55,7 +53,7 @@ You can read more about the community discussion and planning in the
-->
Dockershim 向来都是一个临时解决方案（因此得名：shim）。
你可以进一步阅读
[移除 Kubernetes 增强方案 Dockershim][drkep]
[移除 Dockershim 这一 Kubernetes 增强方案][drkep]
以了解相关的社区讨论和计划。
<!--
@@ -89,7 +87,7 @@ startup if using Docker as the runtime.
<!--
Given the impact of this change, we are using an extended deprecation timeline.
It will not be removed before Kubernetes 1.22, meaning the earliest release without
dockershim would be 1.23 in late 2021.
dockershim would be 1.23 in late 2021.
_Update_: removal of dockershim is scheduled for Kubernetes v1.24, see
[Dockershim Removal Kubernetes Enhancement Proposal][drkep].
We will be working closely with vendors and other ecosystem groups to ensure a smooth transition and will evaluate
@@ -98,9 +96,26 @@ things as the situation evolves.
考虑到此改变带来的影响，我们使用了一个加长的废弃时间表。
在 Kubernetes 1.22 版之前，它不会被彻底移除；换句话说，dockershim 被移除的最早版本会是 2021 年底发布的 1.23 版。
_更新_：dockershim 计划在 Kubernetes 1.24 版被移除，
请参阅[移除 Kubernetes 增强方案 Dockershim][drkep]。
请参阅[移除 Dockershim 这一 Kubernetes 增强方案][drkep]。
我们将与供应商以及其他生态团队紧密合作，确保顺利过渡，并将依据事态的发展评估后续事项。
<!--
### Can I still use dockershim after it is removed from Kubernetes?
-->
### 从 Kubernetes 中移除后我还能使用 dockershim 吗？ {#can-i-still-use-dockershim-after-it-is-removed-from-kubernetes}
<!--
Update:
Mirantis and Docker have [committed][mirantis] to maintaining the dockershim after
it is removed from Kubernetes.
-->
更新：Mirantis 和 Docker [已承诺][mirantis]在 dockershim 从 Kubernetes
中删除后对其进行维护。
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
<!--
### Will my existing Docker images still work?
-->
@@ -163,11 +178,11 @@ related projects follow a similar pattern as well, demonstrating the stability a
usability of other container runtimes. As an example, OpenShift 4.x has been
using the [CRI-O] runtime in production since June 2019.
-->
此外，[kind](https://kind.sigs.k8s.io/) 项目使用 containerd 已经有年头了，
此外，[kind] 项目使用 containerd 已经有年头了，
并且在这个场景中，稳定性还明显得到提升。
Kind 和 containerd 每天都会做多次协调，以验证对 Kubernetes 代码库的所有更改。
其他相关项目也遵循同样的模式，从而展示了其他容器运行时的稳定性和可用性。
例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O](https://cri-o.io/) 运行时。
例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O] 运行时。
<!--
For other examples and references you can look at the adopters of containerd and
@@ -181,6 +196,11 @@ CRI-O, two container runtimes under the Cloud Native Computing Foundation ([CNCF
- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md)
- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md)
[CRI-O]: https://cri-o.io/
[kind]: https://kind.sigs.k8s.io/
[CNCF]: https://cncf.io
<!--
### People keep referencing OCI, what is that?
-->
@@ -300,7 +320,7 @@ Kubernetes documentation on [Container Runtimes]
<!--
### What if I have more questions?
-->
### 我还有问题怎么办？{#what-if-I-have-more-question}
### 我还有问题怎么办？{#what-if-I-have-more-questions}
<!--
If you use a vendor-supported Kubernetes distribution, you can ask them about
@@ -308,7 +328,7 @@ upgrade plans for their products. For end-user questions, please post them
to our end user community forum: https://discuss.kubernetes.io/.
-->
如果你使用了一个有供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。
对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。
对于最终用户的问题，请把问题发到我们的最终用户社区的[论坛](https://discuss.kubernetes.io/)。
<!--
You can also check out the excellent blog post
content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
+138 -117
View File
@@ -1,9 +1,10 @@
---
layout: blog
title: "更新：弃用 Dockershim 的常见问题"
linkTitle: "弃用 Dockershim 的常见问题"
title: "更新：移除 Dockershim 的常见问题"
linkTitle: "移除 Dockershim 的常见问题"
date: 2022-02-17
slug: dockershim-faq
aliases: [ 'zh/dockershim' ]
---
<!--
layout: blog
@@ -15,55 +16,69 @@ aliases: [ '/dockershim' ]
-->
<!--
**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
published in late 2020.**
**This supersedes the original
[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
published in late 2020. The article includes updates from the v1.24
release of Kubernetes.**
-->
**本文是针对2020年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。**
**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。
本文包括 Kubernetes v1.24 版本的更新。**
---
<!--
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.
-->
本文介绍了一些关于从 Kubernetes 中移除 _dockershim_ 的常见问题。
该移除最初是作为 Kubernetes v1.20
版本的一部分[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。
Kubernetes 在 [v1.24 版](/releases/#release-v1-24)移除了 dockershim。
<!--
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/).
-->
本文回顾了自 Kubernetes v1.20 版本[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)弃用
Dockershim 以来所引发的一些常见问题。关于弃用细节以及这些细节背后的含义，请参考博文
关于细节请参考博文
[别慌: Kubernetes 和 Docker](/zh/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-deprecation-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/).
-->
你还可以查阅：[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)这篇文章，
以确定弃用 dockershim 会对你或你的组织带来多大的影响。
要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅：
[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-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.
-->
随着 Kubernetes 1.24 版本的发布迫在眉睫，我们一直在努力尝试使其能够平稳升级顺利过渡。
在 Kubernetes 1.24 发布之前的几个月和几天里，Kubernetes
贡献者努力试图让这个过渡顺利进行。
<!--
- 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).
-->
- 我们已经写了一篇博文，详细说明了我们的[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)。
- 我们我们相信可以无障碍的迁移到其他[容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes)。
- 我们撰写了 [dockershim 迁移指南](/docs/tasks/administer-cluster/migrating-from-dockershim/)供你参考。
- 我们还创建了一个页面来列出[有关 dockershim 移除和使用 CRI 兼容运行时的文章](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。
- 一篇详细说明[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)的博文。
- 检查是否存在迁移到其他 [容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。
- 添加 [从 dockershim 迁移](/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。
该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。
<!--
### Why is the dockershim being removed from Kubernetes?
### Why was the dockershim removed from Kubernetes?
-->
### 为什么会从 Kubernetes 中移除 dockershim ？
### 为什么会从 Kubernetes 中移除 dockershim ？ {#why-was-the-dockershim-removed-from-kubernetes}
<!--
Early versions of Kubernetes only worked with a specific container runtime:
@@ -95,46 +110,101 @@ dockershim 代码一直是一个临时解决方案（因此得名：shim）。
<!--
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.
-->
此外，在较新的 CRI 运行时中实现了与 dockershim 不兼容的功能，例如 cgroups v2 和用户命名空间。
取消对 dockershim 的支持将加速这些领域的发展。
从 Kubernetes 中移除 dockershim 允许在这些领域进行进一步的开发。
<!--
### Are Docker and containers the same thing?
-->
### Docker 和容器一样吗？ {#are-docker-and-containers-the-same-thing}
<!--
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.
-->
Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用，但是 Linux
中的容器已经存在了很长时间，容器生态系统已经发展到比 Docker 广泛得多。
OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大，其中一些替代了 Docker
的某些方面，而另一些则增强了现有功能。
<!--
### Will my existing container images still work?
-->
### 我现有的容器镜像是否仍然有效？ {#will-my-existing-container-images-still-work}
<!--
Yes, the images produced from `docker build` will work with all CRI implementations.
All your existing images will still work exactly the same.
-->
是的，从 `docker build` 生成的镜像将适用于所有 CRI 实现，
现有的所有镜像仍将完全相同。
<!--
#### What about private images?
-->
#### 私有镜像呢？ {#what-about-private-images}
<!--
Yes. All CRI runtimes support the same pull secrets configuration used in
Kubernetes, either via the PodSpec or ServiceAccount.
-->
当然可以，所有 CRI 运行时都支持在 Kubernetes 中使用的相同的 pull secrets
配置，无论是通过 PodSpec 还是 ServiceAccount。
<!--
### Can I still use Docker Engine in Kubernetes 1.23?
-->
### 在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？
### 在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？ {#can-i-still-use-docker-engine-in-kubernetes-1-23}
<!--
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.
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.
-->
可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine，
在 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
启动时会打印一个警告日志。
你将在 1.23 版本及以前版本看到此警告。dockershim 将在 Kubernetes 1.24 版本中移除 。
你将在 1.23 版本及以前版本看到此警告，dockershim 已在 Kubernetes 1.24 版本中移除 。
<!--
### When will dockershim be removed?
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).
-->
### 什么时候移除 dockershim ？
如果你运行的是 Kubernetes v1.24 或更高版本，请参阅
[我仍然可以使用 Docker Engine 作为我的容器运行时吗？](#can-i-still-use-docker-engine-as-my-container-runtime)
（如果你使用任何支持 dockershim 的版本，可以随时切换离开；从版本 v1.24
开始，因为 Kubernetes 不再包含 dockershim，你**必须**切换）。
<!--
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.
### Which CRI implementation should I use?
-->
考虑到此变更带来的影响，我们使用了一个加长的废弃时间表。
dockershim 计划在 Kubernetes v1.24 中进行移除，
参见 [Kubernetes 移除 Dockershim 增强方案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)。
Kubernetes 项目将与供应商和其他生态系统组织密切合作，以确保平稳过渡，并将依据事态的发展评估后续事项。
### 我应该用哪个 CRI 实现？ {#which-cri-implementation-should-i-use}
<!--
### Can I still use Docker Engine as my container runtime?
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.
-->
### 我还可以使用 Docker Engine 作为我的容器运行时吗？
这是一个复杂的问题，依赖于许多因素。
如果你正在使用 Docker Engine，迁移到 containerd
应该是一个相对容易地转换，并将获得更好的性能和更少的开销。
然而，我们鼓励你探索 [CNCF landscape] 提供的所有选项，做出更适合你的选择。
[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
<!--
#### Can I still use Docker Engine as my container runtime?
-->
#### 我还可以使用 Docker Engine 作为我的容器运行时吗？ {#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.
@@ -155,51 +225,17 @@ Mirantis 和 Docker 已[承诺](https://www.mirantis.com/blog/mirantis-to-take-o
替代适配器名为 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。
<!--
### Will my existing container images still work?
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.
-->
### 我现有的容器镜像还能正常工作吗？
你可以安装 `cri-dockerd` 并使用它将 kubelet 连接到 Docker Engine。
阅读[将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)
以了解更多信息。
<!--
Yes, the images produced from `docker build` will work with all CRI implementations.
All your existing images will still work exactly the same.
-->
当然可以，`docker build` 创建的镜像适用于任何 CRI 实现。
所有你的现有镜像将和往常一样工作。
<!--
#### What about private images?
-->
### 私有镜像呢？
<!--
Yes. All CRI runtimes support the same pull secrets configuration used in
Kubernetes, either via the PodSpec or ServiceAccount.
-->
当然可以。所有 CRI 运行时均支持在 Kubernetes 中相同的拉取（pull）Secret 配置，
无论是通过 PodSpec 还是 ServiceAccount。
<!--
### Are Docker and containers the same thing?
-->
### Docker 和容器是一回事吗？
<!--
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.
-->
Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用，
但是 Linux 中的容器已经存在了很长时间。容器的生态相比于 Docker 具有更宽广的领域。
OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大，
其中一些替代了 Docker 的某些方面，而另一些则增强了现有功能。
<!--
### Are there examples of folks using other runtimes in production today?
-->
### 现在是否有在生产系统中使用其他运行时的例子？
### 现在是否有在生产系统中使用其他运行时的例子？ {#are-there-examples-of-folks-using-other-runtimes-in-production-today}
<!--
All Kubernetes project produced artifacts (Kubernetes binaries) are validated
@@ -233,7 +269,7 @@ CRI-O, two container runtimes under the Cloud Native Computing Foundation ([CNCF
<!--
### People keep referencing OCI, what is that?
-->
### 人们总在谈论 OCI，它是什么？
### 人们总在谈论 OCI，它是什么？ {#people-keep-referencing-oci-what-is-that}
<!--
OCI stands for the [Open Container Initiative], which standardized many of the
@@ -251,27 +287,11 @@ OCI 是 [Open Container Initiative](https://opencontainers.org/about/overview/)
这也是 [containerd](https://containerd.io/) 和 [CRI-O](https://cri-o.io/) 依赖的默认运行时。
CRI 建立在这些底层规范之上，为管理容器提供端到端的标准。
<!--
### Which CRI implementation should I use?
-->
### 我应该用哪个 CRI 实现？
<!--
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.
-->
这是一个复杂的问题，依赖于许多因素。
如果你正在使用 Docker，迁移到 containerd 应该是一个相对容易地转换，并将获得更好的性能和更少的开销。
然而，我们鼓励你探索 [CNCF landscape](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category)
提供的所有选项，做出更适合你的选择。
<!--
### What should I look out for when changing CRI implementations?
-->
### 当切换 CRI 实现时，应该注意什么？
### 当切换 CRI 实现时，应该注意什么？ {#what-should-i-look-out-for-when-changing-cri-implementations}
<!--
While the underlying containerization code is the same between Docker and most
@@ -284,19 +304,19 @@ 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
-->
- 日志配置
- 运行时的资源限制
- 调用 docker 或通过其控制套接字使用 docker 的节点配置脚本
- 需要访问 docker 命令或控制套接字的 kubectl 插件
- 调用 docker 或通过其控制套接字使用 Docker Engine 的节点配置脚本
- 需要 `docker` 命令或 Docker Engine 控制套接字的 `kubectl` 插件
- 需要直接访问 Docker Engine 的 Kubernetes 工具（例如：已弃用的 'kube-imagepuller' 工具）
- `registry-mirrors` 和不安全注册表等功能的配置
- 保障 Docker Engine 可用、且运行在 Kubernetes 之外的脚本或守护进程（例如：监视或安全代理）
@@ -304,7 +324,7 @@ common things to consider when migrating are:
<!--
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.
-->
@@ -314,8 +334,9 @@ 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/debug-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/debug-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.
-->
另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。
@@ -345,15 +366,15 @@ Kubernetes documentation on [Container Runtimes].
<!--
### What if I have more questions?
-->
### 我还有其他问题怎么办？
### 我还有其他问题怎么办？ {#what-if-i-have-more-questions}
<!--
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/.
-->
如果你使用了供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。
对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。
对于最终用户的问题，请把问题发到我们的最终用户社区的[论坛](https://discuss.kubernetes.io/)。
<!--
You can discuss the decision to remove dockershim via a dedicated
@@ -371,9 +392,9 @@ discussion of the changes.
对这些变化进行更深入的技术讨论。
<!--
### Is there any tooling that can help me find dockershim in use
### Is there any tooling that can help me find dockershim in use?
-->
### 是否有任何工具可以帮助我找到正在使用的 dockershim
### 是否有任何工具可以帮助我找到正在使用的 dockershim？ {#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
@@ -383,7 +404,7 @@ Find more details and usage patterns in the DDS project's [README][dds].
-->
是的！ [Docker Socket 检测器 (DDS)][dds] 是一个 kubectl 插件，
你可以安装它用于检查你的集群。 DDS 可以检测运行中的 Kubernetes
工作负载是否将 Docker 引擎套接字 (`docker.sock`) 作为卷挂载。
工作负载是否将 Docker Engine 套接字 (`docker.sock`) 作为卷挂载。
在 DDS 项目的 [README][dds] 中查找更多详细信息和使用方法。
[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket
@@ -391,7 +412,7 @@ Find more details and usage patterns in the DDS project's [README][dds].
<!--
### Can I have a hug?
-->
### 我可以加入吗？
### 我可以加入吗？ {#can-i-have-a-hug}
<!--
Yes, we're still giving hugs as requested. 🤗🤗🤗