namespace	系统调用参数	隔离内容	内核版本
UTS	CLONE_NEWUTS	主机名和域名	2.6.19
IPC	CLONE_NEWIPC	信号量、消息队列和共享内存	2.6.19
PID	CLONE_NEWPID	进程编号	2.6.24
Network	CLONE_NEWNET	网络设备、网络栈、端口等	2.6.29
Mount	CLONE_NEWNS	挂载点，文件系统	2.4.19
User	CLONE_NEWUSER	用户和用户组	3.8

2.2、Control Groups（CGroups）的作用

容器化技术的隔离机制是靠namespaces实现，而容器化的资源分配靠的是在内核级通过CGroups机制实现，它会把系统级的资源分成多个组，然后把每一个组内的资源量指派分配到特定的namespace的进程上去来实现

2.2.1、CGroups的功能

blkio	块设备IO
cpu	CPU
cpuacct	CPU资源使用报告
cpuset	多处理器平台上的CPU集合，有两种分派方式，一种是比例，一种是分核数
devices	设备访问
freezer	挂起或恢复任务
memory	内存用量及报告
perf_event	对cgroup中的任务进行统一性能测试
net_cls	cgroup中的任务创建的数据报文的类别标识符

2.3、LXC（Linux Container）

虽然在内核的层面上解决了隔离，实现了容器技术，但是我们需要写代码来调用这些实现的方法，所以要变成大多数用户都能使用的应用，所以我们要把它做成工具，也就有了这样的解决方案。

LXC是最早除了Vserver之外，真正把完整的容器技术用一组简易使用的工具和模板来极大的简化了容器技术使用的一个方案。LXC靠一组工具包帮我们快速的实现了创建名称空间，利用模板完成内部所需要的各种文件的安装。同时，还有些工具能够自动完成chroot切换，于是，就可以使用多个并行的用户空间，而每一个用户空间，就像我们之前使用的虚拟机，是一个独立的系统。

三、Docker的诞生

LXC虽然极大的简化了容器技术的使用，但比起过去使用虚拟机来讲，它的复杂程度是没有多大降低的，隔离性也没有虚拟机好、在大规模使用上和分发上都不方便。但好处是它能够让每一个用户空间的进程直接使用宿主机的性能，中间没有额外开销。于是就出现了Docker

3.1、Docker是LXC的增强版，它本身不是容器，而是容器的易用工具。

容器是linux内核中的技术，Docker只是把这种技术在使用上简易普及了。Docker在早期的版本其核心就是LXC的二次封装发行版。Docker利用LXC做容器管理引擎，但是在创建容器时，不在使用模板去安装生成。而是通过镜像技术（把一个操作系统用户空间所需要使用到的组件事先编排好，并整体打包成一个文件，image文件），镜像文件集中放在一个仓库中。当需要创建容器时，Docker调用LXC的工具lxc-create。但是不在通过lxc的模板去安装，而是连接到镜像服务器上下载匹配的镜像文件，而后基于镜像启动容器。所以，Docker极大的简化了容器的使用难度。以后我们创建启动容器，只需要一个命令，docker-run，docker-stop就可以启动停止一个容器了。为了使整个容器使用更加易于管理，Docker采用了一种更精巧的限制机制，在一个容器内，只运行一个进程。而LXC是把一个容器当一个用户空间使用，可以运行N个进程，所以使得我们管理容器进程极为不便。Docker在镜像构建底层使用了分层构建，联合挂载。这种好处就是在以后的镜像分发上就没有那么庞大。可以自由组合镜像实现不同环境的挂载

3.2、Docker容器引擎的更迭

Docker早起是基于LXC容器管理引擎实现，当后来成熟之后，Docker自建了一个容器引擎叫libcontainer，后来CNCF的介入，Docker又研发了一个工业化标准的容器引擎，叫runC，目前所使用的新版Docker，所使用的容器引擎就是RunC。

四、什么是容器编排？

在docker基础之上，能够把应用程序之间的依赖关系，从属关系，隶属关系等等，反应在启动，关闭时的次序和管理逻辑中，这种功能叫做容器编排

所以我们需要容器编排工具：

方案一：machine+swarm+compose：

比如docker自己的swarm（Swarm 是docker公司所拥有的唯一容器编排工具。Swarm是Docker官方提供的一款集群管理工具，其主要作用是把若干台Docker主机抽象为一个整体，并且通过一个入口统一管理这些Docker主机上的各种Docker资源。Swarm和Kubernetes比较类似，但是更加轻，具有的功能也较kubernetes更少一些。）+compose(单机编排工具，只能编排一个docker服务器之上的)，其实还有machine（Docker machine 是 Docker 官方提供的一个工具，它可以帮助我们在远程的机器上安装 Docker，或者在虚拟机 host 上直接安装虚拟机并在虚拟机中安装 Docker。我们还可以通过 docker-machine 命令来管理这些虚拟机和 Docker。）把这三个工具组合起来，当一个编排工具使用。

