魅族大數(shù)據(jù)上云之路

首先我先介紹一下魅族大數(shù)據(jù)上云的背景，即我們?yōu)槭裁匆显疲?

在開始之前我們默認(rèn)今天參與直播的各位同學(xué)對Hadoop相關(guān)技術(shù)和Docker都有一定的了解，另外以下提到Hadoop是泛指目前魅族大數(shù)據(jù)使用的Hadoop生態(tài)圈技術(shù)，資源除特別說明則泛指存儲(chǔ)資源、計(jì)算資源和網(wǎng)絡(luò)資源的總和。

我們先來看一下魅族大數(shù)據(jù)在沒有上云的時(shí)候所遇到的主要問題有以下幾個(gè)方面：

1.資源隔離不徹底

由于一些歷史問題，我們跑在Hadoop上的任務(wù)腳本質(zhì)量參差不齊，導(dǎo)致經(jīng)常有一些異常任務(wù)會(huì)短時(shí)間吃掉所有的機(jī)器資源，導(dǎo)致整臺(tái)機(jī)器down掉。

2.資源利用效率低

目前我們的業(yè)務(wù)增速很快，每個(gè)Q都需要一定數(shù)量的機(jī)器擴(kuò)容，但是業(yè)務(wù)的增速往往不是線性的，為某些關(guān)鍵時(shí)間點(diǎn)的峰值需求而準(zhǔn)備的機(jī)器常常在峰值過去之后存在大量的資源閑置。

3.集群運(yùn)維成本高

由于一些存儲(chǔ)、網(wǎng)絡(luò)方面的物理故障以及異常任務(wù)導(dǎo)致故障恢復(fù)都需要運(yùn)維同學(xué)人工介入。常見的高可用解決方案都需要侵入到Hadoop技術(shù)體系內(nèi)部，有一定技術(shù)門檻。公共運(yùn)維部門的同學(xué)無法很好的支持大數(shù)據(jù)團(tuán)隊(duì)服務(wù)器運(yùn)維。集群部署模型復(fù)雜，過程繁瑣

基于以上這些存在的問題，我們經(jīng)過一番技術(shù)預(yù)研發(fā)現(xiàn)，上云之后可以很好的解決我們的問題。

在討論上云的總體規(guī)劃之前，我覺得有必要先把幾個(gè)非常重要但是卻容易混淆的概念先做一下簡單解釋，這里只是點(diǎn)到為止，希望這對大家理解后面的內(nèi)容會(huì)很有幫助

Docker≠容器技術(shù)

Linux很早就推出了內(nèi)核虛擬化技術(shù)LXC，Docker是有Docker公司研發(fā)的，它把LXC做了進(jìn)一步的封裝（現(xiàn)在已經(jīng)替換成了它自己實(shí)現(xiàn)的libcontainer，加上鏡像管理等一系列功能，變成了一套完整、易用的容器引擎。2015年的dockerCon大會(huì)上，docker和CoreOS共同推出了Open Container Project 來統(tǒng)一容器的定義和實(shí)現(xiàn)標(biāo)準(zhǔn)）。

這里提一些圈兒內(nèi)的軼事給大家提供點(diǎn)兒談資：

剛才提到的OCP（Open Container Project）的建立，google才是背后的真正推手，因?yàn)楫?dāng)年Docker的快速發(fā)展，打敗了google曾經(jīng)的開源容器技術(shù)lmctfy，Docker公司和CoreOS原本和睦，共同發(fā)展Docker技術(shù)，后來由于意見上的分歧，兩家都想做容器技術(shù)的標(biāo)準(zhǔn)制定者，google暗中支持CoreOS，后來CoreOS隨即自立門戶，發(fā)布了自己的容器技術(shù)Rocket，并且和google的kubernetes合作發(fā)布了容器服務(wù)平臺(tái)Tectonic，Docker公司和CoreOS由此徹底決裂。后來Linux基金會(huì)出面調(diào)和，google也從中協(xié)調(diào)，雙方都退讓了一步，才最終和解推出了OCP，但是有心人可以看一下OCP項(xiàng)目的成員名單就知道，Dcoker公司在這中間只占很小的一部分，google在其中扮演了重要角色。此外Docker公司也放棄了自己對Docker技術(shù)的獨(dú)家控制權(quán)，做為回報(bào)Docker的容器實(shí)現(xiàn)被確定為OCP的新標(biāo)準(zhǔn)，但源代碼都必須提交給OCP委員會(huì)。不難看出google實(shí)際上是為了報(bào)當(dāng)年lmctfy的一箭之仇，借CoreOS之手狠踩了Docker公司一腳，自己也成為了容器技術(shù)領(lǐng)域的實(shí)際控制者

