Hadoop與Kubernetes就好像江湖里的兩大絕世高手，一個(gè)是成名已久的長(zhǎng)者，至今仍然名聲遠(yuǎn)揚(yáng)，一個(gè)則是初出茅廬的青澀少年，骨骼驚奇，不走尋常路，一出手便驚詫了整個(gè)武林。Hadoop與Kubernetes之間有很深的淵源，因?yàn)槎汲鲎訧T豪門——Google，只不過(guò)，后者是親兒子，正因?yàn)橛写罄斜硶訩ubernetes一出山，江湖各路門派便都蜂擁而至，擁護(hù)稱王。

不知道是因?yàn)镠adoop是干兒子的緣故還是因?yàn)?ldquo;廉頗老矣”，總之，Hadoop朋友圈的后輩們?nèi)鏢park、Storm等早都有了在Kubernetes上部署運(yùn)行的各種資料和案例，但Hadoop卻一直游離于Kubernetes體系之外，本文我們給出Hadoop在Kubernetes上的實(shí)踐案例，以彌補(bǔ)這種缺憾。

Hadoop容器化的資料不少，但Hadoop部署在Kubernetes上的資料幾乎沒(méi)有，這主要是以下幾個(gè)原因?qū)е碌模?/p>

• 第一， Hadoop集群重度依賴DNS機(jī)制，一些組件還使用了反向域名解析，以確定集群中的節(jié)點(diǎn)身份，這對(duì)Hadoop在Kubernetes上的建模和運(yùn)行帶來(lái)極大挑戰(zhàn)，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解決這一難題。
• 第二， Hadoop新的Map-Reduce計(jì)算框架Yarn的模型出現(xiàn)的比較晚，它的集群機(jī)制要比HDFS復(fù)雜，資料也相對(duì)較少，增加了Hadoop整體建模與遷移Kubernetes平臺(tái)的難度。
• 第三， Hadoop與Kubernetes分別屬于兩個(gè)不同的領(lǐng)域，一個(gè)是傳統(tǒng)的大數(shù)據(jù)領(lǐng)域，一個(gè)是新興的容器與微服務(wù)架構(gòu)領(lǐng)域，這兩個(gè)領(lǐng)域之間交集本來(lái)很小，加之Hadoop最近幾年已經(jīng)失去焦點(diǎn)(這點(diǎn)從百度搜索關(guān)鍵詞就能發(fā)現(xiàn))，所以，沒(méi)有多少人關(guān)注和研究Hadoop在Kubernetes的部署問(wèn)題，也是情理之中的事情。

Hadoop 2.0其實(shí)是由兩套完整的集群所組成，一個(gè)是基本的HDFS文件集群，一個(gè)是YARN資源調(diào)度集群，如下圖所示：

因此在Kubernetes建模之前，我們需要分別對(duì)這兩種集群的工作機(jī)制和運(yùn)行原理做出深入的分析，下圖是HDFS集群的架構(gòu)圖：

我們看到，HDFS集群是由NameNode(Master節(jié)點(diǎn))和Datanode(數(shù)據(jù)節(jié)點(diǎn))等兩類節(jié)點(diǎn)所組成，其中，客戶端程序(Client)以及DataNode節(jié)點(diǎn)會(huì)訪問(wèn)NameNode，因此，NameNode節(jié)點(diǎn)需要建模為Kubernetes Service以提供服務(wù)，以下是對(duì)應(yīng)的Service定義文件：

apiVersion: v1 
kind: Service 
metadata: 
name: k8s-hadoop-master 
spec: 
type: NodePort 
selector: 
app: k8s-hadoop-master 
ports: 
- name: rpc 
  port: 9000 
  targetPort: 9000 
- name: http 
  port: 50070 
  targetPort: 50070 
  nodePort: 32007 

其中，NameNode節(jié)點(diǎn)暴露2個(gè)服務(wù)端口：

