摘要：目前為止，我們有已經(jīng)研究過幾個(gè)非常有代表性的調(diào)度系統(tǒng)和。當(dāng)時(shí)學(xué)習(xí)完這些調(diào)度系統(tǒng)的架構(gòu)后，腦子里面形成個(gè)大大的疑問是二次調(diào)度的架構(gòu)么和相比它的擴(kuò)展性如何為什么所有調(diào)度系統(tǒng)都是無法橫向擴(kuò)展的后面我們就針對這兩個(gè)問題深入討論一下。

小編序：
在上周發(fā)布的《從“鴻溝理論”看云原生，哪些技術(shù)能夠跨越鴻溝？》一文中，靈雀云CTO陳愷表示：Kubernetes在云計(jì)算領(lǐng)域已經(jīng)成為既定標(biāo)準(zhǔn)，進(jìn)入主流市場，最新版本主要關(guān)注在穩(wěn)定性、可擴(kuò)展性方面，在開發(fā)人員中變得非常流行。Kubernetes會(huì)越來越多往下管理所有基礎(chǔ)設(shè)施，往上管理所有種類的應(yīng)用。我們會(huì)看到，越來越多的周邊技術(shù)向它靠攏，在其之上催化出一個(gè)龐大的云原生技術(shù)生態(tài)。

那么，現(xiàn)在最新最流行的 Kubernetes 架構(gòu)是什么樣子呢？本文給大家介紹一下 Kubernetes 整體架構(gòu)，并深入探討其中 2 個(gè)比較關(guān)鍵的問題。

Kubernetes 架構(gòu)解析

首先，Kubernetes 的官方架構(gòu)圖是這樣的：

這個(gè)架構(gòu)圖看起來會(huì)比較復(fù)雜，很難看懂，我把這個(gè)官方的架構(gòu)圖重新簡化了一下，就會(huì)非常容易理解了：

ETCD ：是用來存儲(chǔ)所有 Kubernetes 的集群狀態(tài)的，它除了具備狀態(tài)存儲(chǔ)的功能，還有事件監(jiān)聽和訂閱、Leader選舉的功能，所謂事件監(jiān)聽和訂閱，各個(gè)其他組件通信，都并不是互相調(diào)用 API 來完成的，而是把狀態(tài)寫入 ETCD（相當(dāng)于寫入一個(gè)消息），其他組件通過監(jiān)聽 ETCD 的狀態(tài)的的變化（相當(dāng)于訂閱消息），然后做后續(xù)的處理，然后再一次把更新的數(shù)據(jù)寫入 ETCD。所謂 Leader 選舉，其它一些組件比如 Scheduler，為了做實(shí)現(xiàn)高可用，通過 ETCD 從多個(gè)（通常是3個(gè)）實(shí)例里面選舉出來一個(gè)做Master，其他都是Standby。

API Server：剛才說了 ETCD 是整個(gè)系統(tǒng)的最核心，所有組件之間通信都需要通過 ETCD，實(shí)際上，他們并不是直接訪問 ETCD，而是訪問一個(gè)代理，這個(gè)代理是通過標(biāo)準(zhǔn)的RESTFul API，重新封裝了對 ETCD 接口調(diào)用，除此之外，這個(gè)代理還實(shí)現(xiàn)了一些附加功能，比如身份的認(rèn)證、緩存等。這個(gè)代理就是 API Server。

Controller Manager：是實(shí)現(xiàn)任務(wù)調(diào)度的，關(guān)于任務(wù)調(diào)度可以參考之前的文章，簡單說，直接請求 Kubernetes 做調(diào)度的都是任務(wù)，比如 Deployment 、Deamon Set 或者 Job，每一個(gè)任務(wù)請求發(fā)送給Kubernetes之后，都是由Controller Manager來處理的，每一個(gè)任務(wù)類型對應(yīng)一個(gè)Controller Manager，比如 Deployment對應(yīng)一個(gè)叫做 Deployment Controller，DaemonSet 對應(yīng)一個(gè) DaemonSet Controller。

