Docker-Compose Docker Swarm和Kubernetes的区别
Docker-Compose
Docker-Compose 是用来管理你的容器的，有点像一个容器的管家，想象一下当你的Docker中有成百上千的容器需要启动，如果一个一个的启动那得多费时间。有了Docker-Compose你只需要编写一个文件，在这个文件里面声明好要启动的容器，配置一些参数，执行一下这个文件，Docker就会按照你声明的配置去把所有的容器启动起来，但是Docker-Compose只能管理当前主机上的Docker，也就是说不能去启动其他主机上的Docker容器
Docker Swarm
Docker Swarm 是一款用来管理多主机上的Docker容器的工具，可以负责帮你启动容器，监控容器状态，如果容器的状态不正常它会帮你重新帮你启动一个新的容器，来提供服务，同时也提供服务之间的负载均衡，而这些东西Docker-Compose 是做不到的,它比K8s更加轻量
Kubernetes
Kubernetes它本身的角色定位是和Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也有自己一些不一样的特点。它是谷歌公司根据自身的多年的运维经验研发的一款容器管理平台。而Docker Swarm则是由Docker 公司研发的
这两年Kubernetes已经成为了很多大公司的默认使用的容器管理技术
Kubernetes的具体介绍
节点（Node ） ：一个节点是一个运行 Kubernetes 中的主机。
容器组（Pod ） ：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享资源（网络、 Volumes）。K8s中的最小任务调度单元，可以被调度到任意Node上恢复。
容器组生命周期（pos-states ） ：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。
Replication Controllers：主要负责指定数量的 pod 在同一时间一起运行，保证pod高可用的API对象。
服务（services ） ：对一组提供相同功能的Pods 的抽象，并为它们提供一个统一的入口。
卷（volumes ） ：一个卷就是一个目录，容器对其有访问权限用于持久化数据。
标签（labels ） ：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
ConfigMap：用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。
接口权限（accessing_the_api ） ：端口，IP 地址和代理的防火墙规则。
web 界面（ux ） ：用户可以通过 web 界面操作 Kubernetes。
命令行操作（cli ） ： kubecfg 命令
相关概念的形象理解可以参考：插画版Kubernetes指南（小孩子也能看懂的kubernetes教程） - 站在浪潮之巅 - 博客园
容器组
和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，知道容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（ 也许在将来的版本中会添加容器组的移动）
服务
Replication Controller
存储卷
Volumes（ 存储卷） 是Pod中能够被多个容器访问的共享目录。 Kubernetes的Volumes概念与Docker的Volumes比较类似， 但并不完全相同。 Kubernetes中的Volumes与Pod生命周期相同， 而不与容器的生命周期相关。 当容器终止或者重启时，Volumes中的数据也不会丢失。 另外， Kubernetes支持多种类型的Volumes， 并且一个Pod可以同时使用任意多个Volumes。
架构设计
如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的：
1.分布式架构，保证扩展性；
2.逻辑集中式的控制平面 + 物理分布式的运行平面；
3.一套资源调度系统，管理哪个容器该分配到哪个节点上；
4.一套对容器
Kubernetes 经典架构图
内服务进行抽象和 HA 的系统
Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（ Master Node） ；一类是属于运行平面的工作节点（ Worker Node） 。
显然，复杂的工作肯定都交给控制节点去做了，工作节点负责提供稳定的操作接口和能力抽象即可。
从这张图上，我们没有能发现 Kubernetes 中对于控制平面的分布式实现，但是由于数据后端自身就是一套分布式的数据库 Etcd，因此可以很容易扩展到分布式实现
Etcd
这里 Etcd 即作为数据后端，又作为消息中间件。通过 Etcd 来存储所有的主节点上的状态信息，很容易实现主节点的分布式扩展。组件可以自动的去侦测 Etcd 中的数值变化来获得通知，并且获得更新后的数据来执行相应的。
主节点服务
主节点上需要提供如下的管理服务：
apiserver 是整个系统的对外接口，提供一套 RESTful 的 Kubernetes API，供客户端和架构设计其它组件调用；
scheduler 负责对资源进行调度，分配某个 pod 到某个节点上。是 pluggable 的，意味着很容易选择其它实现方式；
controller-manager 负责管理控制器，包括 endpoint-controller（ 刷新服务和 pod 的关联信息） 和 replication-controller（ 维护某个 pod 的复制为配置的数值）
工作节点
kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（ 同一类标签）
运行机制
Kubernetes运行机制
网络通讯
同一Node的Pod通讯
跨Node的Pod通讯
