背景：

上一节，完成了Kubeblocks系列1-安装。现在就想拿一个简单的应用测试一下kubeblocks这个所谓的神器是否好用，是否可以应用与生产！

Kubeblocks系列2-redis尝试

参照官方文档：创建并连接到 Redis 集群

确保 Redis 引擎已启用

kbcli addon list|grep redis
redis                          0.8.1          community   Enabled    true 

查看可用于创建集群的数据库类型和版本

kbcli clusterdefinition list

kbcli 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安装了