• 9000端口用于內(nèi)部IPC通信，主要用于獲取文件的元數(shù)據(jù)
• 50070端口用于HTTP服務(wù)，為Hadoop 的Web管理使用

為了減少Hadoop鏡像的數(shù)量，我們構(gòu)建了一個(gè)鏡像，并且通過(guò)容器的環(huán)境變量HADOOP_NODE_TYPE來(lái)區(qū)分不同的節(jié)點(diǎn)類型，從而啟動(dòng)不同的Hadoop組件，下面是鏡像里的啟動(dòng)腳本startnode.sh的內(nèi)容：

#!/usr/bin/env bash 
sed -i "s/@HDFS_MASTER_SERVICE@/$HDFS_MASTER_SERVICE/g" $HADOOP_HOME/etc/hadoop/core-site.xml 
sed -i "s/@HDOOP_YARN_MASTER@/$HDOOP_YARN_MASTER/g" $HADOOP_HOME/etc/hadoop/yarn-site.xml 
yarn-master 
HADOOP_NODE="${HADOOP_NODE_TYPE}" 
if [ $HADOOP_NODE = "datanode" ]; then 
    echo "Start DataNode ..." 
    hdfs datanode  -regular 
 
else 
if [  $HADOOP_NODE = "namenode" ]; then 
    echo "Start NameNode ..." 
    hdfs namenode 
else 
    if [ $HADOOP_NODE = "resourceman" ]; then 
        echo "Start Yarn Resource Manager ..." 
        yarn resourcemanager 
    else 
 
         if [ $HADOOP_NODE = "yarnnode" ]; then 
             echo "Start Yarn Resource Node  ..." 
             yarn nodemanager    
         else               
            echo "not recoginized nodetype " 
         fi 
    fi 
fi   
 
fi 

我們注意到，啟動(dòng)命令里把Hadoop配置文件(core-site.xml與yarn-site.xml)中的HDFS Master節(jié)點(diǎn)地址用環(huán)境變量中的參數(shù)HDFS_MASTER_SERVICE來(lái)替換，YARN Master節(jié)點(diǎn)地址則用HDOOP_YARN_MASTER來(lái)替換。下圖是Hadoop HDFS 2節(jié)點(diǎn)集群的完整建模示意圖：

圖中的圓圈表示Pod，可以看到，Datanode并沒(méi)有建模Kubernetes Service，而是建模為獨(dú)立的Pod，這是因?yàn)镈atanode并不直接被客戶端所訪問(wèn)，因此無(wú)需建模Service。當(dāng)Datanode運(yùn)行在Pod容器里的時(shí)候，我們需要修改配置文件中的以下參數(shù)，取消DataNode節(jié)點(diǎn)所在主機(jī)的主機(jī)名(DNS)與對(duì)應(yīng)IP地址的檢查機(jī)制：

dfs.namenode.datanode.registration.ip-hostname-check=false 

如果上述參數(shù)沒(méi)有修改，就會(huì)出現(xiàn)DataNode集群“分裂”的假象，因?yàn)镻od的主機(jī)名無(wú)法對(duì)應(yīng)Pod的IP地址，因此界面會(huì)顯示2個(gè)節(jié)點(diǎn)，這兩個(gè)節(jié)點(diǎn)都狀態(tài)都為異常狀態(tài)。

下面是HDFS Master節(jié)點(diǎn)Service對(duì)應(yīng)的Pod定義：

apiVersion: v1 
kind: Pod 
metadata: 
name: k8s-hadoop-master 
labels: 
app: k8s-hadoop-master 
spec: 
containers: 
- name: k8s-hadoop-master 
  image: kubeguide/hadoop 
  imagePullPolicy: IfNotPresent 
  ports: 
    - containerPort: 9000 
    - containerPort: 50070     
  env: 
    - name: HADOOP_NODE_TYPE 
      value: namenode 
    - name: HDFS_MASTER_SERVICE 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDFS_MASTER_SERVICE 
    - name: HDOOP_YARN_MASTER 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDOOP_YARN_MASTER 