總結(jié)下來Docker只是眾多容器技術(shù)中的一種，只是由于它最近的火爆而幾就成了容器技術(shù)的代名詞。

容器技術(shù)≠虛擬化技術(shù)

容器技術(shù)只是實(shí)現(xiàn)虛擬化的一種輕量級的解決方案，常見的虛擬化方案還包括

KVM、Xen和vmware的解決方案等。

虛擬化≠等于云

虛擬化技術(shù)只是一個(gè)完整云服務(wù)體系中包含的一個(gè)技術(shù)手段，但不是全部，甚至不是必須的。完全使用物理機(jī)也可以搭建一個(gè)云。

常見的云服務(wù)體系中的核心服務(wù)還包括：

認(rèn)證服務(wù)鏡像服務(wù)網(wǎng)絡(luò)服務(wù)（例如：SDN（軟件定義網(wǎng)絡(luò)）和物理網(wǎng)絡(luò)）計(jì)算服務(wù)（管理、分配、調(diào)度計(jì)算任務(wù)）對象存儲(chǔ)服務(wù)（直接為應(yīng)用提供數(shù)據(jù)讀寫服務(wù)）塊存儲(chǔ)服務(wù)（為主機(jī)提供類似裸物理磁盤的存儲(chǔ)服務(wù)）

（以上的分類方式參考了亞馬遜AWS的云服務(wù)體系）

魅族大數(shù)據(jù)上云的一個(gè)整體規(guī)劃，基本上分為3個(gè)大的階段：

PART I — Hadoop on DockerPART II — Container Cluster Management SystemPART III — Hadoop on Cloud Operating System

（這次分享針對PART I的內(nèi)容）

魅族大數(shù)據(jù)目前已經(jīng)來到第三個(gè)階段，前兩個(gè)階段也是我們曾經(jīng)走過的，由于今天篇幅的限制重點(diǎn)介紹第一部分，hadoop on docker的內(nèi)容。

Hadoop on Docker方案演進(jìn)

首先來說明一下我們?yōu)槭裁匆?a href='/map/docker/' style='color:#000;font-size:inherit;'>docker，通過在Docker 上部署Hadoop，我們可以實(shí)現(xiàn)：有效的提升集群部署效率，原本需要運(yùn)維手工部署的過程，現(xiàn)在可以通過一個(gè)命令直接從Docker Registry中pull對應(yīng)的鏡像，一鍵啟動(dòng)。

安全性：在Docker中運(yùn)行的應(yīng)用，在沒有主動(dòng)配置的情況下，基本無法訪問宿主機(jī)的文件系統(tǒng)，這樣可以很好的保護(hù)宿主機(jī)的文件系統(tǒng)和其他設(shè)備。

資源調(diào)控/隔離：Docker可以對應(yīng)用所需要的資源，如CPU計(jì)算資源、內(nèi)存資源、存儲(chǔ)資源、網(wǎng)絡(luò)帶寬等進(jìn)行調(diào)控（資源調(diào)控目前只支持容器啟動(dòng)前的一次性配置），不會(huì)因?yàn)閱我蝗蝿?wù)的一場導(dǎo)致整個(gè)hadoop集群掛起。

一致性：只要源自同一個(gè)鏡像，hadoop集群中的任何節(jié)點(diǎn)都可以保持統(tǒng)一的軟件環(huán)境，不會(huì)由于管理員的人為失誤導(dǎo)致集群環(huán)境不一致。

