數據中心操作系統 DC/OS的深入理解


DC/OS 詳細介紹

DC/OS 是 Mesosphere 開源的數據中心操作系統。可輕松的部署和運行有狀態和無狀態的容器、大數據以及傳統應用。該系統基於 Apache Mesos 構建,其經驗來自 Mesosphere, Yelp, Twitter, Airbnb, 以及很多創新的公司。

管理界面截圖:


技術不斷演進迭代,企業面臨着眾多挑戰,例如:快速開發服務,收集和分析海量數據,接下來是如何對海量數據做出快速響應等挑戰。可以預見,軟件是企業直面這些眾多挑戰的重要因素,當然軟件也驅動了個各種設備,汽車,銀行系統等等。

建立一個支持快速部署服務的現代數據中心平台是一個日益復雜的挑戰。IT組織面臨巨大的壓力來實現這些目標,同時還要關注傳統中的需求,比如:保持敏捷性,高效率,安全性,服務質量和運營方面等。為了滿足不斷增長的業務需求,IT組織和服務提供商正在轉向數據中心操作系統(DC/OS)。

DC/OS是一個開源軟件項目,可在數據中心和雲端的所有服務器上抽象計算資源。DC/OS由Apache Mesos分布式系統內核提供支持,這是一個可擴展的二層調度程序,它可以集中基礎設施資源並跨多個分布式應用共享資源。DC/OS利用Mesos,Marathon和相關組件,為運行應用服務和大型數據平台提供高彈性和可擴展的解決方案

現代應用狀況

容器化技術已成為IT公司的頭等大事。其中很大一部分是由於軟件運行發生變化,軟件如何快速開發和部署。如果開發商應該開始容器之旅,運營商需要弄清楚如何運行在生產環境中。現在,這個談話已經從容器方式轉變成為世界各地現代應用程序提供強大而可擴展的編排系統。

速度和敏捷性在當今的數字化環境中至關重要因素。未來幾年各種設備產生的海量數據會令人難以置信。為了加快創新步伐,公司正在迅速從傳統的應用轉型為微服務。

而傳統的應用程序會綁定單個虛擬機或裸機服務器,現代應用程序完全解耦:由許多容器化的微服務應用和有狀態的大數據引擎組成。大部分公司廣泛使用開源軟件,受益於社區貢獻,讓自己的開發團隊專注於自己業務價值實現。

並不是每個公司都有Google,Facebook,Twitter,Apple或Uber的資源優勢。這些公司花費了巨大人力和財力在平台建設上,並需要強大的性能,彈性,可用性和安全性去處理最先進的應用程序。

DC/OS為企業和服務提供商提供了一個平台,可以獲得同樣的好處 - 一個運行容器和平台服務的平台,共享統一的基礎設施。DC/OS技術在生產中擁有比任何其他開放源代碼軟件更多的容器支持。

什么是DC/OS

DC/OS的核心是Mesos分布式系統內核,在對生產環境最苛刻的環境(如Twitter和Apple)中通過了測試和驗證。DC/OS利用Mesos進行集群資源管理,以處理作業調度,資源管理和抽象,高可用性以及其他基礎設施級流程。

圖片描述

資源調度只是架構的一部分,它的上層技術是Mesos,然后構成了完整的DC/OS平台。這些包括本地容器平台(Marathon);DC/OS安裝程序,Universe軟件包存儲庫; GUI和CLI進行管理和監控;以及許多其他功能,包括網絡,存儲,安全,負載平衡和服務發現。

DC/OS是唯一將所有這些組件捆綁在一起並成為分布式軟件部署的開源項目。DC/OS使每個公司都有能力成為Mesos受益者。做的事情只是自己工作的小部分。

好處包括:

●生產驗證:基於Mesos和Marathon,是業界最成熟,最具企業級的容器編排平台。

●二層調度:Mesos具有兩層調度設計,允許平台服務通過自動分發任務和容器來智能地調度工作負載,從而提高利用率。

●有狀態服務:復雜的分布式系統可以在幾分鍾內部署。

●自動故障恢復:針對所有類型的應用程序,服務和工作負載內置高可用性和容錯能力。

●資源效率:容器實現了性能隔離,消除了靜態分區環境並解放了更高的服務器利用率。在DC/OS上運行Spark,Kafka和Cassandra,可以動態地擴縮容各種計算資源

●簡化操作:通過基於GUI/CLI的監控和管理來控制整個數據中心資源。DC/OS提供了一個單一GUI界面和互操作接入,用於管理應用程序和有狀態服務的連續生命周期。

●寫一次,在任何地方運行:DC/OS提供了一個抽象層,無論部署在裸機,虛擬機,私有雲或公共雲上,都能提供標准用戶體驗。

圖片描述

擁有充滿活力的用戶群體,合作伙伴和貢獻者使我們能夠將DC/OS視為新的需求,出現用例。

DC/OS是開源技術,但它也是一個完整的生態系統。保持高速發展勢頭,建立一個充滿活力的社區是很重要的。合作伙伴包括雲計算提供商,如微軟,領先的系統集成商,如埃森哲,以及世界上最創新的消費者技術公司,如Yelp。DC/OS目前由Mesosphere組織,提供社區提交者的貢獻和路線圖。

使用DC/OS 1.9,增加了諸如Pods和GPU支持等令人興奮的新功能,以加強現代數據豐富的應用程序的企業級解決方案。這使得傳統遺留應用程序的工作負載能夠進行機器學習。DC/OS現在允許您分離和預留GPU資源,和神經網絡與CPU相比提高高達10-20%。此外,增強的監控,日志記錄和故障排除功能使生產中的運行容器更加容易。

超越容器

容器技術已經存在了一段時間。 Apache Mesos在2010年開始使用容器。自2000年初以來,Google決定使用容器而不是Borg的虛擬機,使用容器的資源管理系統。隨着分布式系統和微型服務器的興起,通過引入簡化的容器管理工具,最近出現了人氣的激增。

DC/OS與其他受歡迎的容器技術(如Kubernetes和Docker Datacenter)能夠脫穎而出是如下原因:

1.DC/OS不單單支持Docker,也適用於所有基於OCI容器技術。DC/OS和它的容器編排平台(Marathon)是運行Docker容器的出色平台。然而現代平台需要更多靈活性。DC/OS支持新興的容器格式,如AppC和OCI。

