企业官网建设流程全解析

• 数据库
• KV存储
• 后端

导读

本文以仓库 tools/kubeblocks_helm 目录下的 Helm Charts 为依据，完整讲解如何借助 KubeBlocks 在 Kubernetes 上部署 Pika：既包括由 Codis（Proxy + Dashboard + FE）、etcd、Pika 数据分片组构成的分布式分片集群，也包括单主多从的 Pika Master/Slave 组，并覆盖连接访问、水平扩容、缩容限制、数据备份与恢复等全流程操作。读完本文，你将能够独立完成 KubeBlocks 环境的准备、四个 Chart 的安装与卸载、使用redis-cli直连 Pika、通过kbcli备份恢复集群，并理解每个 Chart 内部的关键配置项与底层实现依据。

一、背景：为什么用 KubeBlocks 部署 Pika

Pika（Pikiwidb）是兼容 Redis 协议、以 RocksDB 为存储引擎的持久化数据库，适合在数据量远超内存的场景下承载 KV 读写。在 Kubernetes 中直接运维有状态数据库的副本、主从切换、存储与备份都较为繁琐，而 KubeBlocks 通过ClusterDefinition / ComponentDefinition / ComponentVersion这套声明式抽象，把数据库的部署形态（拓扑、探针、生命周期脚本）标准化，用户只需安装 Cluster 实例即可。

仓库 tools/kubeblocks_helm 提供了四组 Chart，分工如下：

两者都遵循“先装组件定义（CD），再装集群实例（Cluster）”的安装次序：CD Chart 负责把“Pika 能怎么部署”描述给 KubeBlocks，实例 Chart 负责按 values 参数真正拉起一个集群。

从 pika/Chart.yaml 可以看到，该 CD Chart 的appVersion为3.5.3，对应 pika/values.yaml 中默认拉取的镜像pikadb/pika:3.5.3、pikadb/pika-exporter:3.5.3、pikadb/codis:3.5.3与bitnami/etcd:3.5.9。

二、环境准备：安装 kbcli 与 KubeBlocks

部署前需要准备好 Kubernetes 集群以及 KubeBlocks 的命令行工具kbcli。原文档指向 KubeBlocks 官方安装指南，仓库侧并不包含 kbcli 的安装介质，因此这一步的要点如下：

1. 安装 kbcli：按 KubeBlocks 官方文档下载对应平台版本并放入PATH，用于后续执行kbcli cluster backup、kbcli cluster restore等操作。
2. 安装 KubeBlocks：在集群内安装 KubeBlocks 控制面（operator），使apps.kubeblocks.io/v1alpha1这一组 CRD 可用。本文后续所有 YAML（如 cluster.yaml 中的kind: Cluster）都依赖这套 CRD。
3. （备份/恢复场景必选）准备默认 BackupRepo：KubeBlocks 的数据保护依赖 BackupRepo 定义存储后端，未配置时kbcli cluster backup无法落盘。详见下文第五节。

安装完成后可用kubectl get crd | grep kubeblocks验证 CRD 已注册。

三、部署 Pika Codis 分片集群（pika + pika-cluster）

3.1 安装组件定义与集群实例

进入 Chart 目录后依次执行两次helm install，第一次注册 Pika 的组件定义，第二次创建分片集群：

cd tools/kubeblocks_helm/ helm install pika ./pika helm install pika-cluster ./pika-cluster

仓库同时提供了等价的一键脚本 install.sh：

helm install pika ./pika && helm install pika-cluster ./pika-cluster

说明：原文档使用的目录名是./tools/kubeblocks-helm/，本仓库实际目录为tools/kubeblocks_helm/（下划线），执行前请以实际目录名为准。

安装后等待集群进入Running状态：

kubectl get cluster --watch

3.2 集群拓扑与默认参数

从 pika-cluster/values.yaml 可以看到实例默认拉起哪些组件、各多少副本：

对应到 cluster.yaml，该模板会渲染出如下 componentSpecs：

• pika-group-1、pika-group-2：每个分片组引用componentDef: pika-group，副本数为slaveCount + 1（默认 2，即一主一从），并挂载名为data的 PVC；
• etcd：3 副本的 etcd 集群；
• codis-proxy：引用pika-codis-proxy，默认 2 副本；
• codis-fe：引用pika-codis-fe，默认 1 副本；
• codis-dashboard：引用pika-codis-dashboard，1 副本；
• pika-exporter：监控组件，monitor.enabled控制是否被 KubeBlocks 纳入监控采集。

模板中还保留了一个开关useLegacyCompDef：为true时走传统componentSpecs+componentDef渲染（默认行为）；为false时改用新版shardingSpecs（声明shards: groupCount与template）渲染分片组。默认使用前者，无需改动。

所有组件默认资源限制为cpu: 500m / memory: 3Gi、请求为cpu: 500m / memory: 1Gi（见 pika-cluster/values.yaml 的resources段），可按需调整后helm upgrade生效。

3.3 底层组件画像：Pika、Codis Proxy 与 etcd 的配置来源

CD Chart 通过 ConfigMap 向各组件下发配置文件模板，位于 pika/config：