Scheduler：是用來做資源調(diào)度的，Controller Manager會(huì)把任務(wù)對資源要求，其實(shí)就是Pod，寫入到ETCD里面，Scheduler監(jiān)聽到有新的資源需要調(diào)度（新的Pod），就會(huì)根據(jù)整個(gè)集群的狀態(tài)，給Pod分配到具體的節(jié)點(diǎn)上。

Kubelet：是一個(gè)Agent，運(yùn)行在每一個(gè)節(jié)點(diǎn)上，它會(huì)監(jiān)聽ETCD中的Pod信息，發(fā)現(xiàn)有分配給它所在節(jié)點(diǎn)的Pod需要運(yùn)行，就在節(jié)點(diǎn)上運(yùn)行相應(yīng)的Pod，并且把狀態(tài)更新回到ETCD。

Kubectl: 是一個(gè)命令行工具，它會(huì)調(diào)用 API Server發(fā)送請求寫入狀態(tài)到ETCD，或者查詢ETCD的狀態(tài)。

如果還覺得不清楚，我們就用部署服務(wù)的例子來解釋一下整個(gè)過程。假設(shè)要運(yùn)行一個(gè)多實(shí)例的Nginx，在Kubernetes內(nèi)部，整個(gè)流程是這樣的：

1.通過kubectl命令行，創(chuàng)建一個(gè)包含Nginx的Deployment對象，kubectl會(huì)調(diào)用 API Server 往ETCD里面寫入一個(gè) Deployment對象。

2.Deployment Controller 監(jiān)聽到有新的 Deployment對象被寫入，就獲取到對象信息，根據(jù)對象信息來做任務(wù)調(diào)度，創(chuàng)建對應(yīng)的 Replica Set 對象。

3.Replica Set Controller監(jiān)聽到有新的對象被創(chuàng)建，也讀取到對象信息來做任務(wù)調(diào)度，創(chuàng)建對應(yīng)的Pod來。

4.Scheduler 監(jiān)聽到有新的 Pod 被創(chuàng)建，讀取到Pod對象信息，根據(jù)集群狀態(tài)將Pod調(diào)度到某一個(gè)節(jié)點(diǎn)上，然后更新Pod（內(nèi)部操作是將Pod和節(jié)點(diǎn)綁定）。

5.Kubelet 監(jiān)聽到當(dāng)前的節(jié)點(diǎn)被指定了新的Pod，就根據(jù)對象信息運(yùn)行Pod。

這就是Kubernetes內(nèi)部如何實(shí)現(xiàn)整個(gè) Deployment 被創(chuàng)建的過程。這個(gè)過程只是為了向大家解釋每一個(gè)組件的職責(zé)，以及他們之間是如何相互協(xié)作的，忽略掉了一些繁瑣的細(xì)節(jié)。

目前為止，我們有已經(jīng)研究過幾個(gè)非常有代表性的調(diào)度系統(tǒng)：Hadoop MRv1、YARN、Mesos和Kubernetes。當(dāng)時(shí)學(xué)習(xí)完這些調(diào)度系統(tǒng)的架構(gòu)后，腦子里面形成2個(gè)大大的疑問：

1.Kubernetes是二次調(diào)度的架構(gòu)么？和Mesos相比它的擴(kuò)展性如何？

2.為什么所有調(diào)度系統(tǒng)都是無法橫向擴(kuò)展的？

后面我們就針對這兩個(gè)問題深入討論一下。

Kubernetes 是否是二層調(diào)度？

在 Google 的一篇關(guān)于內(nèi)部 Omega 調(diào)度系統(tǒng)的論文中，將調(diào)度系統(tǒng)分成三類：單體、二層調(diào)度和共享狀態(tài)三種，按照它的分類方法，通常Google的 Borg被分到單體這一類，Mesos被當(dāng)做二層調(diào)度，而Google自己的Omega被當(dāng)做第三類“共享狀態(tài)”。