最后,所有容器引擎都使用現代Linux操作系統中的Linux cgroups和命名空間。用戶不必考慮容器引擎的實際實現或隔離資源的機制。

2.DC/OS對於容器操作,不僅僅是容器編排。 Marathon容器技術流程平台包含一系列功能強大的功能,用於管理整個容器生命周期。很多正在使用Marathon用戶包括Verizon,三星,Yelp,Autodesk,迪士尼,Mattermark等。

3.DC/OS有一個獨一無二的兩層調度器,可以運行許多分布式 系統作為服務。通過從核心資源調度程序中分離解決方案特定的調度邏輯,集群資源可以在諸如Marathon,Spark,Kafka,Cassandra和Jenkins等眾多平台之間共享資源。

有狀態的服務特別受益於這種體系結構,因為框架調度器可以處理諸如節點配置和跨故障區域的數據的智能復制等操作任務,從而提高可用性和數據持久性。

數據中心的應用市場

通過抽象所有數據中心資源,DC/OS可以將微服務的打包,部署和操作等復雜操作進行簡潔化處理。對於現代CI/CD到大數據串聯的場景不會在復雜,也不需要以前那些高度專業化的部署和運營技能。從前需要花費數天,甚至數周的時間來部署有狀態的分布式應用程序是很常見的。

DC/OS Universe是一個包(Package)倉庫,包括開源和商業軟件交付。通過點擊按鈕,您可以輕松部署各種平台服務,如Cassandra,Chronos,Elasticsearch,HDFS,Jenkins,Kafka,Marathon-LB,Spark等。安裝時間以分鍾而不是數天或數周計算。

如果您正在尋找的應用程序不在Universe中,請可以自行打包應用程序並上線應用商城。DC/OS還提供了為私有定制應用程序部署離線本地Universe的功能。

圖片描述

傳統意義上,數據服務框架一般很難使用,通常需要數千行代碼。必須嚴格實施,並達到高可用性等功能,以確保框架能夠生產就緒。

Mesosphere新開發的開源組件叫包SDK,用於在DC/OS上構建新的有狀態服務。使用SDK,開發人員可以使用持續卷,容器和配置方式來編寫大約100行代碼的狀態服務。 
該SDK是Mesosphere為DC/OS(如Kafka,Cassandra和HDFS)編寫時留下來的經驗產物。使用DC/OS SDK編寫將極大提高生產率,並通過與合作伙伴和相關軟件運營商進行配合,制定共同標准,開發和上線時間從幾個月縮短到幾天。

企業級DC/OS

雖然Mesosphere完全繼續支持Mesos,Marathon和新興的DC/OS社區,我們也是一家向全球2000企業提供產品和服務的軟件公司。 Mesosphere Enterprise DC/ OS通過提供關於安全性,性能,網絡,合規性,監控和多租戶支持的關鍵企業功能來增強開源DC/OS項目。

深入解析DC/OS 1.8

– 高可靠的微服務及大數據管理平台

 

大家好,歡迎大家參加這次DC/OS的技術分享。

先做個自我介紹,劉超,Linker Networks首席架構師,Open DC/OS社區貢獻者,長期專注於OpenStack, Docker, Mesos等開源軟件的企業級應用與產品化。

從事容器方面工作的朋友可能已經聽說過DC/OS,往往大家誤解DC/OS就是marathon + mesos,其實DC/OS包含很多的組件,DC/OS 1.8九月份發布了,此次分享給大家做一個介紹。

一、DC/OS的基本思想

所謂的DC/OS,全稱為數據中心操作系統,其基本的思想就是使得運維人員操作整個數據中如操作一台電腦一樣。

DC/OS使用了哪些技術可以做到這一點呢?

如圖,左面是普通的Linux操作系統,右面是DC/OS,在這里做了一個對比。

無論是哪種操作系統,都需要管理外部的硬件設備,最重要的四種硬件資源即CPU,內存,存儲,網絡。

最初使用匯編語言寫程序的前輩,還是需要指定使用那些硬件資源的,例如指定使用哪個寄存器,放在內存的哪個位置,寫入或者讀取那個串口等,對於這些資源的使用,需要程序員自己心里非常的清楚,要不然一旦JUMP錯了位置,程序就無法運行。這就像運維數據中心的一台台物理機的前輩一樣,那個程序放在了哪台機器上,使用多少內存,多少硬盤,都需要心里非常的清楚。

為了將程序員從對硬件的直接操作中解放出來,提升程序設計的效率,從而有了操作系統這一層,實現對於硬件資源的統一管理。某個程序使用哪個CPU,哪部分內存,哪部分硬盤,程序只需要調用API就可以了,由操作系統自行分配和管理,其實操作系統只做了一件事情,就是調度。對應到數據中心,也需要一個調度器,將運維人員從指定物理機或者虛擬機的痛苦中解放出來,這就是Mesos。Mesos即使數據中心操作系統的內核。

在使用操作系統的時候,我們可以開發驅動程序來識別新的硬件資源,可以開發內核模塊(例如openvswitch.ko)來干預對於硬件資源的使用,對於Mesos,同樣可以開發isolator來識別新的硬件資源例如GPU,也可以開發Executor來干預資源的使用。

在內核之上,就是系統服務,例如systemd,是用來維護進程運行的,如果systemctl enable xxx,則保證服務掛掉后自動重啟。對於DC/OS,保持服務long run的是marathon,但是僅僅只有marathon還不夠,因為服務是啟動在多台機器上的,而且服務之間是有依賴關系的,一個服務掛掉了,在另外一台機器啟動起來,如何保持服務之間的調用不需要人工干預呢?這需要另外的技術,稱為服務發現,多是通過DNS,負載均衡,虛擬機IP等技術實現的。

使用操作系統,需要安裝一些軟件,於是需要yum之類的包管理系統,使得軟件的使用者和軟件的編譯者分隔開來,軟件的編譯者需要知道這個軟件需要安裝哪些包,包之間的依賴關系是什么,軟件安裝到什么地方,而軟件的使用者僅僅需要yum install就可以了。DC/OS就有這樣一套包管理軟件,和其他的容器管理平台需要自己編譯Docker鏡像,自己寫yml,自己管理依賴不同,DC/OS的軟件使用者只需要dcos package install就可以安裝好軟件了,軟件的配置,節點數目,依賴關系都是有軟件編譯者設置。