可用性：由于容器節(jié)點(diǎn)的輕量級特征，我們可以非常方便的部署一些針對namenode 的HA方案。另外即使遇到極端情況集群整個(gè)掛掉，我們也可以快速的重啟整個(gè)hadoop集群。

開發(fā)者只需要關(guān)心代碼本身，代碼編寫完成后提交到Git，之后的構(gòu)建，測試、build docker 鏡像，提交鏡像到docker registry都可以由jenkins自動(dòng)化完成，運(yùn)維只需要負(fù)責(zé)在合適的機(jī)器上啟動(dòng)對應(yīng)鏡像的服務(wù)即可。

目前魅族大數(shù)據(jù)已經(jīng)經(jīng)歷過docker方案的預(yù)研和實(shí)施，并且在線下測試和開發(fā)環(huán)境中已經(jīng)開始使用docker驅(qū)動(dòng)DevOps提高開發(fā)->測試的效率，目前在測試環(huán)境中docker宿主機(jī)集群規(guī)模50+，容器數(shù)1000+。

在這個(gè)過程中，我們也經(jīng)歷了從單純的docker，到一個(gè)完整的容器云環(huán)境的演變，docker的build ship run理念看起來很美，但是實(shí)際使用起來如果只有docker還是會(huì)面臨很多的問題和挑戰(zhàn)。

具體的原因我分了以下幾個(gè)方面來介紹，這些也是我們曾經(jīng)踩過的坑，是構(gòu)建一個(gè)完善的云計(jì)算環(huán)境來服務(wù)大數(shù)據(jù)技術(shù)不可避免的幾個(gè)核心點(diǎn)。

資源隔離/動(dòng)態(tài)分配

資源的隔離其實(shí)使我們在使用docker之前面臨的一個(gè)大問題，經(jīng)常會(huì)由于ETL同學(xué)不是特別注意寫了一些有問題的任務(wù)腳本，上線后導(dǎo)致整個(gè)hadoop集群資源耗盡，關(guān)鍵任務(wù)出現(xiàn)延遲甚至失敗，運(yùn)維的同學(xué)每天被這種問題折騰的死去活來。

而采用了docker之后，Docker通過libcontainer調(diào)用linux內(nèi)核的相關(guān)技術(shù)（現(xiàn)在windows和其他操作系統(tǒng)也開始native支持容器技術(shù)了，具體進(jìn)展大家可以關(guān)注Open ContainerProject和docker的官網(wǎng)）實(shí)現(xiàn)了容器間的資源隔離，資源的分配可以在docker容器啟動(dòng)時(shí)通過啟動(dòng)參數(shù)來實(shí)現(xiàn)，這里舉幾個(gè)簡單的例子：

CPU配額控制：docker run-it –rm stress –cpu 4

–cpu代表指定CPU的配額參數(shù)，4代表配額的值，這里的配額可以簡單理解為CPU的占用率，比如一個(gè)宿主機(jī)中有兩個(gè)容器在運(yùn)行時(shí)都指定了—cpu 4，則相當(dāng)于運(yùn)行時(shí)這兩個(gè)容器各站CPU配額的50%，注意這里的配額并不是一個(gè)嚴(yán)格的限制，在剛才的例子中，如果容器1完全空閑，則容器2是可以完全占用100%的CPU的，當(dāng)容器1開始使用CPU時(shí)，則容器2的CPU配額才會(huì)逐步下降，直到兩個(gè)容器都各站50%為止。

內(nèi)存控制：docker run-it –rm -m 128m

-m參數(shù)指定了內(nèi)存限制的大小，注意這里的值指的只是物理內(nèi)存空間的限制，docker在運(yùn)行容器的時(shí)候會(huì)分配一個(gè)和指定物理內(nèi)存空間一樣大的swap空間，也就是說，應(yīng)用在運(yùn)行期占用內(nèi)存達(dá)到了-m參數(shù)指定值的兩倍時(shí)，才會(huì)出現(xiàn)內(nèi)存不足的情況。