論文的作者實(shí)際上之前也是Mesos的設(shè)計(jì)者之一，后來去了Google設(shè)計(jì)新的 Omega 系統(tǒng)，并發(fā)表了論文，論文的主要目的是提出一種全新的“Shard State”的模式，來同時(shí)解決調(diào)度系統(tǒng)的性能和擴(kuò)展性問題。但我覺得 Shared State 模型太過理想化，根據(jù)這個(gè)模型開發(fā)的Omega系統(tǒng)，似乎在Google內(nèi)部并沒有被大規(guī)模使用，也沒有任何一個(gè)大規(guī)模使用的調(diào)度系統(tǒng)采用 Shared State 模型。

因?yàn)镵ubernetes的大部分設(shè)計(jì)是延續(xù) Borg的，而且Kubernetes的核心組件（Controller Manager和Scheduler）缺省也都是綁定部署在一起，狀態(tài)也都是存儲(chǔ)在ETCD里面的，所以通常大家會(huì)把Kubernetes也當(dāng)做“單體”調(diào)度系統(tǒng)，實(shí)際上我并不贊同。

我認(rèn)為 Kubernetes 的調(diào)度模型也完全是二層調(diào)度的，和 Mesos 一樣，任務(wù)調(diào)度和資源的調(diào)度是完全分離的，Controller Manager承擔(dān)任務(wù)調(diào)度的職責(zé)，而Scheduler則承擔(dān)資源調(diào)度的職責(zé)。

實(shí)際上Kubernetes和Mesos調(diào)度的最大區(qū)別在于資源調(diào)度請求的方式：

主動(dòng) Push 方式。是 Mesos 采用的方式，就是 Mesos 的資源調(diào)度組件（Mesos Master）主動(dòng)推送資源 Offer 給 Framework，F(xiàn)ramework 不能主動(dòng)請求資源，只能根據(jù) Offer 的信息來決定接受或者拒絕。

被動(dòng) Pull 方式。是 Kubernetes 的方式，資源調(diào)度組件 Scheduler 被動(dòng)的響應(yīng) Controller Manager的資源請求。

這兩種方式帶來的不同，我主要從一下 5 個(gè)方面來分析。另外注意，我所比較兩者的優(yōu)劣，都是從理論上做的分析，工程實(shí)現(xiàn)上會(huì)有差異，一些指標(biāo)我也并沒有實(shí)際測試過。

1.資源利用率：Kubernetes 勝出

理論上，Kubernetes 應(yīng)該能實(shí)現(xiàn)更加高效的集群資源利用率，原因資源調(diào)度的職責(zé)完全是由Scheduler一個(gè)組件來完成的，它有充足的信息能夠從全局來調(diào)配資源，然后而Mesos 卻做不到，因?yàn)橘Y源調(diào)度的職責(zé)被切分到Framework和Mesos Master兩個(gè)組件上，F(xiàn)ramework 在挑選 Offer 的時(shí)候，完全沒有其他 Framework 工作負(fù)載的信息，所以也不可能做出最優(yōu)的決策。

舉個(gè)例子，比如我們希望把對耗費(fèi) CPU的工作負(fù)載和耗費(fèi)內(nèi)存的工作負(fù)載盡可能調(diào)度到同一臺(tái)主機(jī)上，在Mesos里面不太容易做到，因?yàn)樗麄兎謱俨煌?Framework。

2.擴(kuò)展性：Mesos勝出

從理論上講，Mesos 的擴(kuò)展性要更好一點(diǎn)。原因是Mesos的資源調(diào)度方式更容易讓已經(jīng)存在的任務(wù)調(diào)度遷移上來。舉個(gè)例子，假設(shè)已經(jīng)有了一個(gè)任務(wù)調(diào)度系統(tǒng)，比如 Spark，現(xiàn)在要遷移到集群調(diào)度平臺(tái)上，理論上它遷移到 Mesos 比 Kubernetes 上更加容易。

如果遷移到 Mesos ，沒有改變原來的工作流程和邏輯，原來的邏輯是：來了一個(gè)作業(yè)請求，調(diào)度系統(tǒng)把任務(wù)拆分成小的任務(wù)，然后從資源池里面挑選一個(gè)節(jié)點(diǎn)來運(yùn)行任務(wù)，并且記錄挑選的節(jié)點(diǎn) IP 和端口號(hào)，用來跟蹤任務(wù)的狀態(tài)。遷移到 Mesos 之后，還是一樣的邏輯，唯一需要變化的是那個(gè)資源池，原來是自己管理的資源池，現(xiàn)在變成 Mesos 提供的Offer 列表。

