对标Docker.swarmkit 与 Rancher.cattle

版权说明:原创作品,允许转载,转载时请务必以超连接形式表明文章原始出处、作者信息和本声明。否则将追究法律责任。http://blog.neunn.com/wordpress/?p=381

随着Docker的猛烈发展,单机的 Docker Engine 已经成为历史,新的 Docker Engine 拥有了一个崭新的角色——Swarm Node,这是Swarmkit 为 Engine 带来的新角色,Swarmkit将会内置到Docker Engine v1.12中,在v1.12行将发布之际,着实给生态圈带来了不小的冲击。

笔者是国内较早一批接触Rancher的开发者之一,最初的Rancher就是从自研的Cattle编排引擎起家,虽然目前Rancher集成了Mesos、Swarm、K8s等引擎,但是在笔者平日与国内Rancher用户的沟通了解到,大部分还是使用Cattle引擎居多,在Rancher集成的多个引擎中Cattle与Rancher融合程度上也相对成熟和稳定得多。

本文的主题便是对比一下Swarmkit与Cattle,其目的并不在于比拼技术的先进性与优劣,想必各位英雄深知容器技术在国内的企业落地,能将最终客户的业务落地才是根本。所以本文更多只是给大家一个参考,比较两种引擎的功能差异和某些技术细节。

先来看一张Swarmkit的架构图,

swarmkit-architec

调度方面

Swarmkit支持ReadyFilter、ResourceFilter、PluginFilter、ConstraintFilter基本上继承了Swarm的方式,而虽然Cattle也是基本Swarm的调度规则,但是一个比较关键的ResourceFilter没有支持,也就是说Cattle不能根据Host的资源使用情况来进行调度,这个也是在与Rancher用户交流过程中,大家比较痛苦的地方。

集群管理方面

SwarmKit中有两种角色,Manager和Worker。Manager主要管理节点、调度任务。Worker主要通过Executor来执行任务,集群环境通过 Raft 一致性协议,避免单点故障问题,其内置了K/V存储维护状态,这样也无需连接外部的Etcd/Consule之类的服务。

raft-resource

而在Rancher中实际上我们可以理解为所有Worker共用一个Manager(Rancher-Server),而Rancher-Server的HA实现则略为复杂,尽管其官方开发了cluster-manager组件,但仍然需要部署zoomkeeper、redis等额外组件,还需要通过docker-swarm来编排Rancher-Server的几台node,复杂性同时也会带来不稳定性,此处确实有改进空间。

Swarmkit的节点通信使用gRPC框架并采用ProtoBuf序列化协议,由于gRPC基于HTTP/2标准设计,所以相对于其他RPC框架,gRPC带来了更多强大功能,如双向流、头部压缩、多复用请求等。而Cattle则使用websocket协议来维护节点通信,通过websocket的ping/pang Frame来辨识节点的健康状态。在中小规模集群上两者应该无大差别,在超大规模上Swarmkit应该会更具有优势。另外在节点通信安全性上,Swarmkit实现 node 之间点对点的 TLS 认证,且有周期性证书轮换机制,安全性非常高,Cattle则在这方面要弱很多。

容器网络

这里所说的是跨主机容器网络,对于Swarmkit,由于Swarmkit集成到containerd中,故与Docker libnetwork融合非常紧密,当我们初始化一个集群时会自动创建一个名为ingress的vxlan overlay网络,那么在创建service时可以直接指定这个网络。libnetwork的overlay实现是内置的,无需加载额外插件,使用起来确实方便。

docker-overlay-network-practice-network

对于原生overlay的kernel版本支持问题,2015年10月末社区已经fix了,参见 Add overlay network support in < 3.16 kernels 。

对于Cattle,其通过rancher-net组件得到网络支持,目前rancher-net只支持ipsec overlay。同为overlay网络,vxlan更适合支持私有数据中心,而ipsec则对混合云更合适,毕竟网络通信是有密钥加密的。

