基于Kubernetes平臺部署Hadoop實踐

1、 基于Kubernetes平臺上部署Hadoop實踐Hadoop與Kubernetes就好像江湖里的兩大絕世高手，一個是成名已久的長者，至今仍然名聲遠揚，一個則是初出茅廬的青澀少年，骨骼驚奇，不走尋常路，一出手便驚詫了整個武林。Hadoop與Kubernetes之間有很深的淵源，因為都出自IT豪門Google，只不過，后者是親兒子，正因為有大佬背書，所以Kubernetes一出山，江湖各路門派便都蜂擁而至，擁護稱王。不知道是因為Hadoop是干兒子的緣故還是因為“廉頗老矣”，總之，Hadoop朋友圈的后輩們?nèi)鏢park、Storm等早都有了在Kubernetes上部署運行的各種資料和案例，但H

2、adoop卻一直游離于Kubernetes體系之外，本文我們給出Hadoop在Kubernetes上的實踐案例，以彌補這種缺憾。Hadoop容器化的資料不少，但Hadoop部署在Kubernetes上的資料幾乎沒有，這主要是以下幾個原因?qū)е碌模旱谝唬?Hadoop集群重度依賴DNS機制，一些組件還使用了反向域名解析，以確定集群中的節(jié)點身份，這對Hadoop在Kubernetes上的建模和運行帶來極大挑戰(zhàn)，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解決這一難題。第二， Hadoop新的Map-Reduce計算框架Yarn的模型出現(xiàn)的比較晚，它的集群機制要比HDFS

3、復(fù)雜，資料也相對較少，增加了Hadoop整體建模與遷移Kubernetes平臺的難度。第三， Hadoop與Kubernetes分別屬于兩個不同的領(lǐng)域，一個是傳統(tǒng)的大數(shù)據(jù)領(lǐng)域，一個是新興的容器與微服務(wù)架構(gòu)領(lǐng)域，這兩個領(lǐng)域之間交集本來很小，加之Hadoop最近幾年已經(jīng)失去焦點（這點從百度搜索關(guān)鍵詞就能發(fā)現(xiàn)），所以，沒有多少人關(guān)注和研究Hadoop在Kubernetes的部署問題，也是情理之中的事情。Hadoop 2.0其實是由兩套完整的集群所組成，一個是基本的HDFS文件集群，一個是YARN資源調(diào)度集群，如下圖所示：因此在Kubernetes建模之前，我們需要分別對這兩種集群的工作機制和運行原理

4、做出深入的分析，下圖是HDFS集群的架構(gòu)圖：我們看到，HDFS集群是由NameNode（Master節(jié)點）和Datanode（數(shù)據(jù)節(jié)點）等兩類節(jié)點所組成，其中，客戶端程序（Client）以及DataNode節(jié)點會訪問NameNode，因此，NameNode節(jié)點需要建模為Kubernetes Service以提供服務(wù)，以下是對應(yīng)的Service定義文件：apiVersion: v1kind: Servicemetadata: name: k8s-hadoop-masterspec: type: NodePort selector: app: k8s-hadoop-master ports: -

5、name: rpc port: 9000 targetPort: 9000 - name: http port: 50070 targetPort: 50070 nodePort: 32007其中，NameNode節(jié)點暴露2個服務(wù)端口：9000端口用于內(nèi)部IPC通信，主要用于獲取文件的元數(shù)據(jù)50070端口用于HTTP服務(wù)，為Hadoop 的Web管理使用為了減少Hadoop鏡像的數(shù)量，我們構(gòu)建了一個鏡像，并且通過容器的環(huán)境變量HADOOP_NODE_TYPE來區(qū)分不同的節(jié)點類型，從而啟動不同的Hadoop組件，下面是鏡像里的啟動腳本startnode.sh的內(nèi)容：#!/usr/bin/env

