Hadoop與Kubernetes就好像江湖里的兩大絕世高手，一個是成名已久的長者，至今仍然名聲遠(yuǎn)揚(yáng)，一個則是初出茅廬的青澀少年，骨骼驚奇，不走尋常路，一出手便驚詫了整個武林。Hadoop與Kubernetes之間有很深的淵源，因為都出自IT豪門——Google，只不過，后者是親兒子，正因為有大佬背書，所以Kubernetes一出山，江湖各路門派便都蜂擁而至，擁護(hù)稱王。

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

Hadoop容器化的資料不少，但Hadoop部署在Kubernetes上的資料幾乎沒有，這主要是以下幾個原因?qū)е碌?#xff1a;

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

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

因此在Kubernetes建模之前，我們需要分別對這兩種集群的工作機(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)會訪問NameNode，因此，NameNode節(jié)點(diǎn)需要建模為Kubernetes Service以提供服務(wù)，以下是對應(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個服務(wù)端口：

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

為了減少Hadoop鏡像的數(shù)量，我們構(gòu)建了一個鏡像，并且通過容器的環(huán)境變量HADOOP_NODE_TYPE來區(qū)分不同的節(jié)點(diǎn)類型，從而啟動不同的Hadoop組件，下面是鏡像里的啟動腳本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

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

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

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

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

下面是HDFS Master節(jié)點(diǎn)Service對應(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方式在每個Kubernerntes節(jié)點(diǎn)上部署一個，在這里為了清晰起見，就沒有用這個方式 定義。接下來，我們來看看Yarn框架如何建模，下圖是Yarn框架的集群架構(gòu)圖：

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

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

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

Headless Service的特殊之處在于這種Service沒有分配Cluster IP，在Kuberntes DNS里Ping這種Service的名稱時，會返回后面對應(yīng)的Pod的IP地址，如果后面有多個Pod實(shí)例，則會隨機(jī)輪詢返回其中一個的Pod地址，我們用Headless Service建模NodeManger的時候，還有一個細(xì)節(jié)需要注意，即Pod的名字(容器的主機(jī)名)必須與對應(yīng)的Headless Service的名字一樣，這樣一來，當(dāng)運(yùn)行在容器里的NodeManger進(jìn)程向ResourceManager發(fā)起TCP連接的過程中會用到容器的主機(jī)名，而這個主機(jī)名恰好是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: v1 kind: Service metadata: name: yarn-node-1 spec: clusterIP: None selector: app: yarn-node-1 ports: - port: 8040

注意到定義中“clusterIP:None”這句話，表明這是一個Headless Service，沒有自己的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定義沒有什么特殊的地方，其中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

對應(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

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

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

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

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

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)，驗證剛才的操作結(jié)果：

接下來，我們再登錄到hadoop-master對應(yīng)的Pod上，啟動一個Map-Reduce測試作業(yè)——wordcount，作業(yè)啟動后，我們可以在Yarn的管理界面中看到作業(yè)的執(zhí)行信息，如下圖所示：

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

最后，我們進(jìn)行了裸機(jī)版Hadoop集群與Kubernetes之上的Hadoop集群的性能對比測試，測試環(huán)境為十臺服務(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)測試項：

• TestDFSIO：分布式系統(tǒng)讀寫測試
• NNBench：NameNode測試
• MRBench：MapReduce測試
• WordCount：單詞頻率統(tǒng)計任務(wù)測試
• TeraSort：TeraSort任務(wù)測試

綜合測試下來，Hadoop跑在Kuberntes集群上時，性能有所下降，以TestDFSIO的測試為例，下面是Hadoop集群文件讀取的性能測試對比：

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

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

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

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

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

感興趣的可以自己來我的Java架構(gòu)群，可以獲取免費(fèi)的學(xué)習(xí)資料，群號：855801563對Java技術(shù)，架構(gòu)技術(shù)感興趣的同學(xué)，歡迎加群，一起學(xué)習(xí)，相互討論。

總結(jié)

以上是生活随笔為你收集整理的hadoop没有datanode_Hadoop运行在Kubernetes平台实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。