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

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

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

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

1.資源隔離不徹底

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

2.資源利用效率低

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

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

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

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

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

Docker≠容器技術(shù)

Linux很早就推出了內(nèi)核虛擬化技術(shù)LXC，Docker是有Docker公司研發(fā)的，它把LXC做了進(jìn)一步的封裝（現(xiàn)在已經(jīng)替換成了它自己實(shí)現(xiàn)的libcontainer，加上鏡像管理等一系列功能，變成了一套完整、易用的容器引擎。2015年的dockerCon大會上，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ù)平臺Tectonic，Docker公司和CoreOS由此徹底決裂。后來Linux基金會出面調(diào)和，google也從中協(xié)調(diào)，雙方都退讓了一步，才最終和解推出了OCP，但是有心人可以看一下OCP項目的成員名單就知道，Dcoker公司在這中間只占很小的一部分，google在其中扮演了重要角色。此外Docker公司也放棄了自己對Docker技術(shù)的獨(dú)家控制權(quán)，做為回報Docker的容器實(shí)現(xiàn)被確定為OCP的新標(biāo)準(zhǔn)，但源代碼都必須提交給OCP委員會。不難看出google實(shí)際上是為了報當(dāng)年lmctfy的一箭之仇，借CoreOS之手狠踩了Docker公司一腳，自己也成為了容器技術(shù)領(lǐng)域的實(shí)際控制者

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

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

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

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

虛擬化≠等于云

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

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

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

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

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

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

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

魅族大數(shù)據(jù)目前已經(jīng)來到第三個階段，前兩個階段也是我們曾經(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)在可以通過一個命令直接從Docker Registry中pull對應(yīng)的鏡像，一鍵啟動。

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

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

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

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

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

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

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

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

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

資源的隔離其實(shí)使我們在使用docker之前面臨的一個大問題，經(jīng)常會由于ETL同學(xué)不是特別注意寫了一些有問題的任務(wù)腳本，上線后導(dǎo)致整個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容器啟動時通過啟動參數(shù)來實(shí)現(xiàn)，這里舉幾個簡單的例子：

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

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

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

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

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

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

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

所以如果容器內(nèi)的應(yīng)用使用root賬號啟動，而啟動時又帶上—priviledge參數(shù)的話，會導(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ī)會會在后續(xù)的分享中跟大家交流。

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

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

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

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

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

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

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

bin目錄用來存放鏡像服務(wù)的binary包以及shell腳本tmp目錄用來存放臨時文件，mz agent會定時進(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)控、報警、發(fā)布管理等相應(yīng)特性的實(shí)現(xiàn)。上層的平臺應(yīng)用只需要將一些必要的實(shí)現(xiàn)諸如到base鏡像中，就可以實(shí)現(xiàn)統(tǒng)一的運(yùn)行環(huán)境升級。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

另外我們遇到的一個無法忽略的就是多宿主機(jī)環(huán)境下的網(wǎng)絡(luò)問題，既然要在集群環(huán)境下運(yùn)行，那么如何在多宿主機(jī)的環(huán)境下讓各臺宿主機(jī)上運(yùn)行的容器都能分配到一個指定網(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ò)模塊如上圖所示，通過一個虛擬化的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)境，各個的宿主機(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是一個純layer 3 的解決方案，使用了一個etcd作為外部配置信息存儲，通過BGP廣播路由表配置，直接用主機(jī)的靜態(tài)路由表定義路由，整個過程沒有NAT，沒有Tunnel封包拆包過程。

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

小結(jié)

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

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

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

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

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

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

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

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

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

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

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