基于k8s的家用大数据集群设计与实现

使用3台废旧笔记本搭建k8s集群，部署大数据组件，利用路由器进行异地组网，配合wsl作为管理和客户端，
实现随时随地，在工作笔记本上以本地访问的体验使用自建家庭大数据平台进行学习、开发、测试。

前言

起因

最近换了电脑，之前的机器闲置着浪费，又刚好看到了https://github.com/geekyouth/SZT-bigdata 这个项目，不错不错，让我来可以做得更好。

索性自己在家里搭个大数据集群来玩。而且女朋友的笔记本也闲置着，再搜刮一台来组个集群，就可以为所欲为了。

最初目标

在主力机的wsl里可以提交flink任务，在idea的单元测试里可以配置wsl执行hadoop操作。
这样基本就可以满足日常的开发测试需求了。

物理配置及组网

机器

服务器：lian1、lian2、lian3

蒲公英家用路由器（带内网异地组网功能）

客户端：工作用笔记本（win11，带wsl）

网络配置

3台服务器利用网线连接路由器，组成一个局域网。

在家的时候笔记本直接通过wifi连接到局域网，在外也还可以通过蒲公英的异地组网功能连接。忽略网速的话体验一致。

注意：也可以通过一些内网穿透的软件达到相同效果，不推荐专门去买路由器。

技术选型

大数据平台选型

本来只是出于实验目的，想直接用cdh，方便管理一些。

CDH6.3.3之后没有免费社区版了。我之前还部署了一套6.3.2的。
但是从2021年2月开始下载之前的版本也要订阅了，很麻烦。
算了，人家就是不想让你用免费的，而且免费的组件版本还老，不用也罢。

然后我就开始物色其他的，hdp也早被cdh收编了，mapr本来就是主打商用的。

国内的华为阿里腾讯都是云服务，不会提供这种社区版。

倒是有看到UCloud出了一个USDP的大数据平台免费版。有点意思。
然后看了一遍部署教程和操作文档。嗯。。。再看一眼组件版本，嗯。。。

算了，还是用我自己的基于k8s的方法部署吧

k8s部署管理平台选型

kubernetes相关部署管理工具较多，我是不推荐自己手动一步步部署的

这里我用的是： kubeoperator

使用wsl-docker作为kubeoperator的管理端，将k8s部署到3台机器上
平时需要用到管理功能的时候再启动win11上的docker就行，日常运行不需要

按公网教程一步步操作即可，这里有个坑：
主机的ip只能填ip不能填hostname，虽然填的时候不会报错，但是在生成k8s证书的时候会失败！

资源分配

3台机器本来就是闲置机，唯一配置好一点的前主力机的32g内存也被我拆到现在的主力机上了。
机器配置都是4核，但内存加起来才32g，可以说是非常垃圾，但是受限于经济能力，没办法。
不过一想到云服务器1c2g也被我跑了那么多服务，12c32g好像也还不错了，至少比在自己笔记本上开3台虚拟机强。

经常看到群里出于学习要搭大数据的，怕自己配置不够。
够不够其实看需求，只是做功能测试、验证的，没多大数据量，耗不了多少资源。
再说，就算数据量大，只要控制好，反正最后都是在yarn上面跑，无非就是慢一点，总是能跑完，挂不了。
更何况我还是放在kubernetes上的，就算一个挂了也影响不了其他。这点比cdh脚本部署强。

下面来看各个组件的安排

物理机上直接启用的有： nfs
docker直接启用的有： docker镜像仓库（docker-registry、docker-registry-web-server）、mysql、 ldap（openldap、ldapadmin）
kubernetes管理的有：

1. kerberos

用于大数据组件的认证，支持1主多从，这里给1主1从，毕竟是最基础的组件，就象征性地高可用吧
配置的话1c1g就够了，这里的资源值是指limit而非request，即最高能申请到的内存，实际用到的会低很多

2. zookeeper

分布式协调，一般是其他组件实现高可用的基础。至少3台，1c1g。

3. elasticsearch

搜索引擎，这个是给ranger存储审计日志用的。支持多个，但1个就够了，1c1g。

4. ranger

用于大数据权限管理，主要跑两个程序：
ranger-admin提供ranger核心服务和web管理功能
ranger-usersync负责从ldap同步用户账户信息

5. hdfs

大数据最基本的存储组件，因为是高可用部署，得区分好几种角色（这里用的时hadoop最新版本3.3.1的架构配置）。

• zkfc-format:用于第一次运行时格式化hdfs在zookeeper上的存储，一次性运行，故配置不重要
• jn:journalnode，日志节点，hdfs内部的高可用机制的实现，至少3台，1c1g
• nn-active：active-namenode，默认状态为active的名称节点，即默认主节点，1个，在第一次启动时负责做初始化操作，1c2g
• nn-standby:standby-namenode，默认状态为standby的名称节点，即默认从节点，支持多个，参与主节点选举以实现高可用。这里也给1个，1c2g
• nn-observer:observer-namenode，状态为observer的名称节点，即观察者节点，负责读写分离的读的部分，不参与主节点选举。这里直接不给，省点资源。
• dn:datanode，数据节点，至少3个，1c2g。

虽然把nn-observer给省略了，但实际上hadoop2的时候namenode也只支持两个，所以其实现在这样从设计上来说也很不错了。
一般给1c1g是因为我知道它跑不到1g，1c2g是因为内部进程jvm参数容易配置些。

6. yarn

大数据最基本的资源调度组件

• rm:resource-manager,资源管理器，支持任意多个实现高可用，这里给2个，1c2g
• nm：node-manager,节点管理器，支持任意多个横向拓展，这里给1个，3c8g。

注意，nm的3c8g里面2c6g是给yarn平台调度用的，1g是给nm进程本身的，其他的预留给容器本身的。
所以2c6g就是这个大数据平台的计算任务能调度的最多资源了…

其他

到yarn就已经把大数据最最基础的部分搭建好了。
其他组件按需启动就行，像hive、hbase这些有主从多节点高可用结构的我暂时没用到，又耗资源，就先不管
像flink、spark这种支持把任务放到yarn上面跑的，本身留个一个历史日志服务器节点就够了，甚至不需要。
另外用得比较多就是kafka，一般也是至少3台，1台也可以，先不管

汇总

hostname	cpu核数	内存（g）	组件	limit资源总和
lian1	4	16	kerberos-master、zookeeper、es、ranger、hdfs-jn、hdfs-nn-active、hdfs-dn、yarn-rm、yarn-nm	12c19g
lian2	4	12	kerberos-slave、zookeeper、hdfs-jn、hdfs-nn-standby、hdfs-dn、yarn-rm	6c9g
lian3	4	4	zookeeper、hdfs-jn、hdfs-dn	3c3g

可以看到limit的资源总和是超过实际资源的，但是只是我为了方便分配和设置而已
大部分进程cpu用得都是很低的，内存不跑任务的时候也不多
毕竟条件所限，这样子也不错了
接下来就是实际测试了