Kubernetes最新版本不再支持 Docker了。
乍听到这个消息，我也震惊了。。一口老血差点没压住
费了老大劲 ，刚折腾会 k8s ,google和红帽这一眨眼又不再支持 Docker了。。。
等等...
k8s 不再支持Docker和 google，红帽又有什么关系。这里说来就话长了，大家看文末关联我以前的文章**《k8s极简史》**就好。
扯回k8s不再支持Docker。。
我从infoq拉了最重要的一段
但 Docker 为什么会被弃用？
如前所述，Kubernetes 只能与 CRI 通信，因此要与 Docker 通信，就必须使用桥接服务。这就是弃用 Docker 的第一点原因。
要解释下一个原因，我们必须稍微聊聊 Docker 架构。首先参考以下示意图。
没错，Kubernetes 实际上需要保持在红框之内。Docker 网络与存储卷都被排除在外。
而这些用不到的功能本身就可能带来安全隐患。事实上，您拥有的功能越少，攻击面也就越小。
因此，我们需要考虑使用替代方案，即 CRI 运行时。
原文比较长，大意就是说 Docker和k8s 的网络通信，一直是由 k8s的自己在维护，k8s自己希望使用容器运行时（Container Runtime）通信，但Docker 一直不支持，k8s只好自己写了一个 Dockershim的插件，在中间做网络桥接，转换信息流。更详细的大家可以参考
原文链接：https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
译文参考: https://www.infoq.cn/article/rOhiauJTHHxG51XsCv1j
img
Docker这么强势也是有原因的，早期 Docker最开始流行时，几乎就是容器化的代言词，以致于很多新手，以为Docker就是容器，容器就是Docker。历史上，能有这么牛逼的产品，也就只有席梦思床垫了。
Docker在环境搭建地盘称王称霸后，又找准了环境编排市场，但这又和早期的容器编排老大 CoreOS，同时也是自己的老朋友产生了严重的利益冲突，以致最后两家走上绝交之路。但CoreOS又没有容器化产品，为了和 Docker对抗，不惜自断双臂，和Docker绝交，研发了自己的产品 Rocket。
但此时的Docker在容器化市场上说一不二，根本没有其它容器化产品的市场。
此时的Docker是验证了什么是大紫大红，有钱什么都不是事，抛弃了老战友CoreOS后，大肆收购，现在大家一直在使用的 compose 其实早期的产品雏形是 Fig。此时的Docker大有一统服务市场的势头。
Google, RedHat, 看着彼时的小朋友，竟一眨眼有反吃自己的迹象，再这么发展现在，容器化+编排市场最终只有Docker一家独大，数万亿市场怎么可能供手让人。
最终 CoreOS、Google、RedHat联合起来，推翻了早期 Docker成立的OCI社区，成立了CNCF,同时Google也被逼拿出了看家本领，把自家已经研究了15年的杀手级武器borg,改名为Kubernetes 后，开放给社区。
但考虑到，和Docker兼容，同时因为Docker在容器化市场的一家独大的话语权。并没有开放自家的容器运行时(Container Runtime)。
期间，Docker也并没有妥协，推出了自家的swarm编排工具试图抗衡，而且最初也并不支持k8s。
最终在k8s在社区的强大推动下，docker也不得不做出妥协，于2016宣布放弃Swarm,全面拥抱k8s.。
期间，Docker 仍没弃在作死的边缘上试探。把Docker项目改名为Moby,将 Docker 注册为公司的名字。
哎，不管怎么讲。城墙失火，殃及池鱼呀。。。
最终还是我们这老实搞技术人人最受伤。刚搞完Docker,又要搞运行时了。
但我个人的估计是，kubectl 层面的操作应该不会有太多变化 ，这点大家倒可以放轻松点了。
更多故事，我以前写的这篇文章里都有。
