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

动态升级和扩缩容Proxy支持动态添加切换Redis Cluster的功能，这样Redis Cluster的集群升级和扩容切换过程可以做到对业务端完全无感知。例如，业务方使用30个节点的Redis Cluster集群，由于业务量的增加，数据量和QPS都增长的很快，需要将集群规模扩容两倍。如果在原有的物理机上扩容，需要以下过程:

协调资源，部署60个节点的新集群
手动配置迁移工具，将当前集群的数据迁移到新集群
验证数据无误后，通知业务方修改Redis Cluster连接池拓扑，重启服务

虽然Redis Cluster支持在线扩容，但是扩容过程中slots搬移会对线上业务造成影响，同时迁移时间不可控，所以现阶段很少采用这种方式，只有在资源严重不足时才会偶尔使用。
在新的K8s架构下，迁移过程如下：

通过API接口一键创建60个节点的新集群
同样通过API接口一键创建集群同步工具，将数据迁移到新集群
验证数据无误后，向Proxy发送命令添加新集群信息并完成切换

整个过程对业务端完全无感知。
集群升级也很方便：如果业务方能接受一定的延迟毛刺，可以在低峰时通过StatefulSet滚动升级的方式来实现；如果业务对延迟有要求，可以通过创建新集群迁移数据的方式来实现。
提高服务稳定性和资源利用率通过K8s自带的资源隔离能力，实现和其他不同类型应用混部，在提高资源利用率的同时，也能保证服务稳定性。
遇到的问题
Pod重启导致数据丢失K8s的pod碰到问题重启时，由于重启速度过快，会在Redis Cluster集群发现并切主前将pod重启。如果pod上的Redis是slave，不会造成什么影响。但如果Redis是master，并且没有AOF，重启后原先内存的数据都被清空，Redis会reload之前存储的RDB文件，但是RDB文件并不是实时的数据。之后slave也会跟着把自己的数据同步成之前的RDB文件中的数据镜像，会造成部分数据丢失。
StatefulSet是有状态服务，部署的pod名是固定格式(StatefulSet名+编号) 。我们在初始化Redis Cluster时，将相邻编号的pod设置为主从关系。在重启pod时，通过pod名确定它的slave，在重启pod前向从节点发送cluster failover命令，强制将活着的从节点切主。这样在重启后，该节点会自动以从节点方式加入集群。
LVS映射时延
Proxy的pod是通过LVS实现负载均衡的，LVS对后端IP:Port的映射生效有一定的时延，Proxy节点突然下线会导致部分连接丢失。为减少Proxy运维对业务造成影响，我们在Proxy的deployment模板中增加了如下选项：
lifecycle:preStop:exec:command:- sleep- "171"对于正常的Proxy pod下线，例如集群缩容、滚动更新Proxy版本以及其它K8s可控的pod下线，在pod下线前会发消息给LVS并等待171秒，这段时间足够LVS将这个pod的流量逐渐切到其他pod上，对业务无感知。
K8s StatefulSet无法满足Redis Cluster部署要求K8s原生的StatefulSet不能完全满足Redis Cluster部署的要求：

Redis Cluster不允许同为主备关系的节点部署在同一台机器上。这个很好理解，如果该机器宕机，会导致这个数据分片不可用。
Redis Cluster不允许集群超过一半的主节点失效，因为如果超过一半主节点失效，就无法有足够的节点投票来满足gossip协议的要求。因为Redis Cluster的主备是可能随时切换的，我们无法避免同一个机器上的所有节点都是主节点这种情况，所以在部署时不能允许集群中超过1/4的节点部署在同一台机器上。

为了满足上面的要求，原生StatefulSet可以通过 anti-affinity 功能来保证相同集群在同一台机器上只部署一个节点，但是这样机器利用率很低。
因此我们开发了基于StatefulSet的CRD：RedisStatefulSet，会采用多种策略部署Redis节点。同时，还在RedisStatefulSet中加入了一些Redis管理功能。这些我们将会在其他文章中来继续详细探讨。
总结
目前集团内部已经有多个业务的数十个Redis集群部署到了K8s上并运行了半年多。得益于K8s的快速部署和故障迁移能力，这些集群的运维工作量比物理机上的Redis集群低很多，稳定性也得到了充分的验证。
在运维过程中我们也遇到了不少问题，文章中提到的很多功能都是根据实际需求提炼出来的。目前还是有很多问题需要在后续逐步解决，以进一步提高资源利用率和服务质量。
混布 Vs. 独立部署物理机的Redis实例是独立部署的，单台物理机上部署的都是Redis实例，这样有利于管理，但是资源利用率并不高。Redis实例使用了CPU、内存和网络IO，但存储空间基本都是浪费的。在K8s上部署Redis实例，其所在的机器上可能也会部署其他任意类型的服务，这样虽然可以提高机器的利用率，但是对于Redis这样的可用性和时延要求都很高的服务来说，如果因为机器内存不足而被驱逐，是不能接受的。这就需要运维人员监控所有部署了Redis实例的机器内存，一旦内存不足，就切主和迁移节点，但这样又增加运维的工作量。