docker和Kubernetes发展介绍

落日映苍穹つ 2022-10-08 11:14 160阅读 0赞

### docker和Kubernetes发展介绍 ###

*   *  docker崛起
     *   *  打包技术
     *  docker 平台化
     *   *  Swarm
         *  Fig
     *  Kubernetes崛起
     *   *  Libcontainer

## docker崛起 ##

2013 年的后端技术领域，曾经被人们寄予厚望的云计算技术，也已经从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和账单。而相比于的如日中天AWS 和盛极一时的 OpenStack，以 Cloud Foundry 为代表的开源 PaaS 项目，却成为了当时云计算技术中的一股清流。

### 打包技术 ###

PaaS 之所以能够帮助用户大规模部署应用到集群里，是因为它提供了一套应用打包的功能。 一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。

Docker 项目确实与 Cloud Foundry 的容器在大部分功能和实现原理上都是一样的。 但是在打包这个环节创新了。

而Docker 镜像解决的，恰恰就是打包这个根本性的问题。 所谓 Docker 镜像，其实就是一个压缩包。但是这个压缩包里的内容，比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。实际上，大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。

只需要提供一个下载好的操作系统文件与目录，然后使用它制作一个压缩包即可，这个命令就是：

docker build " 我的镜像 "

一旦镜像制作完成，用户就可以让 Docker 创建一个“沙盒”来解压这个镜像，然后在“沙盒”中运行自已的应用，这个命令就是：

$ docker run " 我的镜像 "

当然，docker run 创建的“沙盒”，也是使用 **Cgroups 和 Namespace** 机制创建出来的隔离环境。

## docker 平台化 ##

### Swarm ###

Swarm 项目则是以一个完整的整体来对外提供集群管理功能。而 Swarm 的最大亮点，则是它完全使用 Docker 项目原本的容器管理 API 来完成集群管理。

多机 Docker 项目：

docker run -H " 我的 Swarm 集群 API 地址 " " 我的容器 "

### Fig ###

Fig 项目 在开发者面前第一次提出了“容器编排”（Container Orchestration）的概念。 后来，Fig 项目被收购后改名为 Compose，它成了 Docker 公司到目前为止第二大受欢迎的项目。

编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。

而容器时代，“编排”显然就是对 Docker 容器的一系列定义、配置和创建动作的管理。

## Kubernetes崛起 ##

2014 年注定是一个神奇的年份。就在这一年的 6 月，基础设施领域的翘楚 Google 公司突然发力，正式宣告了一个名叫 Kubernetes 项目的诞生。而这个项目，不仅挽救了当时的 CoreOS和 RedHat，还如同当年 Docker 项目的横空出世一样，再一次改变了整个容器市场的格局。

### Libcontainer ###

Docker 项目刚刚兴起时，Google 也开源了一个在内部使用多年、经历过生产环境验证的 Linux 容器：lmctfy（Let Me Container That For You）。

面对 Docker 项目的强势崛起，这个对用户没那么友好的 Google 容器项目根本没有招架之力。所以，知难而退的 Google 公司，向 Docker 公司表示了合作的愿望：关停这个项目，和 Docker 公司共同推进一个中立的容器运行时（container runtime）库作为 Docker 项目的核心依赖。

在不久后，docker自己发布了一个容器运行时库 Libcontainer。

2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。

这套标准和规范，就是 OCI（ Open Container Initiative ）。OCI 的提出，意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。这样做，一方面可以改善 Docker公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于 Docker 项目构建各自的平台层能力提供了可能。

眼看着 OCI 并没能改变 Docker 公司在容器领域一家独大的现状，Google 和 RedHat 等公司于是把以下武器摆上了台面。

Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

面对这样的竞争态势，Docker 公司决定更进一步。在 2016 年，Docker 公司宣布了一个震惊所有人的计划：放弃现有的 Swarm 项目，将容器编排和集群管理功能全部内置到 Docker 项目当中。

而Kubernetes 的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构，即：从API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes 项目的每一个阶段。

Kubernetes 项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于Kubernetes API 和扩展接口的二次创新工作

2017 年 10 月，Docker 公司出人意料地宣布，将在自己的主打产品 Docker 企业版中内置Kubernetes 项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。

2018 年 1 月 30 日，RedHat 宣布斥资 2.5 亿美元收购 CoreOS。