背景:
上一节,完成了Kubeblocks系列1-安装。现在就想拿一个简单的应用测试一下kubeblocks这个所谓的神器是否好用,是否可以应用与生产!
Kubeblocks系列2-redis尝试
参照官方文档:创建并连接到 Redis 集群
确保 Redis 引擎已启用
kbcli addon list|grep redis
redis 0.8.1 community Enabled true
查看可用于创建集群的数据库类型和版本
kbcli clusterdefinition listkbcli clusterversion list
到这里我就有些想要放弃了。因为支持的版本很是有限,不是我理解的和想要的那种!
创建一个namespace
为了保持隔离,本文档中创建一个名为 demo 的独立命名空间
kubectl create ns demo
创建一个Standalone单实例redis
我这里就是为了简单测试一下kubeblocks去管理数据库是否可行,就在这里搭建一个简单的单实例redis:
kbcli cluster create redis --mode standalone redis -n demo
注意:执行kbcli cluster create redis -h, 可以查看创建 Redis 集群的选项和默认值。
等待redis创建成功并测试连接:
kbcli cluster list -n demo
kubectl get pods -n demo
使用kbcli测试redis连接:
kbcli cluster connect redis -n demo
到了这里我基本就放弃了。对我来说很不严谨。这不符合我的认知。
继续尝试用本地redis-cli连接一下redis实例。毕竟用户的应用场景是使用redis客户端连接实例而不是kbcli!
kubectl get secret -n demo
kubectl get secrets -n demo redis-redis-account-default -o jsonpath='{.data.\username}' | base64 -d
kubectl get secrets -n demo redis-redis-account-default -o jsonpath='{.data.\password}' | base64 -d
redis-cli连接也没有什么大问题:
放弃的原因:
支持的版本有限
以redis 为例,仅仅支持7.0.6版本,不符合作为一个数据中心的设计吧:
这个我也github提交了issue。给我的回复是kubeblocks0.9版本会支持更多的应用的版本:
版本的一致性 and镜像的官方性
以redis为例,安装的版本是7.0.6 but info server打印出来的版本是7.0.9.这点让我很不爽。我对kubeblocks的官方镜像产生了不信任,这里我希望竟然能直接使用官方的镜像 或者bitnami仓库的镜像这种。现在的镜像让我感到不信任:
其他问题
在使用kbcli的同时必须穿插使用kubectl命令,我希望能减少对kubectl的依赖。同时,我更希望能通过kbcli直接创建和管理namespace,增设安全措施防止误删。
总结:
我还是坚信数据服务可以部署在容器中,但是现阶段的kubeblocks对于我来说还是一个玩具,成熟度较低。希望在以后成熟的版本中再进行深度的学习试用。现在这种阶段我还是宁愿试用bitnami的各种helm安装了