Kubernetes弃用Docker的由来和始末

2020年12月初,Kubernetes在发布v1.20的时候重磅宣称将逐渐弃用Docker,一石激起千层浪,瞬间引爆容器圈;但没想到已经过去两个月时间了,还有文章用UC体误导吃瓜群众,“还在学Docker?”、“Docker已死!”; 额… 累了,毁灭吧,赶紧的…

所以在此梳理下整件事情的来龙去脉,若有不正确的地方还请指正,非常感谢!


快速回顾

最初Docker是建立在Linux的LXC容器技术之上,但LXC最早也是由Google贡献给Linux的,所以一定程度上说没有Google就没有Docker。
Kubernetes弃用Docker的由来和始末_第1张图片
Docker一问世就广受好评,发展迅速,于是在2015年左右,不满足只做容器引擎的Docker开始尝试提供容器编排能力,对单机场景推出了Docker Compose,对集群场景推出了Docker Swarm;也就在同年,Google推出了同样具备容器编排能力的Kubernetes,并在与Docker SwarmApache Mesos的三方大战中大获全胜。

于是在之后的一段时间里形成了“集群容器编排用Kubernetes,单机容器引擎用Docker”的潜规则。Kubernetes弃用Docker的由来和始末_第2张图片
但Kubernetes对于这种合作机制并不满意,因为Kubernetes更贴近用户的上层容器编排能力不想局限于Docker这一种底层容器Runtime,市面上还其他的容器Runtime,比如rkt/frakti等,Kubernetes全都要…

所以Kubernetes于v1.5提出了CRI - Container Runtime Interface,这是一种自上而下的标准,旨在适配底层不同的容器Runtime;
Kubernetes弃用Docker的由来和始末_第3张图片
在kubernetes和容器runtime之间加一层CRI标准进行解耦,kubernetes作为client只和CRI提供的service进行交互,这里CRI主要提供两种service:管理镜像的ImageService和管理pod与container的RuntimeService;

各容器Runtime厂商可以选择接入CRI标准,但Docker拒绝了,所以kubernetes不得不自己来实现和维护docker shim来适配Docker;
Kubernetes弃用Docker的由来和始末_第4张图片
同时Docker也没闲着,联合一众厂商提出了OCI - Open Container Initiative,这是一种自下而上的标准,旨在规范化容器格式与Runtime,也向CNCF贡献了OCI的实现runC
在这里插入图片描述
同时Docker也向"主动"向CNCF贡献了docker deamon的精简版containerd
在这里插入图片描述
至此,Kubernetes准备要去除Docker的条件基本形成…

对于上面的整个链路来说,一直在维护dockershim的kubernetes认为是时候尝试去除docker了,首次尝试是推出了cir-containerd,这是一个符合CRI标准的containerd插件,真正的做到了去Docker化;
在这里插入图片描述
此外还有由红帽推出的更激进的CRI-O,docker去除的更彻底;
在这里插入图片描述
尽管有containerdCRI-O,但用户早已习惯使用docker,所以kubernetes并没有急于立刻停掉dockershim

就这样过了几年,随着containerd的正式毕业,CRI-O的稳步孵化,kubernetes终于决定要真正去除Docker,在发布v1.20的时候正式宣布将去除dockershim,建议用户做好准备选择使用containerd或者CRI-O


有何影响

  • 对于普通开发者来说毫无影响,可以继续使用Docker打包并在单机运行镜像;
  • 对于集群运维同学来说,在Kubernetes升级到v1.22之后需要准备好containerdCRI-O环境;但只要不升级也没有任何影响…

写在最后

Docker虽然没有像一些文章里宣传的那样消亡,但被Kubernetes一点点蚕食也是不争的事实,同时Podman的出现也在尝试将Docker推向幕后… 或许几年后Docker真的会退出历史舞台吧…

你可能感兴趣的:(kubernetes,docker,docker,kubernetes)