|
通过上面的参数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
（编辑：衡阳站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