Docker的資源限制目前必須在容器啟動(dòng)時(shí)手工完成，但是在大規(guī)模集群的環(huán)境下，手工逐一根據(jù)物理機(jī)的資源情況進(jìn)行配額的指定顯然是不現(xiàn)實(shí)的。而且docker并不支持存儲(chǔ)空間的配額限制，只能限制讀寫的速率。

Docker現(xiàn)階段還不能滿足需求，我們需要一個(gè)可以根據(jù)集群的實(shí)際運(yùn)行情況進(jìn)行計(jì)算資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源的合理分配的解決方案。

我們經(jīng)過實(shí)踐的檢驗(yàn)，發(fā)現(xiàn)Docker的資源隔離相比于傳統(tǒng)虛擬機(jī)技術(shù)還是有很多做的不徹底的地方，除了上面所屬的之外，在安全上也一直存在一些比較大的隱患，比如docker一直以來都不支持user namespace。

所以如果容器內(nèi)的應(yīng)用使用root賬號啟動(dòng)，而啟動(dòng)時(shí)又帶上—priviledge參數(shù)的話，會(huì)導(dǎo)致容器內(nèi)的root和宿主機(jī)的root權(quán)限一直，帶來非常大的安全隱患。在這里稍微補(bǔ)充一點(diǎn)，在最新的1.10版本的docker中已經(jīng)支持了user namespace（通過–userns-remap參數(shù)）。

但是魅族大數(shù)據(jù)并沒有升級到這一版，這也是由于我們的服務(wù)編排和容器集群管理使用的是google開源的kubernetes，目前最新版的kubernetes1.2官方聲明最新支持的docker版本只到1.9，有關(guān)kubernetes的內(nèi)容有機(jī)會(huì)會(huì)在后續(xù)的分享中跟大家交流。

定義鏡像/存儲(chǔ)結(jié)構(gòu)

定義存儲(chǔ)結(jié)構(gòu)的目的是為了實(shí)現(xiàn)部署環(huán)境的標(biāo)準(zhǔn)化，之前我們也嘗試過直接提供一個(gè)帶SSH服務(wù)的容器節(jié)點(diǎn)，這樣感覺用起來跟虛擬機(jī)是沒什么差別，但是這樣一來之前虛擬機(jī)運(yùn)維時(shí)碰到的各種環(huán)境不一致的問題還是會(huì)出現(xiàn)，docker的多層鏡像結(jié)構(gòu)的優(yōu)勢就完全沒有發(fā)揮出來。

通過一個(gè)base鏡像定義好一套標(biāo)準(zhǔn)，這就像maven的parent pom一樣（這個(gè)比喻有些不夠恰當(dāng)，maven更多的是進(jìn)行包依賴的管理，而docker的多層鏡像存儲(chǔ)結(jié)構(gòu)可以定義一個(gè)完整的基礎(chǔ)運(yùn)行環(huán)境，并且這個(gè)環(huán)境是可以繼承的），可以給大家提供一個(gè)標(biāo)準(zhǔn)的環(huán)境基礎(chǔ)設(shè)置，另外上層應(yīng)用非常方便的可以收集容器中的數(shù)據(jù)，使用容器的服務(wù)。

首先我們按照部署模型劃分鏡像結(jié)構(gòu)，對每一個(gè)Hadoop生態(tài)中的服務(wù)都抽象出一個(gè)對應(yīng)的鏡像，這個(gè)服務(wù)鏡像包含了主從架構(gòu)的兩套配置，使用環(huán)境變量來區(qū)分該服務(wù)鏡像到底是作為master還是slave部署。

這樣做的好處是可以降低鏡像的數(shù)量，方便做配置和服務(wù)版本的管理和升級，另外需要注意的是mz agent，這是我們自定義的一個(gè)鏡像，用來進(jìn)行臨時(shí)文件的清理、日志數(shù)據(jù)收集，以及對接第三方的監(jiān)控服務(wù)實(shí)現(xiàn)，向我們的監(jiān)控平臺(tái)發(fā)送自定義的一些集群健康度指標(biāo)數(shù)據(jù)。

此外它還負(fù)責(zé)接收客戶端的管理指令請求，可以讓集群管理員像操作一臺(tái)服務(wù)器一樣的對整個(gè)集群或集群中的特定主機(jī)進(jìn)行操作。