在最外層,DC/OS像普通的操作系統一樣,有統一的界面和命令行。通過它們,可以管理安裝包,管理節點,運行任務等。DC/OS不僅僅是運行容器的平台,如果僅僅運行容器,就是容器管理平台,而非數據中心操作系統。通過DC/OS,你可以在每台機器上運行一個命令來進行統一的配置,而無需登錄到每台機器上去。你可以運行容器應用和大數據分析應用並共享資源,並且可以相互發現,這更加符合現代互聯網應用,微服務和大數據不可分割。而且Mesos的架構非常開放,你可以通過開發Framework, Executor, Modules, Hooks等,輕松干預微服務或者大數據任務的執行過程,來定制化你的應用。這也符合操作系統微內核的概念。

二、DC/OS的內核模塊Mesos

Mesos架構如下

這個圖比較的著名了,也有很多文章介紹這個圖,詳情可以看文章http://mesos.apache.org/documentation/latest/architecture/,這里不做過多的介紹。

從圖中可以看到,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。

 

這個圖相對比較的簡略,真正詳細的過程比這個復雜很多,大家可以參考這篇博客http://www.cnblogs.com/popsuper1982/p/5926724.html,在代碼級別分析了整個任務運行的過程,還畫了一個泳道圖http://images2015.cnblogs.com/blog/635909/201608/635909-20160806163718778-1628977219.png

 

要研究Mesos,熟悉整個過程非常重要,這樣一個任務運行出現問題的時候,才能比較好的定位問題在哪里,如果解決。Mesos將一個簡單的任務的運行過程,分成如此多的層次,如此多的角色來做,是為了雙層調度和靈活配置,這是一個內核應該做的事情。

 

我們如何干預一個Task的運行過程呢?

第一、寫一個Framework

如果你想完全自己控制Task的運行,而非讓Marathon來運行並保持一個無狀態的Task長運行,就需要自己寫一個Framework,在你的Framework里面,三個Task之間的關系你可以自己定義,而非像Marathon一樣,Task * 3,3個任務不分彼此,你的Framework可以控制這三個Task一主兩備,可以控制三個Task的啟動順序,可以將一個先啟動的Task的IP,位置等通過環境變量告知另外兩個Task。

寫一個Framework需要寫一個Scheduler,實現一些接口,如文檔http://mesos.apache.org/documentation/latest/app-framework-development-guide/中所述。

然后使用使用MesosSchedulerDriver來運行這個Scheduler。

其實Mesos這些模塊之間的通信都是通過Protocol Buffer定義消息來交互的,然而如果讓Framework的開發人員還要學會如何使用Protocol Buffer消息和Mesos Master通信,是很痛苦的事情,所以MesosSchedulerDriver幫助你做了這個事情,你只需要實現Scheduler定義的接口就可以了,不需要了解這些接口是誰調用的,調用了接口之后,消息如何傳給Mesos Master。

所有的接口里面,最重要的是resourceOffers函數,根據得到的offers(每個slave都有多少資源),創建一系列tasks,然后調用MesosSchedulerDriver的launchTasks函數,MesosSchedulerDriver會將這些tasks封裝為LaunchTasksMessage發送給Mesos Master。

 

第二、寫一個Allocator

通過上面的描述,Mesos有兩層調度,第一層就是Allocator,將資源分配給Framework。

Mesos允許用戶通過自己寫Module的方式,寫一個so,然后啟動的時候加載進去,然后在命令行里面指定使用so中的哪個Module。

當然寫Allocator的不多,因為Mesos的DRF算法是Mesos的核心,如果不用這個算法,還不如不用mesos。

Mesos源碼中默認的Allocator,即HierarchicalDRFAllocator的位置在$MESOS_HOME/src/master/allocator/mesos/hierarchical.hpp,而DRF中對每個Framework排序的Sorter位於$MESOS_HOME/src/master/allocator/sorter/drf/sorter.cpp,可以查看其源碼了解它的工作原理。

HierarchicalDRF的基本原理

如何作出offer分配的決定是由資源分配模塊Allocator實現的,該模塊存在於Master之中。資源分配模塊確定Framework接受offer的順序,與此同時,確保在資源利用最大化的條件下公平地共享資源。

由於Mesos為跨數據中心調度資源並且是異構的資源需求時,資源分配相比普通調度將會更加困難。因此Mesos采用了DRF(主導資源公平算法 Dominant Resource Fairness)

Framework擁有的全部資源類型份額中占最高百分比的就是Framework的主導份額。DRF算法會使用所有已注冊的Framework來計算主導份額,以確保每個Framework能接收到其主導資源的公平份額。

 

舉個例子

考慮一個9CPU,18GBRAM的系統,擁有兩個用戶,其中用戶A運行的任務的需求向量為{1CPU, 4GB},用戶B運行的任務的需求向量為{3CPU,1GB},用戶可以執行盡量多的任務來使用系統的資源。

 

在上述方案中,A的每個任務消耗總cpu的1/9和總內存的2/9,所以A的dominant resource是內存;B的每個任務消耗總cpu的1/3和總內存的1/18,所以B的dominant resource為CPU。DRF會均衡用戶的dominant shares,執行3個用戶A的任務,執行2個用戶B的任務。三個用戶A的任務總共消耗了{3CPU,12GB},兩個用戶B的任務總共消耗了{6CPU,2GB};在這個分配中,每一個用戶的dominant share是相等的,用戶A獲得了2/3的RAM,而用戶B獲得了2/3的CPU。

 

以上的這個分配可以用如下方式計算出來:x和y分別是用戶A和用戶B的分配任務的數目,那么用戶A消耗了{xCPU,4xGB},用戶B消耗了{3yCPU,yGB},在圖三中用戶A和用戶B消耗了同等dominant resource;用戶A的dominant share為4x/18,用戶B的dominant share為3y/9。所以DRF分配可以通過求解以下的優化問題來得到:

max(x,y) #(Maximize allocations)

subject to

x + 3y <= 9 #(CPU constraint)

4x + y <= 18 #(Memory Constraint)

2x/9 = y/3 #(Equalize dominant shares)

