大家好，我是张晋涛。
目前曾经确定，dockershim 的代码将在 Kubernetes v1.24 版本中被正式从 Kubernetes 的代码仓库移除，预计新版本明年 4 月左右公布。对于喜爱尝献的小伙伴，dockershim 的代码下个月就将从 Kubernetes 的源代码仓库中正式移除了，届时能够尝试应用 alpha 版本进行测试应用，或者自性编译。
老粉们可能在去年看过我公布的《K8S 弃用 Docker 了？Docker 不能用了？别逗了！》，在其中我具体的阐明了所谓的“Kubernetes 在弃 Docker 一事上的起源，后果”等。
当初这个事件从正式发表到当初曾经倒退了快一年了，咱们来看看它有哪些变动和更新吧。
为了关照新的小伙伴，咱们再明确下，本次 Kubernetes 移除 dockershim 的树内代码，对于不同角色（架构、开发、集群管理员等等）的小伙伴都有哪些影响以及须要做些什么。
首先，还是须要给大家一剂强心针，本次 Kubernetes 移除树内 dockershim 代码 并不阐明 Docker 不可用 ！ 而 dockershim 自身作用就是通过 CRI 的形式连贯 Kubelet 和 Docker 的。Kubernetes 推出了 CRI，以满足对不同容器运行时的反对！咱们须要从根本上，理解 Docker 的定位以及 dockershim 对 Kubernetes 来讲意味着什么。
追根溯源 – Docker 的定位以及 Kubernetes CRI
晓得的越多，恐怖的越少。
Docker
Docker 的定位是 Development Platform，即，作为一个开发者工具，而非底层的容器运行时。
所以，咱们能够看到，Docker 于 2017 年 给 CNCF 奉献了 containerd，同年的 11 月，Kubernetes 也减少了对 containerd 的反对（2018 年，Kubernetes 的 containerd 集成，正式 GA）。
图 1，Kubernetes CRI 与容器运行时 containerd 的集成
图 1 展现了，如果将容器运行时替换为 containerd 的话，整个的解决链路是什么。能够看到，解决链路缩短了。
Kubernetes CRI
2016 年 12 月，Kubernetes 公布 CRI（Container Runtime Interface）。
在之前的文章中，咱们也说过，2014 年 Kubernetes 的诞生就是为了解决大规模场景下 Docker 容器编排的问题。在过后，Docker 是最风行也是惟一的容器运行时，对 Docker 的反对，使得 Kubernetes 在晚期就迎来了大量的用户。
为了能避免被锁定在 Docker 这一容器运行时，也为了加重在集成其余运行时的时候的开发工作量，Kubernetes 推出了一个对立的 CRI 接口，但凡反对 CRI 的运行时，皆可间接作为 Kubernetes 的底层运行时，以此来应答更多更简单的需要及场景。
从倒退的历史轨迹来看，在 2014 年时，Kubernetes 没有更多抉择，内置 dockershim 也是为了投合大量的 Docker 用户。而 Kubernetes 确也从中获取到相应的益处。而 CRI 的呈现，则是倒退的必然了（毕竟 2016 年 Kubernetes 在那场容器编排之战里胜出了）。
图 2，Kubernetes 减少了对 containerd 的反对
那么什么是 CRI？
CRI 是在 Kubernetes v1.5 版本中引入的（作为 Alpha 公布），一个插件接口，它使 kubelet 可能应用各种容器运行时，而无需从新编译。CRI 的呈现是一次解耦，它使得 Kubernetes 社区的保护老本缩小了些，并且节约了开发者须要对 kubelet 内部结构以及代码深刻理解的门槛，同时也突破了新生容器运行时想接入 Kubernetes 的高壁垒。
Kubelet 应用 gRPC 框架通过 Unix 套接字与容器运行时（或运行时的 CRI shim）通信，其中 kubelet 作为客户端，CRI shim 作为服务器。
图 3，CRI 实现原理
API 包含两个 gRPC Service:
- ImageService – 提供 RPC 以从存储库中提取图像、检查和删除图像。
- RuntimeService – 蕴含 RPC 来治理 Pod 和容器的生命周期，以及与容器交互的调用（exec/attach/port-forward）。
有些难堪又手足无措的 dockershim？
dockershim 始终都是 Kubernetes 社区为了能让 Docker 成为其反对的容器运行时，所保护的一个兼容程序。
而咱们也不用为了 dockershim 太过放心，Mirantis 曾经承诺会接管并且继续反对 dockershim。也就是说，尽管 Kubernetes 代码仓库中移除了 dockershim 的代码，然而，Mirantis 会保护一份树外的 dockershim。如果你想持续应用 Docker 作为 Kubernetes 的容器运行时，那么就须要运行树外的 dockershim 了。
也请小伙伴们急躁查看下方视频，https://www.youtube.com/watch…
Mirantis 再次公开申明，咱们大可不必为 dockershim 的将来忧心。
影响
置信很多小伙伴最关怀的就是，这种变动，会对咱们日常的生产、开发环境带来哪些变动。咱们要怎么疾速的进行应答！
抛开这个问题，请小伙伴们评估下各自的理论生产环境。
- 生产环境中的 Kubernetes 降级周期
- 以后生产集群中应用的容器运行时是什么
当然，作为应用软件的开发者而言，此次的变动，并不带来任何开发角度的影响（除非，你是个容器及容器编排开发ヾ(◍°∇°◍)ﾉﾞ）。
如果，作为容器、容器编排开发、集群保护管理人员、架构、以及对容器技术关注的小伙伴，倡议肯定要关注并踊跃地测试、反馈在 12 月行将公布的 Kubernetes v1.24 的 alpha 和 beta 版本。同时，还须要深刻 CRI 以及目前较风行的容器运行时（containerd、cri-o）。
倡议大家都深刻地理解下 containerd。能够参考我去年做的一次分享：containerd 上手实际。在此处可获取 PPT https://github.com/tao1234566…
尽管，Mirantis 公司声称会和 Docker 一起保护好 dockershim，然而，就 目前来看 Mirantis 保护的 dockershim 并没什么实质性的停顿。而 containerd 在泛滥的云厂商及公司的生产环境中已被作为其 Kubernetes 的运行时应用了。
最初的最初，小伙伴们，拥抱变动吧！
欢送订阅我的文章公众号【MoeLove】