這篇文章主要為大家展示了“Hadoop如何運(yùn)行在Kubernetes平臺(tái)”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Hadoop如何運(yùn)行在Kubernetes平臺(tái)”這篇文章吧。

創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),安陽縣企業(yè)網(wǎng)站建設(shè),安陽縣品牌網(wǎng)站建設(shè),網(wǎng)站定制,安陽縣網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,安陽縣網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

Hadoop與Kubernetes就好像江湖里的兩大絕世高手，一個(gè)是成名已久的長者，至今仍然名聲遠(yuǎn)揚(yáng)，一個(gè)則是初出茅廬的青澀少年，骨骼驚奇，不走尋常路，一出手便驚詫了整個(gè)武林。Hadoop與Kubernetes之間有很深的淵源，因?yàn)槎汲鲎訧T豪門——Google，只不過，后者是親兒子，正因?yàn)橛写罄斜硶?，所以Kubernetes一出山，江湖各路門派便都蜂擁而至，擁護(hù)稱王。
不知道是因?yàn)镠adoop是干兒子的緣故還是因?yàn)椤傲H老矣”，總之，Hadoop朋友圈的后輩們?nèi)鏢park、Storm等早都有了在Kubernetes上部署運(yùn)行的各種資料和案例，但Hadoop卻一直游離于Kubernetes體系之外，本文我們給出Hadoop在Kubernetes上的實(shí)踐案例，以彌補(bǔ)這種缺憾。
Hadoop容器化的資料不少，但Hadoop部署在Kubernetes上的資料幾乎沒有，這主要是以下幾個(gè)原因?qū)е碌模?br/>第一， Hadoop集群重度依賴DNS機(jī)制，一些組件還使用了反向域名解析，以確定集群中的節(jié)點(diǎn)身份，這對(duì)Hadoop在Kubernetes上的建模和運(yùn)行帶來極大挑戰(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)域之間交集本來很小，加之Hadoop最近幾年已經(jīng)失去焦點(diǎn)(這點(diǎn)從百度搜索關(guān)鍵詞就能發(fā)現(xiàn))，所以，沒有多少人關(guān)注和研究Hadoop在Kubernetes的部署問題，也是情理之中的事情。
Hadoop 2.0其實(shí)是由兩套完整的集群所組成，一個(gè)是基本的HDFS文件集群，一個(gè)是YARN資源調(diào)度集群，如下圖所示：
因此在Kubernetes建模之前，我們需要分別對(duì)這兩種集群的工作機(jī)制和運(yùn)行原理做出深入的分析，下圖是HDFS集群的架構(gòu)圖：

Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
我們看到，HDFS集群是由NameNode(Master節(jié)點(diǎn))和Datanode(數(shù)據(jù)節(jié)點(diǎn))等兩類節(jié)點(diǎn)所組成，其中，客戶端程序(Client)以及DataNode節(jié)點(diǎn)會(huì)訪問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è)鏡像，并且通過容器的環(huán)境變量HADOOP_NODE_TYPE來區(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來替換，YARN Master節(jié)點(diǎn)地址則用HDOOP_YARN_MASTER來替換。下圖是Hadoop HDFS 2節(jié)點(diǎn)集群的完整建模示意圖：

Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
圖中的圓圈表示Pod，可以看到，Datanode并沒有建模Kubernetes Service，而是建模為獨(dú)立的Pod，這是因?yàn)镈atanode并不直接被客戶端所訪問，因此無需建模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ù)沒有修改，就會(huì)出現(xiàn)DataNode集群“分裂”的假象，因?yàn)镻od的主機(jī)名無法對(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è)，在這里為了清晰起見，就沒有用這個(gè)方式 定義。接下來，我們來看看Yarn框架如何建模，下圖是Yarn框架的集群架構(gòu)圖：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  我們看到，Yarn集群中存在兩種角色的節(jié)點(diǎn)：ResourceManager以及NodeManger，前者屬于Yarn集群的頭腦(Master)，后者是工作承載節(jié)點(diǎn)(Work Node)，這個(gè)架構(gòu)雖然與HDFS很相似，但因?yàn)橐粋€(gè)重要細(xì)節(jié)的差別，無法沿用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)格匹配，簡單來說，就是要符合如下規(guī)則：
  NodeManger建立TCP連接時(shí)所用的IP地址，必須是該節(jié)點(diǎn)主機(jī)名對(duì)應(yīng)的IP地址，即主機(jī)DNS名稱解析后返回節(jié)點(diǎn)的IP地址。
  所以我們采用了Kubernetes里較為特殊的一種Service——Headless Service來解決這個(gè)問題，即為每個(gè)NodeManger節(jié)點(diǎn)建模一個(gè)Headless Service與對(duì)應(yīng)的Pod，下面是一個(gè)ResourceManager與兩個(gè)NodeManger節(jié)點(diǎn)所組成的Yarn集群的建模示意圖：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  Headless Service的特殊之處在于這種Service沒有分配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的名字一樣，這樣一來，當(dāng)運(yùn)行在容器里的NodeManger進(jìn)程向ResourceManager發(fā)起TCP連接的過程中會(huì)用到容器的主機(jī)名，而這個(gè)主機(jī)名恰好是NodeManger Service的服務(wù)名，而這個(gè)服務(wù)名解析出來的IP地址又剛好是容器的IP地址，這樣一來，就巧妙的解決了Yarn集群的DNS限制問題。
  下面以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，沒有自己的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
  對(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è)問題有待解決：HDFS NameNode節(jié)點(diǎn)重啟后的文件系統(tǒng)格式化問題，這個(gè)問題可以通過啟動(dòng)腳本來解決，即判斷HDFS文件系統(tǒng)是否已經(jīng)格式化過，如果沒有，就啟動(dòng)時(shí)候執(zhí)行格式化命令，否則跳過格式化命令。
  安裝完畢后，我們可以通過瀏覽器訪問Hadoop的HDFS管理界面，點(diǎn)擊主頁上的Overview頁簽會(huì)顯示我們熟悉的HDFS界面：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  切換到Datanodes頁簽，可以看到每個(gè)Datanodes的的信息以及當(dāng)前狀態(tài)：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  接下來，我們可以登錄到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é)果：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  接下來，我們?cè)俚卿浀絟adoop-master對(duì)應(yīng)的Pod上，啟動(dòng)一個(gè)Map-Reduce測試作業(yè)——wordcount，作業(yè)啟動(dòng)后，我們可以在Yarn的管理界面中看到作業(yè)的執(zhí)行信息，如下圖所示：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  當(dāng)作業(yè)執(zhí)行完成后，可以通過界面看到詳細(xì)的統(tǒng)計(jì)信息，比如wordcount的執(zhí)行結(jié)果如下圖所示：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  最后，我們進(jìn)行了裸機(jī)版Hadoop集群與Kubernetes之上的Hadoop集群的性能對(duì)比測試，測試環(huán)境為十臺(tái)服務(wù)器組成的集群，具體參數(shù)如下：
  硬件：
  CPU：2E5-2640v3-8Core
  內(nèi)存：1616G DDR4
  網(wǎng)卡：210GE多模光口
  硬盤：123T 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)測試項(xiàng)：
  TestDFSIO：分布式系統(tǒng)讀寫測試
  NNBench：NameNode測試
  MRBench：MapReduce測試
  WordCount：單詞頻率統(tǒng)計(jì)任務(wù)測試
  TeraSort：TeraSort任務(wù)測試
  綜合測試下來，Hadoop跑在Kuberntes集群上時(shí)，性能有所下降，以TestDFSIO的測試為例，下面是Hadoop集群文件讀取的性能測試對(duì)比：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  我們看到，Kubernetes集群上的文件讀性能與物理機(jī)相比，下降了差不多30%左右，并且任務(wù)執(zhí)行時(shí)間也增加不少，再來對(duì)比文件寫入的性能，測試結(jié)果如下下圖所示：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  我們看到，寫文件性能的差距并不大，這里的主要原因是在測試過程中，HDFS寫磁盤的速度遠(yuǎn)遠(yuǎn)低于讀磁盤的速度，因此無法拉開差距。
  之所以部署在Kuberntes上的Hadoop集群的性能會(huì)有所下降，主要一個(gè)原因是容器虛擬網(wǎng)絡(luò)所帶來的性能損耗，如果用Host Only模型，則兩者之間的差距會(huì)進(jìn)一步縮小，下圖是TestDFSIO測試中Hadoop集群文件讀取的性能測試對(duì)比：
  
  Hadoop 運(yùn)行在 Kubernetes平臺(tái)實(shí)踐
  因此我們建議在生產(chǎn)環(huán)境中采用Host Only的網(wǎng)絡(luò)模型，以提升Hadoop的集群性能。
  攻下Hadoop在Kubernetes上的部署，并且在生產(chǎn)中加以驗(yàn)證，我們可以很自豪的說，現(xiàn)在沒有什么能夠難倒應(yīng)用向Kubernetes的遷移的步伐，采用統(tǒng)一的PaaS構(gòu)建企業(yè)的應(yīng)用集群和大數(shù)據(jù)集群，實(shí)現(xiàn)資源的共享和服務(wù)的統(tǒng)一管理將會(huì)大大的提升企業(yè)的業(yè)務(wù)部署速度和管理的效率。

以上是“Hadoop如何運(yùn)行在Kubernetes平臺(tái)”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

標(biāo)題名稱：Hadoop如何運(yùn)行在Kubernetes平臺(tái)-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://chinadenli.net/article32/cejepc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、自適應(yīng)網(wǎng)站、云服務(wù)器、網(wǎng)站營銷、電子商務(wù)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)