一、k8s设计思想更先进

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

1.k8s的核心功能图



2.k8s的全局架构图



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

* 总体有哪些组织,不同组织有什么样的特点(Job、CronJob、Autoscaler、StatefulSet、DaemonSet...)
*
不同组织之间交流可能需要什么(ConfigMap,Secret...),这样比较紧密的人在相同的pod中,通过Service-不会变更的手机号,来和不同的组织进行沟通,
* 帮助人们快速构建组织(Deployment、RC)。
k8s就是把组织协调这项管理学落实到了计算机工程上

二、功能对比

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

swarm中最小单元是容器,而k8s是pod,pod可以由多个容器组成,在pod内共享volume和namespace,同一pod内的通信更为高效
pod有什么好处?
例如有一个web容器,为了收集web日志,需要安装一个日志插件,如果把插件安装在web容器内:

* 如果插件有更新,即使服务没有变化也要重新把镜像构建部署一遍
* 如果插件存在内存泄露问题,整个容器都会被连累
而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则不具备这样的功能