Libnetwork的vlan支持还处在experimental,有macvlan/ipvlan两种实现方式,但是目前对内核版本要求非常高,落地使用还有段距离。rancher-net对于其他网络模型的支持将会在Rancher v1.2中增加,届时rancher-net将会支持CNI,那么基于CNI构件的容器网络插件都可以集成到Rancher中。

服务发现

Swarmkit与Cattle都是以dns方式提供服务发现能力,Swarmkit是通过Libnetwork组件,Cattle是通过rancher-dns 组件,Libnetwork dns与rancher-dns最终都是通过miekg-dns 库来实现,所以性能上应该无太大差别。rancher-dns 支持从<stack_name>.<service.name>.<container_name>各个级别的records,还能自定义alias/external service 绑定对应的 record,功能上还是非常丰富的。Libnetwork目前来看支持的比较初级,官方提供的操作文档也比较少。

健康检查

健康检查有两个粒度,一是对node节点的检查,而是对应用服务的检查。对于node节点的健康检查是基本功能,Swarmkit和Cattle均能很好支持。对Service的健康检查,Cattle基于Haproxy的health check来实现,能够支持TCP&HTTP的check,功能上自由度比较大,而Swarmkit目前支持还不是很完善,Service & Container级别的 Healthcheck Support 仍然处在P1级别的开发中。

负载均衡

负载均衡通常包括ingress load balancing 和 internal load balancing,前者是指应用服务外部入口的负载均衡,后者是指应用服务内部的负载均衡。

对于ingress load balancing,Swarmkit使用IPVS,IPVS 是在 Linux 内核中构建的传输层 4 层网络上的负载均衡,也被称为 4 层转发(Layer-4 Switching)。IPVS 在宿主机上可以像一个负载均衡器一样,在多个实际 Server 的前端做 TCP/UDP 等方面的转发,从而使得多个实际 Server 对外暴露一个单独的虚拟 Server。IPVS 目前已经被融合进入 Linux Virtual Server(LVS);而Cattle则使用的是Haproxy。论性能上讲Swarmkit应该略胜一筹,实用性方面实际上相差无几。

对于internal load balancing,Swarmkit使用dns来实现简单的负载均衡;而Cattle则同样使用Haproxy,这个应用场景下,Haproxy更胜一筹,毕竟基于dns的负载均衡,其灵活性要差很多。

部署方面

Swarmkit的两个核心swarmd和swarmctl都会内置到Docker的Containerd服务中,这就意味着基本不需要额外部署,只要安装了Docker Engine即可使用。而Cattle则和其它编排引擎一样,需要启动额外的容器来处理,且agent容器内部需要映射宿主机的docker.sock。

总结

Swarmkit基本上实现了各家编排引擎的核心功能,尤其是内置到Docker Engine中的杀伤力是巨大的,在集群维护和节点管理方面Swarmkit的确天生就比较优秀,毕竟是采纳百家之长,但是真正落到应用管理和服务编排方面,Swarmkit仍有一些路需要走,而Cattle与Rancher其他组件的融合已经达到了“开箱即用”的水准。笔者在撰写此文之时,Rancher已经在v1.2版本的开发计划中加入了Swarmkit的集成,Swarmkit将会作为Rancher的又一个编排引擎。天下大势,合久必分,分久必合,你中有我,我中有你。最后还是那句话,技术对比只是参考,容器在企业落地最终还是得解决企业实际的业务问题。

TBC..

 

东网科技有限公司(英文名NEUNN)总部位于中国沈阳,由东北大学、沈阳市政府及战略投资者联合创立,注册资本1.2亿元,是国内领先的数据与基础设施服务商,业务范围覆盖超云计算、大数据、智慧城市等领域,致力于通过技术及商业模式的突破开启“大数据时代的智慧生活”。

niusmallnan

初出茅庐在阿里口碑网,后与朋友创业创办美食点评网站meishixing.com,
后离开加入东网(Neunn)从事OpenStack和Docker相关开发工作,
在云计算领域有一定经验,目前在公司担任Rancher平台的技术负责人。

发表评论

电子邮件地址不会被公开。 必填项已用*标注