容器技术之发展简史

容器技术之发展简史

简介： 容器技术催生了云原生思潮，云原生生态推动了容器技术发展。整理容器技术近 20 年的发展历史，大致可以将其分为四个历史阶段。

背景

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可d性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。”

聊容器技术避不开云原生，聊云原生也避不开容器技术。容器技术和云原生就是一对双螺旋体，**容器技术催生了云原生思潮，云原生生态推动了容器技术发展。**从 2013 年 docker（container）技术诞生，到 2015 年 CNCF 这个云原生领域重量级联盟便成立，这不是历史的巧合而是历史的必然。作为云原生关键技术之一的容器，从 2013 年诞生以来一直是行业关注的焦点之一。借用一张业界广泛引用的云原生容器技术进阶图来了解一下容器技术和云原生诞生的历史背景。

技术萌芽期

容器技术需要解决的核心问题之一是运行时的环境隔离。

容器的运行时环境隔离，目标是给容器构造一个无差别的运行时环境，用以在任意时间、任意位置运行容器镜像。由于 docker 的布道，大家习惯性认为容器的运行时环境隔离就是 OS 虚拟化，或者容器等于 namespace + cgroup + 安全防护机制。我不太赞同这种看法，这个只是一段历史时期、一种容器运行时的实现技术，还有很多种其它可能的技术方案来实现容器运行环境。所以，回到需求的本源：容器需要运行时隔离技术来保证容器的运行环境符合预期。习惯上，大家把这种实现容器隔离技术的组件叫做容器运行时。

从另外一个角度看，容器隔离技术解决的是资源供给问题。为啥需要容器隔离技术来解决资源供给问题呢？成也萧何，败也萧何！摩尔定律实在太过强大，它让我们有了越来越多的计算资源可以使用。10 年前做小型机时，小型机的典型规格是 32 路 8 核 CPU，现在一台 4 路 PC 服务器计算能力都超过 10 年前的小型机服务器。小型机的典型用法是把整机切分为多个分区使用。观察当下云服务硬件发展趋势，越来越有熟悉的感觉，我们在把小型机相关技术“军转民”。现在我们一台 PC 服务器拥有了非常强大的、能和十年前小型机媲美的计算能力，巧合的是当下 PC 服务器的典型用法也和十年前的小型机用法类似，切割为 1-8vCPU 的虚拟机/容器使用。

为什么人们总是习惯于把一个大的服务器资源切分为小的分区使用而不是研发能够充分发挥大型服务器整机计算能力的软件呢？个人认为背后有两个制约因素：

待解决问题本身内在的并行度有限。随着多核多处理器系统的日益普及，IT 行业从 2004 年开始进行串行编程到并行编程的升级改造。开始阶段针对特定行业应用的并行化改造效果非常明显，但是后来发现随着并行度提高改造成本越来越大、收益却越来越低。受阿姆达尔定律制约，解决特定问题的并行度超过一定临界点之后收益将逐渐变小。所以一味提高系统并行度并不是经济的做法。

人类智力有限。受人类智力限制，系统越复杂、并行度越高，软件越容易出故障，软件维护代价成指数级增长。所以，从软件工程看，大家也趋向于接口化、模块化、单元化的软件架构设计，尽量控制软件的复杂度，降低工程成本。

技术迸发期

2013 年之前，云计算行业一直在为云原生的正确打开姿势而 *** 心。Platform as a Service（PaaS）看起来是个有前途的方向。2006 年 Fotango 公司发布的 Zimi 服务，可以说是 PaaS 行业的鼻祖，具有按使用付费、免运维（Serverless）、API 化配置和服务等典型云原生的特征；2008 年 Google 推出 GAE；2011 年 Pivotal 发布 Cloud Foundry。这些早期的 PaaS 平台进行了非常有益的探索，推动了云计算生态的健康发展，但是这些早期探索技术并没有形成大的行业趋势，而是局限在一些的特定的领域。直到 Docker 开源，大家才如梦方醒，原来不是方向不对，而是应用分发和交付的手段不行。

