duliye
作者duliye2017-06-28 14:57
系统架构师, ABC

K8S& swarm对比

字数 3344阅读 4449评论 0赞 4

Swarm
Swarm是Docker开发的原生集群工具,Swarm使用标准的docker API,这意味着容器能够使用Docker客户端命令启动,Swarm会选择合适的主机来运行容器。
1.jpg

1.jpg

Swarm的基本架构很简单:每个主机运行一个Swarm代理,一个主机运行Swarm管理器(在测试的集群中,这个主机也可以运行代理),这个管理器负责主机上容器的编排和调度。Swarm能以高可用性模式(etcd、Consul 或ZooKeeper 中任何一个都可以用来将故障转移给后备管理器处理)运行。当有新主机加入到集群,有几种不同的方式来发现新加的主机,在Swarm中也就是服务发现。默认情况下使用的是token,也就是在Docker Hub上会储存一个主机地址的列表。
Swarm的优势:
swarm API兼容docker API,使得swarm 学习成本低,同时架构简单,部署运维成本较低。
Swarm的劣势:
同样是因为API兼容,无法提供集群的更加精细的管理。
在网络方面,默认docker容器是通过桥接与NAT和主机外网络通信,这样就出现2个问题,一个是因为是NAT,外部主机无法主动访问到容器内(除了端口映射),另外默认桥接IP是一样的,这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面,有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决,比如用 Flannel 或者 OVS网桥。
在容器可靠性方面,相较于K8s的Replication Controllers可以监控并维持容器的生命,swarm在启动时刻可以控制容器启动,在启动后,如果容器或者容器主机崩溃,swarm没有机制来保证容器的运行。

Kubernetes
Kubernetes是一个由google基于他们上个世纪容器产品化的经验而推出的容器编排工具,Kubernetes有些固执己见对于容器如何组织和网络强制了一些概念,需要了解的主要概念有:
· Pods
Pod是Kubernetes的基本操作单元,把相关的一个或多个容器构成一个Pod,通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个node(Host)上,看作一个统一管理单元,共享相同的volumes和network namespace/IP和Port空间。
· Services
Services也是Kubernetes的基本操作单元,是真实应用服务的抽象,每一个服务后面都有很多对应的容器来支持,通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器,对外表现为一个单一访问接口,外部不需要了解后端如何运行,这给扩展或维护后端带来很大的好处。
Services可以对外暴露ip地址, 一般用公网IP地址,执行暴露服务IP地址命令过后,我们就可以在公网上访问了,但是这里有个问题就是这个IP地址必须是安装了k8s的机器的IP(实质是需要该IP的主机上的kube-proxy来转发网络请求),如果你随便用一个IP是不能访问的,这里也给应用上造成了不便。
· Replication Controllers
Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods,一旦创建成功,pod 模板和创建的pods没有任何关联,可以修改pod 模板而不会对已创建pods有任何影响,也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods,Replication Controller根据labelselector来关联,通过修改pods的label可以删除对应的pods。Replication Controller主要有如下用法:
1) Rescheduling
如上所述,Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行, 即使在节点出错时。
2) Scaling
通过修改Replication Controller的副本(replicas)数量来水平扩展或者缩小运行的pods。
3) Rolling updates
Replication Controller的设计原则使得可以一个一个地替换pods来rolling updates服务。
4) Multiple release tracks
如果需要在系统中运行multiple release的服务,Replication Controller使用labels来区分multiple release tracks。
· Labels
Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、 Replication Controller可以有多个label,但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础,为了将访问Service的请求转发给后端提供服务的多个容器,正是通过标识容器的labels来选择正确的容器。同样,Replication Controller也使用labels来管理通过pod 模板创建的一组容器,这样Replication Controller可以更加容易,方便地管理多个容器,无论有多少容器。

2.jpg

2.jpg

3.jpg
3.jpg

第一张图是旧版本的k8s,第二张图是最新的架构图,从图上或者源代码可以看书,新版本的k8s代理程序kuberlet不可再直接watch etcd了,而是轮询API来获取pod配置变动信息(不知道什么原因)(查了下资料,原来是从安全性方面考虑,etcd只能被一个部件访问)。

在网络方面,k8s 默认使用Flannel作为overlay网络。
Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网络(OverlayNetwork)工具,其目的在于帮助每一个使用 Kuberentes 的CoreOS 主机拥有一个完整的子网。
简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

在Kubernetes的网络模型中,假设了每个物理节点应该具备一段“属于同一个内网IP段内”的“专用的子网IP”。例如:

节点A:10.0.15.0/24
节点B:10.0.25.0/24
节点C:10.0.30.0/24

4.jpg

4.jpg

上图是Flannel的示意图。在使用Flannel的主机,docker容器桥接的不再是主机网卡,而是Flannel创建的虚拟Flannel网卡,同时各主机虚拟Flannel网卡的IP段不同。虚拟Flannel网卡将数据包发往Flanneld服务, Flanneld服务根据配置,以UDP或者vxlan封装数据包,再从主机网卡发往目标主机。
在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址。k8s安装时,需要修改docker的配置文件,使的docker 网桥的地址错开,同时不再直接桥接在物理网卡上,而是Flannel网络或者OVS网桥上,这使这些容器之间能够之间通过IP地址相互找到,也就是相互ping通。

K8s 的优势:
容器的高可用性,集群的精细管理,复杂的网络场景。
K8s 的劣势:
K8s的学习曲线陡峭,同时运维的成本相对高点。

总的来说,个人觉得对内使用,当作私有云来使用场景,或者对容器的可靠性要求不高,swarm比较合适;对外服务,或者需要提供高可靠服务的场景,k8s更合适。

文章作者:liuliuzi_hz

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

4

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广