不跟风，容器技术的真实优、缺点

传统虚拟机和容器云的真实优缺点对比：

（本文基于的前提：同样是在DevOps自动化程度很高的情况下。

很多时候有人说容器云平台更先进，那是因为他们传统的模式做得不好，如果把传统的模式做好，不见得比容器化平台的自动化程度低。）

1、构建和部署方面

传统的方案是：

a）使用支持虚机部署的DevOps平台，每个节点安装有agent，可以执行命令、上传文件等做很多事（参见阿里的云效、StarAgent）；
b）使用jenkins，功能很成熟、强大，可以自定义脚本，有很多现成的插件；
c）使用批量自动化工具，ansible，saltstack等。

容器云方案：

a）使用容器云平台，但大多数都是商业版的，开源的选择不多，一般都用Rancher；
b）类似于DevOps平台的用法，编写pipline一键打包（实际上也是基于构建脚本和Dockerfile），上传到镜像仓库，然后基于kubernetes yaml定制化部署。

总结：

从构建和部署来说，容器云方案相比Jenkins等方案，优势并不明显，而且jenkins+脚本+插件，可以全方位操控打包过程和服务器，定制化程度比容器平台还高（因为它直接深入到OS内部执行命令，且整个过程集中自动化管理，而容器要在OS内部做操作，一般是在构建镜像时写在Dockerfile中、每个镜像单独管理，有过大规模实施的人都知道，Dockfile功能还是很鸡肋，而且不方便统一管理，很多构建编译过程，大家都倾向于在流水线上去实现，然而新兴容器平台的流水线，通常没有老牌的Jenkins那么成熟，特别是使用开源容器云平台，比如Rancher，很多时候不能满足需求，需要二次开发，相对而言，商业的容器云平台要好一点）。

2、自动扩容和缩容

自动扩容和缩容，通常的前提是无状态服务，且不要求固定IP。

拿一个后管项目来说，它只部署一个节点，无扩容、缩容需求。

再拿一个用户基础服务项目，当调用量大时，倒是可以扩容，传统方案是，前端挂载了负载均衡设备Nginx，做4层或7层转发，添加节点时要修改Nginx配置。有这种需求时，执行一下手动扩缩容，好像也不难。

但是说实话，对于一般中小公司，自动“扩缩容”的需求还是很少，最多只是少数入口流量会爆发的地方才用得着。而使用运维自动工具和平台，手动扩容也很简单。

只有一个问题，就是面对超大规模的系统，手工操作确实不合适。我认为，总体规模5000个节点以下，传统的运维自动化工具+虚拟机都很好做。真正的超大规模，可能是上万个节点，机房都有好几个那种。

3、支持多种发布策略

蓝绿发布、金丝雀（灰度）发布，蓝绿的话，重新部署一套，然后一键切换流量，使用传统方式也不难。金丝雀的话，先发布一小部分，关键是网络配置，重启nginx，也不难。分析同上，关键是服务器规模有多大。

再来看看，有人总结的容器几大优点：

1）更小的计算开销意味着更低的总体成本。

的确，比起虚机独立操作系统而言，Docker更节省资源。

但是Docker的资源隔离和控制，比起虚机有更高的学习成本。不可否则，虚拟机的隔离方法更成熟，更有效，就拿VMware厂商来说，它有很多很多的黑科技去优化资源使用，比如超额分配（后面会讲）。

2）低风险的快速部署、移植

没错，应用自带操作系统，在哪里都能运行。

由于其高一致性，测试完了，直接推生产，不用考虑服务器环境问题，导致的和测试环境不一样。

但是，有数据持久化需求怎么办，日志怎么处理，网络问题怎么解决，还有不少问题要解决，OS不能完全代表“可快速部署和移植”。

3）运行环境更容易管理

有利有弊。以前要修改服务器的东西，打补丁等，需要一个个虚拟机去操作，好处是，处理一个立即生效，应用不需要动。使用Docker，好处是只需要更新基础镜像，缺点是要生效，必须更新应用，更新应用意味着要停机重启。

有人总结了4、5个优点，其实容器技术显著的优点只有两个：

1、高资源利用率；

2、标准化、可移植

侧面印证：我们公司之前做了一个很正式的容器技术评估报告，列了一堆容器的优点、很全面，但实际上，很多都是自动化相关的，那是因为我们本身的自动化程度太低，而不能说是容器技术的优点；然后容器技术剩下的优点实际上就是我上面列的那两条。当时根据现有资源估算的结果是，使用容器只需要现有资源的1/4，可以节约75%的服务器成本（那也是因为，传统的虚机CPU和内存的利用率实在是太低！如果能好好管理和利用，实际上节约不到这么多，下面详细说明）。

注意，资源利用率细节，相对于虚拟机，虚拟化Hypervisor层的开销是减少了，但整体并没有一些人说的那么夸张，比如节省75%，这要看具体情况。首先，容器通常是用的最小化操作系统，而虚拟机用的完整版系统，这样对比是不公平的，如果虚拟机也用最小化操作系统，其实也可以将系统内存控制在50MB以下，而容器如果使用完整版的系统，内存也能达到300MB以上。实际上，我们正式运行的容器，我看了一下，简单Java应用，也使用了2.2G内存，不见得比虚拟机要节省多少（虚拟机，你分配4G内存给它，实际上也不代表它一定独占4G物理内存）。

