背景
为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、ElasticSearch、Kafka和Redis。
下面将从不同角度对上面提到的四个组件进行多租户以及资源隔离方案的描述，并根据需求选取效果明显且性价比高的方案进行适配与实现。
正文
目标
-
实现单集群支持多租户，租户之间相互不影响
-
能够快速方便的管理单租户的数据
-
对当前已经存在的产品代码和架构的侵入在可控范围之内尽量的小
方案
HBase
多租户
HBase多租户方案可以使用HBase的namespace来实现,单套威胁感知测试程序使用单独的namespace，由于namespace中资源是可以单独管理的，所以将单套威胁感知数据放入特定的namespace中便于后续该套威胁感知测试环境HBase资源的管理和回收
资源隔离
HBase的资源隔离包含RSGroup、Quota管理以及读写分离的相关配置。
其中RsGroup应用的场景是针对服务器资源异构的HBase集群，根据服务的重要程度或者业务特点将Region分组用来满足不同的需求
而读写分离以及读写控制则是针对大数据高并发下针对读写的特点进行请求数量的比例控制，保证不同场景的协同工作
上面两种场景明显不符合公司当前的需求，所以暂时不考虑。
而Quota管理可以针对namespace的资源分配来满足不同的测试产品的配额来满足资源管控的需求。主要的控制方法和维度如下：
| 配置的维度 | limit限制的类型 | 请求size还是请求次数 | 单位时间 |
|---|---|---|---|
| NAMESPACE USER TABLE USER+NAMESPACE USER+TABLE | READ WRITE READ+WRITE | 请求次数：req 请求Size：B, K, M, G, T, P | sec, min, hour, day |
注：Space Quotas使用的是filesystem quotas，这个特性是随着HBASE-16961在HBase 2.0之后实现的，而当前产品HBase的版本是1.2，所以该功能暂时无法支持，后续升级HBase版本后可以考虑。
ElasticSearch
ElasticSearch没有主流的官方多租户的方案，现在比较流行的多租户方案包含两种：
-
基于索引的多租户方案，即每个用户使用不同前缀的一套表，最后基于该套表完成对不同租户的管理。这针对集群规模不算太大时候的场景比较友好，当集群和租户规模过大时，元数据膨胀率会比较高，集群的负载会比较高。
-
基于索引中的路由进行多租户管理的方案，即所有的用户使用一套表，通过routing来进行数据分发和隔离。这样做的好处是能保持很好的扩展性以及较好的性能，但是缺点是如果在原有代码的基础上改动较大，且按用户删除数据时并不是很方便。
根据上面两种方案的对比，结合当前产品K8S环境的需求以及特点，第一套方案比较合适，暂时采取第一套方案。
Kafka
多租户
kafka多租户可以使用两种方式实现：
-
基于不同的用户使用不同的topic组分开消费，优点是代码改动较小，只需要配置适配即可，方便资源管理。配合权限管理，可以做到资源隔离。但是缺点是针对部分公用数据的数据膨胀率过高，资源浪费，元数据膨胀率高，用户多的时候集群压力较大。
-
基于不同的用户使用相同的topic来存储数据，根据不用的key来进行区分和消费。优点是代码改动小，元数据膨胀率可以得到有效控制，适用于多用户的场景。但是缺点是无法做到资源隔离，且消费数据时需要根据key进行判断，影响数据处理效率，不适合大数据高并发处理场景，且没办法很容易地按照用户来单独管理数据。
根据上面两种方案的对比，结合当前产品的K8S环境的需求以及特点，第一套方案比较合适，暂时采取第一套方案。
资源隔离
kafka资源隔离包含两个层面，即Quota(配额)管理以及ACL权限管理。
Quota管理适用于对kafka的各种流量进行控制和限制，保证kafka的broker的资源不会被一个或者几个client耗尽，保证整个集群的稳定性和可用性。适用于高性能高并发场景下的集群稳定性的阿提升与保证。
权限ACL管理则是进行资源隔离的重要实现方式，在开启认证后，可以管理用户对于topic的访问权限，实现kafka的资源隔离。
Redis
redis通用的多租户的实现方式和kafka以及elasticsearch的方式类似，都是在key的前面加上租户的前缀来进行管理。
有种极端的情况可以投机取巧，那就是如果保证redis是单机版的前提下，可以使用redis自带的数据库进行多租户的管理，但是这个方案有有很大的制约：
-
redis必须是单机版，集群模式的redis不支持分库即select操作;
-
该隔离只是逻辑层面上的隔离，底层并没有做隔离，FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据;
-
redis也不支持为每个数据库设置不同的访问密码，所以一个客户端要么可以访问全部数据库，要么一个数据库也没有权限访问;
从上面可以看出，其实redis的分库操作并没有想象中的那么美好。
最后考虑到公司产品对redis的占用比较少，所以更简单的方式就是使用docker快速部署多个redis实例来支撑多版本多租户，效果和单实例多套key效果差别不大。不仅不需要修改代码而且在实施上更容易把控。
总结
K8S的出现极大的提升了产品以及系统运维的效率以及效果，成为各个公司以及各个场景的宠儿也在意料之中。但是我们也没有必要过分神话K8S的作用，从而事事都K8S化，这样显然是矫枉过正的。
回到今天的需求，通过分析，对于公司产品来说，大数据组件由于其稳定性，对K8S的需求并不是很强烈，而且每个产品和系统都部署各自的存储集群的话，对整个K8S的资源也是一个浪费，更推高了K8S使用成本以及性能调优成本，得不偿失。
所以换个思路，将大数据组件以及存储单独部署在物理机上形成一个集群，而产品的应用利用K8S的特性进行管理，可以算是各取所需，扬长避短，也算是一个比较实际和高效的方案了。而实现这个目标的基础就是要实现大数据组件多租户以及资源隔离，也就是本文的需求来源了。
最后，如果想一起入门学习K8S的小伙伴，欢迎点赞转发加关注，下次学习不迷路，我们在K8S的路上共同前进！
最后挂个公众号二维码，公众号的文章是最新的，CSDN的会有些滞后，想追更的朋友欢迎大家关注公众号，谢谢大家支持。
公众号地址：
扫一扫
8180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
