容器云技术选择之kubernetes和swarm对比
swarm和k8s本质都是容器编排服务。它们都能把底层的宿主机抽象化，然后将应用从以构建好的镜像开始，最终以docker的方式部署到宿主机上。
应该选择哪种方案作为我们的容器云服务呢？
我觉得k8s（kubernetes简称）跟swarm的比较好比MySQL和SQL Server的比较，前者轻量级、实施快、以实现核心功能为重，比较适合小规模部署，后者则是企业级、功能全、支撑场景多，适合做企业级docker云方案。
如下我对两者做出的一些对比：
- 设计理念有区别
swarm偏重的是容器的部署，而k8s更高一层：应用的部署。k8s对容器的所有操作都渗透着为应用而服务的理念，比如pod是为了让联系紧密但又不适合部署在一起的应用分别部署在不同docker里面，但docker之间共享volume和network namespace方式，以便实现紧密地“交流”，在比如service是为了隐藏pod（容器的集合，下文会介绍到）的网络细节，让pod提供固定的访问入口，从而方便地让其他应用访问等。
另外，k8s特别擅长大规模docker的管理。为了解决复杂场景下应用的部署，k8s的组件要比swarm多得多，即便似乎功能类似的组件，k8s很多时候都在场景支持上要优化swarm，以调度为例，swarm只有三种调度策略：宿主机负载、宿主机运行容器的多寡、随机指定宿主机，但K8s除此之外，策略更加丰富，它的策略数量是swarm的2倍以上。比如它还有端口冲突策略（在大规模部署docker时，端口冲突是必须要考虑的场景）、容器挂载的卷冲突策略、指定特定宿主机策略等。
- k8s安装复杂当适应更多场景
swarm与docker天然集成，安装和使用很简单，特别是docker 1.12及以上版本，swarm已经集成到了docker的engine中，因此docker安装后swarm的 部署已经完成了一半，而且swarm的操作都是通过docker api来实现，掌握了docker的操作命令后上手swarm很简单，基本上一个星期都可以玩的比较6了。
k8s基于docker，但围绕着应用的部署开发了很多组件，这些组件很多并不依赖于docker的api，在部署时需要单独规划和实施，而且因为组件中很多策略适应不同的部署场景，所以在部署前不仅仅要明白场景需求，而且还要对组件的设计逻辑了如指掌。所以安装和熟悉过程相比swarm而言要曲折很多。
- 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，变可以很方便的让日志插件读取。同时，两个容器拥有各自的镜像，彼此更新互不影响。
- 容器内的负载均衡
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对访问者来说是透明的，因此不管怎么变都不会影响负载均衡。
- 谁最适合灰度发布
两者都支持灰度发布。
但swarm的灰度发布是一次梭哈。当执行swarm update操作时，所有旧的docker逐一全部替换成新的版本。如果在替换过程中我发现新版本存在问题时，我只能强行终止update，然后执行回滚。在这个过程中对线上的应用会有影响。
而k8s有replication controller的机制，可以人为控制灰度发布的过程。在发布的过程中，我可以让k8s通过replication controller起一小部分新版本的pod并减少对应数量老版本的pod，新的pod可响应用户的请求，如果新的pod比较顺利，则慢慢增加新版本的数量而减少老版本数量，直至新版本全部替换老版本，如果新的pod出现了问题，此时让新pod立即下线，从而不对线上业务造成影响。
k8s的发布过程可以人为干预，因此在重大发布时，这种方式其实更优。
- 弹性伸缩
弹性伸缩是指根据宿主机硬件资源承载的情况而做出的一种容器部署架构动态变化的过程。
比如某台宿主机的CPU使用率使用偏高，k8s可以根据Pod的使用率自动调整一个部署里面Pod的个数，保障服务可用性，但swarm则不具备这种能力。
- 生态
swarm是docke官方推出的集群方案，k8s是脱胎于google的一款基于容器的应用部署和管理打造一套强大并且易用的管理平台。相比swarm而言，k8s更懂容器的管理。
从github上也可以到看到k8s项目的star和fork 都很高，而且网上找的资料也非常丰富。也正是基于k8s的生态影响力，导致docker不得不在新发布的docker EE（Enterprise Edition）将k8s整合进来。
结论：
综上所述，K8S作为一款企业级的容器云方案，更值得我们进行研究。套用业界流行的话：swarm懂容器，但K8S更懂管理。