最后解出x=3以及y=2,因而用戶A獲得{3CPU,12GB},B得到{6CPU, 2GB}。

 

HierarchicalDRF核心算法實現在Src/main/allocator/mesos/hierarchical.cpp中HierarchicalAllocatorProcess::allocate函數中。

 

概況來說調用了三個Sorter(quotaRoleSorter, roleSorter, frameworkSorter),對所有的Framework進行排序,哪個先得到資源,哪個后得到資源。

 

總的來說分兩大步:先保證有quota的role,調用quotaRoleSorter,然后其他的資源沒有quota的再分,調用roleSorter。

 

對於每一個大步分兩個層次排序:一層是按照role排序,第二層是相同的role的不同Framework排序,調用frameworkSorter。

 

每一層的排序都是按照計算的share進行排序來先給誰,再給誰。

 

這里有幾個概念容易混淆:Quota, Reservation, Role, Weight

  • 每個Framework可以有Role,既用於權限,也用於資源分配
  • 可以給某個role在offerResources的時候回復Offer::Operation::RESERVE,來預訂某台slave上面的資源。Reservation是很具體的,具體到哪台機器的多少資源屬於哪個Role
  • Quota是每個Role的最小保證量,但是不具體到某個節點,而是在整個集群中保證有這么多就行了。
  • Reserved資源也算在Quota里面。
  • 不同的Role之間可以有Weight

 

在allocator算法結束之后,便調用Master::Offer,最終調用Framework的Scheduler的resourceOffers,讓Framework進行二次調度。同上面的邏輯就串聯起來。

 

第三、寫一個Hook

你可以寫hook模塊,講代碼插在很多關鍵的步驟,從而改寫整個Executor或者Docker或者Task的啟動的整個過程。

 

可以干預的hook的地方定義在mesos/hook.hpp中。

 

Class hook定義如下:

其中比較常用的是slavePrelaunchDockerHook,可以在Docker啟動之前做一些事情,比如准備工作。

還有slaveRemoveExecutorHook,這個可以在executor結束的時候,做一些事情,比如清理工作。

 

第四、創建Isolator

當你有一種新的資源需要管理,並且每個Task需要針對這個資源進行隔離的時候,寫一個Isolator就是有必要的了。

例如默認的容器並不能動態指定並限制任務硬盤使用的大小,所以mesos-containerizer就有了"disk/du"來定時查看任務使用的硬盤大小,當超出限制的時候采取操作。

Src/slave/containerizer/mesos/containerizer.cpp里面列出了當前支持的isolator,你也可以實現自己的isolator,並且通過modules參數load進去。

 

Isolator定義了以下函數

 

在運行一個容器的最后,會調用每一個isolator的isolate函數,通過這個函數,可以對資源進行一定的限制,例如寫入cgroup文件等,但是對於硬盤使用量,其實沒有cgroup可以設置,需要過一段時間du一些,這就需要實現watch函數,過一段時間查看一下硬盤使用量,超過后做一定的操作。

 

第五、寫一個Executor

如果運行一個普通的容器,或者命令行,則不需要實現Executor,僅僅Mesos默認的Executor就能夠實現這個功能。如果你需要在Executor里面做很多自己定制化的工作,則需要自己寫Executor。

 

寫一個Executor需要實現一些接口,最重要的就是launchTask接口,然后MesosExecutorDriver將這個Executor運行起來。

 

就像Framework一樣,Executor也是通過protocol buffer協議和Mesos-Agent進行溝通,通過MesosExecutorDriver,你不需要關心協議的事情,僅僅需要實現接口即可。

 

三、DC/OS的核心模塊

下面的圖描述了DC/OS的部署架構圖:

在DC/OS看來,所有的節點分為三個區域,一個是管理區域,主要處理對於服務的管理方面的操作,如增刪查改,啟停擴縮等。為了高可用,Master節點可以是多個,在多個Master節點之前,需要有一個負載均衡器。第二個是對外服務區域,也即外界能夠訪問DC/OS內部的服務的區域,這個區域里面的服務多為對外的Nginx之類的,也會有marathon-lb來做外部的負載均衡器,所有對外服務區域的節點之外還需要一個負載均衡器。第三個區域是內部服務區域,用於部署內部服務,如數據庫,消息總線等,這些內部節點不能對外訪問。

 

第一、Admin Router

AdminRouter是一個反向代理,正是它將對外的區域和對內的區域完全隔離開來,在admin router之外,可以通過公網訪問,在admin router之內全部是私網地址,這樣提供了安全的統一訪問機制。

 

安裝完畢Open DC/OS之后,安裝一個dcos的命令行工具,通過這個工具可以ssh到master的節點上。

  1. eval `ssh-agent -s`
  2. ssh-add .ssh/aws01.pem
  3. dcos node ssh --master-proxy --leader

在這個節點上/etc/systemd/system路徑下面有三個systemd的service,Open DC/OS的所有組件都是用systemd進行管理的。

  1. ip-10-0-7-1 system # ls -l | grep adminrouter
  2. lrwxrwxrwx. 1 root root 135 Oct 3 08:00 dcos-adminrouter-reload.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.service
  3. lrwxrwxrwx. 1 root root 133 Oct 3 08:00 dcos-adminrouter-reload.timer -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.timer
  4. lrwxrwxrwx. 1 root root 128 Oct 3 08:00 dcos-adminrouter.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter.service

可以看到dcos-adminrouter.service是指向/opt/mesosphere/packages下面的一個路徑,Open DC/OS的所有組件都是安裝在這個路徑下面的。

 

在/opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/nginx/conf這個路徑下面,有一個文件nginx.master.conf,打開這個文件,就能看到熟悉的對於nginx的配置。

  1. upstream mesos {
  2.     server leader.mesos:5050;
  3. }
  4.  
  5. upstream marathon {
  6.     server master.mesos:8080;
  7. }
  8.  
  9. location /mesos/ {
  10.     access_by_lua 'auth.validate_jwt_or_exit()';
  11.     proxy_set_header Host $http_host;
  12.     proxy_pass http://mesos/;
  13. }
  14.  
  15. location /marathon/ {
  16.     # Enforce access restriction. Auth-wise, treat /marathon*
  17.     # equivalently to /service/marathon*.
  18.     access_by_lua 'auth.validate_jwt_or_exit()';
  19.     proxy_set_header Host $http_host;
  20.     proxy_pass http://marathon/;
  21. }