為了方便做統(tǒng)一的監(jiān)控和存儲(chǔ)的管理，我們在鏡像內(nèi)定義了一些基本的目錄結(jié)構(gòu)

bin目錄用來存放鏡像服務(wù)的binary包以及shell腳本tmp目錄用來存放臨時(shí)文件，mz agent會(huì)定時(shí)進(jìn)行文件的清理data存放一些需要持久化的數(shù)據(jù)文件，通過volume掛載到宿主機(jī)的目錄中，包括一些需要進(jìn)行分析的應(yīng)用日志，應(yīng)用的數(shù)據(jù)文件等。conf保存服務(wù)相關(guān)配置信息鏡像管理使用git+docker registry，git中保存鏡像的構(gòu)建過程，Dockerfile，docker registry保存實(shí)際鏡像。

這樣定義鏡像結(jié)構(gòu)可以幫助我們通過統(tǒng)一的標(biāo)準(zhǔn)更好的進(jìn)行監(jiān)控、報(bào)警、發(fā)布管理等相應(yīng)特性的實(shí)現(xiàn)。上層的平臺(tái)應(yīng)用只需要將一些必要的實(shí)現(xiàn)諸如到base鏡像中，就可以實(shí)現(xiàn)統(tǒng)一的運(yùn)行環(huán)境升級。

這里會(huì)存在一個(gè)問題，docker容器在運(yùn)行時(shí)產(chǎn)生的數(shù)據(jù)是保存在宿主機(jī)的特定目錄的，而且這些數(shù)據(jù)的生命周期跟容器的生命周期一樣，一但容器銷毀，則這些數(shù)據(jù)也會(huì)一并刪除，如果將HDFS部署在容器中，這也是不能容忍的。

我們?nèi)绻ㄟ^volume的方式將數(shù)據(jù)掛載到宿主機(jī)則會(huì)導(dǎo)致宿主機(jī)中存在大量跟容器的ID相關(guān)的存儲(chǔ)目錄，而且一旦節(jié)點(diǎn)掛掉想要在其他節(jié)點(diǎn)上啟動(dòng)相同的服務(wù)還需要進(jìn)行數(shù)據(jù)的遷移。大規(guī)模集群的環(huán)境下在每個(gè)節(jié)點(diǎn)上管理這些目錄會(huì)帶來額外的運(yùn)維成本。

為了解決這一問題，我們需要一個(gè)存儲(chǔ)管理的服務(wù)來托管容器運(yùn)行時(shí)生成的數(shù)據(jù)，使得Hadoop集群能夠隨時(shí)創(chuàng)建，隨時(shí)銷毀。集群內(nèi)的應(yīng)用服務(wù)不需要關(guān)心運(yùn)行時(shí)生成的數(shù)據(jù)存放在哪里，如何管理等等。

在分布式環(huán)境下運(yùn)行容器

由于hadoop生態(tài)圈技術(shù)的特點(diǎn)，docker必須部署在分布式的環(huán)境中，而這會(huì)帶來很多新的挑戰(zhàn)。如果有熟悉docker的同學(xué)就會(huì)發(fā)現(xiàn)一個(gè)問題，HDFS默認(rèn)會(huì)將數(shù)據(jù)做3個(gè)副本。

但docker可以在同一個(gè)宿主機(jī)中啟動(dòng)多個(gè)容器，如果這三個(gè)副本都落在了同一個(gè)宿主機(jī)上，那么一但宿主機(jī)down掉，三個(gè)副本就一起失效，HDFS的這種利用多副本來提高數(shù)據(jù)可用性的策略就無效了。

不僅是HDFS，其他需要通過類似雙master或多副本的結(jié)構(gòu)來做HA的方案都會(huì)遇到同樣的問題。

在只使用docker的情況下，只能通過人工的方式，將namenode和datanode分開在不同的宿主機(jī)上啟動(dòng)。

