kubernetes和swarm对比

kubernetes和swarm哪个好

复杂场景下应用的部署

swarm偏重的是容器的部署,而k8s更高一层:应用的部署。

k8s的组件要比swarm多得多,即便似乎功能类似的组件,k8s很多时候都在场景支持上要优化swarm,以调度为例,swarm只有三种调度策略:宿主机负载、宿主机运行容器的多寡、随机指定宿主机,但K8s除此之外,策略更加丰富,它的策略数量是swarm的2倍以上。比如它还有端口冲突策略(在大规模部署docker时,端口冲突是必须要考虑的场景)、容器挂载的卷冲突策略、指定特定宿主机策略等。

日志处理与镜像更新

在swarm中,被创建、调度和管理的最小单元就是docker。在k8s中,最小单元则是pod(豌豆荚),pod由一个或者多个为实现某个特定功能而放在一起的容器组成。在pod内的docker共享volume和网络namespace,彼此之间可以通过localhost通信或者标准进程间通信。用pod有什么好处呢?我们试想这样一个场景:我们有一个web应用的容器,现在我们为了收集web日志需要安装一个日志插件,如果把插件安装在web应用容器的里面,则会面临如下一些问题:

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

如果把插件安装在不同的容器,同样也不合适,因为你要想办法解决插件所在容器读取web容器的日志的问题。有了pod以后,这些问题都可以迎刃而解。在pod里面为日志插件和web应用各自创建一个容器,两者共享volume,web应用容器只需将日志保存到volume,变可以很方便的让日志插件读取。同时,两个容器拥有各自的镜像,彼此更新互不影响。

灰度发布

两者都支持灰度发布。但swarm的灰度发布是一次梭哈。当执行swarm update操作时,所有旧的docker逐一全部替换成新的版本。如果在替换过程中我发现新版本存在问题时,我只能强行终止update,然后执行回滚。在这个过程中对线上的应用会有影响。而k8s有replication controller的机制,可以人为控制灰度发布的过程。在发布的过程中,我可以让k8s通过replication controller起一小部分新版本的pod并减少对应数量老版本的pod,新的pod可响应用户的请求,如果新的pod比较顺利,则慢慢增加新版本的数量而减少老版本数量,直至新版本全部替换老版本,如果新的pod出现了问题,此时让新pod立即下线,从而不对线上业务造成影响。k8s的发布过程可以人为干预,因此在重大发布时,这种方式其实更优。

实时更新内部网络信息变更

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

弹性伸缩

弹性伸缩是指根据宿主机硬件资源承载的情况而做出的一种容器部署架构动态变化的过程。比如某台宿主机的CPU使用率使用偏高,k8s可以根据Pod的使用率自动调整一个部署里面Pod的个数,保障服务可用性,但swarm则不具备这种能力。

赞(2) 打赏
特别声明:除特殊标注,本站文章均为原创,遵循CC BY-NC 3.0,转载请注明出处。三伏磨 » kubernetes和swarm对比

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