6、bashsed -i s/HDFS_MASTER_SERVICE/$HDFS_MASTER_SERVICE/g $HADOOP_HOME/etc/hadoop/core-site.xmlsed -i s/HDOOP_YARN_MASTER/$HDOOP_YARN_MASTER/g $HADOOP_HOME/etc/hadoop/yarn-site.xmlyarn-masterHADOOP_NODE=$HADOOP_NODE_TYPEif $HADOOP_NODE = datanode ; then echo Start DataNode . hdfs datanode -regularelse

7、 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

8、 fi我們注意到，啟動命令里把Hadoop配置文件（core-site.xml與yarn-site.xml）中的HDFS Master節(jié)點地址用環(huán)境變量中的參數(shù)HDFS_MASTER_SERVICE來替換，YARN Master節(jié)點地址則用HDOOP_YARN_MASTER來替換。下圖是Hadoop HDFS 2節(jié)點集群的完整建模示意圖：圖中的圓圈表示Pod，可以看到，Datanode并沒有建模Kubernetes Service，而是建模為獨立的Pod，這是因為Datanode并不直接被客戶端所訪問，因此無需建模Service。當Datanode運行在Pod容器里的時候，我們需要修改配置文件

9、中的以下參數(shù)，取消DataNode節(jié)點所在主機的主機名（DNS）與對應(yīng)IP地址的檢查機制：node.datanode.registration.ip-hostname-check=false如果上述參數(shù)沒有修改，就會出現(xiàn)DataNode集群“分裂”的假象，因為Pod的主機名無法對應(yīng)Pod的IP地址，因此界面會顯示2個節(jié)點，這兩個節(jié)點都狀態(tài)都為異常狀態(tài)。下面是HDFS Master節(jié)點Service對應(yīng)的Pod定義：apiVersion: v1kind: Podmetadata: name: k8s-hadoop-master labels: app: k8s-hadoop-masterspec

10、: 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 - nam

11、e: HDOOP_YARN_MASTER valueFrom: configMapKeyRef: name: ku8-hadoop-conf key: HDOOP_YARN_MASTER restartPolicy: Always下面是HDFS的Datanode的節(jié)點定義（hadoop-datanode-1）：apiVersion: v1kind: Podmetadata: name: hadoop-datanode-1 labels: app: hadoop-datanode-1spec: containers: - name: hadoop-datanode-1 image: kubegu

12、ide/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

13、: ku8-hadoop-conf key: HDOOP_YARN_MASTER restartPolicy: Always實際上，Datanode可以用DaemonSet方式在每個Kubernerntes節(jié)點上部署一個，在這里為了清晰起見，就沒有用這個方式 定義。接下來，我們來看看Yarn框架如何建模，下圖是Yarn框架的集群架構(gòu)圖：我們看到，Yarn集群中存在兩種角色的節(jié)點：ResourceManager以及NodeManger，前者屬于Yarn集群的頭腦（Master），后者是工作承載節(jié)點（Work Node），這個架構(gòu)雖然與HDFS很相似，但因為一個重要細節(jié)的差別，無法沿用HDFS的建

14、模方式，這個細節(jié)就是Yarn集群中的ResourceManager要對NodeManger節(jié)點進行嚴格驗證，即NodeManger節(jié)點的節(jié)點所在主機的主機名（DNS）與對應(yīng)IP地址嚴格匹配，簡單來說，就是要符合如下規(guī)則：NodeManger建立TCP連接時所用的IP地址，必須是該節(jié)點主機名對應(yīng)的IP地址，即主機DNS名稱解析后返回節(jié)點的IP地址。所以我們采用了Kubernetes里較為特殊的一種ServiceHeadless Service來解決這個問題，即為每個NodeManger節(jié)點建模一個Headless Service與對應(yīng)的Pod，下面是一個ResourceManager與兩個Nod

