KubeBlocks × 快手｜是否应在 Kubernetes 上运行 Redis？快手这样做！

本文链接：https://blog.youkuaiyun.com/baidu_41642080/article/details/144288003

导读

针对无状态服务，业界已拥有成熟解决方案，但对于有状态服务（如数据库、Redis）是否适合容器化与 K8s 托管，仍存在争议。本文基于快手在 Redis 云原生化实践中的经验，探讨有关有状态服务的云原生化思考及应对方案。

在推进 Redis 云原生化过程中，快手与 KubeBlocks 社区合作，低成本实现了技术方案的落地。在单集群编排层面，快手通过扩展 KubeBlocks InstanceSet 的能力边界，更好地支持角色定义、探测与更新策略，实现了 Pod 与 PVC 直接管理、异构配置等特性，并结合 Component、Shard 和 Cluster 抽象，构建了完整的 Redis 集群管理体系。

针对超大规模部署需求，快手将 KubeBlocks Operator 解耦为联邦集群和成员集群两部分。其中，InstanceSet Controller 部署于成员集群，而 Cluster 和 Component Operator 则运行在联邦层。通过自研的 Fed-InstanceSet 控制器，巧妙解决了实例全局唯一编号和跨集群管控等技术难题，实现了大规模 Redis 集群的统一调度和运维。

快手的实践证明，将数据库运行在 K8s 上是完全可行的，Redis 容器化带来的性能损耗在可接受范围内（不超过10%），云原生化带来的资源利用率提升和运维效率改善带来了显著收益。

如果您对在 K8s 上运行 Redis 或者其他数据库感兴趣，可扫码添加 KubeBlocks 小助手，了解技术详情。

扫码备注「公司+职位」，添加小助手

作者简介

刘裕惺，快手高级软件工程师。曾就职于阿里云和快手的云原生团队，专注于云原生领域，在云原生技术的开源、商业化和扩展方面拥有丰富的经验。刘裕惺也是 CNCF/Dragonfly 项目的 Maintainer 之一，也是 CNCF/Sealer 项目的 Maintainer 之一。目前专注于推动快手有状态业务的云原生转型。

一、背景

随着行业技术的不断演进，快手的基础设施顺应技术潮流逐步迈向云原生化。在各业务团队的支持下，容器云成为服务与基础设施的新界面，目前在快手无状态服务已基本全面实现 Kubernetes (K8s) 的云原生化。然而，有状态服务的云原生化之路却仍然充满了挑战：

有状态服务究竟是否适合在 K8S上运行？
有状态服务的云原生化如何实现与落地？

以 Redis 为例，它是快手广泛使用的有状态服务之一，超大规模是其显著特征。即使微小的优化在如此庞大的规模下也能为企业带来巨大的收益。在面向未来的长期规划中，快手高度认可 Redis 云原生化带来的潜在价值，尤其是资源利用率提升带来的成本优化。本文基于快手 Redis 云原生化实践中的经验，深入剖析有状态服务的云原生化思考及应对策略。