容器云技术选择之kubernetes和swarm对比

swarm和k8s本质都是容器编排服务。它们都能把底层的宿主机抽象化，而后将应用从以构建好的镜像开始，最终以docker的方式部署到宿主机上。

 

应该选择哪一种方案做为咱们的容器云服务呢？

我以为k8s（kubernetes简称）跟swarm的比较比如MySQL和SQL Server的比较，前者轻量级、实施快、以实现核心功能为重，比较适合小规模部署，后者则是企业级、功能全、支撑场景多，适合作企业级docker云方案。

以下我对二者作出的一些对比：

 

1. 设计理念有区别

swarm偏重的是容器的部署，而k8s更高一层：应用的部署。k8s对容器的全部操做都渗透着为应用而服务的理念，好比pod是为了让联系紧密但又不适合部署在一块儿的应用分别部署在不一样docker里面，但docker之间共享volume和network namespace方式，以便实现紧密地“交流”，在好比service是为了隐藏pod（容器的集合，下文会介绍到）的网络细节，让pod提供固定的访问入口，从而方便地让其余应用访问等。

另外，k8s特别擅长大规模docker的管理。为了解决复杂场景下应用的部署，k8s的组件要比swarm多得多，即使彷佛功能相似的组件，k8s不少时候都在场景支持上要优化swarm，以调度为例，swarm只有三种调度策略：宿主机负载、宿主机运行容器的多寡、随机指定宿主机，但K8s除此以外，策略更加丰富，它的策略数量是swarm的2倍以上。好比它还有端口冲突策略（在大规模部署docker时，端口冲突是必需要考虑的场景）、容器挂载的卷冲突策略、指定特定宿主机策略等。

 

2. k8s安装复杂当适应更多场景

swarm与docker自然集成，安装和使用很简单，特别是docker 1.12及以上版本，swarm已经集成到了docker的engine中，所以docker安装后swarm的 部署已经完成了一半，并且swarm的操做都是经过docker api来实现，掌握了docker的操做命令后上手swarm很简单，基本上一个星期均可以玩的比较6了。

k8s基于docker，但围绕着应用的部署开发了不少组件，这些组件不少并不依赖于docker的api，在部署时须要单独规划和实施，并且由于组件中不少策略适应不一样的部署场景，因此在部署前不只仅要明白场景需求，并且还要对组件的设计逻辑了如指掌。因此安装和熟悉过程相比swarm而言要曲折不少。

 

3. docker vs pod

在swarm中，被建立、调度和管理的最小单元就是docker。

在k8s中，最小单元则是pod（豌豆荚），pod由一个或者多个为实现某个特定功能而放在一块儿的容器组成。在pod内的docker共享volume和网络namespace，彼此之间能够经过localhost通讯或者标准进程间通讯。

用pod有什么好处呢？

咱们试想这样一个场景：咱们有一个web应用的容器，如今咱们为了收集web日志须要安装一个日志插件，若是把插件安装在web应用容器的里面，则会面临以下一些问题：

• 若是插件有更新，尽管web应用没有变化，但由于二者共享一个镜像，则必须把整个镜像构建一遍；
• 若是插件存在内存泄露的问题，整个容器就会有被拖垮的风险

若是把插件安装在不一样的容器，一样也不合适，由于你要想办法解决插件所在容器读取web容器的日志的问题。

有了pod之后，这些问题均可以迎刃而解。在pod里面为日志插件和web应用各自建立一个容器，二者共享volume，web应用容器只需将日志保存到volume，变能够很方便的让日志插件读取。同时，两个容器拥有各自的镜像，彼此更新互不影响。

 

4. 容器内的负载均衡

swarm自带的负载均衡机制应用不广，大部分仍是采用nginx+consul。nginx自己也是单独的 容器，而consul保存了各个docker中应用的网络信息（IP和端口），nginx镜像在compose时，在dockerfile中指定consul的地址，取出consul中保存的应用的网络信息，做为参数配置到nginx的config file中，从而实现负载均衡。

这种模式的缺点就是：nginx的容器中的配置文件没法跟着应用docker的网络信息发生变化而更改，也就是说，若是新增长了docker，新增长的docker IP和应用端口则须要手动添加到nginx的config file中，或者从新构建nginx的容器。

kubernetes的负载均衡要完善不少，内部集成了负载均衡。并且，对于dockerIP变动的问题也有很好的处理机制：k8s经过service实现负载均衡，service是pod（pod包含了容器，容器中包含了应用）的访问入口，它指向一组有相同label的多个pod。每一个service建立的时候会在k8s内置的dns服务器中写入一条记录：service的名称和service的IP。当须要访问pod中的应用时，只需访问service的名称便可，pod的IP对访问者来讲是透明的，所以无论怎么变都不会影响负载均衡。

 

5. 谁最适合灰度发布

二者都支持灰度发布。

但swarm的灰度发布是一次梭哈。当执行swarm update操做时，全部旧的docker逐一所有替换成新的版本。若是在替换过程当中我发现新版本存在问题时，我只能强行终止update，而后执行回滚。在这个过程当中对线上的应用会有影响。

而k8s有replication controller的机制，能够人为控制灰度发布的过程。在发布的过程当中，我可让k8s经过replication controller起一小部分新版本的pod并减小对应数量老版本的pod，新的pod可响应用户的请求，若是新的pod比较顺利，则慢慢增长新版本的数量而减小老版本数量，直至新版本所有替换老版本，若是新的pod出现了问题，此时让新pod当即下线，从而不对线上业务形成影响。

k8s的发布过程能够人为干预，所以在重大发布时，这种方式其实更优。

 

6. 弹性伸缩

弹性伸缩是指根据宿主机硬件资源承载的状况而作出的一种容器部署架构动态变化的过程。

好比某台宿主机的CPU使用率使用偏高，k8s能够根据Pod的使用率自动调整一个部署里面Pod的个数，保障服务可用性，但swarm则不具有这种能力。

 

7. 生态

swarm是docke官方推出的集群方案，k8s是脱胎于google的一款基于容器的应用部署和管理打造一套强大而且易用的管理平台。相比swarm而言，k8s更懂容器的管理。

从github上也能够到看到k8s项目的star和fork 都很高，并且网上找的资料也很是丰富。也正是基于k8s的生态影响力，致使docker不得不在新发布的docker EE（Enterprise Edition）将k8s整合进来。

 

结论：

综上所述，K8S做为一款企业级的容器云方案，更值得咱们进行研究。套用业界流行的话：swarm懂容器，但K8S更懂管理。