|
通过上面的参数KubasService启动Docker时，在启动呼吁中操作hadoop_xml_conf.sh和env-init.py修改hbase-site.xml和hbase-env.sh文件来完成最后的设置注入，如下所示：
- source /usr/lib/hbase/bin/hadoop_xml_conf.sh
- && put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.regionserver.codecs --value snappy
- && put_config --file /etc/hbase/conf/hbase-site.xml --property zookeeper.znode.parent --value /test-cluster
- && put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.rootdir --value hdfs://namenode01:8020/tmp/hbase/test-cluster
- && put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.quorum --value zookeeper01,zookeeper02,zookeeper03
- && put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.property.clientPort --value 2181
- && service hbase-regionserver start && tail -f /var/log/hbase/hbase-hbase-regionserver.log
3、收集通讯
收集方面，回收了Kubernetes上原生的收集模式，每一个Pod都有本身的IP地点，容器之间可以直接通讯，同时在Kubernetes集群中添加了DNS自动注册和反注册成果，以Pod的标识名字作为域名，在Pod建设和重启和烧毁时将相干信息同步全局DNS。
在这个处所我们碰着干涉题，其时我们的DNS理会不能在Docker收集情形中通过IP反解出对应的容器域名，这就使得Regionserver在启动之后向Master注册和向Zookeeper集群注册的处事名字纷歧致，导致Master中对统一个Regionserver挂号两次，造成Master与Regionserver无法正常通讯，整个集群无法正常提供处事。
颠末我们对源码的研究和尝试之后，我们在容器启动Regionserver处事之前修改/etc/hosts文件，将Kubernetes对注入的hostname信息屏障。
这样的修改让容器启动的HBase集群可以或许顺遂启动并初始化乐成，可是也给运维晋升了伟大度，由于此刻HBase提供的Master页此刻看到的Regionserver都是IP情势的记录，给监控和妨碍处理赏罚带来了诸多未便。
六、存在题目
初代架构顺遂落地，在乐成接入了近十个集群营业之后，这套架构面对了以下几个题目：
打点操纵营业HBase集群较为繁琐
- 必要手动提前确定HDFS集群的存储，以及申请独立Zookeeper集群，早期为了省事直接多套HBase共享了一套Zookeeper集群，这和我们计划的初志不切合;
- 容器标识符和HBaseMaster里注册的regionserver地点纷歧致，影响妨碍定位;
- 单Regionserver运行在一个单独的ReplicationController(以下简称RC)，可是扩容缩容为充实操作RC的特征，粗暴的回收增进或镌汰RC的方法举办扩容缩容。
HBase设置
- 最初的计划缺乏机动性，与HBase处事设置有关的hbase-site.xml以及hbase-env.sh固化在DockerImage里，这种环境下，假如必要更新大量设置，则必要从头build镜像;
- 因为最初计划是共享一套HDFS集群作为多HBase集群的存储，以是与HDFS有关的hdfs-site.xml和core-site.xml设置文件也被直接设置进了镜像。假如必要在Kubasservice中上线依靠其他HDFS集群的HBase，也必要从头构建镜像。
HDFS断绝
- 跟着接入HBase集群的增多，差异的HBase集群营业对HDFS的IO耗损有差异的要求，因此有了疏散HBase依靠的HDFS集群的需求;
- 首要题目源自Docker镜像对相干设置文件的固化，与HDFS有关的hdfs-site.xml和core-site.xml设置文件与相干Docker镜像对应，而差异Docker镜像的版本完全由研发职员本身打点，最初版本的实现并未思量到这些题目。
监控运维
- 指标数据不充实，堆内堆外内存变革，region以及table的会见信息都未有提取或聚合;
- Region热门定位较慢，无法在短时刻内定位到热门Region;
- 新增可能下线组件只能通过扫KubasService的数据库来发明相干改观，组件的非常如RegionServer掉线或重启，Master切换等不能实时反馈;
七、重构
为了进一步办理初版架构存在的题目，优化HBase的管控流程，我们从头审阅了已有的架构，并团结Kubernetes的新特征，对原有的架构举办进级改革，从头用Golang重写了整个Kubas打点体系的处事(初版行使了Python举办开拓)。
并在Kubas打点体系的基本上，开拓了多个用于监控和运维的基本微处事，进步了在Kubernetes长举办HBase集群陈设的机动性，架构如下图所示：
二代架构图
1、Deployment&ConfigMap
（编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
