正文
我们使用K8s原生的HPA(Horizontal Pod Autoscaler)来实现Proxy的动态扩缩容。当Proxy所有pod的平均CPU使用率超过一定阈值时，会自动触发扩容，HPA会将Proxy的replica数加1，之后LVS就会探测到新的Proxy pod并将一部分流量切过去。如果扩容后CPU使用率仍然超过规定的阈值，会继续触发扩容逻辑。但是在扩容成功5分钟内，不论CPU使用率降到多低，都不会触发缩容逻辑，这样就避免了频繁的扩缩容给集群稳定性带来的影响。
HPA可配置集群的最少(MINPODS)和最多(MAXPODS)pod数量，集群负载再低也不会缩容到MINPODS以下数量的pods。建议客户可以根据自己的实际业务情况来决定MINPODS和MAXPODS的值。
使用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智能客户端。
在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在客户端和Redis实例之间，客户端访问Redis数据需要先访问Proxy再访问Redis节点，多了一跳，会导致时延增加。经测试，多一跳会增加0.2~0.3ms的时延，不过通常这对业务来说是可以接受的。
Proxy在K8s上是通过deployment部署的，一样会有节点重启导致IP变化的问题。我们K8s的LB方案可以感知到Proxy的IP变化，动态的将LVS的流量切到重启后的Proxy上。
