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

一、k8s设计思想更先进

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

1.k8s的核心功能图

2.k8s的全局架构图

kube-apiserver：API服务
Kube-scheduler：调度
kube-controller-manager：容器编排
etcd：持久化
kubelet：节点核心部分，负责同容器运行时打交道、与Device Plugin交互管理宿主机GPU等物理设备组件，调用网络和存储插件为容器配置网络和持久化存储
- CRI：Container Runtime Interface 容器远程调用接口，定义了容器运行时的各项核心操作）
- Device Plugin：kubelet通过grpc调用这个插件来管理CPU等宿主机物理设备
- CNI：Container Networking Interface，容器配置网络接口
- CSI：Container Storage Interface，容器持久化存储接口

把微服务比喻成人的管理

把微服务理解为人，服务治理解决的是人的沟通，人太多了就需要生存空间和沟通方式的优化，这就需要集群和编排。
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容器内：
1.如果插件有更新，即使服务没有变化也要重新把镜像构建部署一遍

如果插件存在内存泄露问题，整个容器都会被连累
而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则不具备这样的功能