K8s概述：几种集群方案的对比
几种集群方案简介
下面以docker部署为主，主流的容器化集群部署方案主要有以下几种：
- Docker Compose：帮助在 同一个节点 上部署多个容器。
- Docker Swarm：多台机器上部署容器。开箱即用，快速部署容器。偏重容器部署
- K8s：社区活跃度高，组件丰富。微服务化，偏重应用的部署。
- Marathon+Mesos：大数据组件部署。双层调度，侧重底层资源管理。任务调度需自己实现
compose支持在 同一节点 上部署，swarm支持在多个节点上部署容器。这两者都是docker原生支持的docker集群部署方式，开箱即用，比较方便，偏重于容器的部署。
swarm偏重的是容器的部署，而k8s偏重于应用的部署。k8s对容器的所有操作都渗透着为应用而服务的理念，比如pod是为了让联系紧密但又不适合部署在一起的应用分别部署在不同docker里面，但docker之间共享volume和network namespace方式，以便实现紧密地“交流”，在比如service是为了隐藏pod（容器的集合，下文会介绍到）的网络细节，让pod提供固定的访问入口，从而方便地让其他应用访问等。
在swarm中，被创建、调度和管理的最小单元就是docker。在k8s中，最小单元则是pod。
marathon+mesos，一开始是给大数据组件部署用的，这个框架是一个双层调度框架，侧重于底层资源管理。需要自己实现任务调度。
下面重点对比一下k8s和mesos。
k8s vs mesos
k8s
k8s一些概念
- Node：资源节点的抽象
- Pod：pod为kubernetes的最小管理单元，一个pod中可以部署多个容器，通常建议是一个容器
- Daemonset：每个node上有一个，比如使用gpu、联通上的seman服务
- Statefulset：解决有状态服务，保证部署和scale的顺序。比如mysql。
- Deployment：一个Deployment通过多个ReplicaSet管理pod，一个Replica Set拥有一个或多个Pod。滚动升级的时候是用新的rs替代旧的rs
- Endpoint：一个资源对象，用于记录一个service对应的所有pod的访问地址
- Service：容器互联或者对外暴露的服务。Service通过label选择Pod，这些 Pod 通过endpoints 暴露出来。通过与具体后端pod解耦，使得后端pod迁移时访问不受影响。
k8s组件
- kube-dns：用Service向集群内部提供服务的
- Etcd：存储配置数据库。存储网络的配置信息和各种对象的状态和元信息配置
- kube-apiserver：k8s主节点的管理中心，整个集群的控制入口。它有助于各个组件之间的通信，从而保持集群的健康。
- kube-controller-manager：确保通过向上和向下扩展工作负载来使群集的期望状态与当前状态相匹配。
- kube-scheduler：将工作负载放置在适当的节点上。
- Kubelet：从API服务器接收pod规范并管理在主机中运行的pod。
kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源。可以把kubelet理解成【Server-Agent】架构中的agent，是Node上的pod管家。
scheduler负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
controller-manager负责执行各种控制器，目前有两类：
- endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
- replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
K8s概述：几种集群方案的对比
提交流程
提交一个pod的流程
- 用户提交pod，APIServer记录到etcd中；
- scheduler周期性查询APIServer，以获取未绑定的pod，尝试为pod分配节点；
- scheduler调度：首先过滤不符合pod资源要求的主机。然后考虑整体优化策略对主机打分，比如使用最低负载，使用分散主机等。最后选择最高分的主机存储绑定信息到etcd中；
- kubelet周期查询绑定对象，获取需要在本机启动的pod并通过docker启动。
K8s概述：几种集群方案的对比
提交一个controller的流程
- 用户提交一个controller；
- APIServer把controller对象保存到etcd中；
- controller周期性查询APIServer获取未绑定的pod：APIServer获取每个节点上绑定的kubeletkubelet请求docker获取pod状态kubelet返回pod状态
- controller创建pod
K8s概述：几种集群方案的对比
提交一个service的流程
- APIServer创建service对象写入etcd。
- controller不断扫描service对应的pod。
- controller调用APIServer创建对应的访问端点endpoint。
- APIServer将endpoint对象写入etcd。
- proxy不断发现有没有可以放在自己上面的转发规则，如果有则创建socket监听端口，并且创建相应的iptables规则。
K8s概述：几种集群方案的对比
mesos
mesos+marathon
mesos复制资源管理，主要有以下四个组件：
- Agent：即Slave，上报资源
- Master：接入framework和slave
- Framework：如Hadoop、Marathon，修改调度器，获取Mesos分配给自己的资源
- Executor：如何启动task
这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。其它框架的调度器是直接面对整个集群，Mesos的优势在于，第一层调度先将整个Node分配给一个Framework，然后Framework的调度器面对的集群规模小很多，然后在里面进行二次调度，而且如果有多个Framework，例如有多个Marathon，则可以并行调度不冲突。
以下面这个调度图为例子：
- Slave1 向 Master 报告，有4个CPU和4 GB内存可用。
- Master 发送一个 Resource Offer 给 Framework1 来描述 Slave1 有多少可用资源。
- FrameWork1 中的 FW Scheduler会答复 Master，我有两个 Task 需要运行在 Slave1，一个Task 需要<2个cpu，1 gb内存="">，另外一个Task需要<1个cpu，2 gb内存="">。
- 最后，Master 发送这些 Tasks 给 Slave1。然后，Slave1还有1个CPU和1 GB内存没有使用，所以分配模块可以把这些资源提供给 Framework2。
K8s概述：几种集群方案的对比
DC/OS
DC/OS是以Mesos为内核，加上marathon和chronos作为运行和管理任务和应用的框架。它集成了许多大数据处理框架（hadoop、spark等）。
K8s概述：几种集群方案的对比
Mesosphere DCOS除了内核Mesos，还有两个关键组件Marathon和Chronos。其中，Marathon(名分布式的init)是一个用于启动长时间运行应用程序和服务的框架，Chronos(又名分布式的cron)是一个在Mesos上运行和管理计划任务的框架。
Mesosphere DCOS在其公有仓库上已提供了40多种服务组件，比如Hadoop，Spark，Cassandra, Jenkins, Kafka, MemSQL等等。
DC/OS上面的Framework实现也可以使用k8s。
k8s vs mesos
K8s概述：几种集群方案的对比
DC/OS采用二次调度的机制，使得应用调度与资源调度相分离。这一点与Kubernetes不同，Kubernetes的应用调度与资源调度全部都是通过内部的组件完成的，其自身的资源调度平台仅能为容器运行提供支撑，不能为其它的Framework提供资源支撑，可以说Kubernetes的容器调度与资源调度是紧耦合的。而在DC/OS平台下，各应用调度框架与Mesos资源实现了松耦合，Mesos仅负责资源的调度，而上层应用的调度则由各应用的Framework自身完成，Framework自身也可以通过容器的方式运行在平台之上。
不同集群规模的选择
K8s概述：几种集群方案的对比
因为容器和集群编排有学习成本，所以对于小集群，建议是使用Iaas和裸机部署docker。
然后当发展到一定程度，有50+个以上的服务的中等规模集群，建议使用Docker Swarm，Swarm与docker紧密结合，命令与docker相对一致，比较容易上手。
到了百级别的集群，在这个量级上需要有一些定制化工作，swarm调度方面开始有压力，组件内置又不好debug。这时候会比较多选择Mararthon+Mesos，双层调度机制使得集群可以大很多。
到了千级别的集群，kubernetes的模块划分的更细，设计思想也更偏向于微服务部署，就是学习成本比较高。
然后是万级别的节点，这时候Kubernetes的调度和etcd等组件的压力在万级别上会达到瓶颈，单个etcd集群和串行调度，controller监听单队列会遇到性能的问题。这时候需要定制化K8s组件，比如etcd做多集群，对于多租户可以实现并行调度，监听多个队列，定制事件优先级，比如add优先于delete等等。
在这个级别上也可以使用DC/OS做定制化，天生的双层调度可以给不同的租户独立使用Marathon并行调度。
最后是部署大数据组件，推荐是使用Mesos做调度，因为天生就是从做大数据组件部署起来的，拥有丰富的大数据Framework。