为何有了Compose和Swarm，还会有Kubernetes的出现？

1、k8s设计思想更先进

k8s的主要设置思想，是从更宏观的角度，以统一的方式来定义任务之间的各类关系

1.k8s的核心功能图

2.k8s的全局架构图

把微服务比喻为人，服务治理解决的是人的沟通，人太多了就须要生存空间和沟通方式的优化，这就须要集群和编排。 compose和swarm能够解决少数人之间的关系，好比把手机号给你，你就能够方便的找到我，可是若是手机号变动的时候就会麻烦，人多了也会麻烦。 而k8s是站在上帝视角的高度抽象，看到了

1. 整体有哪些组织，不一样组织有什么样的特色（Job、CronJob、Autoscaler、StatefulSet、DaemonSet...）
2. 不一样组织之间交流可能须要什么（ConfigMap，Secret...），这样比较紧密的人在相同的pod中，经过Service-不会变动的手机号，来和不一样的组织进行沟通，
3. 帮助人们快速构建组织(Deployment、RC)。

k8s就是把组织协调这项管理学落实到了计算机工程上

2、功能对比

1. swarm偏重的是容器的部署，而k8s偏重应用的部署

swarm中最小单元是容器，而k8s是pod，pod能够由多个容器组成，在pod内共享volume和namespace，同一pod内的通讯更为高效 pod有什么好处？ 例若有一个web容器，为了收集web日志，须要安装一个日志插件，若是把插件安装在web容器内：

1. 若是插件有更新，即便服务没有变化也要从新把镜像构建部署一遍
2. 若是插件存在内存泄露问题，整个容器都会被连累

而pod能够为日志插件和web应用各自建立一个容器，二者共享volume，web应用只须要日志保存到volume，两个容器各自有本身的镜像，更新互不影响

2. k8s比swarm有更多的调度策略，更适合大规模容器的的管理

swarm只有三种调度策略：spread、binpack、random，而k8s策略数更多多，还有端口冲突策略、容器挂载卷冲突策略、指定特定宿主机策略等。 Composer中，经过link将容器关联起来，如DB的的链接写入环境变量供进程使用，若是DB发生变化（如镜像） 集群中的节点，只要在同一network内，服务之间

3. k8s的负载均衡机制比swarm更灵活

swarm采用的是nginx+consul。 consul保存了各个docker中应用的网络信息，nginx在compose时，在dockerfile中指定consul的地址，配置到nginx配置中，从而实现负载均衡，这样有个缺点，就是新添加的容器IP和网络须要手动添加到nginx文件中 而k8s负载均衡经过service实现，没有容器IP变动问题，只要有相同的label的pod均可以经过service访问，新添加的容器IP和网络不会影响负载均衡器

4.k8s支持弹性伸缩

k8s能够根据Pod的CPU、内存自动的调整Pod的个数，保障服务的可用性，swarm则不具有这样的功能

原文出处：https://www.cnblogs.com/chenqionghe/p/11474486.html