這樣一來，一但某個(gè)容器內(nèi)的服務(wù)掛掉，為了保持有足夠數(shù)量的服務(wù)中容器，則需要運(yùn)維的同學(xué)人工的通過監(jiān)控平臺(tái)去檢查集群目前各宿主機(jī)的負(fù)載和健康度情況，同時(shí)結(jié)合不同容器服務(wù)的部署架構(gòu)要求選擇合適的宿主機(jī)啟動(dòng)容器。

雖然最后部署的動(dòng)作已經(jīng)相對自動(dòng)化，但是選擇部署服務(wù)器的過程依然是痛苦的。

再補(bǔ)充一點(diǎn)，如果希望升級Hadoop生態(tài)中的某個(gè)服務(wù)的版本，一般都是先在測試環(huán)境進(jìn)行部署驗(yàn)證，ok之后才會(huì)將鏡像發(fā)送到線上的Registry，這就涉及到了如何隔離測試和線上生產(chǎn)環(huán)境的問題，不同環(huán)境的存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)資源必須相對隔離。

如果是在運(yùn)行中的集群中更新服務(wù)的版本則還會(huì)涉及到灰度發(fā)布的問題。如果線上集群已經(jīng)存在了多個(gè)版本的服務(wù)，則還要考慮個(gè)版本升級過程是否有差異，是否需要進(jìn)行滾動(dòng)發(fā)布等，這些docker暫時(shí)都不能幫我們解決，僅僅依靠人工或者自己搭建平臺(tái)來完成依然需要很大的工作量。

這也就引出了Docker僅僅作為一個(gè)容器引擎的不足，如果需要大規(guī)模的部署，我們需要一個(gè)容器調(diào)度管理服務(wù)，來按照我們指定的策略分配容器運(yùn)行的實(shí)際宿主機(jī)。同時(shí)能夠根據(jù)預(yù)定義的發(fā)布更新策略，對運(yùn)行中的容器服務(wù)進(jìn)行動(dòng)態(tài)的滾動(dòng)更新（rolling update）

多宿主機(jī)網(wǎng)絡(luò)解決方案

另外我們遇到的一個(gè)無法忽略的就是多宿主機(jī)環(huán)境下的網(wǎng)絡(luò)問題，既然要在集群環(huán)境下運(yùn)行，那么如何在多宿主機(jī)的環(huán)境下讓各臺(tái)宿主機(jī)上運(yùn)行的容器都能分配到一個(gè)指定網(wǎng)段內(nèi)的IP，并且彼此之間可以進(jìn)行正常網(wǎng)絡(luò)通信。

由于大數(shù)據(jù)相關(guān)的應(yīng)用和服務(wù)往往需要進(jìn)行大量的網(wǎng)絡(luò)吞吐，這一方案在性能上也不能有很大的損失。

Docker自帶的網(wǎng)絡(luò)模塊如上圖所示，通過一個(gè)虛擬化的docker0網(wǎng)橋，把主機(jī)上的eth0端口和docker engine內(nèi)部的container通過veth pair連接到一起，容器間的網(wǎng)絡(luò)通訊都是通過docker0網(wǎng)橋來轉(zhuǎn)發(fā)，容器帶外網(wǎng)的請求是通過docker0網(wǎng)橋來進(jìn)行NAT轉(zhuǎn)換后發(fā)送到外網(wǎng)，這樣的網(wǎng)絡(luò)方案能夠在單一宿主機(jī)上解決網(wǎng)絡(luò)通信的問題。

但一旦進(jìn)入多宿主機(jī)的集群環(huán)境，各個(gè)的宿主機(jī)上運(yùn)行的容器就無法得知彼此的IP網(wǎng)段和路由信息。

在Docker的技術(shù)體系中，解決這一問題目前主流的方案有以下幾種：

Dockernetworking（from 1.9）FlannelOpenvSwitchWeavecalico

這幾種解決方案的優(yōu)缺點(diǎn)和適用場景涉及內(nèi)容很多，有興趣的同學(xué)可以參考一下這篇文章。

http://www.chunqi.li/2015/11/15/Battlefield-Calico-Flannel-Weave-and-Docker-Overlay-Network/

