项目背景

奇虎 360 是中国领先的互联网安全公司，旗下 360 智汇云是其云计算品牌，提供云基础设施、大数据、AI 等服务。360 内部沉淀了海量用户行为数据，对大容量、高性能的键值存储有着极为迫切的需求。

为此，360 DBA 和基础架构团队自主研发了 PikiwiDB（原名 Pika）——一款以 RocksDB 为存储引擎、完全兼容 Redis 协议的大容量持久化 KV 数据库。PikiwiDB 将数据落盘至 SSD，单实例可支撑 TB 级存储，彻底突破了传统 Redis 的内存瓶颈，成功解决了 360 内部 Redis 节点因内存不足、重启恢复慢等问题。项目随后对外开源，并捐赠给 OpenAtomFoundation 开源社区，持续服务于业界。

随着业务规模扩大，360 智汇云云平台基础架构团队希望将 PikiwiDB 集群搬上 Kubernetes，实现分钟级交付与弹性伸缩，进一步降低运维成本。

面临的挑战

集群组件复杂，抽象难度高。 PikiwiDB 集群由控制面（FE、Dashboard、ETCD 集群）和数据面（Proxy、多组 Pika 主从实例）组成，组件间依赖关系错综复杂。直接使用 StatefulSet 等 Kubernetes 原生对象难以满足有状态管理需求，大量地址、变量和启动顺序需要精确管控。团队曾尝试自研 Operator，但在如何将复杂集群清晰映射为可重复部署的声明式配置这一问题上进展迟缓。

有状态扩缩容逻辑难以编排。 PikiwiDB 集群扩容需严格遵循操作顺序：先创建新 Group，等待就绪后，再通知 Dashboard 执行 Slot 搬迁。缩容时则反向操作——先完成 Slot 迁移，才能缩减节点数量。仅凭 Kubernetes 原生机制，难以优雅地串联这套带有业务语义的有序状态流转。

为什么选择 KubeBlocks

2023 年，KubeBlocks 正式开源。360 团队在深入调研后，决定放弃自研 Operator，完全基于 KubeBlocks 实现 PikiwiDB 的云原生化。

KubeBlocks 将集群拆分为三层抽象——细粒度的 Component、集群定义 ClusterDefinition 和集群实例配置 Cluster，将分布式模型、配置、脚本、存储、监控、备份等关注点分别对应到不同层次，使复杂的有状态集群能够清晰映射到 Kubernetes 资源模型上。这套设计在灵活性与易用性之间取得了很好的平衡，正是团队在自研过程中最难攻克的痛点。

此外，KubeBlocks 背后的团队拥有原 PolarDB 云原生数据库的大规模生产经验，将云厂商多年积累的 DBaaS 实践浓缩进了框架设计之中，让 360 团队得以直接站在这些经验之上构建方案，而无需从零摸索。

建设方案

360 智汇云团队基于 KubeBlocks 的 Addon 扩展机制，为 PikiwiDB 各组件分别编写了对应的声明式 YAML 配置，再用一个集群模板定义拓扑、组件配置和启动脚本，从而在任意 Kubernetes 环境中实现一键拉起完整的 PikiwiDB 分布式集群。

针对扩容时"先建 Group、再触发 Slot 搬迁"的有序操作需求，团队利用 KubeBlocks 的 postStartSpec 机制，在 Component 就绪后自动触发后续的 Dashboard 通知和 Slot 迁移逻辑。整个过程完全声明式，无需人工干预，彻底解决了有状态扩容编排的难题。

所有 Helm Chart 文件已开源至 OpenAtomFoundation/pika 社区仓库，任何用户均可按照 README 快速完成集群部署与水平扩缩容。

项目收益

放弃自研 Operator 的决定让团队将精力重新聚焦到数据库内核本身，避免了重复造轮子。KubeBlocks 提供的三层抽象模型完整覆盖了 PikiwiDB 的集群拓扑需求，扩缩容编排完全自动化，大幅降低了运维门槛。

对于社区用户而言，PikiwiDB 的 KubeBlocks Addon 提供了开箱即用的 Kubernetes 集群部署方案，只需少量 YAML 配置即可在任何云环境中拉起生产级的大容量 Redis 兼容集群，推动了 PikiwiDB 在更广泛场景下的落地应用。