restartPolicy: Always 

下面是HDFS的Datanode的節(jié)點(diǎn)定義(hadoop-datanode-1)：

apiVersion: v1 
kind: Pod 
metadata: 
name: hadoop-datanode-1 
labels: 
  app: hadoop-datanode-1 
spec: 
containers: 
- name: hadoop-datanode-1 
  image: kubeguide/hadoop 
  imagePullPolicy: IfNotPresent 
  ports: 
    - containerPort: 9000 
    - containerPort: 50070     
  env: 
    - name: HADOOP_NODE_TYPE 
      value: datanode 
    - name: HDFS_MASTER_SERVICE 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDFS_MASTER_SERVICE 
    - name: HDOOP_YARN_MASTER 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDOOP_YARN_MASTER         
restartPolicy: Always 

實(shí)際上，Datanode可以用DaemonSet方式在每個(gè)Kubernerntes節(jié)點(diǎn)上部署一個(gè)，在這里為了清晰起見，就沒(méi)有用這個(gè)方式 定義。接下來(lái)，我們來(lái)看看Yarn框架如何建模，下圖是Yarn框架的集群架構(gòu)圖：

我們看到，Yarn集群中存在兩種角色的節(jié)點(diǎn)：ResourceManager以及NodeManger，前者屬于Yarn集群的頭腦(Master)，后者是工作承載節(jié)點(diǎn)(Work Node)，這個(gè)架構(gòu)雖然與HDFS很相似，但因?yàn)橐粋€(gè)重要細(xì)節(jié)的差別，無(wú)法沿用HDFS的建模方式，這個(gè)細(xì)節(jié)就是Yarn集群中的ResourceManager要對(duì)NodeManger節(jié)點(diǎn)進(jìn)行嚴(yán)格驗(yàn)證，即NodeManger節(jié)點(diǎn)的節(jié)點(diǎn)所在主機(jī)的主機(jī)名(DNS)與對(duì)應(yīng)IP地址嚴(yán)格匹配，簡(jiǎn)單來(lái)說(shuō)，就是要符合如下規(guī)則：

NodeManger建立TCP連接時(shí)所用的IP地址，必須是該節(jié)點(diǎn)主機(jī)名對(duì)應(yīng)的IP地址，即主機(jī)DNS名稱解析后返回節(jié)點(diǎn)的IP地址。

所以我們采用了Kubernetes里較為特殊的一種Service——Headless Service來(lái)解決這個(gè)問(wèn)題，即為每個(gè)NodeManger節(jié)點(diǎn)建模一個(gè)Headless Service與對(duì)應(yīng)的Pod，下面是一個(gè)ResourceManager與兩個(gè)NodeManger節(jié)點(diǎn)所組成的Yarn集群的建模示意圖：

Headless Service的特殊之處在于這種Service沒(méi)有分配Cluster IP，在Kuberntes DNS里Ping這種Service的名稱時(shí)，會(huì)返回后面對(duì)應(yīng)的Pod的IP地址，如果后面有多個(gè)Pod實(shí)例，則會(huì)隨機(jī)輪詢返回其中一個(gè)的Pod地址，我們用Headless Service建模NodeManger的時(shí)候，還有一個(gè)細(xì)節(jié)需要注意，即Pod的名字(容器的主機(jī)名)必須與對(duì)應(yīng)的Headless Service的名字一樣，這樣一來(lái)，當(dāng)運(yùn)行在容器里的NodeManger進(jìn)程向ResourceManager發(fā)起TCP連接的過(guò)程中會(huì)用到容器的主機(jī)名，而這個(gè)主機(jī)名恰好是NodeManger Service的服務(wù)名，而這個(gè)服務(wù)名解析出來(lái)的IP地址又剛好是容器的IP地址，這樣一來(lái)，就巧妙的解決了Yarn集群的DNS限制問(wèn)題。

