Redis Sentinel Operator容器化技术解读.docx

《Redis Sentinel Operator容器化技术解读.docx》由会员分享，可在线阅读，更多相关《Redis Sentinel Operator容器化技术解读.docx（8页珍藏版）》请在第一文库网上搜索。

1、RedisSentine1Operator容器化解读【导读】对于ReCIiSC1USter的容器化，民生银行已在ReeIiSPaaS中做了先期的探索和使用。在RediSPaaS中实现了RediS哨兵模式、集群模式的容器化部署，结合IPAAS使得项目可依据自身需要自助申请并实时交付。之前已介绍过RediSC1USterOPerator容器化方案（点击可阅读），本文介绍RedisSentine1Operator容器化。先前介绍过RediSC1usterOPeratOr容器化方案，本次介绍ReCIiSSentine1OPeratOr容器化ORedisSentine1容器化与RediSC1USter有

2、相同的地方，如也需要解决节点分布、节点快重启等问题，与此同时，RediSSe11tine1包含两类不同角色的节点并且该种模式不涉及数据分片的事情，使得RediSSentine1容器化在部署架构、服务暴露、异常处理等方面有着其特殊性。节点分布与节点容器重启问题节点分布RedisSentine1容器化部署同RedisC1uster的一样，也需要将不同Redis节点和Sentine1节点分别置于不同的主机上，防止由于主机故障导致主从或者sentine1功能失效。这一点同样使用Kubernets的Pod反亲和性来配置：IPreferrecIDUringSchedu1ing1gnoredDuringEx

3、ecution：IIabe1Se1ector:Imatchckci.I（）p（）1ORyKcy：kubcrnotcs.i（）/hostnani。Redis容器快重启同RedisC1USter一样，RedisSentine1模式中，Redismaster节点容器一旦停止运行很快就会被kubernetes重新拉起，这个时间不足以触发Sentine1进行故障转移，可能会造成RediS数据丢失。会避免这个问题，RedisSentine1容器化中继续采用了容器启动和进程启动相分离的方法，即默认容器启动时不启动Redis/Sentine1进程，由operator判断在合适的时机启动Redis/Sentin

4、e1进程。对于新的Redis容器:Case1：MaSter节点存在，则启动容器RediS进程加入集群Case2：MaSter节点不存在，但SIaVe节点存在o Case2-1：Sentine1可以正常工作，则等待Sei1tine1启动故障转移提升S1ave为Master,然后依Case1操作o Case2-2：Sentine1不能正常工作，提升一个SIaVe节点为主节点，调整Sentine1的主节点指向，然后依CaSe1操作 Case3：S1aVe和MaSter节点均不存在，则直接启动ReeIiS进程，同时调整Sentine1指向的master节点为本节点对于新Sentine1容器： Case

5、1：如果RediSMaSter存在，启动Sei1tinei进程并指向MaSter Case2：如果RediSMaSter不存在，依新RediS容器启动场景处理，等待MaSter节点存在后，依CaSe1处理RedisSentine1OperatorRedisSentine1容器化部署架构在RediSSentine1架构中，Sentinei的功能主要有两个：1.监控RediS节点，发现RediS故障并进行fai1over；2.为客户端提供RediS最新的主从拓扑信息。换而言之，SentineI对于RediS数据处理并不是必须的，基于此，在设计RediSSentine1OPeratOr架构的时候可以

6、有两种选择： 方案一：使用原始的RediSSentii1e1架构，分别部署RediS和Sentine1节点，并由Operator进行管控 方案二：只部署RediS节点，由OPerator完成SentineI的功能方案一、二各有其优缺点。方案一优点为使用RediSSer1tine1原始部署架构，OPerator不需要集成Sentine1的功能，便于版本和功能与社区保持一致。然而，方案一需要对Sentine1进行管控，如维持Sentine1节点的配置一致性和正确性等，而Sentine1对动态配置这块支持很弱，很多场景下更改Sentine1的配置就必须重启SeI1tir1e1节点；方案二不需要部署S

7、entine1节点，节约K8S的资源而且OPerator也不需要麻烦的对SentineI进行管控。但是，方案二最大的问题在于Operator本身实质上是单节点运行，而不是像Sentine1一样实行多节点分散部署多数派共识机制，这样在故障判断的时候可能会由于集群内部节点间的网络断连造成误判。在架构选择的时候我们选择了方案一。在服务暴露方面，由于Ree1iSSentine1模式中，各Sentine1之间是对等的，而且RediS节点之间除了角色不一样，数据是对等的，所以也有两个选择： 方式一：对于Sentine1节点，为其建立一个统一的nodeport型的Service,客户端通过该Service连

8、接到任一Sentine1节点上获取主从信息。对于RediS节点，分别为每个RediS节点建立一个nodeport型Service,并且在Redis中使用如下配置设置暴露的端口为nodeport的取值，暴露的IP为其所在的宿主机的地址。这样客户端从Se11tineI获取到的Redis信息就是该Redis节点的nodeportService信息。方式二：客户端通过Sentine1获取的是主从信息，所以可以直接建立两个SerViCe：一个写SerViCe指向主节点，一个读SerViCe指向所有Redis节点。并且通过由Operator监听Sentine1的主从变化信息保障这种指向的正确性，那么客户端

9、可以不连接Sentine1,像使用单机Redis一样，按需求连接写Service或者读Service即可ORedisSentine1OPeratOr两种服务暴露方式都支持，根据不同的CRSpec内容来选择。如下图所示，一套RediSSentine1的部署包含： 一个ReCIiSStatefu1set,负责维持部署RediS所需的Pod资源 一个Sentine1Statefu1set,负责维持部署Sentine1所需的POd资源 Secret存储Redis密码 一个负责Redis配置的Configmap和一个负责Sentine1配置的Configmap 一个暴露Sentine1服务的Servic

10、e一个指向Redis主节点的写Service和一个指向所有Redis的读Service,或单独为每个RediSPOd建立的SerViCe负责定期对Redis进行持久化的一个CronjobRedisSentine1CRD建立RedisSentine1CRD资源,首先将RediSSentine1的需求进行抽象，如下所示:Isentine1Size：IrwMode：fa1seIimage：redis：IateStdbSize：4Gi该spec描述了部署一个RedisSentine1的基本需求，包含Redis节点数、Sentine1节点数、是否使用读写SerViCe模式、使用的redis镜像版本和每个

11、Redis节点的最大内存大小。然后，我们使用CRD将该需求定义扩展到Kubernetes,成为Kubernetes支持的资源：apiVersion：apiextensions.k8s.io/vIbeta1HMetadata：Iname：hstKind：RedISSentineI1IStIP1Ura1：rediSSentine1Isingu1ar：redissentineIscope：该yam1文件定义了KUberneteS支持的一个资源，资源的GrOUP是,Versionv1a1pha1,KindRedisSentine1o接下来就可以使用如下yam1在KUberneteS中创建RediSSentineI资源的实例:apiVersion:redis.CnI,cn/v1a1pha1kind:RedisSentine1InIetadata：namespace：redispaasspec：-全文完-