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

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

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

Kubernetes 架構(gòu)解析

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

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

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

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

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

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

Kubelet：是一個Agent，運(yùn)行在每一個節(jié)點(diǎn)上，它會監(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: 是一個命令行工具，它會調(diào)用 API Server發(fā)送請求寫入狀態(tài)到ETCD，或者查詢ETCD的狀態(tài)。

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

1.通過kubectl命令行，創(chuàng)建一個包含Nginx的Deployment對象，kubectl會調(diào)用 API Server 往ETCD里面寫入一個 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)度到某一個節(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)整個 Deployment 被創(chuàng)建的過程。這個過程只是為了向大家解釋每一個組件的職責(zé)，以及他們之間是如何相互協(xié)作的，忽略掉了一些繁瑣的細(xì)節(jié)。

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

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

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

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

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

因?yàn)镵ubernetes的大部分設(shè)計是延續(xù) Borg的，而且Kubernetes的核心組件（Controller Manager和Scheduler）缺省也都是綁定部署在一起，狀態(tài)也都是存儲在ETCD里面的，所以通常大家會把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)度請求的方式：

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

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

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

1.資源利用率：Kubernetes 勝出

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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