下面以yarn-node-1為例，給出對(duì)應(yīng)的Service與Pod的YAM文件，首先是yarn-node-1對(duì)應(yīng)的Headless Service的YAM定義：

apiVersion: v1 
kind: Service 
metadata: 
name: yarn-node-1 
spec: 
clusterIP: None 
selector: 
app: yarn-node-1 
ports: 
 - port: 8040 

注意到定義中“clusterIP:None”這句話，表明這是一個(gè)Headless Service，沒(méi)有自己的Cluster IP地址，下面給出YAM文件定義：

apiVersion: v1 
kind: Pod 
metadata: 
name: yarn-node-1 
labels: 
app: yarn-node-1 
spec: 
containers: 
- name: yarn-node-1 
  image: kubeguide/hadoop 
  imagePullPolicy: IfNotPresent 
  ports: 
    - containerPort: 8040 
    - containerPort: 8041    
    - containerPort: 8042         
  env: 
    - name: HADOOP_NODE_TYPE 
      value: yarnnode 
    - name: HDFS_MASTER_SERVICE 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDFS_MASTER_SERVICE 
    - name: HDOOP_YARN_MASTER 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDOOP_YARN_MASTER           
restartPolicy: Always 

ResourceManager的YAML定義沒(méi)有什么特殊的地方，其中Service定義如下：

apiVersion: v1 
kind: Service 
metadata: 
name: ku8-yarn-master 
spec: 
type: NodePort 
selector: 
app: yarn-master 
ports: 
 - name: "8030"        
   port: 8030 
 - name: "8031"      
   port: 8031 
 - name: "8032" 
   port: 8032      
 - name: http 
   port: 8088 
   targetPort: 8088 
   nodePort: 32088 

對(duì)應(yīng)的Pod定義如下：

apiVersion: v1 
kind: Pod 
metadata: 
name: yarn-master 
labels: 
app: yarn-master 
spec: 
containers: 
- name: yarn-master 
  image: kubeguide/hadoop 
  imagePullPolicy: IfNotPresent 
  ports: 
    - containerPort: 9000 
    - containerPort: 50070     
  env: 
    - name: HADOOP_NODE_TYPE 
      value: resourceman 
    - name: HDFS_MASTER_SERVICE 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDFS_MASTER_SERVICE 
    - name: HDOOP_YARN_MASTER 
      valueFrom: 
        configMapKeyRef: 
          name: ku8-hadoop-conf 
          key: HDOOP_YARN_MASTER           
restartPolicy: Always 

目前這個(gè)方案，還遺留了一個(gè)問(wèn)題有待解決：HDFS NameNode節(jié)點(diǎn)重啟后的文件系統(tǒng)格式化問(wèn)題，這個(gè)問(wèn)題可以通過(guò)啟動(dòng)腳本來(lái)解決，即判斷HDFS文件系統(tǒng)是否已經(jīng)格式化過(guò)，如果沒(méi)有，就啟動(dòng)時(shí)候執(zhí)行格式化命令，否則跳過(guò)格式化命令。

安裝完畢后，我們可以通過(guò)瀏覽器訪問(wèn)Hadoop的HDFS管理界面，點(diǎn)擊主頁(yè)上的Overview頁(yè)簽會(huì)顯示我們熟悉的HDFS界面：

切換到Datanodes頁(yè)簽，可以看到每個(gè)Datanodes的的信息以及當(dāng)前狀態(tài)：

接下來(lái)，我們可以登錄到NameNode所在的Pod里并執(zhí)行HDSF命令進(jìn)行功能性驗(yàn)證，下面的命令執(zhí)行結(jié)果是建立一個(gè)HDFS目錄，并且上傳一個(gè)文件到此目錄中：

