小米Redis的K8s容器化部署实践( 二 ) _小米Redis

HPA可配置集群的最少(MINPODS)和最多(MAXPODS)pod数量，集群负载再低也不会缩容到MINPODS以下数量的pods 。建议客户可以根据自己的实际业务情况来决定MINPODS和MAXPODS的值。
Why Proxy
Redis pod重启可导致IP变化使用Redis Cluster的Redis客户端，都需要配置集群的部分IP和Port，用于客户端重启时查找Redis Cluster的入口。对于物理机集群部署的Redis节点，即便遇到实例重启或者机器重启，IP和Port都可以保持不变，客户端依然能够找到Redis Cluster的拓扑。但是部署在K8s上的Redis Cluster，pod重启是不保证IP不变的(即便是重启在原来的K8s node上)，这样客户端重启时，就可能会找不到Redis Cluster的入口。
通过在客户端和Redis Cluster之间加上Proxy，就对客户端屏蔽了Redis Cluster的信息，Proxy可以动态感知Redis Cluster的拓扑变化，客户端只需要将LVS的IP:Port作为入口，请求转发到Proxy上，即可以像使用单机版Redis一样使用Redis Cluster集群，而不需要Redis智能客户端。
Redis处理连接负载高在6.0版本之前，Redis都是单线程处理大部分任务的。当Redis节点的连接较高时，Redis需要消耗大量的CPU资源处理这些连接，导致时延升高。有了Proxy之后，大量连接都在Proxy上，而Proxy跟Redis实例之间只保持很少的连接，这样降低了Redis的负担，避免了因为连接增加而导致的Redis时延升高。
集群迁移切换需要应用重启在使用过程中，随着业务的增长，Redis集群的数据量会持续增加，当每个节点的数据量过高时，BGSAVE的时间会大大延长，降低集群的可用度。同时QPS的增加也会导致每个节点的CPU使用率增高。这都需要增加扩容集群来解决。目前Redis Cluster的横向扩展能力不是很好，原生的slots搬移方案效率很低。新增节点后，有些客户端比如Lettuce，会因为安全机制无法识别新节点。另外迁移时间也完全无法预估，迁移过程中遇到问题也无法回退。
当前物理机集群的扩容方案是：

按需创建新集群
使用同步工具将数据从老集群同步到新集群
确认数据无误后，跟业务沟通，重启服务切换到新集群

整个过程繁琐而且风险较大，还需要业务重启服务。
有了Proxy层，可以将后端的创建、同步和切换集群对客户端屏蔽掉。新老集群同步完成之后，向Proxy发送命令就可以将连接换到新集群，可以实现对客户端完全无感知的集群扩缩容。
数据安全风险Redis是通过AUTH来实现鉴权操作，客户端直连Redis，密码还是需要在客户端保存。而使用Proxy，客户端只需要通过Proxy的密码来访问Proxy，不需要知道Redis的密码。Proxy还限制了FLUSHDB、CONFIG SET等操作，避免了客户误操作清空数据或修改Redis配置，大大提高了系统的安全性。
同时，Redis并没有提供审计功能。我们在Proxy上增加了高危操作的日志保存功能，可以在不影响整体性能的前提下提供审计能力。
Proxy 带来的问题
多一跳带来的时延Proxy在客户端和Redis实例之间，客户端访问Redis数据需要先访问Proxy再访问Redis节点，多了一跳，会导致时延增加。经测试，多一跳会增加0.2~0.3ms的时延，不过通常这对业务来说是可以接受的。
Pod漂移造成IP变化Proxy在K8s上是通过deployment部署的，一样会有节点重启导致IP变化的问题。我们K8s的LB方案可以感知到Proxy的IP变化，动态的将LVS的流量切到重启后的Proxy上。
LVS带来的时延LVS也会带来时延，如下表中的测试，不同的数据长度get/set操作，LVS引入的时延小于0.1ms 。

文章插图

K8S 带来的好处
部署方便通过运维平台调用K8s API部署集群，大大提高了运维效率。
解决端口管理问题目前小米在物理机上部署Redis实例是通过端口来区分的，并且下线的端口不能复用，也就是说整个公司每个Redis实例都有唯一的端口号。目前65535个端口已经用到了40000多，按现在的业务发展速度，将在两年内耗尽端口资源。而通过K8s部署，每一个Redis实例对应的K8s pod都有独立的IP，不存在端口耗尽问题和复杂的管理问题。
降低客户使用门槛对应用来说，只需要使用单机版的非智能客户端连接VIP，降低了使用门槛，避免了繁琐复杂的参数设置。同时由于VIP和端口是固定不变的，应用程序不再需要自己管理Redis Cluster的拓扑。
提高客户端性能使用非智能客户端还可以降低客户端的负载，因为智能客户端需要在客户端对key进行hash以确定将请求发送到哪个Redis节点，在QPS比较高的情况下会消耗客户端机器的CPU资源。当然，为了降低客户端应用迁移的难度，我们让Proxy也支持了智能客户端协议。