基于Kubernetes平台部署Hadoop实践.docx

基于Kubernetes平台上部署Hadoop实践Hadoop与Kubernetes就好像江湖里的两大绝世高手，一个是成名已久的长者，至今仍然名声远扬，一个则是初出茅庐的青涩少年，骨骼惊奇，不走寻常路，一出手便惊诧了整个武林。Hadoop与Kubernetes之间有很深的渊源，因为都出自IT豪门——Google，只不过，后者是亲儿子，正因为有大佬背书，所以Kubernetes一出山，江湖各路门派便都蜂拥而至，拥护称王。不知道是因为Hadoop是干儿子的缘故还是因为“廉颇老矣”，总之，Hadoop朋友圈的后辈们如Spark、Storm等早都有了在Kubernetes上部署运行的各种资料和案例，但Hadoop却一直游离于Kubernetes体系之外，本文我们给出Hadoop在Kubernetes上的实践案例，以弥补这种缺憾。Hadoop容器化的资料不少，但Hadoop部署在Kubernetes上的资料几乎没有，这主要是以下几个原因导致的：第一， Hadoop集群重度依赖DNS机制，一些组件还使用了反向域名解析，以确定集群中的节点身份，这对Hadoop在Kubernetes上的建模和运行带来极大挑战，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解决这一难题。第二， Hadoop新的Map-Reduce计算框架Yarn的模型出现的比较晚，它的集群机制要比HDFS复杂，资料也相对较少，增加了Hadoop整体建模与迁移Kubernetes平台的难度。第三， Hadoop与Kubernetes分别属于两个不同的领域，一个是传统的大数据领域，一个是新兴的容器与微服务架构领域，这两个领域之间交集本来很小，加之Hadoop最近几年已经失去焦点（这点从百度搜索关键词就能发现），所以，没有多少人关注和研究Hadoop在Kubernetes的部署问题，也是情理之中的事情。Hadoop 2.0其实是由两套完整的集群所组成，一个是基本的HDFS文件集群，一个是YARN资源调度集群，如下图所示：因此在Kubernetes建模之前，我们需要分别对这两种集群的工作机制和运行原理做出深入的分析，下图是HDFS集群的架构图：我们看到，HDFS集群是由NameNode（Master节点）和Datanode（数据节点）等两类节点所组成，其中，客户端程序（Client）以及DataNode节点会访问NameNode，因此，NameNode节点需要建模为Kubernetes Service以提供服务，以下是对应的Service定义文件：apiVersion: v1kind: Servicemetadata: ?name: k8s-hadoop-masterspec: ?type: NodePort ?selector: ? ?app: k8s-hadoop-master ?ports: ? ?- name: rpc ? ? ?port: 9000 ? ? ?targetPort: 9000 ? ?- name: http ? ? ?port: 50070 ? ? ?targetPort: 50070 ? ? ?nodePort: 32007其中，NameNode节点暴露2个服务端口：9000端口用于内部IPC通信，主要用于获取文件的元数据50070端口用于HTTP服务，为Hadoop 的Web管理使用为了减少Hadoop镜像的数量，我们构建了一个镜像，并且通过容器的环境变量HADOOP_NODE_TYPE来区分不同的节点类型，从而启动不同的Hadoop组件，下面是镜像里的启动脚本startnode.sh的内容：#!/usr/bin/env bashsed -is/@HDFS_MASTER_SERVICE@/$HDFS_MASTER_SERVICE/g$HADOOP_HOME/etc/hadoop/core-site.xmlsed -is/@HDOOP_YARN_MASTER@/$HDOOP_YARN_MASTER/g$HADOOP_HOME/etc/hadoop/yarn-site.xmlyarn-masterHADOOP_NODE=${HADOOP_NODE_TYPE}if [ $HADOOP_NODE = datanode ]; then ? ? ? ?echoStart DataNode ... ? ? ? ?hdfsdatanode ?-regularelse ? ?if [ ?$HADOOP_NODE = namenode ]; then ? ? ? ?echoStart NameNode ... ? ? ? ?hdfsnamenode ? ?else ? ? ? ?if [ $HADOOP_NODE = resourceman ];