• pika-config.tpl：Pika 实例配置。默认监听port : 9221（注意端口魔法偏移：port+1000即 10221 用于 Rsync 全量同步，port+2000即 11221 用于主从复制通道）；default-slot-num : 1024与slotmigrate : no表明 Pika 侧按 1024 个 slot 与 Codis 协同，日常关闭 slot 迁移、迁移时再开启；instance-mode : classic、databases : 1；write-buffer-size : 256M、target-file-size-base : 20M、compression : snappy、expire-logs-days : 7、binlog-file-size : 104857600（100M，主从必须一致）、maxclients : 20000等均为关键运行参数。
• codis-proxy.tpl：Codis Proxy 配置。默认proxy_addr = "0.0.0.0:19000"（客户端入口）、admin_addr = "0.0.0.0:11080"；max_slot_num = 1024与 Pika 侧 slot 数一致；product_name = "codis-demo"、product_auth/session_auth默认空；jodis_name支持zookeeper或etcd，本方案采用 etcd 作为协调服务；proxy_max_clients = 1000、proxy_max_offheap_size = "1024mb"、backend_max_pipeline = 20480、session_max_pipeline = 10000等控制并发与缓冲。
• codis-dashboard.tpl、exporter-info.tpl：分别承载 Dashboard 与 exporter 的接入信息。

这些模板被 templates/configmap.yaml 渲染为 ConfigMap，再由 KubeBlocks 挂载进对应 Pod；用户如要调整 Pika 或 Proxy 参数，可直接修改 Chart 内 tpl 后升级，或按 KubeBlocks 的配置热加载机制在集群内修改配置。

3.4 通过 Codis FE 添加 Pika 实例

Codis FE 是集群的管理前端。将 FE 服务转发到本地后，浏览器访问控制台：

kubectl port-forward svc/pika-cluster-codis-fe 8080 # 打开浏览器访问 http://localhost:8080

在 FE 控制台中，可以看到由 KubeBlocks 编排出的 Pika 分片组与 Proxy 已注册到 etcd（jodis），通常无需手工添加实例；如需手工操作，按 FE 页面指引将各pika-group-*的 Pika 地址加入集群分组即可。

3.5 客户端连接 Pika 集群

Codis Proxy 对外暴露 19000 端口，通过port-forward后即可用标准 Redis 客户端访问：

kubectl port-forward svc/pika-cluster-codis-proxy 19000 # 另开一个终端 redis-cli -p 19000 info

连接后执行info、set/get等 Redis 兼容命令即可读写数据，请求由 Proxy 依据 key 的 hash 路由到对应 slot 的 Pika 分片组。由于默认session_auth为空，本地联调可直接免密访问；生产环境建议在 codis-proxy.tpl 中配置product_auth与session_auth，并同步配置 Pika 侧requirepass/masterauth。

四、Pika 分片集群的水平扩容

4.1 扩缩容能力边界

原文档明确：Pika 分片集群支持 Scale out（扩容），不支持 Scale in（缩容）。这一限制与底层实现一致——Pika 分片的数据按 slot 分布在各组，缩容需要跨组搬迁 slot 数据，当前 Helm 编排不提供该流程，因此缩容不在支持范围内。

4.2 Scale out：增大副本与分片组

扩容的常规手段有两种，均通过修改 pika-cluster/values.yaml 后执行helm upgrade完成：

方式一：增加每个分片组的从节点（slaveCount）

# 编辑 pika-cluster/values.yaml，例如 # slaveCount: 2 （原值 1） helm upgrade pika-cluster ./pika-cluster

cluster.yaml中每个分片组的副本数取slaveCount + 1，因此这会使每个pika-group-*都多出一个从节点，提升读扩展能力与容灾冗余。

方式二：增加分片组数量（groupCount）

# 编辑 pika-cluster/values.yaml，例如 # groupCount: 3 （原值 2） helm upgrade pika-cluster ./pika-cluster

新增的pika-group-3会作为新分片组加入集群，配合 Codis 的 slot 迁移能力承载更多数据，实现横向扩容。注意：新组加入后，slot 的重新分配与数据搬迁需要在 Codis FE 或通过 slot 迁移命令完成，纯 Helm upgrade 只负责拉起新组。

升级完成后同样可用kubectl get cluster --watch观察各组 Pod 逐个变为Running。

五、部署 Pika 主从组（pika-master-slave + pika-master-slave-cluster）

5.1 安装组件定义与主从实例

与分片集群同理，先安装主从形态的组件定义，再安装实例：

cd tools/kubeblocks_helm/ helm install pika-master-slave ./pika-master-slave helm install pika-master-slave-cluster ./pika-master-slave-cluster

一键脚本 install_ms.sh 等价于：

helm install pika-master-slave ./pika-master-slave && helm install pika-master-slave-cluster ./pika-master-slave-cluster

等待全部 Pod 就绪：

kubectl get pods --watch

5.2 主从组的组成与默认参数

主从组没有 Codis 与 etcd，只包含一个pika组件。从 pika-master-slave-cluster/values.yaml 看：

