|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "弃用 Dockershim 的常见问题" |
| 4 | +date: 2020-12-02 |
| 5 | +slug: dockershim-faq |
| 6 | +aliases: [ '/dockershim' ] |
| 7 | +--- |
| 8 | +<!-- |
| 9 | +layout: blog |
| 10 | +title: "Dockershim Deprecation FAQ" |
| 11 | +date: 2020-12-02 |
| 12 | +slug: dockershim-faq |
| 13 | +aliases: [ '/dockershim' ] |
| 14 | +--> |
| 15 | + |
| 16 | +<!-- |
| 17 | +This document goes over some frequently asked questions regarding the Dockershim |
| 18 | +deprecation announced as a part of the Kubernetes v1.20 release. For more detail |
| 19 | +on the deprecation of Docker as a container runtime for Kubernetes kubelets, and |
| 20 | +what that means, check out the blog post |
| 21 | +[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). |
| 22 | +--> |
| 23 | +本文回顾了自 Kubernetes v1.20 版宣布弃用 Dockershim 以来所引发的一些常见问题。 |
| 24 | +关于 Kubernetes kubelets 从容器运行时的角度弃用 Docker 的细节以及这些细节背后的含义，请参考博文 |
| 25 | +[别慌: Kubernetes 和 Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/) |
| 26 | + |
| 27 | +<!-- |
| 28 | +### Why is dockershim being deprecated? |
| 29 | +--> |
| 30 | +### 为什么弃用 dockershim {#why-is-dockershim-being-deprecated} |
| 31 | + |
| 32 | +<!-- |
| 33 | +Maintaining dockershim has become a heavy burden on the Kubernetes maintainers. |
| 34 | +The CRI standard was created to reduce this burden and allow smooth interoperability |
| 35 | +of different container runtimes. Docker itself doesn't currently implement CRI, |
| 36 | +thus the problem. |
| 37 | +--> |
| 38 | +维护 dockershim 已经成为 Kubernetes 维护者肩头一个沉重的负担。 |
| 39 | +创建 CRI 标准就是为了减轻这个负担，同时也可以增加不同容器运行时之间平滑的互操作性。 |
| 40 | +但反观 Docker 却至今也没有实现 CRI，所以麻烦就来了。 |
| 41 | + |
| 42 | +<!-- |
| 43 | +Dockershim was always intended to be a temporary solution (hence the name: shim). |
| 44 | +You can read more about the community discussion and planning in the |
| 45 | +[Dockershim Removal Kubernetes Enhancement Proposal][drkep]. |
| 46 | +--> |
| 47 | +Dockershim 向来都是一个临时解决方案（因此得名：shim）。 |
| 48 | +你可以进一步阅读 |
| 49 | +[移除 Kubernetes 增强方案 Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim) |
| 50 | +以了解相关的社区讨论和计划。 |
| 51 | + |
| 52 | +<!-- |
| 53 | +Additionally, features that were largely incompatible with the dockershim, such |
| 54 | +as cgroups v2 and user namespaces are being implemented in these newer CRI |
| 55 | +runtimes. Removing support for the dockershim will allow further development in |
| 56 | +those areas. |
| 57 | +--> |
| 58 | +此外，与 dockershim 不兼容的一些特性，例如：控制组（cgoups）v2 和用户名字空间（user namespace），已经在新的 CRI 运行时中被实现。 |
| 59 | +移除对 dockershim 的支持将加速这些领域的发展。 |
| 60 | + |
| 61 | +<!-- |
| 62 | +### Can I still use Docker in Kubernetes 1.20? |
| 63 | +--> |
| 64 | +### 在 Kubernetes 1.20 版本中，我还可以用 Docker 吗？ {#can-I-still-use-docker-in-kubernetes-1.20} |
| 65 | + |
| 66 | +<!-- |
| 67 | +Yes, the only thing changing in 1.20 is a single warning log printed at [kubelet] |
| 68 | +startup if using Docker as the runtime. |
| 69 | +--> |
| 70 | +当然可以，在 1.20 版本中仅有的改变就是：如果使用 Docker 运行时，启动 |
| 71 | +[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) |
| 72 | +的过程中将打印一条警告日志。 |
| 73 | + |
| 74 | +<!-- |
| 75 | +### When will dockershim be removed? |
| 76 | +--> |
| 77 | +### 什么时候移除 dockershim {#when-will-dockershim-be-removed} |
| 78 | + |
| 79 | +<!-- |
| 80 | +Given the impact of this change, we are using an extended deprecation timeline. |
| 81 | +It will not be removed before Kubernetes 1.22, meaning the earliest release without |
| 82 | +dockershim would be 1.23 in late 2021. We will be working closely with vendors |
| 83 | +and other ecosystem groups to ensure a smooth transition and will evaluate things |
| 84 | +as the situation evolves. |
| 85 | +--> |
| 86 | +考虑到此改变带来的影响，我们使用了一个加长的废弃时间表。 |
| 87 | +在 Kubernetes 1.22 版之前，它不会被彻底移除；换句话说，dockershim 被移除的最早版本会是 2021 年底发布 1.23 版。 |
| 88 | +我们将与供应商以及其他生态团队紧密合作，确保顺利过渡，并将依据事态的发展评估后续事项。 |
| 89 | + |
| 90 | +<!-- |
| 91 | +### Will my existing Docker images still work? |
| 92 | +--> |
| 93 | +### 我现有的 Docker 镜像还能正常工作吗？ {#will-my-existing-docker-image-still-work} |
| 94 | + |
| 95 | +<!-- |
| 96 | +Yes, the images produced from `docker build` will work with all CRI implementations. |
| 97 | +All your existing images will still work exactly the same. |
| 98 | +--> |
| 99 | +当然可以，`docker build` 创建的镜像适用于任何 CRI 实现。 |
| 100 | +所有你的现有镜像将和往常一样工作。 |
| 101 | + |
| 102 | +<!-- |
| 103 | +### What about private images? |
| 104 | +--> |
| 105 | +### 私有镜像呢？{#what-about-private-images} |
| 106 | + |
| 107 | +<!-- |
| 108 | +Yes. All CRI runtimes support the same pull secrets configuration used in |
| 109 | +Kubernetes, either via the PodSpec or ServiceAccount. |
| 110 | +--> |
| 111 | +当然可以。所有 CRI 运行时均支持 Kubernetes 中相同的拉取（pull）Secret 配置， |
| 112 | +不管是通过 PodSpec 还是通过 ServiceAccount 均可。 |
| 113 | + |
| 114 | +<!-- |
| 115 | +### Are Docker and containers the same thing? |
| 116 | +--> |
| 117 | +### Docker 和容器是一回事吗？ {#are-docker-and-containers-the-same-thing} |
| 118 | + |
| 119 | +<!-- |
| 120 | +Docker popularized the Linux containers pattern and has been instrumental in |
| 121 | +developing the underlying technology, however containers in Linux have existed |
| 122 | +for a long time. The container ecosystem has grown to be much broader than just |
| 123 | +Docker. Standards like OCI and CRI have helped many tools grow and thrive in our |
| 124 | +ecosystem, some replacing aspects of Docker while others enhance existing |
| 125 | +functionality. |
| 126 | +--> |
| 127 | +虽然 Linux 的容器技术已经存在了很久， |
| 128 | +但 Docker 普及了 Linux 容器这种技术模式，并在开发底层技术方面发挥了重要作用。 |
| 129 | +容器的生态相比于单纯的 Docker，已经进化到了一个更宽广的领域。 |
| 130 | +像 OCI 和 CRI 这类标准帮助许多工具在我们的生态中成长和繁荣， |
| 131 | +其中一些工具替代了 Docker 的某些部分，另一些增强了现有功能。 |
| 132 | + |
| 133 | +<!-- |
| 134 | +### Are there examples of folks using other runtimes in production today? |
| 135 | +--> |
| 136 | +### 现在是否有在生产系统中使用其他运行时的例子？ {#are-there-example-of-folks-using-other-runtimes-in-production-today} |
| 137 | + |
| 138 | +<!-- |
| 139 | +All Kubernetes project produced artifacts (Kubernetes binaries) are validated |
| 140 | +with each release. |
| 141 | +--> |
| 142 | +Kubernetes 所有项目在所有版本中出产的工件（Kubernetes 二进制文件）都经过了验证。 |
| 143 | + |
| 144 | +<!-- |
| 145 | +Additionally, the [kind] project has been using containerd for some time and has |
| 146 | +seen an improvement in stability for its use case. Kind and containerd are leveraged |
| 147 | +multiple times every day to validate any changes to the Kubernetes codebase. Other |
| 148 | +related projects follow a similar pattern as well, demonstrating the stability and |
| 149 | +usability of other container runtimes. As an example, OpenShift 4.x has been |
| 150 | +using the [CRI-O] runtime in production since June 2019. |
| 151 | +--> |
| 152 | +此外，[kind](https://kind.sigs.k8s.io/) 项目使用 containerd 已经有年头了， |
| 153 | +并且在这个场景中，稳定性还明显得到提升。 |
| 154 | +Kind 和 containerd 每天都会做多次协调，以验证对 Kubernetes 代码库的所有更改。 |
| 155 | +其他相关项目也遵循同样的模式，从而展示了其他容器运行时的稳定性和可用性。 |
| 156 | +例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O](https://cri-o.io/) 运行时。 |
| 157 | + |
| 158 | +<!-- |
| 159 | +For other examples and references you can look at the adopters of containerd and |
| 160 | +CRI-O, two container runtimes under the Cloud Native Computing Foundation ([CNCF]). |
| 161 | +- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) |
| 162 | +- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) |
| 163 | +--> |
| 164 | +至于其他示例和参考资料，你可以查看 containerd 和 CRI-O 的使用者列表， |
| 165 | +这两个容器运行时是云原生基金会（[CNCF]）下的项目。 |
| 166 | + |
| 167 | +- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) |
| 168 | +- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) |
| 169 | + |
| 170 | +<!-- |
| 171 | +### People keep referencing OCI, what is that? |
| 172 | +--> |
| 173 | +### 人们总在谈论 OCI，那是什么？ {#people-keep-referenceing-oci-what-is-that} |
| 174 | + |
| 175 | +<!-- |
| 176 | +OCI stands for the [Open Container Initiative], which standardized many of the |
| 177 | +interfaces between container tools and technologies. They maintain a standard |
| 178 | +specification for packaging container images (OCI image-spec) and running containers |
| 179 | +(OCI runtime-spec). They also maintain an actual implementation of the runtime-spec |
| 180 | +in the form of [runc], which is the underlying default runtime for both |
| 181 | +[containerd] and [CRI-O]. The CRI builds on these low-level specifications to |
| 182 | +provide an end-to-end standard for managing containers. |
| 183 | +--> |
| 184 | +OCI 代表[开放容器标准](https://opencontainers.org/about/overview/)， |
| 185 | +它标准化了容器工具和底层实现（technologies）之间的大量接口。 |
| 186 | +他们维护了打包容器镜像（OCI image-spec）和运行容器（OCI runtime-spec）的标准规范。 |
| 187 | +他们还以 [runc](https://github.com/opencontainers/runc) |
| 188 | +的形式维护了一个 runtime-spec 的真实实现， |
| 189 | +这也是 [containerd](https://containerd.io/) 和 [CRI-O](https://cri-o.io/) 依赖的默认运行时。 |
| 190 | +CRI 建立在这些底层规范之上，为管理容器提供端到端的标准。 |
| 191 | + |
| 192 | +<!-- |
| 193 | +### Which CRI implementation should I use? |
| 194 | +--> |
| 195 | +### 我应该用哪个 CRI 实现？ {#which-cri-implementation-should-I-use} |
| 196 | + |
| 197 | +<!-- |
| 198 | +That’s a complex question and it depends on a lot of factors. If Docker is |
| 199 | +working for you, moving to containerd should be a relatively easy swap and |
| 200 | +will have strictly better performance and less overhead. However, we encourage you |
| 201 | +to explore all the options from the [CNCF landscape] in case another would be an |
| 202 | +even better fit for your environment. |
| 203 | +--> |
| 204 | +这是一个复杂的问题，依赖于许多因素。 |
| 205 | +在 Docker 工作良好的情况下，迁移到 containerd 是一个相对容易的转换，并将获得更好的性能和更少的开销。 |
| 206 | +然而，我们建议你先探索 [CNCF 全景图](https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category) |
| 207 | +提供的所有选项，以做出更适合你的环境的选择。 |
| 208 | + |
| 209 | +<!-- |
| 210 | +### What should I look out for when changing CRI implementations? |
| 211 | +--> |
| 212 | +### 当切换 CRI 底层实现时，我应该注意什么？ {#what-should-I-look-out-for-when-changing-CRI-implementation} |
| 213 | + |
| 214 | +<!-- |
| 215 | +While the underlying containerization code is the same between Docker and most |
| 216 | +CRIs (including containerd), there are a few differences around the edges. Some |
| 217 | +common things to consider when migrating are: |
| 218 | +--> |
| 219 | +Docker 和大多数 CRI（包括 containerd）的底层容器化代码是相同的，但其周边部分却存在一些不同。 |
| 220 | +迁移时一些常见的关注点是： |
| 221 | + |
| 222 | +<!-- |
| 223 | +- Logging configuration |
| 224 | +- Runtime resource limitations |
| 225 | +- Node provisioning scripts that call docker or use docker via it's control socket |
| 226 | +- Kubectl plugins that require docker CLI or the control socket |
| 227 | +- Kubernetes tools that require direct access to Docker (e.g. kube-imagepuller) |
| 228 | +- Configuration of functionality like `registry-mirrors` and insecure registries |
| 229 | +- Other support scripts or daemons that expect Docker to be available and are run |
| 230 | + outside of Kubernetes (e.g. monitoring or security agents) |
| 231 | +- GPUs or special hardware and how they integrate with your runtime and Kubernetes |
| 232 | +--> |
| 233 | + |
| 234 | +- 日志配置 |
| 235 | +- 运行时的资源限制 |
| 236 | +- 直接访问 docker 命令或通过控制套接字调用 Docker 的节点供应脚本 |
| 237 | +- 需要访问 docker 命令或控制套接字的 kubectl 插件 |
| 238 | +- 需要直接访问 Docker 的 Kubernetes 工具（例如：kube-imagepuller） |
| 239 | +- 像 `registry-mirrors` 和不安全的注册表这类功能的配置 |
| 240 | +- 需要 Docker 保持可用、且运行在 Kubernetes 之外的，其他支持脚本或守护进程（例如：监视或安全代理） |
| 241 | +- GPU 或特殊硬件，以及它们如何与你的运行时和 Kubernetes 集成 |
| 242 | + |
| 243 | +<!-- |
| 244 | +If you use Kubernetes resource requests/limits or file-based log collection |
| 245 | +DaemonSets then they will continue to work the same, but if you’ve customized |
| 246 | +your dockerd configuration, you’ll need to adapt that for your new container |
| 247 | +runtime where possible. |
| 248 | +--> |
| 249 | +如果你只是用了 Kubernetes 资源请求/限制或基于文件的日志收集 DaemonSet，它们将继续稳定工作， |
| 250 | +但是如果你用了自定义了 dockerd 配置，则可能需要为新容器运行时做一些适配工作。 |
| 251 | + |
| 252 | +<!-- |
| 253 | +Another thing to look out for is anything expecting to run for system maintenance |
| 254 | +or nested inside a container when building images will no longer work. For the |
| 255 | +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-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the |
| 256 | +latter you can use newer container build options like [img], [buildah], |
| 257 | +[kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker. |
| 258 | +--> |
| 259 | +另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 |
| 260 | +对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案 |
| 261 | +(参见 [从 docker 命令映射到 crictl](https://kubernetes.io/zh/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))； |
| 262 | +对于后者，可以用新的容器创建选项，比如 |
| 263 | +[img](https://github.com/genuinetools/img)、 |
| 264 | +[buildah](https://github.com/containers/buildah)、 |
| 265 | +[kaniko](https://github.com/GoogleContainerTools/kaniko)、或 |
| 266 | +[buildkit-cli-for-kubectl](https://github.com/vmware-tanzu/buildkit-cli-for-kubectl |
| 267 | +)， |
| 268 | +他们均不需要访问 Docker。 |
| 269 | + |
| 270 | +<!-- |
| 271 | +For containerd, you can start with their [documentation] to see what configuration |
| 272 | +options are available as you migrate things over. |
| 273 | +--> |
| 274 | +对于 containerd，你可以从它们的 |
| 275 | +[文档](https://github.com/containerd/cri/blob/master/docs/registry.md) |
| 276 | +开始，看看在迁移过程中有哪些配置选项可用。 |
| 277 | + |
| 278 | +<!-- |
| 279 | +For instructions on how to use containerd and CRI-O with Kubernetes, see the |
| 280 | +Kubernetes documentation on [Container Runtimes] |
| 281 | +--> |
| 282 | +对于如何协同 Kubernetes 使用 containerd 和 CRI-O 的说明，参见 Kubernetes 文档中这部分： |
| 283 | +[容器运行时](/zh/docs/setup/production-environment/container-runtimes)。 |
| 284 | + |
| 285 | +<!-- |
| 286 | +### What if I have more questions? |
| 287 | +--> |
| 288 | +### 我还有问题怎么办？{#what-if-I-have-more-question} |
| 289 | + |
| 290 | +<!-- |
| 291 | +If you use a vendor-supported Kubernetes distribution, you can ask them about |
| 292 | +upgrade plans for their products. For end-user questions, please post them |
| 293 | +to our end user community forum: https://discuss.kubernetes.io/. |
| 294 | +--> |
| 295 | +如果你使用了一个有供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。 |
| 296 | +对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。 |
| 297 | + |
| 298 | +<!-- |
| 299 | +You can also check out the excellent blog post |
| 300 | +[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical |
| 301 | +discussion of the changes. |
| 302 | +--> |
| 303 | +你也可以看看这篇优秀的博文： |
| 304 | +[等等，Docker 刚刚被 Kubernetes 废掉了？](https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m) |
| 305 | +一个对此变化更深入的技术讨论。 |
| 306 | + |
| 307 | +<!-- |
| 308 | +### Can I have a hug? |
| 309 | +--> |
| 310 | +### 我可以加入吗？{#can-I-have-a-hug} |
| 311 | + |
| 312 | +<!-- |
| 313 | +Always and whenever you want! 🤗🤗 |
| 314 | +--> |
| 315 | +只要你愿意，随时随地欢迎加入！ |
| 316 | + |
0 commit comments