本文讲述了小米是如何将Redis Cluster部署在K8S上提供高质量的服务的
往期文章回顾:HBase Region Read Replicas功能详解
背景
Why K8S
How K8s
Why Proxy
Proxy带来的问题
K8s带来的好处
遇到的问题
总结
背景
小米的Redis使用规模很大,现在有数万个实例,并且每天有百万亿次的访问频率,支撑了几乎所有的产品线和生态链公司。之前所有的Redis都部署在物理机上,也没有做资源隔离,给管理治理带来了很大的困难。我们的运维人员工作压力很大,机器宕机网络抖动导致的Redis节点下线都经常需要人工介入处理。由于没有做CPU的资源隔离,slave节点打RDB或者由于流量突增导致节点QPS升高造成的节点CPU使用率升高,都可能对本集群或其他集群的节点造成影响,导致无法预测的时延增加。
Redis分片方式采用社区的Redis Cluster协议,集群自主分片。Redis Cluster带来了一定的易用性的同时,也提高了应用开发的门槛,应用开发人员需要一定程度上了解Redis Cluster,同时需要使用智能客户端访问Redis Cluster。这些智能客户端配置参数繁多,应用开发人员并无法完全掌握并设置这些参数,踩了很多坑。同时,由于智能客户端需要做分片计算,给应用端的机器也带来了一定的负载。
Why K8S
资源隔离
当前的Redis Cluster部署在物理机集群上,为了提高资源利用率节约成本,多业务线的Redis集群都是混布的。由于没有做CPU的资源隔离,经常出现某Redis节点CPU使用率过高导致其他Redis集群的节点争抢不到CPU资源引起时延抖动。因为不同的集群混布,这类问题很难快速定位,影响运维效率。K8s容器化部署可以指定 CPU request 和 CPU limit ,在提高资源利用率的同时避免了资源争抢。
自动化部署
自动化部署。当前Redis Cluster在物理机上的部署过程十分繁琐,需要通过查看元信息数据库查找有空余资源的机器,手动修改很多配置文件再逐个部署节点,最后使用redis_trib工具创建集群,新集群的初始化工作经常需要一两个小时。
K8s通过StatefulSet部署Redis集群,使用configmap管理配置文件,新集群部署时间只需要几分钟,大大提高了运维效率。
How K8S
客户端通过LVS的VIP统一接入,通过Redis Proxy转发服务请求到Redis Cluster集群。这里我们引入了Redis Proxy来转发请求。
Redis Cluster部署方式
Redis部署为StatefulSet,作为有状态的服务,选择S