docker 集群：K8S& swarm对比

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