方案二：mesos+marathon：

ASF的著名的数据中心操作系统，统一资源编排工具，叫mesos，但是mesos不是专门用来编排容器的，他是实现统一资源调度和分配的，如果我们要实现编排工具，还需要加一个中间层叫marathon。

方案三：kubernetes（简称为k8s，因为这个单词有8个字母）：

有意思的是google这家公司秘而不宣的悄悄的使用容器已经有十几年的历史了。据说每一周新建和销毁的容器就多达几十亿个。docker竟然姻缘巧合之间摸到了这个门道，并且把它做成了开源软件，google就坐不住了。因为google把容器当做独门武器使用，docker竟然找到了容器的方法给所有人使用。后来google发现藏不住了。但是此时docker已经独霸了话语权了。好在docker也不是铁板一块，这时候google扶持了另一家做容器的公司，但是发现实在是难以跟docker抗衡。这个时候就换了个方法，虽然docker在容器领域成为了标准，但是容器一般不会单独使用，这个时候google就想做容器编排工具，而容器编排工具在google内部有一个重要的系统叫伯格（Borg），也已经跑了十几年了。但是docker在这方面没有经验，这时候google就看到了这个机会，所以k8s横空出世，一出世就横扫一切。但是在去年2017年12月就尘埃落定了。k8s占据了80%的市场份额。再次基础之上，google还主导成立了CNCF（Cloud Native Computing Foundation），即所谓的容器标准组织，于 2015 年 7 月成立，隶属于 Linux 基金会，初衷围绕“云原生”服务云计算，致力于维护和集成开源技术，支持编排容器化微服务架构应用。首先它是一个非营利组织，致力于通过技术优势和用户价值创造一套新的通用容器技术，推动本土云计算和服务的发展。CNCF 关注于容器如何管理而不是如何创建，因为如果没有一个成熟的平台去管理容器，那么大型企业无法真正放心接受并使用容器。

五、容器历史上的尔虞我诈，亲亲合合的故事：

docker技术永生，docker公司已死，就说docker有一手好牌，但是打的稀巴烂，因为docker对容器编排毫无建树。后来docker为了活着吸引更多的人来投资，要扩大领域和份额及收益，为了变性，就推出了docker社区版CE和企业版EE,后来docker把社区版改名了不再叫docker了，而把原来docker的所有的流量引入到了docker企业版的概念中去了。以至于后来有一段时间社区为此闹得沸沸扬扬的，就说docker过河拆桥啊这这那那的。后来这个docker社区版叫做Moby，dockerr社区版的标识符迁移到github上并重新命名为叫Moby。而后把docker所有的关键词全部引向了docker的企业版，所以大家觉得docker使用了一个混招。而之所以能做成这样的原因是：docker是一家商业公司叫做dockerclub，这个商业公司拥有了docker技术，拥有了docker这个代码往何处走的主导权。因为就是docker这样的做法，大家对他产生了疑虑。google为了避免大家这样的顾虑，google作为一家公司不会控制k8s走势的意图，所以成立了CNCF，然后把k8s的代码捐给了CNCF。而CNCF是由很多组织和公司成立的一个公共组织。类似于开源委员会之类的。当然他是容器类的。所以k8s不在属于google一家公司，而是由想微软啊，google，ibm这样的公司联合成立起来的组织叫CNCF。所以就不用担心google哪天会把k8s私有化。google这招做的，让大家对k8s简直可以算得上是趋之若鹜。所以这也是k8s这个社区茁壮成长的原因。到现在为止k8s还没有到稳定的阶段，一年四个版本的发布。原因就是k8s还没有到成熟的阶段（指的是很多的功能还在不断地加进来）。docker是go语言研发的。k8s也是go研发的。所以运行docker要有go环境。

docker在过河拆桥的道路上一路狂奔，因为docker早起是基于LXC构建的。后来略具实力以后，docker就抛弃了LXC，自建了一个容器引擎叫：libcontainer，细化了LXC，所以现在的版本docker已经没有了LXC。但后来docker被CNCF挟持了，为了docker能占据点话语权，因为为了容器的发展，要走向标准化，要开源，不能受控一家公司，要指定一个标准，那么谁来指定这个标准化呢？因为容器要运行起来，容器底层的引擎要标准化，容器的格式要标准化。CNCF自己做完全有实力，因为google在里面呢。但是这样做明摆着欺负docker呢。所以给docker了一个机会。你来定义标准化，同时做一款软件开源出来，所以后来libcontainer转换成下一步叫runC（runContainer），所以我们现在用的新版的docker的容器引擎就是runC。runC就是容器运行时的环境标准。当然镜像文件也有标准叫OCF（Open Container Format,叫开放容器格式标准），这个标准成为了事实上的工业标准。我们做容器都应该遵循这个标准。

