近日，OpenStack基金會宣佈了第九次用戶調查結果。 OpenStack用戶調查是迄今爲止全球

4月22日，由K8S技術社區、Linux中國聯合主辦的K8S GeekGathering 2017吸引了國內容器領域關注者100+人到場參與，如下是IBM 軟件架構師馬達的演講實錄整理：

IBM 軟件架構師馬達

你們好，我今天分享的主題是資源管理和資源調度，我所在的是IBM，CSL，咱們作分佈式資源管理，分佈式資源調度，從大概九幾年就作了，國際的投行，包括一些產品，迪斯尼作模擬的時候也用了咱們的產品，咱們主要作的是在資源管理和資源調度這塊，咱們會把好多的數據用在裏面，主要在K8S流程這塊作得多一些。

1

Kubernetes整體架構

這是目錄，K8S的主體架構，這是由於總體架構跟咱們後面看到的調度，包括和cmecsos的比較。1.7裏面會涉及到一些，包括以前百度同事講的如何多個資源共享，具體的尚未定，具體的多是DIF，寫出來就好了，咱們也但願各個廠商基於咱們定好的去作不一樣的調度，看一下整體架構，想說的是K8S有這麼多的，能夠發現，controller manage，他們總體圍繞kube apiserver，對不一樣的操做，kube apiserver，全部的東西都把數據寫在ITC裏面，跟咱們原來作的產品是不同的，包括cmecsos也是，對外拿不到空間和數據，咱們本身產品作的時候也是拿到。這裏看到K8S經過源數據驅動來作，這個帶來的好處是裏面的任何東西能夠被代替掉。

2

Kubernetes調度流程

這些東西均可以去掉，常常有人說K8S能夠像搭積木同樣建設你想要的平臺，最主要的一點是基於原數據驅動整個系統的運做。若是不想用這些，徹底能夠替掉。能夠經過kube controll去掉。可是你沒有它豐富的站點。因此這個時候，包括在社區裏面畫的時候。這個會經過API拿到斷定的做業，徹底能夠把它轉過去。這裏面數據至關於數據變動了，這時候相應的，好比說kubelet數據，因此基本是在api裏面的狀態，基本是按照共享數據作這樣的數據。

這是mesos的調度流程，咱們作的時候跟mesos比較像，這個調度的話，從下面到上面，這個是中間會有一些數據，這些數據你都不知道，你知道的都是內部數據，出去的時候是一套作的，這個事情對咱們來說，像咱們產品跟這個也是同樣的。有多個angent作這個事情，這個架構一旦定下來以後，你想改它，彼此的通訊協議是蠻複雜的事情，包括咱們下一代作交互的時候，由於咱們產品有將近20年的產品，包括從通信協議，都不太敢動。上層有不一樣的應用場景，對咱們來說是蠻大的差別。

如今來看K8S的結構好一點。如今咱們也不太肯定，因此這個只是一種模式的事情，剛纔說到流程，當你建立ctl的時候，這種架構其實有不少東西，當你建立ctl的時候，流程竟然什麼都沒有作，控制管理者就都作了，在每臺機器上建立一個pot，寫到這裏面，就有剛纔的邏輯作這個事情，你對單獨的ctl來講沒有什麼問題，可是你有其餘rc來講，你會發現，kube流程和管理者均可以調動這個資源。

1.7討論的時候，要把管理者調動的部分拿到流程來作。暫時作成單流程的東西。其實這裏涉及到另外的問題，一說調度的時候，不少人會把谷歌的那篇文章出來，告訴你三種調度的模型，如今來看，前兩種還有得玩，不管是調度也好，中性化也好，這個事情能夠作，能夠上生產線，咱們本身的產品有中性化的，這個東西都驗證過了，目前來看，沒有人真正能作出來，而且我在跟去年的時候跟谷歌聊過，那個項目在谷歌內部有被叫停了。

