Hadoop运行在Kubernetes平台实践

标签：分析   硬件   意图   组件   cfa   reg   count   dem   不同的   

• 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 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节点地址用环境变量中的参数HDFS_MASTER_SERVICE来替换，YARN Master节点地址则用HDOOP_YARN_MASTER来替换。下图是Hadoop HDFS 2节点集群的完整建模示意图：

Hadoop 运行在 Kubernetes平台实践
图中的圆圈表示Pod，可以看到，Datanode并没有建模Kubernetes Service，而是建模为独立的Pod，这是因为Datanode并不直接被客户端所访问，因此无需建模Service。当Datanode运行在Pod容器里的时候，我们需要修改配置文件中的以下参数，取消DataNode节点所在主机的主机名(DNS)与对应IP地址的检查机制：
dfs.namenode.datanode.registration.ip-hostname-check=false
如果上述参数没有修改，就会出现DataNode集群“分裂”的假象，因为Pod的主机名无法对应Pod的IP地址，因此界面会显示2个节点，这两个节点都状态都为异常状态。
下面是HDFS Master节点Service对应的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的节点定义(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
  实际上，Datanode可以用DaemonSet方式在每个Kubernerntes节点上部署一个，在这里为了清晰起见，就没有用这个方式 定义。接下来，我们来看看Yarn框架如何建模，下图是Yarn框架的集群架构图：
  
  Hadoop 运行在 Kubernetes平台实践
  我们看到，Yarn集群中存在两种角色的节点：ResourceManager以及NodeManger，前者属于Yarn集群的头脑(Master)，后者是工作承载节点(Work Node)，这个架构虽然与HDFS很相似，但因为一个重要细节的差别，无法沿用HDFS的建模方式，这个细节就是Yarn集群中的ResourceManager要对NodeManger节点进行严格验证，即NodeManger节点的节点所在主机的主机名(DNS)与对应IP地址严格匹配，简单来说，就是要符合如下规则：
  NodeManger建立TCP连接时所用的IP地址，必须是该节点主机名对应的IP地址，即主机DNS名称解析后返回节点的IP地址。
  所以我们采用了Kubernetes里较为特殊的一种Service——Headless Service来解决这个问题，即为每个NodeManger节点建模一个Headless Service与对应的Pod，下面是一个ResourceManager与两个NodeManger节点所组成的Yarn集群的建模示意图：
  
  Hadoop 运行在 Kubernetes平台实践
  Headless Service的特殊之处在于这种Service没有分配Cluster IP，在Kuberntes DNS里Ping这种Service的名称时，会返回后面对应的Pod的IP地址，如果后面有多个Pod实例，则会随机轮询返回其中一个的Pod地址，我们用Headless Service建模NodeManger的时候，还有一个细节需要注意，即Pod的名字(容器的主机名)必须与对应的Headless Service的名字一样，这样一来，当运行在容器里的NodeManger进程向ResourceManager发起TCP连接的过程中会用到容器的主机名，而这个主机名恰好是NodeManger Service的服务名，而这个服务名解析出来的IP地址又刚好是容器的IP地址，这样一来，就巧妙的解决了Yarn集群的DNS限制问题。
  下面以yarn-node-1为例，给出对应的Service与Pod的YAM文件，首先是yarn-node-1对应的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
  对应的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节点重启后的文件系统格式化问题，这个问题可以通过启动脚本来解决，即判断HDFS文件系统是否已经格式化过，如果没有，就启动时候执行格式化命令，否则跳过格式化命令。
  安装完毕后，我们可以通过浏览器访问Hadoop的HDFS管理界面，点击主页上的Overview页签会显示我们熟悉的HDFS界面：
  
  Hadoop 运行在 Kubernetes平台实践
  切换到Datanodes页签，可以看到每个Datanodes的的信息以及当前状态：
  
  Hadoop 运行在 Kubernetes平台实践
  接下来，我们可以登录到NameNode所在的Pod里并执行HDSF命令进行功能性验证，下面的命令执行结果是建立一个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文件系统，验证刚才的操作结果：
  
  Hadoop 运行在 Kubernetes平台实践
  接下来，我们再登录到hadoop-master对应的Pod上，启动一个Map-Reduce测试作业——wordcount，作业启动后，我们可以在Yarn的管理界面中看到作业的执行信息，如下图所示：
  
  Hadoop 运行在 Kubernetes平台实践
  当作业执行完成后，可以通过界面看到详细的统计信息，比如wordcount的执行结果如下图所示：
  
  Hadoop 运行在 Kubernetes平台实践
  最后，我们进行了裸机版Hadoop集群与Kubernetes之上的Hadoop集群的性能对比测试，测试环境为十台服务器组成的集群，具体参数如下：
  硬件：
  CPU：2E5-2640v3-8Core
  内存：1616G DDR4
  网卡：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
  我们执行了以下这些标准测试项：
  TestDFSIO：分布式系统读写测试
  NNBench：NameNode测试
  MRBench：MapReduce测试
  WordCount：单词频率统计任务测试
  TeraSort：TeraSort任务测试
  综合测试下来，Hadoop跑在Kuberntes集群上时，性能有所下降，以TestDFSIO的测试为例，下面是Hadoop集群文件读取的性能测试对比：
  
  Hadoop 运行在 Kubernetes平台实践
  我们看到，Kubernetes集群上的文件读性能与物理机相比，下降了差不多30%左右，并且任务执行时间也增加不少，再来对比文件写入的性能，测试结果如下下图所示：
  
  Hadoop 运行在 Kubernetes平台实践
  我们看到，写文件性能的差距并不大，这里的主要原因是在测试过程中，HDFS写磁盘的速度远远低于读磁盘的速度，因此无法拉开差距。
  之所以部署在Kuberntes上的Hadoop集群的性能会有所下降，主要一个原因是容器虚拟网络所带来的性能损耗，如果用Host Only模型，则两者之间的差距会进一步缩小，下图是TestDFSIO测试中Hadoop集群文件读取的性能测试对比：
  
  Hadoop 运行在 Kubernetes平台实践
  因此我们建议在生产环境中采用Host Only的网络模型，以提升Hadoop的集群性能。
  攻下Hadoop在Kubernetes上的部署，并且在生产中加以验证，我们可以很自豪的说，现在没有什么能够难倒应用向Kubernetes的迁移的步伐，采用统一的PaaS构建企业的应用集群和大数据集群，实现资源的共享和服务的统一管理将会大大的提升企业的业务部署速度和管理的效率。

Hadoop运行在Kubernetes平台实践

标签：分析   硬件   意图   组件   cfa   reg   count   dem   不同的   

原文地址：http://blog.51cto.com/14024441/2333370