对应的 cluster.yaml 只渲染一个componentSpecs条目：name: pika、componentDef: pika、replicas: slaveCount + 1，并挂载名为data的 PVC。主从关系由 KubeBlocks 依据 pika-master-slave 的 ClusterDefinition 自动建立（首个副本为 master，其余为 slave），Pika 侧的slaveof、masterauth、binlog等参数由 pika/config/pika-config.tpl（主从 Chart 复用同款模板，位于 pika-master-slave/config/pika-config.tpl）统一配置。

5.3 连接主从集群

kubectl port-forward svc/pika-master-slave-cluster-pika 9221 # 另开一个终端 redis-cli -p 9221

服务端口即 Pika 默认监听端口 9221。连接后可用info replication查看主从状态、set/get验证读写。

5.4 卸载主从集群

helm uninstall pika-master-slave-cluster helm uninstall pika-master-slave

六、备份与恢复（基于 KubeBlocks DataProtection）

6.1 前置条件：默认 BackupRepo

备份/恢复依赖 KubeBlocks 的数据保护框架，必须先在集群中定义默认的BackupRepo（即备份存储后端，如对象存储或 PVC）。未配置时执行备份命令会因缺少存储后端而失败。仓库根目录附带了一个示例 BackupRepo_config，可作为自定义 BackupRepo 配置的参考。

6.2 创建备份

kbcli cluster backup pika-master-slave-cluster --method datafile

--method datafile表示采用数据文件级备份。备份动作由 pika-master-slave 中的 BackupActionSet/BackupPolicyTemplate 定义，实际执行脚本为 dataprotection/backup.sh，其流程与源码实现如下：

1. 通过redis-cli -h ${DP_DB_HOST} -p ${DP_DB_PORT}记录当前LASTSAVE时间点；
2. 下发BGSAVE，等待LASTSAVE变化，确认 dump 完成（Pika 的BGSAVE会生成dump-path下的快照文件）；
3. 进入${DATA_DIR}，将./log（含 binlog）与./db（RocksDB 数据）打包为 tar 流，经datasafed push -z zstd-fastest以 zstd 压缩上传到 BackupRepo，备份对象名为${DP_BACKUP_NAME}.tar.zst；
4. 将备份总大小写入${DP_BACKUP_INFO_FILE}，供 KubeBlocks 记录备份元数据。

6.3 从备份恢复集群

先用kbcli cluster list-backups（或kbcli cluster backup list）找到目标备份名，然后创建恢复集群：

kbcli cluster restore <clusterName> --backup <backup-name>

恢复阶段执行 dataprotection/restore.sh，其关键逻辑：

• 若${DATA_DIR}非空且不存在.kb-data-protection占位文件，则拒绝恢复（防止覆盖现有数据）；
• 写入占位文件后，用datasafed pull -d zstd-fastest "${DP_BACKUP_NAME}.tar.zst"拉取备份流并解压到${DATA_DIR}（同时兼容旧版.tar.gz备份）；
• 解压完成后删除占位文件并sync，恢复出的db目录即可被新集群的 Pika 实例直接加载。

注意事项：恢复出的数据同时包含 binlog 与 RocksDB 数据，新集群主从关系建立后会基于 binlog 继续增量同步；由于备份以整个${DATA_DIR}为单位，恢复目标 PVC 大小不应小于原数据卷（默认 10Gi，见 pika-master-slave-cluster/values.yaml）。

七、卸载与清理

两种形态的卸载顺序与安装相反，先删实例、再删组件定义：

分片集群（Codis 形态）：

helm uninstall pika-cluster helm uninstall pika

主从组：

helm uninstall pika-master-slave-cluster helm uninstall pika-master-slave

卸载时terminationPolicy: Delete会随集群删除 PVC；若需保留数据，可在卸载前将terminationPolicy调整为Retain并执行helm upgrade。仓库还提供了配套脚本 uninstall.sh 与 uninstall_ms.sh，内容即上述两条命令。

八、常用运维速查

九、局限性说明

基于仓库现状，以下几点需要明确：

• 缩容（Scale in）不受支持：分片集群仅支持 Scale out，这是官方文档明确声明的边界（见原 README.md）；
• 默认无鉴权：分片集群的product_auth、session_auth与 Pika 的requirepass/masterauth默认均为空，生产部署务必修改配置模板并同步主从两侧；
• 镜像版本：分片集群默认 Pika3.5.3（pika/values.yaml），主从组 CD Chart 声明的版本为v3.5.5而实际镜像 tag 仍为3.5.3（pika-master-slave/values.yaml），升级镜像时需同时核对两处；
• slot 数据搬迁：新增分片组后，存量 slot 的重新分布与数据搬迁不属于 Helm upgrade 的职责，需要结合 Codis 的迁移能力另行操作。

以上即 KubeBlocks 上 Pika 两种部署形态的完整实战路径。对照仓库中 pika 与 pika-master-slave 的模板与脚本，可以进一步验证本文涉及的组件定义、配置模板与备份恢复实现细节。

• 数据库
• KV存储
• 后端