如果遷移到 Kubernetes，則需要修改原來的基本邏輯來適配 Kubernetes，資源的調(diào)度完全需要調(diào)用外部的組件來完成，并且這個(gè)變成異步的。

3.靈活的任務(wù)調(diào)度策略：Mesos 勝出

Mesos 對各種任務(wù)的調(diào)度策略也支持的更好。舉個(gè)例子，如果某一個(gè)作業(yè)，需要 All or Nothing 的策略，Mesos 是能夠?qū)崿F(xiàn)的，但是 Kubernetes 完全無法支持。所以All or Nothing 的意思是，價(jià)格整個(gè)作業(yè)如果需要運(yùn)行 10 個(gè)任務(wù)，這 10個(gè)任務(wù)需要能夠全部有資源開始執(zhí)行，否則就一個(gè)都不執(zhí)行。

4.性能：Mesos 勝出

Mesos 的性能應(yīng)該更好，因?yàn)橘Y源調(diào)度組件，也就是 Mesos Master 把一部分資源調(diào)度的工作甩給 Framework了，承擔(dān)的調(diào)度工作更加簡單，從數(shù)據(jù)來看也是這樣，在多年之前 Twitter 自己的 Mesos 集群就能夠管理超過 8萬個(gè)節(jié)點(diǎn)，而 Kubernetes 1.3 只能支持 5千個(gè)節(jié)點(diǎn)。

5.調(diào)度延遲：Kubernetes 勝出

Kubernetes調(diào)度延遲會(huì)更好。因?yàn)镸esos的輪流給Framework提供Offer機(jī)制，導(dǎo)致會(huì)浪費(fèi)很多時(shí)間在給不需要資源的 Framework 提供Offer。

為什么不支持橫向擴(kuò)展？

可能大家已經(jīng)注意到了，幾乎所有的集群調(diào)度系統(tǒng)都無法橫向擴(kuò)展（Scale Out），比如早期的 Hadoop MRv1 的管理節(jié)點(diǎn)是單節(jié)點(diǎn)，管理的集群上限是 5000 臺(tái)機(jī)器，YARN 資源管理節(jié)點(diǎn)同時(shí)也只能有一個(gè)節(jié)點(diǎn)工作，其他都是備份節(jié)點(diǎn)，能夠管理的機(jī)器的上限1萬個(gè)節(jié)點(diǎn)，Mesos通過優(yōu)化，一個(gè)集群能夠管理 8 萬個(gè)節(jié)點(diǎn)，Kubernetes 目前的 1.13 版本，集群管理節(jié)點(diǎn)的上限是 5000 個(gè)節(jié)點(diǎn)。

所有的集群調(diào)度系統(tǒng)的架構(gòu)都是無法橫向擴(kuò)展的，如果需要管理更多的服務(wù)器，唯一的辦法就是創(chuàng)建多個(gè)集群。集群調(diào)度系統(tǒng)的架構(gòu)看起來都是這個(gè)樣子的：

中間的 Scheduler（資源調(diào)度器）是最核心的組件，雖然通常是由多個(gè)（通常是3個(gè)）實(shí)例組成，但是都是單活的，也就是說只有一個(gè)節(jié)點(diǎn)工作，其他節(jié)點(diǎn)都處于 Standby 的狀態(tài)。為什么會(huì)這樣呢？看起來不符合互聯(lián)網(wǎng)應(yīng)用的架構(gòu)設(shè)計(jì)原則，現(xiàn)在大部分互聯(lián)網(wǎng)的應(yīng)用通過一些分布式的技術(shù)，能夠很容易的實(shí)現(xiàn)橫向擴(kuò)展，比如電商應(yīng)用，促銷時(shí)，通過往集群里面添加服務(wù)器，就能夠提升服務(wù)的吞吐量。如果是按照互聯(lián)網(wǎng)應(yīng)用的架構(gòu)，看起來應(yīng)該是這樣的：