不管我们怎么样认为docker被人欺负，但是直到今天docker确实是大家心中的容器技术。谈到容器你可以不知道LXC是什么也不知道linux内核名称构建是什么。但是大家都知道docker。所以不管今天k8s在编排上多么的一家独大，但是扔无法摆脱docker。我们用的k8s底层容器都是docker，虽然k8s支持很多种容器。docker只是其中一种。但是现在我们去用基本上都是k8s+docker。

插曲：

从2000年以来，谷歌基于容器研发三个容器管理系统，分别是Borg、Omega和Kubernetes。这篇论文由这三个容器集群管理系统长年开发维护的谷歌工程师Brendan Burns, Brian Grant, David Oppenheimer, Eric Brewer, 和John Wilkes于近日发表，阐述了谷歌从Borg到Kubernetes这个旅程中所获得知识和经验教训。
尽管对软件容器广泛传播的兴趣是最近的现象，但在谷歌我们大规模使用Linux容器已经有10多年了，而且期间我们建了三种不同的容器管理系统。每一个系统都受之前的系统影响颇深，尽管它们的诞生是出于不同原因。这篇文章描述了我们在研发和使用它们的过程中得到的经验教训。
       第一个在谷歌被开发出来的统一的容器管理系统，在我们内部称之为“Borg”，它管理着长时间运行的生产服务和批处理服务。这两类任务之前是由两个分离开的系统来管理的：Babysitter和Global Work Queue。Global Work Queue的构架极大地影响了Borg，但却只是针对批量服务的，且两者都在Linux control groups诞生之前。Borg将这两种应用所用的机器统一成一个池子，这样得以提高资源利用率，进而降低成本。之所以可以实现这样的机器资源共享，是因为可以拿到linux内核的容器支持（确实，Google对Linux内核的容器代码贡献了很多），这使得在对时限敏感的、且面对用户的服务和占用很多CPU资源的批处理进程提供了更好的隔离。

        由于越来越多的应用被开发并运行在Borg上，我们的应用和底层团队开发了一个广泛的工具和服务的生态系统。这些系统提供了配置和更新job的机制，能够预测资源需求，动态地对在运行中的程序推送配置文件、服务发现、负载均衡、自动扩容、机器生命周期的管理、额度管理以及更多。这个生态系统的发展源自谷歌内部不同团队的需求，发展的结果成为了异构的、ad-hoc系统的集合，Borg的使用者能够用几种不同的配置语言和进程来配置和沟通。由于Borg的规模、功能的广泛性和超高的稳定性，Borg在谷歌内部依然是主要的容器管理系统。

       Omega，作为Borg的延伸，它的出现是出于提升Borg生态系统软件工程的愿望。Omega应用到了很多在Borg内已经被认证的成功的模式，但是是从头开始来搭建以期更为一致的构架。Omega存储了基于Paxos、围绕transaction的集群的状态，能够被集群的控制面板（比如调度器）接触到，使用了优化的进程控制来解决偶尔发生的冲突。这种分离允许Borgmaster的功能被区分成几个并列的组建，而不是把所有变化都放到一个单独的、巨石型的master里。许多Omega的创新（包括多个调度器）都被收录进了Borg.

       谷歌研发的第三个容器管理系统是Kubernetes。Kubernetes的研发和认知背景，是针对在谷歌外部的对Linux容器感兴趣的开发者以及谷歌在公有云底层商业增长的考虑。和Borg、Omega完全是谷歌内部系统相比，Kubernetes是开源的。像Omega一样，Kubernetes在其核心有一个被分享的持久存储，有组件来检测相关ojbect的变化。跟Omega不同的是，Omega把存储直接暴露给信任的控制面板的组件，而在Kubernete中，是要完全由domain-specific的提供更高一层的版本控制认证、语义、政策的REST API来接触，以服务更多的用户。更重要的是，Kubernetes是由一支在集群层面应用开发能力更强的开发者开发的，他们主要的设计目标是用更容易的方法去部署和管理复杂的分布式系统，同时仍然能通过容器所提升的使用效率来受益。

Docker容器技术基础用法（二）

docker容器技术基础入门（一）

一、什么是容器

二、虚拟化的实现

1、主机级虚拟化

2、容器级别虚拟化

2.1、Linux Namespaces