root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -ls  / 
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -mkdir /leader-us 
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -ls / 
Found 1 items 
drwxr-xr-x   - root supergroup          0 2017-02-17 07:32 /leader-us 
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -put hdfs.cmd /leader-us 

然后，我們可以在HDFS管理界面中瀏覽HDFS文件系統(tǒng)，驗(yàn)證剛才的操作結(jié)果：

接下來(lái)，我們?cè)俚卿浀絟adoop-master對(duì)應(yīng)的Pod上，啟動(dòng)一個(gè)Map-Reduce測(cè)試作業(yè)——wordcount，作業(yè)啟動(dòng)后，我們可以在Yarn的管理界面中看到作業(yè)的執(zhí)行信息，如下圖所示：

當(dāng)作業(yè)執(zhí)行完成后，可以通過(guò)界面看到詳細(xì)的統(tǒng)計(jì)信息，比如wordcount的執(zhí)行結(jié)果如下圖所示：

最后，我們進(jìn)行了裸機(jī)版Hadoop集群與Kubernetes之上的Hadoop集群的性能對(duì)比測(cè)試，測(cè)試環(huán)境為十臺(tái)服務(wù)器組成的集群，具體參數(shù)如下：

硬件：

• CPU：2*E5-2640v3-8Core
• 內(nèi)存：16*16G DDR4
• 網(wǎng)卡：2*10GE多模光口
• 硬盤：12*3T SATA

軟件：

• BigCloud Enterprise Linux 7(GNU/Linux 3.10.0-514.el7.x86_64 x86_64)
• Hadoop2.7.2
• Kubernetes 1.7.4+ Calico V3.0.1

我們執(zhí)行了以下這些標(biāo)準(zhǔn)測(cè)試項(xiàng)：

• TestDFSIO：分布式系統(tǒng)讀寫測(cè)試
• NNBench：NameNode測(cè)試
• MRBench：MapReduce測(cè)試
• WordCount：?jiǎn)卧~頻率統(tǒng)計(jì)任務(wù)測(cè)試
• TeraSort：TeraSort任務(wù)測(cè)試

綜合測(cè)試下來(lái)，Hadoop跑在Kuberntes集群上時(shí)，性能有所下降，以TestDFSIO的測(cè)試為例，下面是Hadoop集群文件讀取的性能測(cè)試對(duì)比：

我們看到，Kubernetes集群上的文件讀性能與物理機(jī)相比，下降了差不多30%左右，并且任務(wù)執(zhí)行時(shí)間也增加不少，再來(lái)對(duì)比文件寫入的性能，測(cè)試結(jié)果如下下圖所示：

我們看到，寫文件性能的差距并不大，這里的主要原因是在測(cè)試過(guò)程中，HDFS寫磁盤的速度遠(yuǎn)遠(yuǎn)低于讀磁盤的速度，因此無(wú)法拉開差距。

之所以部署在Kuberntes上的Hadoop集群的性能會(huì)有所下降，主要一個(gè)原因是容器虛擬網(wǎng)絡(luò)所帶來(lái)的性能損耗，如果用Host Only模型，則兩者之間的差距會(huì)進(jìn)一步縮小，下圖是TestDFSIO測(cè)試中Hadoop集群文件讀取的性能測(cè)試對(duì)比：

因此我們建議在生產(chǎn)環(huán)境中采用Host Only的網(wǎng)絡(luò)模型，以提升Hadoop的集群性能。

攻下Hadoop在Kubernetes上的部署，并且在生產(chǎn)中加以驗(yàn)證，我們可以很自豪的說(shuō)，現(xiàn)在沒(méi)有什么能夠難倒應(yīng)用向Kubernetes的遷移的步伐，采用統(tǒng)一的PaaS構(gòu)建企業(yè)的應(yīng)用集群和大數(shù)據(jù)集群，實(shí)現(xiàn)資源的共享和服務(wù)的統(tǒng)一管理將會(huì)大大的提升企業(yè)的業(yè)務(wù)部署速度和管理的效率。