從這個配置文件可以看出,所有對內的訪問marathon的頁面,訪問mesos的頁面,都是通過leader.mesos進行,這個域名是mesos-dns給出的,對應的是內部的IP地址,如果從外部訪問marathon或者mesos的頁面,則必須通過admin router,通過http://admin-router-external-ip/marathon或者http://admin-router-external-ip/mesos來訪問。

 

第二、Mesos-DNS

對於數據中心操作系統來講,服務發現和負載均衡是最最核心的功能,只有有了這些功能,才能使得服務的物理布局,服務之間的依賴關系,服務掛掉之后的自動修復不需要用戶關心,才能使得用戶像用一台電腦一樣使用整個數據中心。

如果服務之間的相互調用不使用IP地址,而使用域名的話,問題會簡單很多。

如圖所示,對於Mesos上運行的每一個Task,Mesos-DNS都可以通過調用Mesos-Master的API得到,並且為每個Task分配一個域名和IP的對應項。如果一個Task需要訪問另一個Task,則需要配置域名即可,無論Task如何掛掉,如何分配到其他的節點上運行,域名都不會變,當然Task的IP可能會變,但是不用擔心,Mesos-DNS會更新它。每個Mesos-Agent只需要配置/etc/resolv.conf指向mesos-dns就可以了。

 

當一個Task運行的時候,Mesos-DNS會創建一個域名<task>.<service>.mesos對應:

  • Mesos-Agent的IP地址
  • 如果是Mesos Containerizer的話,返回的是Task內部容器的IP

 

另外<task>.<service>.slave.mesos還會提供所在的物理機的IP地址。這樣通過hostport和Mesos-DNS所給的域名,可以實現服務的發現。

 

第三:marathon-lb

 

使用DNS雖然可以實現服務的自發現,但是不容易實現服務的負載均衡和彈性伸縮,而marathon-lb實現了這些功能。

Marathon-lb是一個基於haproxy的負載均衡器,但是它會監聽marathon event bus,每當注冊到marathon-lb上的服務數目變化的時候,marathon-lb也會自動更新haproxy的配置文件,從而實現負載均衡。Marathon-lb可以如圖中實現對外的負載均衡,也可以實現對內的服務之間相互調用的負載均衡。

 

Marathon的安裝可以在界面中universe里面搜索marathon-lb安裝,也可以通過命令行執行dcos package install Marathon-LB進行安裝,默認安裝的對外的負載均衡器。

 

我們在服務里面創建如下的應用:

  1. {
  2.   "id": "nginx",
  3.   "container": {
  4.     "type": "DOCKER",
  5.     "docker": {
  6.       "image": "nginx:1.7.7",
  7.       "network": "BRIDGE",
  8.       "portMappings": [
  9.         { "hostPort": 0, "containerPort": 80, "servicePort": 10000 }
  10.       ],
  11.       "forcePullImage":true
  12.     }
  13.   },
  14.   "instances": 1,
  15.   "cpus": 0.1,
  16.   "mem": 65,
  17.   "healthChecks": [{
  18.       "protocol": "HTTP",
  19.       "path": "/",
  20.       "portIndex": 0,
  21.       "timeoutSeconds": 10,
  22.       "gracePeriodSeconds": 10,
  23.       "intervalSeconds": 2,
  24.       "maxConsecutiveFailures": 10
  25.   }],
  26.   "labels":{
  27.     "HAPROXY_GROUP":"external"
  28.   }
  29. }

在這個應用里面,servicePort為10000則說明我們注冊到marathon-lb上的外部端口為10000, labels里面寫的是external,也即注冊到外部的負載均衡器上。

 

這個時候,我們訪問public slave上的10000端口,就能看到啟動的nginx的頁面http://54.254.148.129:10000/,內部其他的應用可以通過http://marathon-lb.marathon.mesos:10000來訪問這個nginx

如果我們訪問public slave上的haproxy的配置頁面http://54.254.148.129:9090/haproxy?stats,可以看到如下的映射關系。

對外marathon-lb監聽10000端口,對內映射為10.0.1.78上的20215端口,如果我們從服務頁面上查看,的確啟動的nginx是監聽20215端口的。

 

接下來我們部署marathon-lb-autoscale,它監控haproxy,發現RPS(request per seconds)超過一定的數目,就對應用進行彈性擴展。

 

  1. {
  2.   "id": "marathon-lb-autoscale",
  3.   "args":[
  4.     "--marathon", "http://leader.mesos:8080",
  5.     "--haproxy", "http://marathon-lb.marathon.mesos:9090",
  6.     "--target-rps", "100",
  7.     "--apps", "nginx_10000"
  8.   ],
  9.   "cpus": 0.1,
  10.   "mem": 16.0,
  11.   "instances": 1,
  12.   "container": {
  13.     "type": "DOCKER",
  14.     "docker": {
  15.       "image": "brndnmtthws/marathon-lb-autoscale",
  16.       "network": "HOST",
  17.       "forcePullImage": true
  18.     }
  19.   }
  20. }

 

接下來,我們部署應用siege向nginx發送請求

  1. {
  2.   "id": "siege",
  3.   "args":[
  4.     "-d1",
  5.     "-r1000",
  6.     "-c100",
  7.     "http://marathon-lb.marathon.mesos:10000/"
  8.   ],
  9.   "cpus": 0.5,
  10.   "mem": 16.0,
  11.   "instances": 1,
  12.   "container": {
  13.     "type": "DOCKER",
  14.     "volumes": [],
  15.     "docker": {
  16.       "image": "yokogawa/siege",
  17.       "network": "HOST",
  18.       "privileged": false,
  19.       "parameters": [],
  20.       "forcePullImage": false
  21.     }
  22.   }
  23. }

 

如果我們看haproxy的stats頁面,發現已經有請求發過來了。這個時候我們增加siege到10,給nginx加壓。

過一段時間就會發現marathon-lb-autoscale已經有動作了。

將一個nginx變成8個nginx

 

當我們將siege從10個變回0個的時候。

 

第四、Minuteman

Minuteman是一個內部的東西向的負載均衡器,可用於設置VIP,多個實例使用同一個VIP來進行負載均衡。