15、eManger節(jié)點所組成的Yarn集群的建模示意圖：Headless Service的特殊之處在于這種Service沒有分配Cluster IP，在Kuberntes DNS里Ping這種Service的名稱時，會返回后面對應(yīng)的Pod的IP地址，如果后面有多個Pod實例，則會隨機輪詢返回其中一個的Pod地址，我們用Headless Service建模NodeManger的時候，還有一個細節(jié)需要注意，即Pod的名字（容器的主機名）必須與對應(yīng)的Headless Service的名字一樣，這樣一來，當運行在容器里的NodeManger進程向ResourceManager發(fā)起TCP連接的過程中會用到容

16、器的主機名，而這個主機名恰好是NodeManger Service的服務(wù)名，而這個服務(wù)名解析出來的IP地址又剛好是容器的IP地址，這樣一來，就巧妙的解決了Yarn集群的DNS限制問題。下面以yarn-node-1為例，給出對應(yīng)的Service與Pod的YAM文件，首先是yarn-node-1對應(yīng)的Headless Service的YAM定義：apiVersion: v1kind: Servicemetadata: name: yarn-node-1spec: clusterIP: None selector: app: yarn-node-1 ports: - port: 8040注意到定義中

17、“clusterIP:None”這句話，表明這是一個Headless Service，沒有自己的Cluster IP地址，下面給出YAM文件定義：apiVersion: v1kind: Podmetadata: name: yarn-node-1 labels: app: yarn-node-1spec: containers: - name: yarn-node-1 image: kubeguide/hadoop imagePullPolicy: IfNotPresent ports: - containerPort: 8040 - containerPort: 8041 - contain

18、erPort: 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: AlwaysResourceManager的YA

19、ML定義沒有什么特殊的地方，其中Service定義如下：apiVersion: v1kind: Servicemetadata: name: ku8-yarn-masterspec: 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對應(yīng)的Pod定義如下：apiVersion: v1kind:

20、Podmetadata: name: yarn-master labels: app: yarn-masterspec: 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: configMapKeyR

21、ef: 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 NameNode節(jié)點重啟后的文件系統(tǒng)格式化問題，這個問題可以通過啟動腳本來解決，即判斷HDFS文件系統(tǒng)是否已經(jīng)格式化過，如果沒有，就啟動時候執(zhí)行格式化命令，否則跳過格式化命令。安裝完畢后，我們可以通過瀏覽器訪

22、問Hadoop的HDFS管理界面，點擊主頁上的Overview頁簽會顯示我們熟悉的HDFS界面：切換到Datanodes頁簽，可以看到每個Datanodes的的信息以及當前狀態(tài)：接下來，我們可以登錄到NameNode所在的Pod里并執(zhí)行HDSF命令進行功能性驗證，下面的命令執(zhí)行結(jié)果是建立一個HDFS目錄，并且上傳一個文件到此目錄中：roothadoop-master:/usr/local/hadoop/bin# hadoop fs -ls /roothadoop-master:/usr/local/hadoop/bin# hadoop fs -mkdir /leader-usroothadoo

23、p-master:/usr/local/hadoop/bin# hadoop fs -ls /Found 1 itemsdrwxr-xr-x - root supergroup 0 2017-02-17 07:32 /leader-usroothadoop-master:/usr/local/hadoop/bin# hadoop fs -put hdfs.cmd /leader-us然后，我們可以在HDFS管理界面中瀏覽HDFS文件系統(tǒng)，驗證剛才的操作結(jié)果：接下來，我們再登錄到hadoop-master對應(yīng)的Pod上，啟動一個Map-Reduce測試作業(yè)wordcount，作業(yè)啟動后，我們可以在Yarn的管理界面中看到作業(yè)的執(zhí)行信息，如下圖所示：當作業(yè)執(zhí)行完成后，可以通過界面看到詳細的統(tǒng)計信息，比如wordcount的執(zhí)行結(jié)果如下圖所示：最后，我們進行了裸機版Hadoop集群與Kubernetes之上的Hadoop集群的性能對比測試，測試環(huán)境為十臺服務(wù)器組成的集群，具體參數(shù)如下：硬件：CPU：2*E5-2640v3-8Cor