Docker 真正核心的创新是容器镜像（docker image），一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种 *** 作系统发行版无关的不可变更软件包。

容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的 *** 作系统，从而实现 “build once，run anywhere”。

容器镜像一旦构建完成，就变成 read only，成为不可变基础设施的一份子。

*** 作系统发行版无关，核心解决的是容器进程对 *** 作系统包含的库、工具、配置的依赖，但是容器镜像无法解决容器进程对内核特性的特殊依赖。这个在实际使用容器的过程中也经常跳进这个大坑：

Docker 的宣传口号是 “Build，Ship and Run Any App，Anywhere”。我们已经理解了 docker 通过container image 解决“Run Anywhere”的机制，那么“Run Any App”是如何实现的呢？其实也是依赖 container image，用户可以打包任何容器进程所依赖的环境，而不用改造应用来适配 PaaS 定义的运行环境。真是“Run Any App”一举打破了 PaaS 行业面临的困境，创造出了无限的可能性，大力推动了云原生的发展。让我们一起来向这个伟大的创意致敬！

商用探索期

经过 5 年的技术发展期，容器技术基本成熟，云原生体系也具雏型。从 2017 年开始，各大云厂商开始试水容器服务及进步的云原生服务。从目前的商业形态看，容器相关的公共云服务大致可以划分为三种形态：

通用容器编排服务。在容器编排系统三国杀结果出来以前，基于多方下注策略构建的容器编排服务系统。其中 AWS 是自研的编排系统，Azure 的 ACS 同时支持 Docker Swarm、DC/OS 和 Kubernetes，阿里云 ACS 则是支持 Docker swarm 和 Kubernetes。Google 和华为则是坚定支持 Kubernetes 而未推出支持其它容器编排系统的容器服务。随着 Kubernetes 一统容器编排江湖，这条路线的容器服务日渐式微，Azure 更是在今年初直接终止了 ACS 服务。

Kubernetes 容器编排服务。Google 是理所当然最早试水 Kubernetes 容器编排服务的大厂，也较早开展了 K8s 容器编排服务。随着 2017 年各大厂在 CNCF 这张谈判桌上达成了 Kubernetes 兼容性认证流程，Kubernetes 编排服务市场迎来一轮大爆发，到 2018 年各大云厂商的 K8s 容器编排服务就完整就位了。

Serverless 容器实例服务。从 2017 年开始，行业开始试水 Serverless 容器实例服务，把用户从维护容器基础设施的繁重任务中解放出来从而聚焦业务本身。Google Cloud Run 核心目标是支持 Knative，所以其使用形态上附加了不少约束条件。

商用拓展期

到 2019 年，容器服务的商业形态以及市场趋势已经很明显了，行业整体进入了商业拓展阶段，对外宣传吸引更多的客户群体，对内苦练内功提升产品技术竞争力，行业正在经历从“有”到“优”的技术升级。行业正在经历这个技术升级的历史阶段，还谈不上结论，只能一起来聊聊趋势及预判。本系列专题的关注点是容器隔离技术，所以先不聊商业拓展和容器编排而聚焦于容器引擎技术发展趋势。到现在为止，我们大体上可以把容器引擎技术划分为两代：

Container on VM。也就是按照分层设计思路，通过 IaaS + PaaS 的架构构建容器服务，这个是商用探索阶段的典型架构。基于各大云厂商成熟的 IaaS 基础设施生产虚拟机，在虚拟机里面部署容器服务组件。这种架构采用的是 lift and shift 策略，把容器服务的运维责任从用户转移到云厂商。采用和用户相同的软件组件，只是转移运维责任，有利于引导客户逐步上云、接受云原生思维。但是这个时期云厂商提供的服务是单纯的运维托管，相对用户自建容器服务并没有太明显的技术优势，甚至受多租户隔离的限制部分使用体验还不如用户自建容器服务。