在創建服務的時候,選擇Load Balanced,則下面會出現一行地址:nginxdocker.marathon.l4lb.thisdcos.directory:80,這個就是minuteman分配的VIP。

 

當服務創建好了之后,通過curl http://nginxdocker.marathon.l4lb.thisdcos.directory:80就可以訪問這個服務,但是我們如果ping這個域名卻是不通的,而且對於的IP地址也是很奇怪的IP地址,這個IP就是VIP.

 

這是怎么做到的呢?minuteman的load balancer是基於Netfilter的,在dcos的slave節點上,我們能看到多出來了四個iptables規則。其中前兩個規則是在raw表里面的,后兩個規則是在filter表里面的。

  1. -A PREROUTING -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j NFQUEUE --queue-balance 50:58
  2. -A OUTPUT -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j NFQUEUE --queue-balance 50:58
  3. -A FORWARD -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
  4. -A OUTPUT -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable

根據iptbles的規則raw表中的規則會被先執行,一旦到達了filter表的minuteman的包就都過濾掉了。

NFQUEUE的規則表示將對於包的處理權交給用戶態的一個進程。--queue-balance表示會將包發給幾個queue,然后用戶態進程會使用libnetfilter_queue連接到這些queue中,將包讀出來,根據包的內容做決策后放回內核進行發送。

 

在每一個Mesos-Agent節點上都運行這一個minuteman的進程,監聽這些queue,我們可以通過訪問API查看VIP的映射關系,curl http://localhost:61421/vips。

 

我們可以看到VIP的11.112.175.214后面跟着兩個節點10.0.1.78:27003和10.0.1.78:4989,正好對應nginx的兩個實例。

 

四、DC/OS的微服務及大數據的管理機制

DC/OS是基於Mesos的,Mesos的靈活框架機制可以使得DC/OS既能夠部署容器,也能夠部署大數據框架,大數據框架在不運行任務的時候,幾乎不占用資源,從而真正實現微服務和大數據框架的資源共享。

前面我們部署容器的時候,都是自己准備marathon的json進行部署的,這就需要使用服務的人和設計服務的人同樣的專業。

DC/OS采用了一種package管理機制,將運行一個微服務或者框架所需要的各種配置制作成模板,模板由專業人士制作好上傳到package repository,使用者就不需要那么專業,只要運行dcos package install安裝即可。

 

Mesosphere提供了官方的package repository,名為universe,地址為https://universe.mesosphere.com/repo,在github上可以找到對應的代碼https://github.com/mesosphere/universe

 

 

對於一個package,往往包含下面的部分:

  • package.json:這里面保存了一些metadata的數據,例如對於spark
  1. "name": "spark",
  2. "description": "Spark is a fast and general cluster computing system for Big Data. Documentation: https://docs.mesosphere.com/current/usage/service-guides/spark/",
  3. "licenses": [
  4.     {
  5.         "name": "Apache License Version 2.0",
  6.         "url": "https://raw.githubusercontent.com/apache/spark/master/LICENSE"
  7.     }
  8. ],
  9. "tags": [
  10.     "bigdata",
  11.     "mapreduce",
  12.     "batch",
  13.     "analytics"
  14. ],
  • config.json:保存一些配置項,例如對於spark
  1. "name": {
  2.     "default": "spark",
  3.     "description": "The Spark Dispatcher will register with Mesos with this as a framework name. This service will be available at http://<dcos_url>/service/<name>/",
  4.     "type": "string"
  5. },
  6. "cpus": {
  7.     "default": 1,
  8.     "description": "CPU shares",
  9.     "minimum": 0.0,
  10.     "type": "number"
  11. },
  12. "mem": {
  13.     "default": 1024.0,
  14.     "description": "Memory (MB)",
  15.     "minimum": 1024.0,
  16.     "type": "number"
  17. },
  18. "role": {
  19.     "description": "The Spark Dispatcher will register with Mesos with this role.",
  20.     "type": "string",
  21.     "default": "*"
  22. },
  • marathon.json.mustache:是一個模板,里面的一些變量會替換為config.json里面的內容,最終變成可以直接發送給marathon的請求。以spark為例
  1. "id": "{{service.name}}",
  2. "cpus": {{service.cpus}},
  3. "mem": {{service.mem}},
  4. "container": {
  5.     "type": "DOCKER",
  6.     "docker": {
  7.         "image": "{{resource.assets.container.docker.spark_docker}}",
  8.         "network": "HOST",
  9.         "forcePullImage": true
  10.     }
  11. },
  • resource.json:是一些資源,如image,tar.gz文件等
  1. "assets": {
  2.     "container": {
  3.         "docker": {
  4.             "spark_docker": "mesosphere/spark:1.0.2-2.0.0"
  5.         }
  6.     }
  7. },

所有的這些配置都像模板一樣已經預先寫好,安裝的時候界面上一點,或者一行命令就安裝好了。

當然你如果點擊Advanced Installation,則所有的配置都可以定制化

 

就像yum里面一樣,將mysql-server的yum包的制作者和mysql的使用者分開,普通用戶作為使用者,不需要了解太多的細節,用就是了。

 

如果想在數據中心里面使用package管理,可以生成自己的local universe,里面放入自己的應用,只要專業人士設計一次,便可以多次使用。也可以一次安裝多個軟件形成一個group,里面包含微服務的,也包含大數據的,兩者可以通過服務發現相互訪問。

 

我們在這里先安裝一個spark的軟件

 

最初安裝完畢spark,卻發現只有一個docker

Spark不是一個集群計算框架嗎,怎么會只有一個Docker呢?這就是mesos對大數據框架管理的特殊之處。在spark不運行任務的時候,就僅僅占用這一個docker,其實是一個框架。

安裝過程如圖所示:

  1. dcos package install spark會將請求提交給admin router
  2. admin router會將請求提交給cosmos,也即package管理的服務
  3. cosmos將config.json, resource.json, marathon.json組合成為一個marathon請求提交給marathon
  4. marathon將請求交給mesos-master,然后交給mesos-agent
  5. mesos-agent啟動一個容器運行spark
  6. 啟動的spark容器會注冊到mesos里面成為一個新的framework

 