Scheduler 應(yīng)該是可以多活的，有任意多的實(shí)例一起對外提供服務(wù)，無論是資源的消費(fèi)者，還是資源的提供者在訪問 Scheduler 的時(shí)候，都需要經(jīng)過一個(gè)負(fù)載均衡的組件或者設(shè)備，負(fù)責(zé)把請求分配給某一個(gè) Scheduler 實(shí)例。為什么這種架構(gòu)在集群調(diào)度系統(tǒng)里面變得不可行么？為了理解這件事情，我們先通過一個(gè)互聯(lián)網(wǎng)應(yīng)用的架構(gòu)的例子，來探討一下具備橫向擴(kuò)展需要哪些前提條件。

橫向擴(kuò)展架構(gòu)的前提條件

假設(shè)我們要實(shí)現(xiàn)這樣一個(gè)電商系統(tǒng)：

1.這是一個(gè)二手書的交易平臺(tái)，有非常多的賣家在平臺(tái)上提供二手書，我們暫且把每一本二手書叫做庫存；

2.賣家的每一個(gè)二手書庫存，根據(jù)書的條碼，都可以找到圖書目錄中一本書，我們把這本書叫做商品；

3.賣家在錄入二手書庫存的時(shí)候，除了錄入是屬于哪一個(gè)商品，同時(shí)還需要錄入其他信息，比如新舊程度、價(jià)錢、發(fā)貨地址等等。

4.買家瀏覽圖書目錄，選中一本書，然后下單，訂單系統(tǒng)根據(jù)買家的要求（價(jià)格偏好、送貨地址等），用算法從這本書背后的所有二手書庫存中，匹配一本符合要求的書完成匹配，我們把這個(gè)過程叫訂單匹配好了。

這樣一個(gè)系統(tǒng)，從模型上看這個(gè)電商系統(tǒng)和集群調(diào)度系統(tǒng)沒啥區(qū)別，這個(gè)里面有資源提供者（賣家），提供某種資源（二手書），組成一個(gè)資源池（所有二手書），也有資源消費(fèi)者（買家），提交自己對資源的需求，然后資源調(diào)度器（訂單系統(tǒng)）根據(jù)算法自動(dòng)匹配一個(gè)資源（一本二手書）。

但是很顯然，這個(gè)電商系統(tǒng)是可以設(shè)計(jì)成橫向擴(kuò)展架構(gòu)的，為什么呢？這個(gè)電商系統(tǒng)和集群調(diào)度系統(tǒng)的區(qū)別到底在什么地方？ 在回答這個(gè)問題之前，我們先來回答另外一個(gè)問題：這個(gè)電商系統(tǒng)橫向擴(kuò)展的節(jié)點(diǎn)數(shù)是否有上限，上限是多少，這個(gè)上限是有什么因素決定的？

系統(tǒng)理論上的并發(fā)數(shù)量決定了橫向擴(kuò)展的節(jié)點(diǎn)數(shù)

假設(shè)系統(tǒng)架構(gòu)設(shè)計(jì)的時(shí)候，不考慮任何物理限制（比如機(jī)器的資源大小，帶寬等），能夠并發(fā)處理 1000個(gè)請求，那么很顯然，橫向擴(kuò)展的節(jié)點(diǎn)數(shù)量上限就是1000，因?yàn)榫退悴渴鹆?1001個(gè)節(jié)點(diǎn)，在任何時(shí)候都有一個(gè)節(jié)點(diǎn)是處于空閑狀態(tài)，部署更多的節(jié)點(diǎn)已經(jīng)完全無法提高系統(tǒng)的性能。我們下面需要想清楚的問題其實(shí)就變成了：系統(tǒng)理論上能夠并發(fā)處理請求的數(shù)量是多少，是有什么因素決定的。

系統(tǒng)的并發(fā)數(shù)量是由“獨(dú)立資源池”的數(shù)量決定的

“獨(dú)立資源池”是我自己造出來的一個(gè)詞，因?yàn)閷?shí)在想不到更加合適的。還是以上面的電商系統(tǒng)為例，這個(gè)訂單系統(tǒng)的理論上能夠處理的并發(fā)請求（訂購商品請求）數(shù)量是由什么來決定的呢？先看下面的圖：