至少我我的提到一點是說當咱們如今兩個流程對整個集羣都有資源的使用權的時候，如今沒有最好的解決方案，當你的集羣規模比較大，請求比較複雜的時候，當你資源發過來的時候，會再檢查一遍，他們三個在一塊兒去操做那個基本元素的時候，對調度的蠻大，因此咱們在1.7的時候，大部分，要把ctl功能所有挪到流程裏面，會達到中性化的調度，讓他們倆作這件事情，可是中性化這個有一個問題，就是中性化流程會作得愈來愈複雜，並且這個流程作了不少比較，因此它的性能，會是個問題，剛纔咱們看到說有一個地方沒有特別細講，是在流程怎麼轉，就變成像一個從前到後跑一遍，全部的節點過完這一部分以後。

第二步關於作scheduler，這個你們如今沒開使用，基本是隻有幾個公司用，未來mesos會用，由於kub mesos有本身的資源，另外promit進來之後，會根據你的配置排序，選擇最高的node，再走剛纔的目標機器寫到這個裏面去。因此這個能作的，像這個會檢查你機器上有多少，image的大小是多少，把前五十個發上來，會在這裏作前五十個。比較經常使用的是這些多一些，在社區裏面看到他們對這個問題提得比較多。裏在多臺機器的時候，證實ICE比較穩定。

3

Kubernetes 1.6 （sig-scheduling, released）

K8S1.6作了四件事情，規則scheduler，把集羣中的pot劃組，這個scheduler能夠在裏面單獨調度，每一個scheduler走的流程仍是剛纔的流程，這裏也是涉及到剛纔的事情，scheduler調度的時候必定有那個衝突，可是那臺機器沒有資源了，最後用不了，如今這個衝突是在那個時候解決了，那個是最準的點，它也有權檢查全部的人，在那兒檢查有一點問題就是說好比作pot的affinty的時候，有問題，你是基於rank的，好比你這臺機器上有，這臺機器上有pod，你不知道其餘機器有沒有這個pod，因此你可能把它接受掉了，去年華爲人講了關於scheduler，他們想在那個作一些功能，作一些前期的檢測，有單點的控制，有集羣的資源和集羣的請求，在那點作成單點的控制，因此這是mart scheduler。

另外作得比較可能是把機器打成標籤，其餘人就不能用這臺機器了，就是這樣的一個功能，這塊還有一個事情是它分了scheduler等兩個階段，若是你打了這個標籤會把你這個東西殺掉，這個事情也跟taint tolerant，仍是走那套東西，再以後就加了一些code覆蓋。後面作得比較簡單的功能就是priority和preemption，還有batchjob，這個和以前的同事說的，基於他們倆的比較的模式，那種只能作成三個，這個能夠自定義多級的，好比priority，定義成多少個等級，在起來的時候，告訴你優先級多少，對RC來講好一點，對純Pod比較麻煩，對preemption，不會把整個的pod都刪除掉，這是一個增強。而後這塊的功能是經過這個作得比較多，那天來的時候，他們整個是基於priority作的。

另一個就是batchjob。咱們如今的K8S作資源劃分的時候，是靜態劃分，那個裏面有上限，你不能超，假設有兩個用戶，設裏兩個code，若是有一個已經超了，好比它自己想要請求一百個，可是你的code設成50，超不了，建立不出來，有另一個，另外50個徹底能夠給別人用。還有人說我把兩個的資源code超過，當超過了以後，彼此之間沒有比例，基本按照先服務，以前的經驗在用戶那兒作的時候，在這裏看到這是batchjob的概念，這裏面的object能夠填任何的東西，能夠寫本身的，能夠加crud的操做。

