容器為用戶打開了一扇通往新世界的大門，真正進入這個容器的世界后，卻發現新的生態系統如此龐大。在生產使用中，不論個人還是企業，都會提出更復雜的需求。這時，我們需要眾多跨主機的容器協同工作，需要支持各種類型的工作負載，企業級應用開發更是需要基于容器技術，實現支持多人協作的持續集成、持續交付平臺。即使Docker只需一條命令便可啟動一個容器，一旦試圖將其推廣到軟件開發和生產環境中，麻煩便層出不窮，容器相關的網絡、存儲、集群、高可用等就是不得不面對的問題。從容器到容器云的進化應運而來。
同一臺機器通過docker集群、什么是容器云？
容器云以容器為資源分割和調度的基本單位，封裝整個軟件運行時環境，為開發者和系統管理員提供用于構建、發布和運行分布式應用的平臺。當容器云專注于資源共享與隔離、容器編排與部署時，它是一種IaaS；當容器云滲透到應用支撐與運行時環境時，它是一種PaaS。
docker in docker？一個軟件項目的成功常常需要依托其衍生的生態系統，圍繞或基于核心技術而構建的相關項目日臻豐富和完善，軟件本身的功能和易用性也隨之增加，Docker的迅猛發展與其強大的生態系統息息相關。
這里要介紹的就是在這個龐大的docker生態系統中的“編排/調度/監控”——zookeeper+Mesos+Marathon
Zookeeper介紹
k8s docker集群搭建。Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，它包含一個簡單的原語集，分布式應用程序可以基于它實現同步服務，配置維護和命名服務等。Zookeeper是hadoop的一個子項目，在分布式應用中，由于工程師不能很好地使用鎖機制，以及基于消息的協調機制不適合在某些應用中使用，因此需要有一種可靠的、可擴展的、分布式的、可配置的協調機制來統一系統的狀態。Zookeeper的目的就在于此。
角色
Zookeeper中的角色主要有以下三類：
系統模型如圖所示：
設計目的
- 最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
- 可靠性：具有簡單、健壯、良好的性能，如果消息被一臺服務器接受，那么它將被所有的服務器接受。
- 實時性：Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。但由于網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
- 等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
- 原子性：更新只能成功或者失敗，沒有中間狀態。
- 順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發布，則在所有Server上消息a都將在消息b前被發布；偏序是指如果一個消息b在消息a后被同一個發送者發布，a必將排在b前面。
工作原理
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以后，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性，zookeeper采用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬于那個leader的統治時期。低32位用于遞增計數。
每個Server在工作過程中有三種狀態：
- LOOKING：當前Server不知道leader是誰，正在搜尋
- LEADING：當前Server即為選舉出來的leader
- FOLLOWING：leader已經選舉出來，當前Server與之同步
選主流程
當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基于basic paxos實現的，另外一種是基于fast paxos算法實現的。系統默認的選舉法為fast paxos。先介紹basic paxos流程：
- 選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，并選出推薦的Server；
- 選舉線程首先向所有Server發起一次詢問（包括自己）；
- 選舉現成收到回復后，驗證是否是自己發起的詢問（驗證zxid是否一致），然后獲取對方的id（myid），并存儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息（id，zxid），并將這些信息存儲到當次選舉的投票記錄表中；
- 收到所有Server回復以后，就計算出zxid最大的那個Server，并將這個Server相關信息設置成下一次要投票的Server；
- 線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader為獲勝的Server，將根據獲勝的Server相關信息設置自己的狀態，否則，繼續這個過程，直到leader被選舉出來。 通過流程分析我們可以得出：要使Leader獲得多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少于n+1. 每個Server啟動后都會重復以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日志并定期進行快照，方便在恢復時進行狀態恢復。
選主的具體流程圖所示：
fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以后，解決epoch和zxid的沖突，并接受對方的提議，然后向對方發送接受提議完成的消息，重復這個流程，最后一定能選舉出Leader。
其流程圖如下所示：
同步流程
選完leader以后，zk就進入狀態同步過程。
- leader等待server連接；
- Follower連接leader，將最大的zxid發送給leader；
- 完成同步后通知follower已經成為uptodate狀態；
- Follower收到uptodate消息后，又可以重新接受client的請求進行服務了。
流程圖如下所示：
工作流程
Leader工作流程
Leader主要有三個功能：
-
- 恢復數據；
- 維持Learner的心跳，接收Learner請求并判斷Learner的請求消息類型；
- Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不同的消息類型，進行不同的處理。?
PING消息是指Learner的心跳消息；
REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；
ACK消息是Follower的對象提議回復，超過半數的Follower通過，則commit該提議；
REVALIDATE消息是用來延長SESSION有效時間。
Leader的工作流程簡圖如下所示，在實際實現中，流程要比下圖復雜得多，啟動了三個線程來實現功能。
Follower工作流程
Follower主要有四個功能：
-
- 向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDA消息）；
- 接受Leader消息并進行處理；
- 接收Client的請求，如果為寫請求，發送給Leader進行投票；
- 返回Client結果。
Follower的消息循環處理如下幾種來自Leader的消息：
-
- PING消息：心跳消息；
- PROPOSAL消息：Leader發起的提案，要求Follower投票；
- COMMIT消息：服務端最新一次提案的消息；
- UPTODATE消息：表明同步完成；
- REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受消息；
- SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制得到最新的更新。
Follower的工作流程簡圖如下，在實際實現中，Follower是通過5個線程來實現功能的。
?對于observer的流程不再敘述，observer流程和Follower的唯一不同的地方就是observer不會參加leader發起的投票。
Mesos介紹
Mesos是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核。Mesos能夠在同樣的集群機器上運行多種分布式系統類型，更加動態有效率低共享資源。提供失敗偵測，任務發布，任務跟蹤，任務監控，低層次資源管理和細粒度的資源共享，可以擴展伸縮到數千個節點。Mesos已經被Twitter用來管理它們的數據中心。
Apache mesos中的基本術語解釋
- Mesos-master：Mesos master，主要負責管理各個framework和slave，并將slave上的資源分配給各個framework
- Mesos-slave：Mesos slave，負責管理本節點上的各個mesos-task，比如：為各個executor分配資源
- Framework：計算框架，如Hadoop，Spark等，通過MesosSchedulerDiver接入Mesos
- Executor：執行器，安裝到mesos-slave上，用于啟動計算框架中的task。
當用戶試圖添加一種新的計算框架到Mesos中時，需要實現一個Framework sheduler和executor以接入Mesos。
- Mesos-master是這個系統的核心，負責管理接入Mesos的各個framework（由frameworks_manager管理）和slave（slaves_manager管理），并將slave上的資源按照某種策略分配給framework（有獨立插拔模塊Allocator管理）。
- Mesos-slave負責接收并執行來自mesos-master的命令、管理節點上的mesos-task，并為各個task分配資源。mesos-slave將自己的資源量發送給mesos-master，由mesos-master中的Allocator模塊決定將資源分配給哪個framework，當前考慮的資源有CPU和內存兩種，也就是說，mesos-slave會將CPU個數和內存量發送給mesos-master，而用戶提交作業時，需要制定每個任務需要的CPU個數和內存量，這樣，當任務運行時，mesos-slave會將任務放到包含固定資源的linux container中運行，以達到資源隔離的效果。很明顯，master存在單點故障的問題，為此，mesos采用了zookeeper解決該問題。
- Framework是指外部的計算框架，如Hadoop，Mesos等，這些計算框架可通過注冊的方式接入mesos，以便mesos進行統一管理和資源分配。Mesos要求可接入的框架必須有一個調度器模塊，該調度器負責框架內部的任務調度。當一個framework想要接入mesos時，需要修改自己的調度器，以便向mesos注冊，并獲取mesos分配給自己的資源，這樣再由自己的調度器將這些資源分配給框架中的任務，也就是說，整個mesos系統采用了雙層調度框架：第一層，由mesos將資源分配給框架；第二層，框架自己的調度器將資源分配給自己內部的任務。當前Mesos支持三種語言編寫的調度器，分別是C++，Java和python，為了向各種調度器提供統一的接入方式，Mesos內部采用C++實現一個MesosScheduleDriver（調度器驅動），framework的調度器可調用該driver中的接口與Mesos-master交互，完成一系列功能（如注冊，資源分配等）。
- Executor主要用于啟動框架內部的task。由于不同的框架，啟動task的接口或者方式不同，當一個新的框架要接入mesos時，需要編寫一個executor，告訴mesos如何啟動該框架中的task。為了向各種框架提供統一的執行器編寫方式，Mesos內部采用C++實現了一個MesosExecutorDiver（執行器驅動器），framework可通過該驅動器的相關接口告訴mesos啟動task的方法。
Mesos基礎架構
首先Mesos是一個Master / Agent的架構方式，其中：
- Master負責資源的統一管理跟任務的分發；
- Agent負責起停執行器，匯報主機資源、執行器狀態等信息；
- 一般情況下，會啟動3個以上Master，以確保高可用，Master的狀態由Zookeeper維護；
- Framerwork是Mesos上的調度框架，Marathon Hadoop Chonous都是比較常見的任務調度框架。
這樣的架構給人的整體感受就清晰明朗。另外：
- 每臺機器上都會部署一個Mesos-Agent，Agent會把信息匯報給Master。
- 調度器scheduler向Mesos-Master請求資源，Mesos-Master把所有可用的資源都反饋給Scheduler，Scheduler根據自己的規則決定該部署到哪一臺。
Mesos總體架構
?
上圖展示了Mesos的重要組成部分：
1）mesoso由一個master進程管理運行著每個客戶端節點的salve進程和跑任務的mesos計算框架。master進程通過計算框架可以很細致的管理cpu和內存等，從而提供資源。每個資源提供與包含了一個清單(slave ID, resource1: amount1, resource2, amount2, …),master會根據現有的政府決定提供每個計算框架多少資源，例如公平分享或者根據優先級分享。 為了支持不同種的政策，master通過插件機制新增了一個allocation模塊使之分配資源更簡單方便。 ??
2）一個計算框架運行在兩個組件之上，一個是scheduler，他是master提供資源的注冊中心，另一個是executor程序，用來發起在slave節點上運行計算框架的任務。master決定給每個計算框架提供多少計算資源，計算框架的的調度去選擇使用哪個資源。當一個計算框架接受了提供的資源，他會通過mesos的任務描述運行程序，mesos也會在相應的slave上發起任務。
從上面圖中可以看到，Mesos有Framework（Framework里面有Scheduler）, Master（Master里面有Allocator）、Agent、Executor、Task幾部分組成。
這里面有兩層的Scheduler，一層在Master里面，Allocator會將資源公平的分給每一個Framework，二層在Framework里面，Framework的Scheduler將資源按規則分配給Task。
Mesos的這幾個角色在一個任務運行的生命周期中，相互關系如下：
Agent會將資源匯報給Master，Master會根據Allocator的策略將資源offer給Framework的Scheduler。Scheduler 可以accept這個資源，運行一個Task，Master將Task交給Agent，Agent交給Executor去真正的運行這個Task。
Mesos資源提供的例子：
簡單梳理一下上圖的流程步驟：
- slave 1 報告給master他擁有4核cpu和4G剩余內存，matser調用allocation政策模塊，告訴salve 1 計算框架1應該被提供可用的資源。
- master給計算框架1發送一個在slave1上可用的資源描述。
- 計算框架的調度器回復給master運行在slave上兩個任務的相關信息，任務1需使用2個cpu，內存1G，任務2需使用1個cpu，2G內存。
- 最后，master發送任務給slave，分配適當的給計算框架執行器，繼續發起兩個任務（圖上虛線處），因為仍有1個cpu和1G內存未分配，allocation模塊現在或許提供剩下的資源給計算框架2。
- 除此之外，當任務完成，新的資源成為空閑時，這個資源提供程序將會重復。
Mesos框架式一個在Mesos上運行分布式應用的應用程序，它有兩個組件：
- 調度器：與Mesos交互，訂閱資源，然后在mesos從服務器中加載任務。
- 執行器：從框架的環境變量配置中獲得信息，在mesos從服務器中運行任務。
下面看看其是如何實現資源調用？Mesos通過“resources offers”分配資源，資源其實是當前可用資源的一個快照，調度器使用這些資源在mesos從服務器上運行任務。
Mesos主從服務器調度資源的順序如下圖：
首先由Mesos主服務器查詢可用資源給調度器，第二步調度器向主服務器發出加載任務，主服務器再傳達給從服務器，從服務器向執行器命令加載任務執行，執行器執行任務以后，將狀態反饋上報給從服務器，最終告知調度器 。
從服務器下管理多個執行器，每個執行器是一個容器，以前可以使用Linux容器LXC，現在使用Docker容器。
Mesos失敗恢復和高可用性
- Mesos主服務器使用Zookeeper進行服務選舉和發現。它有一個注冊器記錄了所有運行任何和從服務器信息，使用MultiPaxos進行日志復制實現一致性。
- Mesos有一個從服務器恢復機制，無論什么時候一個從服務器死機了，用戶的任務還是能夠繼續運行，從服務器會將一些關鍵點信息如任務信息狀態更新持久化到本地磁盤上，重新啟動時可以從磁盤上恢復運行這些任務(類似Java中的鈍化和喚醒)
Marathon介紹
Marathon是一個成熟的，輕量級的，擴展性很強的Apache Mesos的容器編排框架，它主要用來調度和運行常駐服務（long-running service），提供了友好的界面和Rest API來創建和管理應用。marathon是一個mesos框架，能夠支持運行長服務，比如web應用等，它是集群的分布式Init.d，能夠原樣運行任何Linux二進制發布版本，如Tomcat Play等等，可以集群的多進程管理。也是一種私有的Pass，實現服務的發現，為部署提供提供REST API服務，有授權和SSL、配置約束，通過HAProxy實現服務發現和負載平衡。
這樣，我們可以如同一臺Linux主機一樣管理數千臺服務器，它們的對應原理如下圖，使用Marathon類似Linux主機內的init Systemd等外殼管理，而Mesos則不只包含一個Linux核，可以調度數千臺服務器的Linux核，實際是一個數據中心的內核：
Marathon中重要的概念介紹：
- Application是Marathon中一個重要的核心概念，它代表了一個長服務。
- Application definition表示一個長服務的定義，規定了一個Application啟動和運行時的所有行為。Marathon提供了兩種方式讓你來定義你的長服務，第一種通過Portal來定義，它方便終端用戶的理解和使用，另一種是通過JSON格式的文件來定義，并通過RestAPI的方式來創建和管理這個Application，這種方式方便和第三方的系統進行集成，提供了再次的可編程接口。?
- Application instance表示一個Application的實例，也稱作Mesos的一個task。Marathon可以為一個Application創建和管理多個實例，并可以動態的增大和減小某個Application實例的個數，并且通過Marathon-lb實現服務發現和負載均衡。?
- Application Group：Marathon可以把多個Application組織成一棵樹的結構，Group稱為這個樹的樹枝，Application稱為這個樹的葉子。同一個Group中的Application可以被Marathon統一管理。
- Deployments:對Application或者Group的definition的一次修改的提交稱為一次deployment。它包括創建，銷毀，擴容縮容Application或者Group等。多個deployments可以同時進行，但是對于一個應用的deployments必須是串行的，如果前一個deployment沒有結束就執行下一個deployment，那么它將會被拒絕。
?
