在上周发布的《从“鸿沟理论”看云原生,哪些技术能够跨越鸿沟?》一文中,灵雀云CTO陈恺表示:Kubernetes在云计算领域已经成为既定标准,进入主流市场,最新版本主要关注在稳定性、可扩展性方面,在开发人员中变得非常流行。Kubernetes会越来越多往下管理所有基础设施,往上管理所有种类的应用。我们会看到,越来越多的周边技术向它靠拢,在其之上催化出一个庞大的云原生技术生态。
那么,现在最新最流行的 Kubernetes 架构是什么样子呢?本文给大家介绍一下 Kubernetes 整体架构,并深入探讨其中 2 个比较关键的问题。
Kubernetes 架构解析
首先,Kubernetes 的官方架构图是这样的:
这个架构图看起来会比较复杂,很难看懂,我把这个官方的架构图重新简化了一下,就会非常容易理解了:
- ETCD :是用来存储所有 Kubernetes 的集群状态的,它除了具备状态存储的功能,还有事件监听和订阅、Leader选举的功能,所谓事件监听和订阅,各个其他组件通信,都并不是互相调用 API 来完成的,而是把状态写入 ETCD(相当于写入一个消息),其他组件通过监听 ETCD 的状态的的变化(相当于订阅消息),然后做后续的处理,然后再一次把更新的数据写入 ETCD。所谓 Leader 选举,其它一些组件比如 Scheduler,为了做实现高可用,通过 ETCD 从多个(通常是3个)实例里面选举出来一个做Master,其他都是Standby。
- API Server:刚才说了 ETCD 是整个系统的最核心,所有组件之间通信都需要通过 ETCD,实际上,他们并不是直接访问 ETCD,而是访问一个代理,这个代理是通过标准的RESTFul API,重新封装了对 ETCD 接口调用,除此之外,这个代理还实现了一些附加功能,比如身份的认证、缓存等。这个代理就是 API Server。
- Controller Manager:是实现任务调度的,关于任务调度可以参考之前的文章,简单说,直接请求 Kubernetes 做调度的都是任务,比如 Deployment 、Deamon Set 或者 Job,每一个任务请求发送给Kubernetes之后,都是由Controller Manager来处理的,每一个任务类型对应一个Controller Manager,比如 Deployment对应一个叫做 Deployment Controller,DaemonSet 对应一个 DaemonSet Controller。
- Scheduler:是用来做资源调度的,Controller Manager会把任务对资源要求,其实就是Pod,写入到ETCD里面,Scheduler监听到有新的资源需要调度(新的Pod),就会根据整个集群的状态,给Pod分配到具体的节点上。
- Kubelet:是一个Agent,运行在每一个节点上,它会监听ETCD中的Pod信息,发现有分配给它所在节点的Pod需要运行,就在节点上运行相应的Pod,并且把状态更新回到ETCD。
- Kubectl: 是一个命令行工具,它会调用 API Server发送请求写入状态到ETCD,或者查询ETCD的状态。
如果还觉得不清楚,我们就用部署服务的例子来解释一下整个过程。假设要运行一个多实例的Nginx,在Kubernetes内部,整个流程是这样的:
1.通过kubectl命令行,创建一个包含Nginx的Deployment对象,kubectl会调用 API Server 往ETCD里面写入一个 Deployment对象。
2.Deployment Controller 监听到有新的 Deployment对象被写入,就获取到对象信息,根据对象信息来做任务调度,创建对应的 Replica Set 对象。
3.Replica Set Controller监听到有新的对象被创建,也读取到对象信息来做任务调度,创建对应的Pod来。
4.Scheduler 监听到有新的 Pod 被创建,读取到Pod对象信息,根据集群状态将Pod调度到某一个节点上,然后更新Pod(内部操作是将Pod和节点绑定)。
5.Kubelet 监听到当前的节点被指定了新的Pod,就根据对象信息运行Pod。
这就是Kubernetes内部如何实现整个 Deployment 被创建的过程。这个过程只是为了向大家解释每一个组件的职责,以及他们之间是如何相互协作的,忽略掉了一些繁琐的细节。
目前为止,我们有已经研究过几个非常有代表性的调度系统:Hadoop MRv1、YARN、Mesos和Kubernetes。当时学习完这些调度系统的架构后,脑子里面形成2个大大的疑问:
1.Kubernetes是二次调度的架构么?和Mesos相比它的扩展性如何?
2.为什么所有调度系统都是无法横向扩展的?
后面我们就针对这两个问题深入讨论一下。
Kubernetes 是否是二层调度?
在 Google 的一篇关于内部 Omega 调度系统的论文中,将调度系统分成三类:单体、二层调度和共享状态三种,按照它的分类方法,通常Google的 Borg被分到单体这一类,Mesos被当做二层调度,而Google自己的Omega被当做第三类“共享状态”。
论文的作者实际上之前也是Mesos的设计者之一,后来去了Google设计新的 Omega 系统,并发表了论文,论文的主要目的是提出一种全新的“Shard State”的模式,来同时解决调度系统的性能和扩展性问题。但我觉得 Shared State 模型太过理想化,根据这个模型开发的Omega系统,似乎在Google内部并没有被大规模使用,也没有任何一个大规模使用的调度系统采用 Shared State 模型。
因为Kubernetes的大部分设计是延续 Borg的,而且Kubernetes的核心组件(Controller Manager和Scheduler)缺省也都是绑定部署在一起,状态也都是存储在ETCD里面的,所以通常大家会把Kubernetes也当做“单体”调度系统,实际上我并不赞同。
我认为 Kubernetes 的调度模型也完全是二层调度的,和 Mesos 一样,任务调度和资源的调度是完全分离的,Controller Manager承担任务调度的职责,而Scheduler则承担资源调度的职责。
实际上Kubernetes和Mesos调度的最大区别在于资源调度请求的方式:
- 主动 Push 方式。是 Mesos 采用的方式,就是 Mesos 的资源调度组件(Mesos Master)主动推送资源 Offer 给 Framework,Framework 不能主动请求资源,只能根据 Offer 的信息来决定接受或者拒绝。
- 被动 Pull 方式。是 Kubernetes 的方式,资源调度组件 Scheduler 被动的响应 Controller Manager的资源请求。
这两种方式带来的不同,我主要从一下 5 个方面来分析。另外注意,我所比较两者的优劣,都是从理论上做的分析,工程实现上会有差异,一些指标我也并没有实际测试过。
1.资源利用率:Kubernetes 胜出
理论上,Kubernetes 应该能实现更加高效的集群资源利用率,原因资源调度的职责完全是由Scheduler一个组件来完成的,它有充足的信息能够从全局来调配资源,然后而Mesos 却做不到,因为资源调度的职责被切分到Framework和Mesos Master两个组件上,Framework 在挑选 Offer 的时候,完全没有其他 Framework 工作负载的信息,所以也不可能做出最优的决策。
举个例子,比如我们希望把对耗费 CPU的工作负载和耗费内存的工作负载尽可能调度到同一台主机上,在Mesos里面不太容易做到,因为他们分属不同的 Framework。
2.扩展性:Mesos胜出
从理论上讲,Mesos 的扩展性要更好一点。原因是Mesos的资源调度方式更容易让已经存在的任务调度迁移上来。举个例子,假设已经有了一个任务调度系统,比如 Spark,现在要迁移到集群调度平台上,理论上它迁移到 Mesos 比 Kubernetes 上更加容易。
如果迁移到 Mesos ,没有改变原来的工作流程和逻辑,原来的逻辑是:来了一个作业请求,调度系统把任务拆分成小的任务,然后从资源池里面挑选一个节点来运行任务,并且记录挑选的节点 IP 和端口号,用来跟踪任务的状态。迁移到 Mesos 之后,还是一样的逻辑,唯一需要变化的是那个资源池,原来是自己管理的资源池,现在变成 Mesos 提供的Offer 列表。
如果迁移到 Kubernetes,则需要修改原来的基本逻辑来适配 Kubernetes,资源的调度完全需要调用外部的组件来完成,并且这个变成异步的。
3.灵活的任务调度策略:Mesos 胜出
Mesos 对各种任务的调度策略也支持的更好。举个例子,如果某一个作业,需要 All or Nothing 的策略,Mesos 是能够实现的,但是 Kubernetes 完全无法支持。所以All or Nothing 的意思是,价格整个作业如果需要运行 10 个任务,这 10个任务需要能够全部有资源开始执行,否则就一个都不执行。
4.性能:Mesos 胜出
Mesos 的性能应该更好,因为资源调度组件,也就是 Mesos Master 把一部分资源调度的工作甩给 Framework了,承担的调度工作更加简单,从数据来看也是这样,在多年之前 Twitter 自己的 Mesos 集群就能够管理超过 8万个节点,而 Kubernetes 1.3 只能支持 5千个节点。
5.调度延迟:Kubernetes 胜出
Kubernetes调度延迟会更好。因为Mesos的轮流给Framework提供Offer机制,导致会浪费很多时间在给不需要资源的 Framework 提供Offer。
为什么不支持横向扩展?
可能大家已经注意到了,几乎所有的集群调度系统都无法横向扩展(Scale Out),比如早期的 Hadoop MRv1 的管理节点是单节点,管理的集群上限是 5000 台机器,YARN 资源管理节点同时也只能有一个节点工作,其他都是备份节点,能够管理的机器的上限1万个节点,Mesos通过优化,一个集群能够管理 8 万个节点,Kubernetes 目前的 1.13 版本,集群管理节点的上限是 5000 个节点。
所有的集群调度系统的架构都是无法横向扩展的,如果需要管理更多的服务器,唯一的办法就是创建多个集群。集群调度系统的架构看起来都是这个样子的:
中间的 Scheduler(资源调度器)是最核心的组件,虽然通常是由多个(通常是3个)实例组成,但是都是单活的,也就是说只有一个节点工作,其他节点都处于 Standby 的状态。为什么会这样呢?看起来不符合互联网应用的架构设计原则,现在大部分互联网的应用通过一些分布式的技术,能够很容易的实现横向扩展,比如电商应用,促销时,通过往集群里面添加服务器,就能够提升服务的吞吐量。如果是按照互联网应用的架构,看起来应该是这样的:
Scheduler 应该是可以多活的,有任意多的实例一起对外提供服务,无论是资源的消费者,还是资源的提供者在访问 Scheduler 的时候,都需要经过一个负载均衡的组件或者设备,负责把请求分配给某一个 Scheduler 实例。为什么这种架构在集群调度系统里面变得不可行么?为了理解这件事情,我们先通过一个互联网应用的架构的例子,来探讨一下具备横向扩展需要哪些前提条件。
横向扩展架构的前提条件
假设我们要实现这样一个电商系统:
1.这是一个二手书的交易平台,有非常多的卖家在平台上提供二手书,我们暂且把每一本二手书叫做库存;
2.卖家的每一个二手书库存,根据书的条码,都可以找到图书目录中一本书,我们把这本书叫做商品;
3.卖家在录入二手书库存的时候,除了录入是属于哪一个商品,同时还需要录入其他信息,比如新旧程度、价钱、发货地址等等。
4.买家浏览图书目录,选中一本书,然后下单,订单系统根据买家的要求(价格偏好、送货地址等),用算法从这本书背后的所有二手书库存中,匹配一本符合要求的书完成匹配,我们把这个过程叫订单匹配好了。
这样一个系统,从模型上看这个电商系统和集群调度系统没啥区别,这个里面有资源提供者(卖家),提供某种资源(二手书),组成一个资源池(所有二手书),也有资源消费者(买家),提交自己对资源的需求,然后资源调度器(订单系统)根据算法自动匹配一个资源(一本二手书)。
但是很显然,这个电商系统是可以设计成横向扩展架构的,为什么呢?这个电商系统和集群调度系统的区别到底在什么地方? 在回答这个问题之前,我们先来回答另外一个问题:这个电商系统横向扩展的节点数是否有上限,上限是多少,这个上限是有什么因素决定的?
系统理论上的并发数量决定了横向扩展的节点数
假设系统架构设计的时候,不考虑任何物理限制(比如机器的资源大小,带宽等),能够并发处理 1000个请求,那么很显然,横向扩展的节点数量上限就是1000,因为就算部署了 1001个节点,在任何时候都有一个节点是处于空闲状态,部署更多的节点已经完全无法提高系统的性能。我们下面需要想清楚的问题其实就变成了:系统理论上能够并发处理请求的数量是多少,是有什么因素决定的。
系统的并发数量是由“独立资源池”的数量决定的
“独立资源池”是我自己造出来的一个词,因为实在想不到更加合适的。还是以上面的电商系统为例,这个订单系统的理论上能够处理的并发请求(订购商品请求)数量是由什么来决定的呢?先看下面的图:
在订单系统在匹配需求的时候,实际上应该是这样运行的,在订单请求来了之后,根据订单请求中的购买的商品来排队,购买同一个商品的请求被放在一个队列里面,然后订单的调度系统开始从队列里面依次处理请求,每次做订单匹配的时候,都需根据当前商品的所有库存,从里面挑选一个最佳匹配的库存。
虽然在实现这个系统的时候,这个队列不见得是一个消息队列,可能会是一个关系型数据库的锁,比如一个购买《乔布斯传》的订单,系统在处理的时候需要先从所有库存里面查询出《乔布斯传》的库存,将库存记录锁住,并做订单匹配且更新库存(将生成订单的库存商品设置为”不可用”状态)之后,才会将数据库锁释放,这时候所有后续购买《乔布斯传》的订单请求都在队列中等待。
也有些系统在实现的时候采用“乐观锁”,就是每次订单处理时,并不会在一开始就锁住库存信息,而是在最后一步更新库存的时候才会锁住,如果发生两个订单匹配到了同一个库存物品,那么其中一个订单处理就需要完全放弃然后重试。这两种实现方式不太一样,但是本质都是相同的。
所以从上面的讨论可以看出来,之所以所有购买《乔布斯传》的订单需要排队处理,是因为每一次做订单匹配的时候,需要《乔布斯传》这个商品的所有库存信息,并且最后会修改(占用)一部分库存信息的状态。在该订单匹配的场景里面,我们就把《乔布斯传》的所有库存信息叫做一个“独立资源池”,订单匹配这个“调度系统”的最大并发数量就完全取决于独立资源池的数量,也就是商品的数量。我们假设一下,如果这个二手书的商城只卖《乔布斯传》一本书,那么最后所有的请求都需要排队,这个系统也几乎是无法横向扩展的。
集群调度系统的“独立资源池”数量是 1
我们再来看一下集群调度系统,每一台服务器节点都是一个资源,每当资源消费者请求资源的时候,调度系统用来做调度算法的“独立资源池”是多大呢?答案应该是整个集群的资源组成的资源池,没有办法在切分了,因为:
1.调度系统的职责就是要在全局内找到最优的资源匹配。
2.另外,哪怕不需要找到最优的资源匹配,资源调度器对每一次资源请求,也没办法判断应该从哪一部分资源池中挑选资源。
正是因为这个原因,“独立资源池”数量是 1,所以集群调度系统无法做到横向扩展。