真正運行spark任務的時候,才會有其他占用資源的任務被創建出來。

  1. dcos spark run --submit-args='-Dspark.mesos.coarse=true --driver-cores 1 --driver-memory 1024M --class org.apache.spark.examples.SparkPi https://downloads.mesosphere.com/spark/assets/spark-examples_2.10-1.4.0-SNAPSHOT.jar 30'

 

 

Spark運行過程如圖:

  1. dcos spark run將任務提交給admin router
  2. admin router將任務提交給spark framework
  3. spark framework將任務提交給mesos-master
  4. mesos-master將任務分發給mesos-agent進行分別處理
  5. 任務運行完畢后,所有mesos-agent上占用的資源又都釋放了。

 

正是這種模式,才實現微服務和大數據框架的共享資源,與此相對應的是使用Docker來部署spark集群,然后集群自管理,不歸mesos管理。這樣在創建spark集群的時候,就需要指定spark worker占用的資源,比如16G,然而這16G資源則無論spark是否在計算,都會被占用,都不會被其他的框架使用。

 

五、DC/OS 1.8的新功能

對於最新的DC/OS 1.8,有一個博客https://dcos.io/blog/2016/introducing-dc-os-1-8-ga/index.html描述了最新的功能。

 

其中第一個重要的功能為Mesos 1.0 and the Universal Container Runtime,也即可以使用mesos-containerizer來運行Docker的鏡像了。這也是DC/OS對於容器的管理越來越獨立的體現。

 

我們在mesos-agent所在的機器上可以查看

  1. ip-10-0-1-78 dcos.target.wants_slave # ps aux | grep mesos-agent
  2. root 1824 0.6 0.3 1069204 46948 ? Ssl Oct03 9:57 /opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent

mesos-agent的配置在路徑/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004下面,在/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/dcos.target.wants_slave/dcos-mesos-slave.service里面是mesos-slave的啟動參數的設置,通過mesos的文檔,我們知道對於mesos的參數可以使用環境變量進行設置。

  1. ip-10-0-1-78 dcos.target.wants_slave # cat dcos-mesos-slave.service
  2. [Unit]
  3. Description=Mesos Agent: DC/OS Mesos Agent Service
  4.  
  5. [Service]
  6. Restart=always
  7. StartLimitInterval=0
  8. RestartSec=5
  9. KillMode=control-group
  10. Delegate=true
  11. LimitNOFILE=infinity
  12. TasksMax=infinity
  13. EnvironmentFile=/opt/mesosphere/environment
  14. EnvironmentFile=/opt/mesosphere/etc/mesos-slave-common
  15. EnvironmentFile=/opt/mesosphere/etc/mesos-slave
  16. EnvironmentFile=/opt/mesosphere/etc/proxy.env
  17. EnvironmentFile=-/opt/mesosphere/etc/mesos-slave-common-extras
  18. EnvironmentFile=-/var/lib/dcos/mesos-slave-common
  19. EnvironmentFile=-/var/lib/dcos/mesos-resources
  20. EnvironmentFile=-/run/dcos/etc/mesos-slave
  21. ExecStartPre=/bin/ping -c1 ready.spartan
  22. ExecStartPre=/bin/ping -c1 leader.mesos
  23. ExecStartPre=/opt/mesosphere/bin/bootstrap dcos-mesos-slave
  24. ExecStartPre=/opt/mesosphere/bin/make_disk_resources.py /var/lib/dcos/mesos-resources
  25. ExecStartPre=/bin/bash -c 'for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 2 > $i; echo -n "$i: "; cat $i; done'
  26. ExecStart=/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent

 

在文件/opt/mesosphere/etc/mesos-slave-common中配置了大量的mesos-agent的參數

  1. MESOS_MASTER=zk://zk-1.zk:2181,zk-2.zk:2181,zk-3.zk:2181,zk-4.zk:2181,zk-5.zk:2181/mesos
  2. MESOS_CONTAINERIZERS=docker,mesos
  3. MESOS_LOG_DIR=/var/log/mesos
  4. MESOS_MODULES_DIR=/opt/mesosphere/etc/mesos-slave-modules
  5. MESOS_CONTAINER_LOGGER=org_apache_mesos_LogrotateContainerLogger
  6. MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume
  7. MESOS_DOCKER_VOLUME_CHECKPOINT_DIR=/var/lib/mesos/isolators/docker/volume
  8. MESOS_IMAGE_PROVIDERS=docker
  9. MESOS_NETWORK_CNI_CONFIG_DIR=/opt/mesosphere/etc/dcos/network/cni
  10. MESOS_NETWORK_CNI_PLUGINS_DIR=/opt/mesosphere/active/cni/
  11. MESOS_WORK_DIR=/var/lib/mesos/slave
  12. MESOS_SLAVE_SUBSYSTEMS=cpu,memory
  13. MESOS_EXECUTOR_ENVIRONMENT_VARIABLES=file:///opt/mesosphere/etc/mesos-executor-environment.json
  14. MESOS_EXECUTOR_REGISTRATION_TIMEOUT=10mins
  15. MESOS_CGROUPS_ENABLE_CFS=true
  16. MESOS_CGROUPS_LIMIT_SWAP=false
  17. MESOS_DOCKER_REMOVE_DELAY=1hrs
  18. MESOS_DOCKER_STOP_TIMEOUT=20secs
  19. MESOS_DOCKER_STORE_DIR=/var/lib/mesos/slave/store/docker
  20. MESOS_GC_DELAY=2days
  21. MESOS_HOSTNAME_LOOKUP=false
  22. GLOG_drop_log_memory=false

默認的mesos-containerizer的隔離只包括cpu和memory,然而在最新的mesos版本里面,多了provisioner這一層,在上面的配置里面隔離了MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume,從而可以啟動docker的鏡像了。

 

第二個最重要的功能是CNI, container network interface。

 

 

CNI要工作需要三部分:

首先DC/OS不需要外置的IPAM,而是由mesos-master的replicated_log負責管理分配IP地址,Mesos需要啟動的時候,載入overlay network的modules。

