作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://blog.csdn.net/HiWangWenBing/article/details/122750196
目录
2.2 管理的业务场景的规模与复杂度不同：中小规模VS超大规模
Docker引擎实现了容器化服务在某台服务器上的灵活部署，然后面对成百上千服务的集群系统，手工部署就显得力不从心，效率低下。为此docker开发了docker swarm来应对这个问题，google公司也提供了自己的解决方案K8S。本文就是比较这两种工具的相同点与优缺点，以便于作出技术方案。
K8S与SWARM都是架构在docker之上，都是对集群化的容器服务进行部署、运维的工具。
swarm和k8s本质都是容器编排服务,。
swarm本身就是内嵌在docker引擎之中的，与docker引擎融为一体。
k8s自身大部分功能也是以容器的方式部署，来完成容器编排的任务 。
如何对他们进行比较和选择呢？
总体上讲，swarm与k8s（kubernetes简称）的比较，一点像MySQL和SQL Server的比较。
前者轻量级、实施快、以实现核心功能为重，比较适合小规模部署，后者则是企业级、功能全、支撑场景多，适合做企业级大规模docker云方案。
swarm和K8S，虽然都是架构在容器之上，处于同一层次。但是，他们的侧重点却不相同。
swarm：内嵌在容器引擎内部，是容器引擎的一部分，与容器深度绑定，swarm偏重的是容器的部署，侧重于容器技术的扩展。
k8s：独立于docker，与docker是分离的，并完全不依赖于底层的docker，它侧重于业务应用的集群部署。k8s对容器的所有操作都渗透着为应用而服务的理念。以服务为中心，docker仅仅是其底层技术支撑的一种技术。
在调度策略方面：
swarm只有三种调度策略：Host宿主机负载、宿主机运行容器的多寡、随机调度指定宿主机。
K8s除此之外，策略更加丰富，它的策略数量是swarm的2倍以上。比如它还有端口冲突策略（在大规模部署docker时，端口冲突是必须要考虑的场景）、容器挂载的卷冲突策略、指定特定宿主机策略等。
K8S调度测试的多样化，使得K8S更能够适应和解决杂场景下应用的部署。
k8s的组件要比swarm多得多，即便似乎功能类似的组件，k8s特殊场景支持上要优于swarm。
因此，k8s更适合大规模、超大规模、部署场景复杂的场合。
swarm更适合中小规模，部署场景简单的场合。
swarm与docker天然集成，安装和使用很简单，特别是docker 1.12及以上版本，swarm已经集成到了docker的engine中，因此docker安装后swarm的部署已经完成了一半，而且swarm的操作都是通过docker api来实现，掌握了docker的操作命令后上手swarm很简单，基本上一个星期就可以掌握。
k8s虽然是基于docker，但围绕着应用的部署，K8S开发了很多组件，这些组件很多并不依赖于docker的api，在部署时需要单独规划和实施，而且因为组件中很多策略适应不同的部署场景，所以在部署前不仅仅要明白场景需求，而且还要对组件的设计逻辑了如指掌。所以安装和熟悉过程相比swarm而言要曲折很多，需要独立于docker之外，安装很多套件。
因此，K8S的学习难度也要比swarm大很多。
在swarm中，被创建、调度和管理的最小单元就是container。
在k8s中，最小单元则是pod（豌豆荚），pod由一个或者多个为实现某个特定功能，逻辑紧密的容器组成。在pod内的docker共享volume和网络namespace，彼此之间可以通过localhost通信或者标准进程间通信。以便pod内部的docker之间实现紧密地“交流”。
用pod有什么好处呢？
我们试想这样一个场景：我们有一个web应用的容器，现在我们为了收集web日志需要安装一个日志插件，我们面临两种选择：
（1）把插件安装在web应用容器的里面，则会面临如下一些问题：
（2）如果把插件安装在不同的容器，同样也不合适：
但有了pod以后，这些问题都可以迎刃而解。
在pod里面，为日志插件和web应用各自创建一个容器，两者共享volume（即文件系统目录），web应用容器只需将日志保存到volume，便可以很方便的让日志容器插件读取。同时，两个容器拥有各自的镜像，彼此更新互不影响。他们通过文件系统的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对访问者来说是透明的，因此不管怎么变都不会影响负载均衡。
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。
业务软件系统可以同时进行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的发布过程还可以人为干预，因此在重大发布时，这种方式其实更优。
弹性伸缩是指根据宿主机硬件资源承载的情况以及外部的业务请求的情况，做出的一种容器部署架构动态变化的过程，比如某台宿主机的CPU使用率使用偏高，需要进行动态调度。
k8s可以根据Pod的使用率，自动、动态调整宿主机中Pod的个数，保障服务可用性。
但swarm的最小单元是容器，则不具备上述这种能力，只能基于容器进行弹性调度。
swarm是docke官方推出的集群方案，重在对容器的动态调度。
k8s是脱胎于google的一款基于容器的应用部署和管理打造一套强大并且易用的管理平台，重在对业务的动态调度。
从github上也可以到看到k8s项目的star和fork 都很高，而且网上找的资料也非常丰富。
也正是基于k8s的生态影响力，导致docker不得不在新发布的docker EE（Enterprise Edition）将k8s整合进来。
综上所述，K8S作为一款企业级的容器云方案，
Swarm轻量级、实施快、比较适合小规模部署，K8S则是企业级、功能全、支撑场景多，适合做企业级大规模云方案。
套用业界流行的话：swarm懂容器与技术，但K8S更懂管理云运营。
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://blog.csdn.net/HiWangWenBing/article/details/122750196