這個建立了之後，會有新的batchjob，會根據它的名字進入裏面，或者其餘的咱們本身有它的mds，這裏有另外的scheduler，如今想的是定義的能分到多少資源，這個資源分完之後能夠更新到configmap裏面去，當這個之後，是建立不出來的，因此這塊整個轉起來的時候，在這塊會有專門資源調度的功能，這個如今到最後作完以後，你會發現它除了K8S自己的功能之外，包含了像mesos的能力。這個案例也是在去年作的時候，谷歌和紅帽作了一個項目，在如今的功能都是說K8S給你幾個機器或者給你幾個pod，在那個裏面搭一個本身的就完了，不少人說是資源共享，不少資源以前的那個很難定義出來。

好比我給你十臺機器的空間，你很難保證它永遠跑得那麼滿，峯值可能不夠，這是資源調度解決的問題，那裏會有另一個問題，我能不能讓K8S做爲資源的管理者，不是簡單定死給你多少，這是簡單的觀點，這個會根據分給它的在這個基礎上分給它的資源建立，這塊的時候你會發現，當你有了framwork，其餘能夠更多的，這裏當你資源滿的時候，一人分了一百個CPU，他倆都分一百個的時候，最開始你們討論得沒有問題，這個請求有150，這裏的scheduler會供它調整，因此它會動態地改這個，這樣的話，資源就能夠共享出來。從而提升你整個資源的效率。

4

Kubernetes 1.7（sig-scheduling）

由於這個控制，能夠用戶本身來寫，因此這個沒有定下來。還有其餘的scheduler，這個是在1.7要這樣作的事情，這個作完之後，能夠考慮經過K8S用來運行多個，資源能夠動態調整，資源能夠動態共享，當你若是用單個集羣很難動態調整，這塊有幾個模型，這是未來咱們要考慮和控制的事情。如今用得比較多，好比說調度請求的時候，要這麼大，這塊中間的任務不必定都跑滿，資源是收不回去的，好比CPU沒有問題。

這是第一種案例，第二個事情就是說，這是另一個模式，我一個Executor跑一個任務，這個資源率會提升，由於像剛纔那種，只剩一個的任務，這個資源可讓出來，這個是分狀況的，這個狀況要佔用相同的任務比較多，好比在好多任務能夠複用，這樣你的資源使用率比較高。咱們有產品大概是這樣的架構，這個使用率可以達到70%以上，這是一個，另一種就是說，這是咱們須要考慮的事情，以前有人問關於MPI的事情，MPI做業有一些需求，兩個最基本的需求是第一個，啓的時候要拿到全部資源才能啓，並且它本身有彼此之間會有通訊，像如今的K8S裏面沒有這個功能，當你建立的時候，一個循環，往上扔就好了，能啓多少啓多少，你有可能這面你先起了三個，那面兩個，可能守在那兒了。必定要拿到全部的資源。

另一個案例比較簡單的是，我收到任務之後，就訪問結果就好了。最簡單的就是這種並行的時候，K8S現有的這種，它有job的功能，比較類似，就是把這個東西往上跑，很是很是簡單。你不知道當前的任務會分到哪塊工做，檢查一些功能，我不須要跟別人通訊，我抓一些數據，會變成那樣，那樣是最簡單的事情。會考慮這三種的需求，至少在一些版本里面，早期的版本里面支持案例一和案例二，會加上更多的東西，知足並行做業的一些特定的東西。關於1.7裏面batchjob是討論最多的東西，下面一些相關的問題，第一個就是關於管理多個問題，這個是去年在那兒提的事情，這個基於K8S的想法，它但願作這樣的事情，在整個集羣裏面，你是基於當前的需求作的調度，你過了一天之後，有的人可能會停掉，好比死了之後重啓等等這樣的功能，因此你啓動之後，總體的功能多是最多的，過了一段時間之後，我從新算整個裏面的資源狀況，而後根據須要達到最優解，它是按期解決這樣的問題。像這些batchjob做業就沒有太大的做用。那個跑好幾周都是能夠接受的，關於scheduler就介紹這麼多，後續還會有機會，把batchjob的細節講一下，由於講起來太多了。