Container with hardware virtualization。如果沿用 Container on VM 的分层设计架构，云厂商很难构建独有的技术优势。对于 Serverless 容器实例服务，服务交付平面已经从 IaaS 的硬件接口上移到 OS Syscall，所以不要遵循 VM + 容器的分层设计思路。我们需要从需求本源出发，容器服务需要高性能、强隔离、够安全和低成本的容器引擎。当前行业研发热点之一就是如何构建这样一个容器引擎，具体技术思路请留意后续系列文章。

小结

总结来看，容器服务生态大概经历了四个阶段，分别解决或试图解决不同的问题：

技术萌芽期：解决了容器运行环境的隔离问题

技术迸发期：解决了软件分发及容器编排问题

商用探索期：确认了容器的商用服务形态

商用拓展期：扩大适用场景和部署规模，通过技术创新提升产品竞争力

闲言碎语

聊了这么多历史，让我们再来闲聊一下 docker 这个公司和 docker 这门技术吧！

2019 年 11 月 13 日，私有云基础设施公司 Mirantis 在其官方博客宣布，收购 Docker 公司企业级业务，包括接管它的 700 多个客户，这标志着 Docker 公司从 2013 年开始的商业化探索彻底失败。在不了解容器发展历史的人看来，这种结果很难理解，Docker 是容器热潮的开创者，容器则是这一轮云计算技术演进的开启者，为什么明明站在风口上了，却仍然飞不起来？

其实，Docker 今天的命运，在 4 年前就决定了。

2014 年 Kubernetes 发布后，迅速吸引了包括 Redhat 在内的一批重量级成员，并在一年之后迅速发布 Kubernetes 1.0 以支撑正式商用。作为回应 Docker 公司主导成立了 OCI，旨在为容器镜像格式和运行时制定一个开放标准，从而继续占据容器生态的话语权。但是 2015 年 7 月 CNCF 成立之后，迅速弯道超车开辟新的战场，主攻容器编排与应用管理。随后 2016 年 Kubernetes 社区制定了容器运行时的接口规范 CRI，只要实现这个 CRI 规范的容器运行时就可以和 K8s 生态对接，从引发了容器引擎的研发热潮。cri-containerd，cri-o，frakti 等引擎不断涌现，加上原有的 rkt 引擎，docker 变成了容器引擎芸芸众生中的一员。从哪儿来到哪儿去，docker 又回到了最初的状态，一个单机版软件打包运行工具，基本上完美错过了云原生浪潮。

但是在相当长的时期内，docker 这个客户端容器管理工具（UI）还是会长期存在的，毕竟强大的用户群体在哪儿。但是在云服务厂商的技术栈中，docker 的地位会越来越弱，逐步被 K8s 专用的容器引擎替代。虽然现在 docker 的群众基础依然强大，但是星星之火已经点燃，趋势已然显现，剩下的只是时间问题！

注：每周福利均会更新，更多福利等你领取，更多技巧，欢迎在评论区一起交流！

学习Java没有那么容易，一定要掌握学习方法，初学者对于学习方法有什么不懂的可以随时找我咨询，真的是希望新手少走弯路，可找我领取Python ，web前端开发，Python爬虫，Python数据分析，大数据开发，人工智能，Java项目，Java基础等精品学习课程。带你从零基础系统性的学好Python，Java，web前端和大数据等！做一名牛逼的程序员！

希望这些能够帮助大家从一个小白成长为大牛，最后提醒大家，不要在拼搏的年纪选择安逸，希望小编的文章能够帮助到小伙伴们！

END 祝大家学的愉快，学的神速。 有帮助的话，各位小伙伴可以点个赞收藏支持下啦！❤️ 也欢迎关煮lili，一个在变秃，但能带你变强的程序员~ 今天先说这么多，我是乐字节哩哩，一个有趣的灵魂！下期见！ 【此文章转自乐字节】