在路徑/opt/mesosphere/etc/mesos-slave-modules下面有文件overlay_slave_modules.json

  1. ip-10-0-1-78 mesos-slave-modules # cat overlay_slave_modules.json
  2. {
  3.   "libraries":
  4.   [
  5.     {
  6.       "file": "/opt/mesosphere/active/mesos-overlay-modules/lib/mesos/libmesos_network_overlay.so",
  7.       "modules":
  8.         [
  9.           {
  10.             "name": "com_mesosphere_mesos_OverlayAgentManager",
  11.             "parameters" :
  12.               [
  13.                 {
  14.                   "key": "agent_config",
  15.                   "value" : "/opt/mesosphere/etc/overlay/config/agent.json"
  16.                 }
  17.               ]
  18.           }
  19.         ]
  20.      }
  21.   ]
  22. }

其次需要載入CNI isolator,這個在MESOS_ISOLATION這個環境變量里面已經配置了。

最后還需要navstar服務來實現跨節點之間的IP互訪問

每個mesos-agent的機器上都有opt/mesosphere/packages/navstar--589afdaef03114a17576ee648ae433a052f7a4b9/,都會運行一個navstar進程。

每個機器上都會創建網卡d-dcos,如果Docker容器使用CNI獲取IP的容器都Attach到這個網卡上,而非docker0上。

每個機器上都會創建網卡m-dcos,如果mesos容器使用CNI獲取IP的容器都Attach到這個網卡上。

每台機器的d-dcos和m-dcos的網段都不同。

每台機器都會創建一個vtep1024的網卡,作為VTEP,背后是vxlan。

每台機器都會創建默認的路由表,從本節點連接到其他的節點默認走vtep1024這個網卡。

  1. 9.0.0.0/24 via 44.128.0.1 dev vtep1024
  2. 9.0.1.0/24 via 44.128.0.2 dev vtep1024
  3. 9.0.3.0/24 via 44.128.0.4 dev vtep1024

對DC/OS的網絡的配置在/opt/mesosphere/etc/dcos/network/cni路徑下

 

為了試驗這兩個新的功能,我們首先創建一個使用CNI的Mesos容器,但是啟動的是Docker的Image nginx

  1. {
  2.    "id":"nginxmesos",
  3.    "cmd":"env; ip -o addr; sleep 3600",
  4.    "cpus":0.10,
  5.    "mem":512,
  6.    "instances":1,
  7.    "ipAddress":{
  8.       "networkName":"dcos"
  9.    },
  10.    "container":{
  11.       "type":"MESOS",
  12.       "docker":{
  13.          "network":"USER",
  14.          "image":"nginx",
  15.          "portMappings":[
  16.             {
  17.                 "host_port": 0,
  18.                 "container_port": 80,
  19.                 "protocol": "tcp"
  20.             }
  21.          ]
  22.       }
  23.    }
  24. }

在日志里面,打印出來容器的IP地址是m-dcos網段的。

 

然后我們再啟動一個使用CNI的Docker容器

  1. {
  2.    "id":"nginxmesos1",
  3.    "cmd":"env; ip -o addr; sleep 3600",
  4.    "cpus":0.10,
  5.    "mem":512,
  6.    "instances":1,
  7.    "ipAddress":{
  8.       "networkName":"dcos"
  9.    },
  10.    "container":{
  11.       "type":"DOCKER",
  12.       "docker":{
  13.          "network":"USER",
  14.          "image":"nginx",
  15.          "portMappings":[
  16.             {
  17.                 "host_port": 0,
  18.                 "container_port": 80,
  19.                 "protocol": "tcp"
  20.             }
  21.          ]
  22.       }
  23.    }
  24. }

從日志我們看出,配置的IP是d-dcos網段的,而非docker0網段的。

 

從Mesos上我們看出這兩個容器是在兩個節點上的

 

登入Docker的容器,ping另外一個CNI的mesos的IP是沒有問題的。

  1. ip-10-0-1-78 cni # docker ps
  2. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
  3. e7908deb3017 nginx "/bin/sh -c 'env; ip " 28 minutes ago Up 28 minutes 80/tcp, 443/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.e3c96fa7-b5ff-4af6-9099-bbed399c7c37
  4. a992929fb0d1 nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:4989->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.fca41f8d-816c-49cd-9b19-ba059b95e885
  5. 8032756dd66e nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:27003->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.c0fdd3db-6f17-41d3-ab05-6f2d4d0bfa13
  6. ip-10-0-1-78 cni # docker exec -it e7908deb3017 bash
  7. root@e7908deb3017:/# ip addr
  8. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
  9.     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  10.     inet 127.0.0.1/8 scope host lo
  11.        valid_lft forever preferred_lft forever
  12.     inet6 ::1/128 scope host
  13.        valid_lft forever preferred_lft forever
  14. 51: eth0@if52: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc noqueue state UP group default
  15.     link/ether 02:42:09:00:03:82 brd ff:ff:ff:ff:ff:ff
  16.     inet 9.0.3.130/25 scope global eth0
  17.        valid_lft forever preferred_lft forever
  18.     inet6 fe80::42:9ff:fe00:382/64 scope link
  19.        valid_lft forever preferred_lft forever
  20. root@e7908deb3017:/# ping 9.0.2.13
  21. PING 9.0.2.13 (9.0.2.13): 56 data bytes
  22. 64 bytes from 9.0.2.13: icmp_seq=0 ttl=62 time=0.709 ms
  23. 64 bytes from 9.0.2.13: icmp_seq=1 ttl=62 time=0.535 ms
【參考資料】

1、DC/OS首頁、文檔和下載 - 數據中心操作系統 - 開源中國社區 http://www.oschina.net/p/dcos

2、DC/OS很難理解嗎? http://geek.csdn.net/news/detail/190111

3、DC/OS、電信行業、亞信_【VerisOS】 http://www.a-site.cn/article/300140.html

4、科學網—如何搭建DC/OS系統的框架私有服務器 - 李銘軒的博文 http://blog.sciencenet.cn/blog-50618-1008633.html

5、彈性服務平台DC/OS—概覽 https://baijiahao.baidu.com/s?id=1567763885994830

6、DCOS領域誕生一個100%開源的企業級Data Open DC/OS前世今生 -http://www.010lm.com/redian/2016/0430/1819984.html

7、深入解析DC/OS 1.8 – 高可靠的微服務及大數據管理平台 - popsuper1982 - 博客園 http://www.cnblogs.com/popsuper1982/p/5930827.html


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com