背景：

上一節，完成了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安裝了