diff --git a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
index 6df3d35086..49e9471153 100644
--- a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
+++ b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
@@ -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
diff --git a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
index 61f3860602..8023f68989 100644
--- a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
+++ b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md
@@ -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. 🤗🤗🤗