在訂單系統(tǒng)在匹配需求的時(shí)候，實(shí)際上應(yīng)該是這樣運(yùn)行的，在訂單請求來了之后，根據(jù)訂單請求中的購買的商品來排隊(duì)，購買同一個(gè)商品的請求被放在一個(gè)隊(duì)列里面，然后訂單的調(diào)度系統(tǒng)開始從隊(duì)列里面依次處理請求，每次做訂單匹配的時(shí)候，都需根據(jù)當(dāng)前商品的所有庫存，從里面挑選一個(gè)最佳匹配的庫存。

雖然在實(shí)現(xiàn)這個(gè)系統(tǒng)的時(shí)候，這個(gè)隊(duì)列不見得是一個(gè)消息隊(duì)列，可能會(huì)是一個(gè)關(guān)系型數(shù)據(jù)庫的鎖，比如一個(gè)購買《喬布斯傳》的訂單，系統(tǒng)在處理的時(shí)候需要先從所有庫存里面查詢出《喬布斯傳》的庫存，將庫存記錄鎖住，并做訂單匹配且更新庫存（將生成訂單的庫存商品設(shè)置為”不可用”狀態(tài)）之后，才會(huì)將數(shù)據(jù)庫鎖釋放，這時(shí)候所有后續(xù)購買《喬布斯傳》的訂單請求都在隊(duì)列中等待。

也有些系統(tǒng)在實(shí)現(xiàn)的時(shí)候采用“樂觀鎖”，就是每次訂單處理時(shí)，并不會(huì)在一開始就鎖住庫存信息，而是在最后一步更新庫存的時(shí)候才會(huì)鎖住，如果發(fā)生兩個(gè)訂單匹配到了同一個(gè)庫存物品，那么其中一個(gè)訂單處理就需要完全放棄然后重試。這兩種實(shí)現(xiàn)方式不太一樣，但是本質(zhì)都是相同的。

所以從上面的討論可以看出來，之所以所有購買《喬布斯傳》的訂單需要排隊(duì)處理，是因?yàn)槊恳淮巫鲇唵纹ヅ涞臅r(shí)候，需要《喬布斯傳》這個(gè)商品的所有庫存信息，并且最后會(huì)修改（占用）一部分庫存信息的狀態(tài)。在該訂單匹配的場景里面，我們就把《喬布斯傳》的所有庫存信息叫做一個(gè)“獨(dú)立資源池”，訂單匹配這個(gè)“調(diào)度系統(tǒng)”的最大并發(fā)數(shù)量就完全取決于獨(dú)立資源池的數(shù)量，也就是商品的數(shù)量。我們假設(shè)一下，如果這個(gè)二手書的商城只賣《喬布斯傳》一本書，那么最后所有的請求都需要排隊(duì)，這個(gè)系統(tǒng)也幾乎是無法橫向擴(kuò)展的。

集群調(diào)度系統(tǒng)的“獨(dú)立資源池”數(shù)量是 1

我們再來看一下集群調(diào)度系統(tǒng)，每一臺(tái)服務(wù)器節(jié)點(diǎn)都是一個(gè)資源，每當(dāng)資源消費(fèi)者請求資源的時(shí)候，調(diào)度系統(tǒng)用來做調(diào)度算法的“獨(dú)立資源池”是多大呢？答案應(yīng)該是整個(gè)集群的資源組成的資源池，沒有辦法在切分了，因?yàn)?

1.調(diào)度系統(tǒng)的職責(zé)就是要在全局內(nèi)找到最優(yōu)的資源匹配。

2.另外，哪怕不需要找到最優(yōu)的資源匹配，資源調(diào)度器對每一次資源請求，也沒辦法判斷應(yīng)該從哪一部分資源池中挑選資源。

正是因?yàn)檫@個(gè)原因，“獨(dú)立資源池”數(shù)量是 1，所以集群調(diào)度系統(tǒng)無法做到橫向擴(kuò)展。