docker 集群：K8S& swarm对比

515439429

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

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可以更加容易，方便地管理多个容器，无论有多少容器。


第一张图是旧版本的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

上图是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更合适。