值得一提，商业化的虚拟化平台，都支持超额分配，比如vSphere5.0+，每个物理内核（cores）最多支持25个vCPU，一个普通服务器有2颗CPU、总物理核数为2*12=24，按常规建议是1:1~1:3之间分配vCPU，可以分出48~144个vCPU，最高可以按1:25比例超额分配，但是在此Dell白皮书中，vCPU:pCPU 指导原则如下：

1:1至3:1没有任何问题

3:1至5:1可能会引发性能下降

6:1或更高通常会引发问题

无所谓，其实CPU通常是足够的，按照1:3分配就够了。内存才是瓶颈，内存分配有3种模式：Limit（上限），Reservation（保留，即私有）和 Shares（共享，即内存不够时，按设置的权重争抢）。很显然，内存是天然支持超额分配的，而且虚拟化平台的内存管理，有许多的优化技术（可参见VMware官方技术文档），应该是很成熟了。

所以，我个人觉得，在相当一个大的物理服务器下，比如256G内存来说，从极限资源利用率来看，Docker占不了多少便宜：假设我部署 48个应用，每个应用真实占用 4G内存，用Docker部署，操作系统占用50MB，Docker引擎占用100M，实际占用内存约为：48*（4G+50MB）+100MB，而换成虚拟机部署，假设Hypervisor引擎占用500MB，则实际占用内存约为：48*（4G+50MB）+500MB。虚拟机也就多占用了400MB内存而已。有些人可能会喷，用Docker就是要多分配一些应用啊，一个256G的物理服务器，怎么才止48个容器，Docker的场景是那种很微小的应用，一个占用0.5G的，可以分配512个容器！。好吧，就算这样，虚拟化平台难道不可以分配512个虚拟机？据我所知，是可以的（vCPU也就1:10），我阿里云的虚拟机就是1vCPU+1GB内存的，最小的好像是256MB内存，256MB内存的系统，你登录进去看，也还有200多MB的剩余，说明系统本身占用内存才几十MB。这里有篇文章，计算了各种配置的物理机，能够做的最大虚拟机数量：虚拟机服务器经典应用配置方案，可以看到，48核+256G内存的服务器，就可以分配400个左右的“微型”虚拟机。所以，我觉得，从资源利用率角度来讲，Docker和虚拟机差别不大，Docker并不是传说中的那样，一个物理机可以运行1000个容器，我们生产也不会这样做，我亲身实践过，我们也会控制一个物理节点分配容器的数量。但容器有一个潜在的优势，那就是它的管理太方便了，随时启停、随时创建和销毁，所以容器的资源利用更灵活，在频繁启停、创建和销毁服务器的场景中，其资源利用率确实大大高于虚拟机（举个很生动的例子：我们有一个Jenkins自动打包的服务器，如果同时有20个打包任务执行，服务器只有4C+8G配置，性能不够，需要加资源，方案1：创建20个2C+4G的虚拟机来分摊执行任务，方案2：创建20个2C+4G的容器来分摊执行任务，表面上看，两个方案最大的差别不在资源利用率，但是方案2，任务执行完，20个容器的资源就自动释放了，而方案1的虚拟机还占用着资源，这个时候的资源利用率，容器完胜，所以我说容器适合那种频繁启停、创建和销毁服务器的场景）。

容器技术的缺点：

1) 有较高的学习成本（不是针对个人，而是针对整个研发及运维团队）

2) 复杂度增加，引入了不少新东西，比如网络层面，引入Calico、Traefik等

3) 某些应用有一定的改造成本，且不是所有应用都适合

4) 增加基础环境的搭建和维护难度（自己维护Kubernetes等一系列环境组件）

5) 抛弃传统成熟稳定的东西，用一堆新的东西，有一定技术风险（有较多bug，我遇到过最严重的一次是，K8s引起一个Linux内核错误，导致物理机直接死机）

我再来总结一下，容器几大优点：

1）高资源利用率；更小的计算开销意味着更低的总体成本。

的确，比起虚机独立操作系统而言，Docker能节省一点点资源（5%~?，具体看情况）。

更多的场景是，容器的灵活启停、创建和销毁，对资源的动态利用率，完胜虚拟机那种静态的方式。

2）标准化、可移植；低风险的快速部署、移植

没错，应用自带操作系统，在哪里都能运行。

由于其高一致性，测试完了，直接推生产，不用考虑服务器环境问题，导致的和测试环境不一样。

3）运行环境更容易管理

自动调度，自动扩容和缩容，故障自愈，全方位监控。

4）支持多种发布策略

蓝绿发布、金丝雀（灰度）发布等非常容易。

个人建议：

容器技术的高资源利用率，标准化和可移植性，是难以抗拒的优点！！以至于为了具备这种优点，而不惜增加人力物力对容器技术的投入。如果公司本身的自动化程度很完善，短期内，就按传统的来，不急着应用容器。但是从长远来看，还是得想办法将容器技术运用起来。最初的应用，可以是和传统的技术进行融合，取长补短。等到对容器技术驾轻就熟之后，且全面胜过传统技术之后，方可深入全面应用。