一、Kubernetes Vs Swarm
kubernetes：kubernetes，是Google多年大规模容器管理技术的开源版本，是众多厂商推崇的docker管理优秀之作，随着越来越多的厂商不停地贡献代码，kubernetes功能也愈发完善。
swarm：Swarm是Docker公司在2014年12月初发布的一套用来管理Docker集群的较为简单的工具，由于Swarm使用标准的Docker API接口作为其前端访问入口，所以各种形式的Docker Client(dockerclient in go, docker_py, docker等)都可以直接与Swarm通信。随着Swarm0.2发布，swarm增加了新的策略来调度集群中的容器方式，使得在可用的节点上传播它们，以及支持更多的Docker命令以及集群驱动。
swarm优点：
1、架构简单，部署运维成本较低
docker swarm 集群模式由于原生态集成到docker-engine中，所以首先学习成本低，对于使用docker-engine 1.12版本及以上可以平滑过渡，service服务可以满足动态增减容器个数，同时具备自身的负载均衡，swarm管理者多台设定保证了机器在出错后有一个良好的容灾机制
2、启动速度快
swarm集群只会有两层交互，容器启动是毫秒级
swarm劣势：
1、无法提供更精细的管理
swarm API兼容docker API，所以使得swarm无法提供集群的更加精细的管理
2、网络问题
在网络方面，默认docker容器是通过桥接与NAT和主机外网络通信，这样就出现2个问题，一个是因为是NAT，外部主机无法主动访问到容器内（除了端口映射），另外默认桥接IP是一样的，这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面，有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决，比如用 Flannel 或者 OVS网桥
3、容器可靠性
在容器可靠性方面，相较于Kubernetes的Replication Controllers可以监控并维持容器的生命，swarm在启动时刻可以控制容器启动，在启动后，如果容器或者容器主机崩溃，swarm没有机制来保证容器的运行。
kubernetes优点：
1、管理更趋于完善稳定
kubernetes 集群管理更趋于完善稳定，同时pod功能上比swarm的service更加强大
2、健康机制完善
Replication Controllers可以监控并维持容器的生命
3、轻松应对复杂的网络环境
kubernetes默认使用Flannel作为overlay网络。
Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（OverlayNetwork）工具，其目的在于帮助每一个使用 Kuberentes 的CoreOS 主机拥有一个完整的子网。
kubernetes劣势：
1、配置、搭建稍显复杂，学习成本高
由于配置复杂，学习成本相对较高，对应运维的成本相对高点
2、启动速度稍逊
kubernetes会有五层交互，启动是秒级，启动速度慢于swarm
二、Docker容器编排的发展历程
2017年底在丹麦哥本哈根的Dockercon17上，Docker宣布支持Kubernetes，至此基本宣告在容器编排领域，Kubernetes取得了阶段性的胜利，但是否是绝对胜利，还要看K8S后续的成长，因为接下来K8S要面对的是，越来越多的企业用户开始在生产中大规模使用以及随之而来的集成复杂软件的挑战。
时间回到2014年6月，Docker 1.0发布。从1.0开始我们使用Docker就不在会收到““Do not run in production!”的警告了。1.0代表着一个软件的成熟，可以用于生产环境了。但是尴尬的是，这个1.0只是Docker Engine, 而单一个Docker Engine并不能用于生产环境，生产环境的复杂性并不是一个两个容器能够解决的，是需要成百上千的容器，而这么多的容器，他们的管理需要有一个容器编排的工具，但是Docker公司并没有。值得肯定的是，Docker Engine作为一个开源免费的工具，确实给广大开发者带来了福音，极大的方便了软件的测试和部署，由此Docker也迎来了一批忠实的拥趸。
2014年年中，容器编排工具Kubernetes诞生，并迅速得到Google和RedHat的支持。2014年7月，Docker收购Orchard Labs，由此Docker公司开始涉足容器编排领域，Orchard Labs这家2013年由两位牛逼的年轻人创建的公司，有一个当时非常著名的容器编排工具fig，而这个fig就是docker-compose的前身。Docker Compose虽然能编排多容器的APP，但是却不能实现在多个机器上进行容器的创建和管理。所以此时Docker公司和Kubernetes并未开始正面竞争和冲突。
2015年初，Docker发布Swarm，开始追赶Kubernetes的脚步，正式进入容器编排领域。2015年7月，Kubernetes 1.0发布，标志着Kubernetes可以用于生产环境。 2015年11月，Swarm 1.0发布。Swarm开始了和Kubernetes的正面竞争。
2016年3月，Docker公司写了一篇软文，声称在各项benchmark中Swarm完胜Kubernetes。2016年6月，一个重要的导火索事件，Docker在其1.12版本里内置集成了Swarm，Swarm像Windows内置IE一样成了Docker默认的容器编排工具，这在容器编排生态圈里引发了轩然大波，从2016年7月底开始，Google Kubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上发生了一场撕B大战。Docker公司的这种不正当竞争的做法引起了业界的强烈不满，大家纷纷开始站队，一场容器编排的战争一触即发。
2017年3月，Docker公司宣布Docker企业版诞生，自此开始区分社区版和企业版，从2016年到2017年初，Docker公司的一些列动作充分展示了一个创业公司的盈利压力。Docker公司的一系列努力，并没有能让Docker Swarm走上容器编排的巅峰，相反，Kubernetes因为其优秀的架构和健康的社区环境，得到迅速发展，在生产环境中得到了广泛的应用，然后用户反馈，社区回应，良性循环了下去。2017年各大厂商都开始拥抱Kubernetes，亚马逊AWS，Microsoft Azure，VMware， 有的甚至抛弃了自家的产品。于是乎就有了本文开头所写的2017年底，Docker宣布在自家企业版里支持Kubernetes，和Swarm一起作为容器编排的解决方案供用户选择。
纵观这段短短的历史，Docker成就了Kubernetes，其实反过来Docker也是受益者，毕竟在容器底层技术领域，Docker还是老大，Kubernetes底层更更多的还是选择使用containerd（工业标准的容器运行时，2016年从Docker Engine中剥离出并捐献给社区）。而对于我们学习者和使用者来讲，要学习Kubernetes之前必须要先深入了解Docker，当然如果能深入了解下Docker Swarm会更好，因为你会不自觉的去比较，看看Swarm和Kubernetes对比，有哪些优点和缺点。
