Docker 1.12 在 2016 年 7 月 28 日正式 GA，除了大量的在使用上的改进和 bug 修复外，最引人瞩目的是原生支持了 Swarm 模式。
熟悉 Docker 的读者都知道 Docker Swarm 是官方三剑客之一，提供了轻量级容器云的支持，以性能卓越出名，跟 K8s 面向应用的较为复杂的容器云方案一时瑜亮，各有千秋。
本次 Swarm 模式特性的发布可谓重要变革，不仅仅是减低使用门槛那么简单，还引入了不少新的围绕应用的特性，从中可以一探 Docker 团队对于容器云的理念。
基本概念
Swarm 定义为一组合作在一起的 Docker 主机集群，由节点组成，每个节点都是一个独立的 Docker 主机。
集群中包括两种节点：管理节点和工作节点。参考 k8s 的结构，也是如此。
- 管理节点：负责对任务进行调度和其它管理任务，多个管理节点通过 Raft 协议组成集群；
- 工作节点：负责运行具体的任务，管理节点可以同时作为工作节点。
如果把所有节点配成管理+工作，那就是绝对的对等了，实际上从性能角度考虑，管理节点数量不宜过多，并且相互之间的互联网络要保证好的质量。
此外，还引入了服务的概念。服务也包括两种类型：
- 复制服务（replicated services）：类似 k8s 中复制集的概念，保持一定数量的相同任务在集群中运行；
- 全局服务（global services）：类似 k8s 中 daemon 的概念，每个工作节点上运行一个。
一个服务由多个任务组成，一个任务即一个运行的容器。
主要特性
负载均衡和服务地址管理
k8s 中让人印象深刻的是它的服务自带了负载均衡和服务地址功能，Swarm 也通过 ingress load balancing （基于 ipvs 的四层代理）来实现，为每一个服务提供一个 DNS 地址，维护一个公共的端口。这点上跟 k8s 默认方式略有不同，但效果是一致的，都保证了无论容器如何变化，任意节点对应用的访问保持不变。
跨主机网络
这点还是基于 overlay 网络来实现。
监控管理
基于服务的概念，对运行状态进行管控，自动保持服务的运行状态。
支持命令
目前围绕对集群和服务进行管理，命令都很容易理解。
- swarm init
- swarm join
- service create
- service inspect
- service ls
- service rm
- service scale
- service ps
- service update
Swarm2k
很有意思的项目，就是基于最新的 Swarm 模式来在全球范围内构建一个超过 2000 个节点，1 M 个容器的大集群。
目前已经达到预定目标，具体可以关注 [这里]（https://github.com/swarm2k/swarm2k/blob/master/PROPOSAL.md）。
这个项目的成功，也再次证明官方的 Swarm 方案，在性能上确实首屈一指！
小结
跟 Docker 技术自身的火爆不同，Docker 团队一直以来就面临着未来发展的困境，几乎所有人都希望他们只安心做好容器引擎。但作为一个商业化公司来说，这样下去毫无疑问是自掘深坑。于是，他们积极的在基于容器的各种平台和工具上进行构建。包括三件套、包括容器云，都是很好的尝试。
从 Swarm 的特性来看，Docker 团队在应用为中心这点上是认同了 K8s 的理念的，但是自身又同时保持了一定的独立性。这对于 Docker 来说自然是利好。但是目前来看，并没有完全解决团队发展的困境。
No comments:
Post a Comment