swarm与docker天然集成，安装和使用很简单，特别是docker 1.12及以上版本，swarm已经集成到了docker的engine中，因此docker安装后swarm的部署已经完成了一半，而且swarm的操作都是通过docker api来实现，掌握了docker的操作命令后上手swarm很简单，基本上一个星期就可以掌握。

k8s虽然是基于docker，但围绕着应用的部署，K8S开发了很多组件，这些组件很多并不依赖于docker的api，在部署时需要单独规划和实施，而且因为组件中很多策略适应不同的部署场景，所以在部署前不仅仅要明白场景需求，而且还要对组件的设计逻辑了如指掌。所以安装和熟悉过程相比swarm而言要曲折很多，需要独立于docker之外，安装很多套件。

因此，K8S的学习难度也要比swarm大很多。

2.4 调度的最小单元不同：docker vs pod

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

在k8s中，最小单元则是pod（豌豆荚），pod由一个或者多个为实现某个特定功能，逻辑紧密的容器组成。在pod内的docker共享volume和网络namespace，彼此之间可以通过localhost通信或者标准进程间通信。以便pod内部的docker之间实现紧密地“交流”。

用pod有什么好处呢？

我们试想这样一个场景：我们有一个web应用的容器，现在我们为了收集web日志需要安装一个日志插件，我们面临两种选择：

（1）把插件安装在web应用容器的里面，则会面临如下一些问题：

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

（2）如果把插件安装在不同的容器，同样也不合适：

那样的话，就需要想办法解决插件所在容器读取web容器的日志的问题。

但有了pod以后，这些问题都可以迎刃而解。

在pod里面，为日志插件和web应用各自创建一个容器，两者共享volume（即文件系统目录），web应用容器只需将日志保存到volume，便可以很方便的让日志容器插件读取。同时，两个容器拥有各自的镜像，彼此更新互不影响。他们通过文件系统的Volume实现了镜像的解耦，由保留了他们之间在业务上的紧密性，相关性。

2.5 负载均衡的机制不同

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对访问者来说是透明的，因此不管怎么变都不会影响负载均衡。

2.6 灰度发布的程度不同

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

业务软件系统可以同时进行A/B testing，即让一部分用户继续用产品原有特性A，一部分用户开始用产品新特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到新特性B上面来。

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，降低问题的影响面。

支持灰度发布的系统，把软件的运行系统由原先的测试系统和运营系统，划分为三个子系统：开发测试系统、生成测试系统、运营系统。经过测试开发后的软件，先部署在生成测试系统。开发测试系统与运营系统共享相同的数据库系统。

并通过负载设备，把一部分用户的业务请求转到生产测试系统，大部分用户的请求保留在原有的运营系统，经过生产测试验证后，就可以升级到运营系统。

swarm和K8S两者都支持灰度发布。

但swarm的灰度发布是一次发布。

当执行swarm update操作时，所有旧的docker逐一全部替换成新的版本。如果在替换过程中发现新版本存在问题时，只能强行终止update，然后执行回滚，整个更新就失败。在这个过程中对线上的应用会有全局性的影响。

而k8s有replication controller的机制，是基于Pod的逐步发布 。

在发布的过程中，可以让k8s通过replication controller起一小部分新版本的pod并减少对应数量老版本的pod，新的pod可响应用户的请求，如果新的pod比较顺利，则慢慢增加新版本的数量而减少老版本数量，直至新版本全部替换老版本，如果新的pod出现了问题，此时让新pod立即下线，从而不对整个线上业务造成影响。

k8s的发布过程还可以人为干预，因此在重大发布时，这种方式其实更优。