Hadoop 运行在 Kubernetes平台实践-低调大师

Hadoop 运行在 Kubernetes平台实践

2018-12-13 495

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集群是由NameNode（Master节点）和Datanode（数据节点）等两类节点所组成，其中，客户端程序（Client）以及DataNode节点会访问NameNode，因此，NameNode节点需要建模为Kubernetes Service以提供服务，以下是对应的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节点暴露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节点集群的完整建模示意图：

图中的圆圈表示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框架的集群架构图：

我们看到，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集群的建模示意图：

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界面：

切换到Datanodes页签，可以看到每个Datanodes的的信息以及当前状态：

接下来，我们可以登录到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-master对应的Pod上，启动一个Map-Reduce测试作业——wordcount，作业启动后，我们可以在Yarn的管理界面中看到作业的执行信息，如下图所示：

当作业执行完成后，可以通过界面看到详细的统计信息，比如wordcount的执行结果如下图所示：

最后，我们进行了裸机版Hadoop集群与Kubernetes之上的Hadoop集群的性能对比测试，测试环境为十台服务器组成的集群，具体参数如下：

硬件：

CPU：2*E5-2640v3-8Core
内存：16*16G DDR4
网卡：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

我们执行了以下这些标准测试项：

TestDFSIO：分布式系统读写测试
NNBench：NameNode测试
MRBench：MapReduce测试
WordCount：单词频率统计任务测试
TeraSort：TeraSort任务测试

综合测试下来，Hadoop跑在Kuberntes集群上时，性能有所下降，以TestDFSIO的测试为例，下面是Hadoop集群文件读取的性能测试对比：

我们看到，Kubernetes集群上的文件读性能与物理机相比，下降了差不多30%左右，并且任务执行时间也增加不少，再来对比文件写入的性能，测试结果如下下图所示：

我们看到，写文件性能的差距并不大，这里的主要原因是在测试过程中，HDFS写磁盘的速度远远低于读磁盘的速度，因此无法拉开差距。

之所以部署在Kuberntes上的Hadoop集群的性能会有所下降，主要一个原因是容器虚拟网络所带来的性能损耗，如果用Host Only模型，则两者之间的差距会进一步缩小，下图是TestDFSIO测试中Hadoop集群文件读取的性能测试对比：

因此我们建议在生产环境中采用Host Only的网络模型，以提升Hadoop的集群性能。

攻下Hadoop在Kubernetes上的部署，并且在生产中加以验证，我们可以很自豪的说，现在没有什么能够难倒应用向Kubernetes的迁移的步伐，采用统一的PaaS构建企业的应用集群和大数据集群，实现资源的共享和服务的统一管理将会大大的提升企业的业务部署速度和管理的效率。

本文转自kubernetes中文社区-Hadoop 运行在 Kubernetes平台实践

微信关注我们

原文链接：https://yq.aliyun.com/articles/679402

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Kubernetes安装部署演示介绍-（一）

序这是差不多2年前我整理的一篇纯手工搭建Kubernetes的文档，里边涉及的软件版本相对偏低一些，但对一些初学者来说应该依然具有一定的借鉴意义。环境介绍： OS：Linux redhat721 3.10.0-327.el7.x86_64 K8S测试集群共2台主机，1台Master和1台Node， Master IP：192.168.80.137 组件版本部署方式安装目录或访问入口 docker 1.10.3 rpm /var/lib/docker etcd 2.3.6 tar /root/etcd-v2.3.6-linux-amd64 flannel 0.5.5 tar /root/flannel-0.5.5 kubernetes 1.2.4 tar /root/kubernetes skydns 2015-10-13 容器固定ip：192.168.3.254 kube2sky 1.14 容器和skydns同pod etcd 2.2.2 容器和skydns同pod exechealthz 1.0 容器和skydns同pod dashboard 1.0.1 容器 ht...

2018-12-14

548

1. 理解认证授权 1.1 为什么要认证想理解认证，我们得从认证解决什么问题、防止什么问题的发生入手。防止什么问题呢？是防止有人入侵你的集群，root你的机器后让我们集群依然安全吗？不是吧，root都到手了，那就为所欲为，防不胜防了。其实网络安全本身就是为了解决在某些假设成立的条件下如何防范的问题。比如一个非常重要的假设就是两个节点或者ip之间的通讯网络是不可信任的，可能会被第三方窃取，也可能会被第三方篡改。就像我们上学时候给心仪的女孩传纸条，传送的过程可能会被别的同学偷看，甚至内容可能会从我喜欢你修改成我不喜欢你了。当然这种假设不是随便想出来的，而是从网络技术现状和实际发生的问题中发现、总结出来的。kubernetes的认证也是从这个问题出发来实现的。 1.2 概念梳理为了解决上面说的问题，kubernetes并不需要自己想办法，毕竟是网络安全层面的问题，是每个服务都会遇到的问题，业内也有成熟的方案来解决。这里我们一起了解一下业内方案和相关的概念。对称加密/非对称加密这两个概念属于密码学的东西，对于没接触过的同学不太容易理解。可以参考知乎大神的生动讲解：《如何用通俗易懂的...

2018-12-14

516

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。