我們采用了上述的最后一種calico，主要是出于性能上的考慮，calico是一個(gè)純layer 3 的解決方案，使用了一個(gè)etcd作為外部配置信息存儲(chǔ)，通過BGP廣播路由表配置，直接用主機(jī)的靜態(tài)路由表定義路由，整個(gè)過程沒有NAT，沒有Tunnel封包拆包過程。

使得數(shù)據(jù)包的體積減小，降低了網(wǎng)絡(luò)開銷，所以只要理論上layer3可達(dá)的網(wǎng)絡(luò)環(huán)境，同時(shí)對協(xié)議支持的要求不是太苛刻（由于是layer3 的解決方案，所以只支持TCP、UDP、ICMP協(xié)議）同時(shí)對性能、吞吐量、網(wǎng)絡(luò)延遲有要求的場景都是適合的。當(dāng)然其他的解決方案也有他們的適用場景，具體大家可以參考上面的那篇文章。

小結(jié)

今天由于時(shí)間關(guān)系沒辦法把Hadoop on Docker方案的方方面面都做詳細(xì)的介紹，因此主要選了一些重點(diǎn)的問題和挑戰(zhàn)來跟大家分享，主要的內(nèi)容就到這里了，但是還有一些上面提到的遺留問題沒有深入下去：

如何搭建一個(gè)存儲(chǔ)管理的服務(wù)來托管容器運(yùn)行時(shí)生成的數(shù)據(jù)，使得Hadoop集群能夠隨時(shí)創(chuàng)建，隨時(shí)銷毀。集群內(nèi)的應(yīng)用服務(wù)不需要關(guān)心運(yùn)行時(shí)生成的數(shù)據(jù)存放在哪里，如何管理等等。

如何搭建一個(gè)容器調(diào)度管理服務(wù)，來按照我們指定的策略分配容器運(yùn)行的實(shí)際宿主機(jī)。同時(shí)能夠根據(jù)預(yù)定義的發(fā)布更新策略，對運(yùn)行中的容器服務(wù)進(jìn)行動(dòng)態(tài)的滾動(dòng)更新（rolling update）。

網(wǎng)絡(luò)方面，如何在一個(gè)多集群、多租戶的環(huán)境下有效的管理和分配網(wǎng)絡(luò)資源，讓各集群之間相對隔離，又有統(tǒng)一的網(wǎng)關(guān)可以彼此訪問。

如何對一個(gè)復(fù)雜的微服務(wù)環(huán)境進(jìn)行編排和管理。

這些都是構(gòu)建一個(gè)完善云服務(wù)所不能避免的問題，docker自身也深知這些問題，如果細(xì)心關(guān)注docker的官方網(wǎng)站就會(huì)看到，他們也在通過docker-machine、docker-compose、docker-swarm等意圖為docker打造一個(gè)完整的解決方案，使其拜托最初人們認(rèn)為docker只是一個(gè)容器引擎這樣的印象。

魅族大數(shù)據(jù)為了能夠在生產(chǎn)環(huán)境中搭建一套完整的容器云服務(wù)環(huán)境，針對這些問題實(shí)踐出了一套解決方案，基本架構(gòu)組成是

Docker 容器引擎Registry負(fù)責(zé)鏡像管理Kubernetes容器編排，集群資源管理監(jiān)控Swift 存儲(chǔ)服務(wù)

目前已經(jīng)有30%的任務(wù)量運(yùn)行在這套容器云平臺(tái)下，線下、測試、正式三套環(huán)境通過registry配合kubennetes的跨namespace調(diào)度實(shí)現(xiàn)任務(wù)的快速發(fā)布和更新。

除了hadoop集群之外，我們自己的平臺(tái)應(yīng)用也正在逐步的遷移到這套環(huán)境當(dāng)中。但為了保證線上任務(wù)的穩(wěn)定性，hadoop集群和平臺(tái)應(yīng)用集群是namespace和宿主機(jī)雙隔離的。

今天的內(nèi)容都是以單純的docker為主，其他幾塊的內(nèi)容以后可以在Hadoop on Container Cluster Management System和Hadoop on Cloud Operating System當(dāng)中再跟大家逐一介紹。