1. 先搞清楚你需要的其实是哪种“集群”一看到“在Kubernetes中安装Redis集群”很多人第一反应就是把Redis官方文档里的cluster模式照搬到K8s上6个节点、3主3从、分片存储。但我在实际项目中碰到的需求十有八九并不是真正的Cluster分片集群而是“主从复制加高可用哨兵”那一套。这两个东西安装方式、运维方式、故障恢复逻辑完全不同如果一开始没分清后面一定会返工。先说结论。如果你只是希望Redis在Pod挂掉之后还能有副本顶上、应用读写不中断那你要的是Redis Sentinel模式主从哨兵。这种架构的维护成本低很多最大规模也就几十个G的数据量读写分离和自动故障转移都够用。只有在数据量真的超过单机内存、必须把数据分散到多个节点或者单机写并发已经扛不住的时候才需要考虑Redis Cluster模式官方分片集群。Kubernetes环境里跑Cluster模式最大的难点不在于Redis配置本身而在于网络标识的稳定性和Pod重建后IP变化带来的集群元数据错乱这一点我会在后面详细展开。还有一种隐蔽的需求是“只要主从不需要哨兵”——比如纯缓存场景丢了数据可以重建应用端自己做降级。这种情况甚至不需要在主节点旁边挂真正的从节点直接用K8s的Deployment跑单实例加探针就够了。装之前一定先问清楚这三个问题数据能丢吗、要分片吗、故障恢复要求多久。答案是“能丢、不分片”的我建议你直接跳过集群别给自己找事。规模预估也很关键。K8s里的Redis集群每个Pod申请的内存、CPU、以及存储卷的IOPS限制都会直接影响分片数量。我们当时评估过一个小项目缓存数据预计20GTPS峰值不到3万这种体量用3主3从的Cluster是完全够的但如果数据量只有2G直接跑一个2G内存的哨兵主从就绰绰有余。分片数量一旦定下来后续扩容很麻烦因为扩容意味着槽位迁移和resharding线上操作窗口很难约所以宁可最开始多留一点余量也不要算得刚刚好。网络环境也要提前确认。Kubernetes集群的CNI插件如果是Calico或者Flannel默认的Pod网络模型对Redis集群的支持都不成问题但如果你是企业内网里带网络策略NetworkPolicy的严格环境就得多检查一步Redis节点之间除了6379端口还有一个总线端口是10000也就是16379。这个端口用于Cluster内部节点之间的gossip通信、故障选举和槽位迁移很多人只开了6379的放行规则集群创建时看着正常一发生故障马上发现节点之间失联。这个坑我踩过一次当时排查了半天最后发现就是安全组和NetworkPolicy把16379给拦了。2. 从零搭建的部署骨架StatefulSet与Headless Service的取舍确定要上Redis Cluster之后第一个核心决策就是用K8s的什么工作负载类型来跑。很多人图省事直接用Deployment加副本数6跑起来也能启动但问题会在第一次Pod重启时集中爆发。2.1 为什么非StatefulSet不可Redis Cluster的节点发现机制依赖每个节点的稳定网络标识。K8s的Deployment创建的Pod每次重启后IP可能变化Pod名称后面的随机串也会变这就导致Redis Cluster元数据里记录的节点地址全是过期的。虽然可以通过配置cluster-announce-ip强行指定某个固定IP但维护这样一来等于把Kubernetes最擅长的调度能力废掉了你还要自己管理IP池。StatefulSet的意义在于它给每个Pod赋予一个有序且稳定的DNS名称例如redis-0.redis-headless.namespace.svc.cluster.local。Pod删了重建名字不变DNS解析结果会自动指向新Pod的IP。Redis Cluster内部只需要记住这个DNS名就能在节点重建后继续正常通信。这是用StatefulSet的根本理由不是因为它听上去更“有状态”这么简单。搭建形态非常简单一个kind: StatefulSet定义里关键字段是serviceName必须指向我们提前建好的Headless Servicereplicas根据分片数量决定例如6个节点就是3主3从。每个Pod的spec.containers里跑的是同一个Redis镜像但配置文件的生成方式要稍微讲究一点不能所有Pod共用一份静态redis.conf。2.2 Headless Service的坑与正确打开方式Headless Service就是clusterIP: None的普通Service它的作用不是负载均衡而是把一组Pod的DNS记录直接映射到每个Pod的实际IP上。Redis Cluster模式下这是强制要求没有它StatefulSet的稳定网络标识就没有意义了。apiVersion: v1 kind: Service metadata: name: redis-headless namespace: default spec: clusterIP: None selector: app: redis-cluster ports: - name: redis port: 6379 targetPort: 6379 - name: cluster-bus port: 16379 targetPort: 16379这个文件里有两个容易忽视的细节。第一16379端口一定要出现在Service里。这不是给外部客户端用的而是让Kubernetes内部的其他Redis节点可以通过统一的DNS名解析到总线路由端口。如果你只暴露6379节点之间的总线流量在初始化阶段虽然也能通过宿主网络跑但一旦有Pod迁移到别的节点上总线端口的网络规则可能就对不上了。第二千万不要在这个Headless Service上再做ClusterIP类型的额外暴露也不要图省事再建一个ClusterIP Service指向这6个Pod。业务客户端连接集群时需要的是分别连接每个节点而不是经过一个VIP转一层。如果你的应用用的是Lettuce或JedisCluster这类支持拓扑感知的客户端它们会自己解析节点列表如果经过ClusterIP转发客户端会发现所有请求都被集中导到某一个Pod上不仅达不到分流目的还会在故障切换时出现大量MOVED重试。2.3 持久化存储怎么选别在本地盘上裸奔Redis在没有数据持久化的情况下可以看作是纯缓存。但Cluster模式的场景一般是数据不能丢的所以持久化存储是刚需。K8s里给StatefulSet挂存储卷常见方案有这么三种我直接说各自的适用边界。本地存储类Local PersistentVolume的性能最好延时最低因为数据直接落在宿主机盘上。缺点是Pod必须被调度到特定节点上如果节点挂了Pod就算被重新调度到别的机器数据也不会跟着走除非你手动恢复。适合的场景是Redis可以接受从RDB文件重新加载数据并且你有定期的冷备机制。云平台提供的SSD云盘是另一个主流选择性能中上带冗余节点迁移时可以快速重新挂载不像本地盘那样绑死节点。缺点是一个Pod一块云盘6个节点就是6块盘成本不低而且如果你用的是动态创建存储卷的StorageClass请一定要确认PVC的删除策略。默认情况下很多StorageClass的reclaimPolicy设置为Delete你删Pod没事但如果误删了StatefulSetPVC和云盘会被一起回收数据直接消失。还有一种选择是网络存储如各类NFS不建议用。Redis对时延非常敏感哪怕是千兆内网NFS的读写时延也往往比本地盘高一个数量级会导致Redis的写操作明显变慢集群故障切换时还可能因为IO阻塞触发频繁的主从切换。我在公司内部见过一个团队用NFS跑Redis的业务高峰期时延毛刺直接让接口超时率飙到5%以上后来全量迁回了本地SSD才解决。就我自己实践下来的经验中小规模集群优先考虑Local PV配合节点亲和性同时每天定时把RDB备份到对象存储有条件上云盘的就用云盘省心很多。不要觉得云盘贵比起真的丢一次数据这点钱花得值。3. 实际动手逐Pod拉起、分片初始化与连通性验证骨架搭好之后就到了真正动手的阶段。这里说的“动手”不是apply一个yaml就完事而是把每个Pod的配置、启动参数、初始化命令、验证流程走一遍。因为Redis Cluster的初始化是一个主动动作不是Pod起来了就自动组成集群的。3.1 先写好可复用的六个Pod配置StatefulSet里每个Pod可以用同一个镜像但配置文件需要通过环境变量或者configmap挂载的方式区分当前Pod的序号。最朴素的方案是给每个Pod单独写一个ConfigMap或直接内联配置但6个节点的配置内容其实只差一个端口或者名称维护成本可控规模再大一点建议用模板化的方式动态渲染配置。我们当时用的是给每个Pod挂载一个存有公共配置段落的ConfigMap再通过启动命令里读取Pod主机名来生成唯一的一段配置。这套做法的好处是后续新增节点的时候不需要给每个Pod手工创建配置文件改一下节点数就行。一个关键参数是一定要提前写进配置文件的cluster-enabled yes cluster-config-file /data/nodes.conf cluster-node-timeout 10000 appendonly yes appendfsync everysec cluster-announce-ip 由启动脚本根据Pod名生成 cluster-announce-port 6379 cluster-announce-bus-port 16379这里有几个参数值得单独解释。cluster-announce-ip如果你是在同一个Kubernetes集群内部访问Redis其实可以省略因为节点间通过DNS名发现K8s解析到的就是Pod的实际IP。但是在跨节点访问、或者用了NodePort暴露、或者Pod IP会变的环境下必须显式配置一个稳定IP否则集群在Pod重启后会陷入节点地址错乱的状态。最怕的情况是Pod重建后IP变了但Cluster元数据里还留着旧IP客户端连上去只能拿到一部分节点地址另外的节点怎么都连不通。cluster-node-timeout默认是15000毫秒就是15秒。意思是节点之间超过这个时间没有心跳就判定对方失联并开始故障转移流程。Kubernetes环境下我习惯把它调到10000毫秒左右因为Pod重建或调度延迟一般几秒内如果开得太低比如3000毫秒一场正常的滚动升级就可能引发多次无谓的主从切换。调太低和调太高是两难我的建议是10秒作为起步值跑一段时间观察有没有“手工频繁切换”的告警再微调。appendonly yes配合appendfsync everysec是Redis默认的持久化策略。保障数据不丢失的强度上它不是最强的完全同步要always但性能开销最低也足够覆盖大部分业务场景。如果你不能接受最多丢一秒数据就得认真评估你的业务需求了那通常说明你不应该用Redis当一个严格意义上的数据库来用。3.2 用on-failure重启策略还是让K8s来管Pod的restartPolicy建议保持默认的Always。这里要说明一下K8s里的重启不是覆盖所有进程异常的如果Redis进程因为OOM被杀了Always策略会由kubelet自动拉起但如果是Redis进程还在、只是集群状态异常比如网络分区、脑裂隐患它不会重启进程你得靠集群自愈或者手动介入。还有一点不要在Redis容器里自己加一个常驻的守护进程来拉Redis。我见过有人在entrypoint里用了类似supervisor的模式Redis挂了自动重启然后Redis自己还会把进程后台运行结果就是K8s的探针看到的永远是活着的进程但集群的slot健康状态早已异常。这种“假活”比真死还难排查因为日志和监控都在就是集群状态红着。所以让K8s的探针来负责健康判定让kubelet来重启Pod是最符合预期的方式。探针的设计也要区分一下。Liveness探针负责判断Redis进程本身是否存活用redis-cli ping或者TCP探测都可以Readiness探针则应该用真实的、反映集群状态的命令来测比如redis-cli cluster info | grep cluster_state。为什么要做这个区分因为如果Redis进程活着但集群暂时不在稳定状态直接拉流量进来会让应用层收到一堆CLUSTERDOWN错误对业务是有损的。反过来进程一旦死了Liveness马上能捕捉到并触发重启。3.3 集群握手与槽位分配的完整命令等6个Pod都进入Running状态、Readiness探针也通过之后集群创建的最后一个动作是在任意一个Pod里执行初始化命令。核心命令是:kubectl exec -it redis-0 -- redis-cli --cluster create \ redis-0.redis-headless.default.svc.cluster.local:6379 \ redis-1.redis-headless.default.svc.cluster.local:6379 \ redis-2.redis-headless.default.svc.cluster.local:6379 \ redis-3.redis-headless.default.svc.cluster.local:6379 \ redis-4.redis-headless.default.svc.cluster.local:6379 \ redis-5.redis-headless.default.svc.cluster.local:6379 \ --cluster-replicas 1这个命令就是让Redis自己完成槽位分配、主从配对和复制关系的建立。--cluster-replicas 1表示每个主节点配1个从节点6个节点正好3主3从。执行过程中会打印出每个节点被分配到的槽位范围以及每个从节点归属于哪个主节点。如果某个Pod的DNS解析失败或者节点还没完全加入集群命令会直接报错这时候最好先检查Pod状态而不是反复重试。有一个细节是初始化时能不能用IP而不是DNS名技术上可以但我不建议。IP方式下Cluster元数据里存的是IP地址Pod一旦重建IP变化之后整个集群的地址表都是错的除非你另外配置了announce-ip并在每次Pod重建后手动清理nodes.conf。用DNS名的话元数据里的地址会自动跟着Pod的解析变化虽然有些版本对DNS名的处理在某些极端场景下有一定延迟但总体上比IP方案靠谱得多。初始化成功后验证集群状态的命令是kubectl exec -it redis-0 -- redis-cli cluster info如果看到cluster_state:ok并且cluster_slots_assigned等于16384、cluster_known_nodes等于6那基本就是正常的。多次执行cluster nodes每次看到的节点视图应该一致且主从关系没有冲突。当年我们第一次建集群的时候没有指定--cluster-yes在交互确认时卡住了半天后来才发现是这个原因。这个参数建议直接加上避免在容器内交互确认的时候因为TTY问题卡死虽然非交互模式下命令也能跑完但加了更干净kubectl exec -it redis-0 -- redis-cli --cluster create ... --cluster-yes3.4 验证和压测不通过时的常规检查集群建好后不要急着接业务先用一个简单的连通性测试验证写入跨分片的行为。用redis-cli直接连上其中一个节点写入几个不同的key比如kubectl exec -it redis-0 -- redis-cli -c SET user:10001 alice kubectl exec -it redis-0 -- redis-cli -c SET order:20250101 1024-c参数让redis-cli自动跟随MOVED重定向这样两个key如果落在不同slot上也能正常写入不会报错。然后再连另一个节点把所有key读一遍确认数据确实分片存储。如果这一步报错最常见的两种原因一是节点之间的16379总线端口没打通二是Pod上的DNS解析不完整。前者的表现是cluster meet在握手阶段就失败后者的表现是初始化能成功、但某些节点一直处于handshake状态。这两种情况都有明确对应的排查路径网络策略看NetworkPolicy和宿主机安全组DNS就看CoreDNS的日志和Pod里的/etc/resolv.conf。性能验证阶段我建议别一开始就用redis-benchmark打太高的并发否则你判断不了是Redis问题还是应用侧问题。先按业务预估的峰值吞吐量打5分钟观察有没有CLUSTERDOWN、MOVED、ASK这类错误码的增多再用redis-cli --latency看网络层面的时延分布。Kubernetes环境里的时延往往不是Redis本身慢而是Pod调度到了不同的物理节点跨机房或者跨交换机的网络路径变长了。如果发现跨节点时延明显偏高可以给StatefulSet加上Pod亲和性把Redis节点尽量调度在同一个机柜或同一批物理机上。4. 集群维护故障转移、升级和恢复的真实操作记录集群不是建完就结束了。实际上真正考验架构设计的是后续的日常维护Pod重启、节点故障、镜像升级、数据恢复。这些场景里Kubernetes和Redis Cluster的交互逻辑有很多细节处理不好轻则服务抖动重则数据分片错乱。4.1 Pod挂了集群真的会自己“活”过来吗先说结论单节点Pod挂了集群大概率能自动恢复但恢复的时长和业务可接受的停机窗口需要提前对齐。假设redis-0这个主节点所在Pod被误删了。StatefulSet会按照控制器逻辑重新创建一个同名Pod新的Pod会继承原来的PVC这意味着里面旧的appendonly文件还在Redis进程起来后可以恢复数据。同时Redis Cluster在节点的故障转移机制中会识别出主节点失联并在它的从节点中提升一个新的主节点。整个自动故障切换的时长受cluster-node-timeout影响默认值下通常是十几秒到几十秒。但这里有个Kubernetes专属的坑旧Pod被删除后新Pod从创建到就绪可能需要几十秒取决于拉镜像时间和挂载卷的时间而Redis Cluster的故障转移是在检测到主节点失联之后立刻触发的。也就是说新Pod还在启动中的这段时间集群已经完成了主从切换。等新Pod起来后它带着旧PVC里的数据加入集群但此时它已经被降级为从节点了。这一切看起来都很正常对吧不要高兴太早。实际操作中我们遇到过的异常情况是新Pod恢复后旧PVC里的nodes.conf还记录着它自己是主节点、包含了部分槽位范围。如果它带着这份错误的配置加入集群会出现槽位冲突甚至出现两个节点都声称自己是某个槽位的主节点。这种状态下部分key会间歇性报错服务不可用的范围比单纯的节点故障还大。解决这个问题的办法有两个方向。一是删除Pod前先主动把该节点从集群中摘除redis-cli --cluster del-node让集群在Pod消失前就把它的槽位迁移走或安排好从节点接管但这样操作时间长手动步骤多违背了K8s自动恢复的初衷。二是让Pod启动时不要使用旧nodes.conf而是让Redis重新通过cluster meet流程加入集群。最简单粗暴的方式是在启动脚本里删除旧nodes.conf每次Pod重建都从干净配置开始让Redis依据Cluster的gossip协议重新学习集群拓扑。前提是节点之间能通过稳定DNS名互相发现否则每次重启都要手动触发一次meet。经历过一次教训后我的习惯是所有Redis Cluster节点的启动命令里都加一条“删除本地nodes.conf再启动”的逻辑。因为对于Kubernetes环境来说PVC负责存数据文件nodes.conf这个元信息文件完全可以视为缓存垃圾删掉不影响数据安全。刚开始团队还有人担心这样会不会导致集群状态丢失实际跑下来完全没事gossip协议会在一分钟内把拓扑信息重新同步回来。4.2 滚动升级Redis镜像顺序比参数更重要K8s上升级Redis镜像版本常用的是StatefulSet的滚动更新策略但直接全量滚动是有风险的。Redis Cluster的滚动升级要求同一时刻不能有多于一个节点处于更新状态并且不能同时升级主节点和它对应的从节点否则一旦出现故障转移主从关系可能配对错乱。我们的做法是在StatefulSet的updateStrategy里设置partition参数把滚动更新的批次控制住。比如partition: 5意味着只有序号大于等于5的Pod会先被更新其余保持旧版本。先升级从节点序号较大的通常是后创建的从节点逐个验证从节点升级后能正常同步数据然后再调整partition值逐步推进到主节点。每升级完一批跑一次redis-cli cluster check确认没有任何slot处于迁移或者失败状态再继续。还有一个容易被忽略的点镜像升级后Redis的AOF文件版本和RDB文件的兼容性。大版本跨级升级时比如5.x直接跳到7.x较老的AOF文件可能无法被新版本加载。官方建议是跨大版本升级时先做一次全量备份和恢复演练别怕麻烦。我们有一次就是从某个老版本跨两个大版本升级启动后Redis进程一直在做AOF重写CPU跑满半小时就是因为新版本对AOF的解析效率变化导致的。后来学乖了升级前先把AOF关掉重新生成一份干净的RDB文件再切换镜像整个启动过程降到几秒。4.3 备份和恢复不是dump完就万事大吉Redis Cluster的备份不像单机Redis那么简单因为数据是分散在多个分片上的。你单独备份某一个节点的RDB文件只能恢复这个分片的数据不能组装出一份完整数据。所以集群备份要按分片逐一执行并且要保证每个分片的备份时间点在业务上尽量一致否则恢复出来的数据在分片之间是对不齐的。Kubernetes环境里我会同时做两层备份。第一层是自动的每天某个时间点遍历所有主节点Pod执行一次BGSAVE把RDB文件拷贝到对象存储或者共享存储目录。第二层是数据库层面为每个分片做一次redis-cli --cluster backup部分版本有这个命令但通常这个命令在一体化备份上不够可靠所以更通用的做法是直接在业务低峰期分别对每个分片执行DUMPRESTORE或直接拷贝RDB。数据量大的时候DUMP逐个key的方式不现实RDB文件拷贝才是王道。恢复的时候顺序也很重要。不要直接把备份拷回去就启动所有节点否则可能因为节点ID冲突导致整个集群互相不认识。标准步骤是停止业务流量把所有Redis节点清空成空集群状态然后按分片逐个恢复RDB文件并启动节点每个节点启动后用redis-cli cluster meet重新入伙等所有节点都加入集群、槽位分配正常后恢复业务流量。这套流程我们演练过一次总耗时大概在10分钟内。如果你没有定期演练恢复流程那我建议至少每季度做一次。Kubernetes环境的好处是Pod可以随时快速重建恢复流程可以自动化脚本化花一次时间写好脚本后面每次恢复就是一条命令的事。5. 监控告警、安全配置和清理操作里最容易翻车的细节集群稳定跑起来之后紧接着的问题就是怎么监控它、怎么保护它、以及万一要下线的时候怎么收摊。这三件事看着是“外围工作”处理不好能直接把前面所有努力清零。5.1 监控怎么接Metrics端口和ServiceMonitor的坑Redis Cluster的监控有两个层面。一是看Pod级别的CPU、内存、网络、磁盘这些可以交给K8s自身的监控体系二是看Redis内部的集群健康状况、缓存命中率、键数量变化、内存碎片率等指标这一层需要Redis暴露INFO数据通过exporter转成Prometheus格式。比较成熟的方案是redis_exporter配合ServiceMonitor接入Prometheus。但这里有个细节每个Redis节点Pod必须暴露一个单独的口令端口或者在不暴露的情况下让exporter能区分出它是主节点还是从节点、属于哪个集群。如果6个Pod共用同一个Service且没有按Pod区分指标来源你在Prometheus里看到的内存指标就分不清是哪台机器的。我们在实践里给每个Pod都配了一个exporter容器让它以sidecar方式运行exporter连接到本地的Redis端口拉取指标再通过各自的Pod指标端口暴露。这种方式的好处是在K8s的ServiceMonitor里可以直接用endpoints配置按Pod名匹配Prometheus会天然给每个Pod生成一套独立的指标序列。另外一定不要忘了监控集群状态本身的关键指标cluster_state是ok还是fail、cluster_known_nodes是否等于预期节点数、cluster_slots_assigned是否等于16384。这三个指标任何一个异常都比内存使用率高一个量级的重要程度应该设置成最高级别的告警。我们见过一次内存使用率告警刷了一堆工单真正严重的主从断连告警却因为规则配错而被忽略了结果业务侧先发现了问题。5.2 密码、TLS和网络策略的取舍K8s环境里的Redis如果只被同集群内部的应用访问过去很多人图方便不设密码。但我要说的不是“必须设密码”这种泛泛的劝告而是一个很具体的场景如果你用了NodePort或者LoadBalancer方式对外暴露Redis端口又或者集群里的其他非Redis应用有权限访问所有Pod网段那么不设密码就是裸奔。Redis Cluster模式下启用密码认证需要在所有节点配置requirepass和masterauth两个参数。前者是客户端认证密码后者是主从复制时从节点向主节点认证用的密码。很多人只设置了requirepass结果从节点同步数据时一直报MASTER auth failed就是这个原因。TLS加密在Kubernetes环境里比较复杂因为每个Pod重建后证书的SAN匹配逻辑很容易出问题。除非安全合规明文要求我一般不推荐在集群内部先上TLS风险收益比不高。更划算的做法是用NetworkPolicy把Redis的网络访问范围限制到只有业务Pod所在的命名空间其他来源一律拒绝。这个措施防的是内部误访问真的防不了恶意攻击但内部环境里最常见的风险本来也就是误操作和非预期访问。还有一个小细节密码不要写在StatefulSet的yaml明文里。虽然K8s有Secret资源但Pod模板里的环境变量引用Secret的值在最终渲染结果中会以明文出现。更稳妥的方式是挂载Secret为文件在Redis配置里通过include的方式读取密码文件内容。配置文件的解析方式不同具体做法可以查一下当前镜像支持的配置能力但无论如何不要在yaml里直接写密码就对了。5.3 删除集群时怎样不让数据“断片”清理集群听起来简单kubectl delete statefulset再删PVC就完了。但在企业环境里往往不是这样干净收场的特别是你有备份、有监控、有其他团队的应用还指着这个集群。删除顺序应该是先停业务流量再摘除应用的连接然后才轮到K8s资源。摘应用连接这个步骤最容易被忘记。如果应用还在持续写入你直接删StatefulSetPVC可能会被保留也可能被回收取决于StorageClass配置。数据本身丢了是一回事更麻烦的是应用端可能残留连接池持续报连接异常影响面从Redis本身扩大到整个业务系统。我的经验是删除前先对所有主节点执行一次redis-cli --cluster check确认没有迁移中的slot然后把集群节点逐个--cluster del-node卸掉让整个集群在逻辑上回到“未初始化”状态最后再删除K8s资源。这个顺序能保证即使后续有人想回溯什么问题Redis的日志和数据文件都还在而不是留下一个半死不活的僵尸集群。PVC是否删除取决于你有没有保留数据的必要。如果明确确认数据不要了删PVC是干净的如果可能有回滚需要建议先给所有RDB文件留一份冷备再删成本不高但能救命。6. 一点个人经验别迷信“开箱即用”最后聊一点不太容易被写在技术文档里的东西。Kubernetes和Redis Cluster都是非常成熟的系统但两者组合之后的坑远远比单用其中一个多。很多团队装集群时顺手搜个yaml直接apply看着起来了、状态ok就觉得完事了。真正的问题往往出现在第一次Pod重建、第一次主从切换、第一次升级运维的时候。我见过不少项目集群装好后半年都没出过事大家以为稳定了结果一次节点维护让整个集群瘫痪了一个小时。我的建议是从装集群的第一天起就把故障演练当成上线流程的一部分。至少每两个月做一次小规模演练手动删掉一个主节点对应的Pod观察集群自动恢复的耗时模拟一次网络分区看看Cluster的故障转移是否按预期触发。这些演练在Kubernetes环境里执行成本很低一条kubectl delete pod命令的事但它的价值会在真正出事那天体现出来。还有一点是关于版本选择。Redis的版本迭代速度很快Kubernetes本身也在持续演进不要追新也不要死守特别老的版本。我的经验是选择比自己需要的稳定版本晚一个大版本或者两个小版本的版本既不会踩太多新版本的坑又能拿到足够多的bug修复。升级前务必先在测试环境跑通一遍再动生产别省这点时间。整个实践过程中我最受益的一个习惯是每个关键参数和每次变更记录都写清楚“为什么这么改”而不是只记“改了什么”。Redis Cluster涉及的参数很多有些参数在单机模式下根本不存在有些参数只有在故障转移时才会展露它的重要性。留下决策记录后面做故障复盘和容量规划的时候能省掉大量重新回顾的时间。如果这篇文章能帮你少踩几个坑那就值了。集群装好后还是那句话稳定运行才是开始好好盯着它善待它。