部署Redis到K8s这件事说简单也简单说复杂也复杂。我见过太多人把Redis部署到K8s之后就当甩手掌柜结果过两天数据全没了也见过有人以为部署进去就万事大吉客户端连接的时候才发现根本连不上。这篇文章是我自己在实际环境里操作过的完整记录从部署设计的思路、配置文件逐项拆解到真正敲下去的每条命令、踩过的每个坑都摊开讲清楚。如果你是刚接触K8s不久的新手这篇文章能让你少走很多弯路如果你已经部署过几次但总感觉哪里不对劲这里也有你想要的排查思路。事情的本质其实是Redis本身是个轻量级的有状态服务而K8s主打的却是无状态工作负载的调度。把Redis搬进K8s你首先要面对的不是Redis本身的问题而是存储、网络、配置管理这些容器的基本功。不把这几块理解透彻Redis在K8s里就是个随时可能爆炸的炸弹。1. 部署前的设计思路为什么K8s上的Redis如此“麻烦”1.1 先搞清楚Redis在K8s里的角色定位Redis是一个典型的有状态服务它需要持久化数据、需要稳定的网络标识、需要感知自己所在节点的位置。而K8s默认的工作负载类型比如Deployment它假设所有Pod都是可替换的无状态副本Pod挂了就重新拉起一个全新的网络标识Pod名字、IP都会发生变化。这就带来了三个直接矛盾数据持久化、网络稳定性、配置同步。数据持久化Redis的内存数据如果不落盘Pod一重启缓存全丢。如果落盘就涉及存储卷挂载、PV/PVC分配、回收策略这些K8s存储体系里的复杂概念。网络稳定性普通Deployment的Pod每次重建IP都会变而客户端无论是业务服务还是外部系统需要稳定的地址去连接Redis。K8s里的Service可以解决这个问题但要把Service的类型、端口映射、集群内外访问方式都考虑清楚。配置同步Redis的密码、绑定地址、持久化策略这些配置怎么管理直接写进容器镜像不行维护成本高。用环境变量传入能解决一部分但复杂的配置项比如多行配置、特殊字符就不太方便。K8s的方式是用ConfigMap和Secret把配置和镜像分离。这三块如果不在动手部署前想明白后面出了问题只能靠瞎猜。1.2 选StatefulSet还是Deployment这是部署Redis时第一个会遇到的决策点。网上教程五花八门有人用Deployment有人用StatefulSet还有人直接用Helm一键装。我的建议很直接单实例Redis、需要稳定磁盘数据、需要稳定网络标识就用StatefulSet如果你的Redis只是当个临时缓存用、数据丢了无所谓、也没有固定域名访问需求那Deployment也能凑合。但生产环境里我强烈建议直接上StatefulSet。StatefulSet和Deployment的核心区别有三个区别点DeploymentStatefulSetPod名称随机后缀如redis-abc12有序标识如redis-0、redis-1存储卷所有Pod共享同一PVC每个Pod绑定独立PVC网络标识Pod重建后IP变化Pod有固定稳定的网络标识可配合Headless Service使用比如你把Redis的StatefulSet声明为redis那么它创建出来的Pod名就是redis-0。只要这个StatefulSet不删除无论Pod怎么重建名字都会是redis-0对应的PVC也是固定的>apiVersion: v1 kind: ConfigMap metadata: name: redis-config namespace: redis data: redis.conf: | bind 0.0.0.0 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised no pidfile /var/run/redis_6379.pid loglevel notice logfile databases 16 always-show-logo no save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb这里有几个关键点我要特别强调。第一daemonize no必须设置为no。在容器里Redis必须以前台进程方式运行如果设置成yesRedis会fork出后台进程容器主进程就直接退出了K8s会认为容器异常然后不断重启最终进入CrashLoopBackOff状态。第二dir /data要跟持久化存储挂载路径对应。后面PVC会挂载到/dataRedis的RDB和AOF文件才会落到持久化卷里。这个路径不对数据就写不进持久化存储。第三bind 0.0.0.0配合protected-mode yes。有人觉得为了安全应该只绑定内网IP但在K8s的Overlay网络环境下Pod的IP是动态分配的你没法提前知道Pod IP所以最方便的是监听所有网卡保护模式靠requirepass来兜底。密码不设的话Redis暴露在集群内就相当于裸奔谁连上谁就能读写。2.2 密码管理用Secret而不是明文写进配置Redis的密码不能直接写在ConfigMap里因为ConfigMap是明文存储的。正确做法是放到Secret里然后通过环境变量注入Redis容器再用启动命令把环境变量拼进Redis的配置。Secret的声明方法很简单apiVersion: v1 kind: Secret metadata: name: redis-secret namespace: redis type: Opaque stringData: redis-password: 这里填你的强密码注意用stringData而不是data这样可以直接写明文密码K8s会自动帮你base64编码存储。密码不要用什么123456、password这类Redis被爆破的例子太多了至少来个20位混合字符。在StatefulSet里把Secret注入环境变量然后通过启动命令传给容器内的Redis进程env: - name: REDIS_PASSWORD valueFrom: secretKeyRef: name: redis-secret key: redis-password对应的启动命令command: [sh, -c] args: - | redis-server /usr/local/etc/redis/redis.conf --requirepass $REDIS_PASSWORD这里用启动命令覆盖配置文件里的requirepass通过环境变量传入避免密码出现在ConfigMap里。即使ConfigMap是明文也不会泄露密码。2.3 持久化存储PVC和StorageClassRedis持久化是整个部署里最容易出错的一环。数据不落盘Pod漂移后缓存全丢这在生产环境是事故级别的问题。使用StatefulSet时你可以通过volumeClaimTemplates来声明存储K8s会自动为每个Pod创建一个PVC命名格式是volumeClaimTemplateName-podName。对应到StatefulSet里就是这样volumeClaimTemplates: - metadata: name: data spec: accessModes: [ReadWriteOnce] storageClassName: standard resources: requests: storage: 10Gi这里有几个细节值得注意存储类storageClassName要和你集群里实际存在的类对应。集群如果用的是云厂商托管K8s通常有默认StorageClass直接写standard即可如果是自建集群得先安装好存储插件比如NFS Provisioner。访问模式Redis是单节点写入用ReadWriteOnce单节点读写就够了。千万别用ReadWriteMany一是很多存储后端不支持二是没必要。容量大小我建议先评估一下你的缓存量级给个宽松值。PV扩容在某些存储后端上不容易操作索性一开始就申请大一点比如10Gi-50Gi。生产数据量大的直接上100Gi也不是不行反正按需分配。2.4 StatefulSet完整清单接下来把上面的内容拼起来一份可用的StatefulSet清单如下apiVersion: apps/v1 kind: StatefulSet metadata: name: redis namespace: redis spec: serviceName: redis-headless replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: - name: redis image: redis:7.0-alpine command: [sh, -c] args: - | redis-server /usr/local/etc/redis/redis.conf --requirepass $REDIS_PASSWORD ports: - containerPort: 6379 name: redis-port env: - name: REDIS_PASSWORD valueFrom: secretKeyRef: name: redis-secret key: redis-password resources: requests: memory: 256Mi cpu: 100m limits: memory: 2Gi cpu: 1 volumeMounts: - name: data mountPath: /data - name: redis-config mountPath: /usr/local/etc/redis/redis.conf subPath: redis.conf volumes: - name: redis-config configMap: name: redis-config volumeClaimTemplates: - metadata: name: data spec: accessModes: [ReadWriteOnce] resources: requests: storage: 10Gi这里再解释几个容易困惑的点。为什么ConfigMap挂载用subPath因为如果直接把整个ConfigMap挂载到目录Redis会找不到配置文件而且ConfigMap里的其他键会覆盖目录下原有文件。用subPath可以把ConfigMap中的redis.conf单独挂成目标文件其余配置项不会污染目录。为什么要设置resources我之前确实踩过坑不在resources里声明limitsRedis在缓存大量数据时内存暴涨直接把节点内存吃满整台K8s节点变得不可用。给Redis一个明确的内存上限比如2Gi超过这个值Redis会开始执行自己的内存淘汰策略而不是把节点搞挂。requests的值可以小一点保证调度时不至于因为资源不足找不到地方放Pod。3. 服务的暴露方式与访问链路3.1 Headless Service和普通Service的区别部署Redis通常需要两类Service一类用在集群内部访问一类用于外部访问或者调试。这里要把Service类型彻底搞清楚。Headless Service是专门配合StatefulSet使用的它的clusterIP设为None。这个Service不为Pod创建虚拟IP而是直接通过DNS记录把域名解析到Pod的IP地址。这样Pod之间可以直接通过稳定域名互访对Redis Cluster这类需要感知Pod成员关系的场景尤其重要。StatefulSet定义里的serviceName字段必须指向这个Headless ServiceapiVersion: v1 kind: Service metadata: name: redis-headless namespace: redis spec: clusterIP: None selector: app: redis ports: - port: 6379 targetPort: 6379ClusterIP Service是给客户端访问用的。它提供一个稳定的虚拟IP集群内其他业务Pod通过这个Service名字就能连接Redis而不用关心后端Pod IP怎么变。定义方式apiVersion: v1 kind: Service metadata: name: redis-service namespace: redis spec: type: ClusterIP selector: app: redis ports: - port: 6379 targetPort: 6379之后集群内的其他应用直接用redis-service.redis.svc.cluster.local:6379就能连上Redis。3.2 集群外部访问Redis的几种方式需要从集群外部连Redis的场景不少本地调试、数据迁移、运维工具连接。三种方式各有利弊NodePort在每个节点上开一个固定端口比如30001映射到Redis的6379端口。简单直接但注意端口范围限制默认是30000-32767。配置方法是在Service定义里指定type: NodePortK8s会随机分配一个可用端口你也可以手动指定。这种方式适合小规模测试环境。LoadBalancer云平台会分配一个公网IP给Service流量直接负载均衡到后端Pod。生产环境推荐。缺点是需要依赖云厂商负载均衡器服务。Ingress不推荐给Redis用。Ingress处理的是HTTP/HTTPS协议虽然新版本也能处理TCP但Redis是二进制协议绕过Ingress直接用Service暴露更简单、更稳定。我自己的习惯是集群内服务访问用ClusterIP公网访问走LoadBalancer。NodePort在调试时临时用一下排查完就关掉免得暴露到不可控的网络范围。4. 实际操作从apply到验证的全过程4.1 创建命名空间和资源对象配置准备好后实际部署操作很直接。假定你的清单文件都存成了文件形式按逻辑顺序执行kubectl create namespace redis kubectl apply -f redis-config.yaml kubectl apply -f redis-secret.yaml kubectl apply -f redis-service.yaml kubectl apply -f redis-statefulset.yaml按顺序执行模块清晰哪个步骤失败也比较容易定位。4.2 查看部署状态apply完成后不要急着去连接Redis先观察Pod状态kubectl -n redis get pods正常情况下你会看到NAME READY STATUS RESTARTS AGE redis-0 1/1 Running 0 1m如果STATUS不是Running就按后面第5节的排查思路去处理。接着查看PVC是否绑定成功kubectl -n redis get pvc输出里STATUS列应该是Bound表示持久化卷已经成功挂载。如果一直是Pending说明存储类有问题检查StorageClass和对应的存储插件。查看Servicekubectl -n redis get svc确认redis-service和redis-headless都存在ClusterIP也分配正常。4.3 进入容器验证Redis功能Pod处于Running状态后进容器里做一轮功能验证kubectl -n redis exec -it redis-0 -- redis-cli不带密码进去会被拒绝这是正常的说明protected-mode和requirepass生效了。接下来用密码登录kubectl -n redis exec -it redis-0 -- redis-cli -a 你的密码连上之后可以输入ping返回PONG说明Redis正常。再验证一下基本读写127.0.0.1:6379 set mykey hello OK 127.0.0.1:6379 get mykey hello然后验证数据持久化kubectl -n redis delete pod redis-0Pod被删除后StatefulSet会自动重建等新Pod起来后再次进入容器执行get mykey如果还返回hello说明数据持久化生效了。这一步非常关键能直接验证你前面所有存储配置是否正确。很多人的问题就出在这里Pod重建后数据丢失那就说明PVC没绑对或挂载路径不对。4.4 从集群内其他Pod连接Redis模拟一个客户端Pod来验证集群内服务的联通性kubectl -n redis run redis-client --rm -it --image redis:7.0-alpine -- sh进入容器后redis-cli -h redis-service.redis.svc.cluster.local -p 6379 -a 你的密码能正常连上说明ClusterIP Service的域名解析和端口转发都工作正常。5. 常见故障与排查我在实际操作中踩过的坑5.1 CrashLoopBackOff容器无限重启这个是部署Redis最最常见的错误。表现形式是Pod一直在重启kubectl get pods看到的STATUS一直是CrashLoopBackOff。排查第一步看日志kubectl -n redis logs redis-0最常见的原因有几种daemonize yes导致容器启动后主进程退出。日志里能看到Redis启动成功但容器依然重启。解决方法就是把daemonize no改回来。配置文件路径不对或者无权限读取。日志里会报找不到配置文件或者权限不足。检查ConfigMap挂载路径和subPath写法确保容器内路径存在且可读。系统权限问题。比如某些安全上下文策略阻止容器写/data目录。日志会报Permission denied。这时需要给StatefulSet里的Pod指定securityContext给Redis容器一个可写的用户IDsecurityContext: runAsUser: 999 fsGroup: 999这里999是Redis官方镜像里redis用户的UID。不做权限配置容器写/data时大概率会遇到权限问题。5.2 Pending状态的Pod存储和资源问题Pod一直Pending说明调度器无法找到合适的节点承载这个Pod。看描述的报错kubectl -n redis describe pod redis-0常见情况PVC未绑定Events里报persistentvolumeclaim not found或storageclass not found。回到PVC那块排查。资源不足节点内存或CPU不足以满足Pod的requests。可以临时调低requests的值测试或者扩容节点。节点亲和性不满足如果清单里配了nodeSelector或污点容忍但没有对应的节点挨得上也会Pending。5.3 ImagePullBackOff镜像拉不下来这个报错信息很直白字面意思就是镜像拉取失败。常见原因镜像标签写错、节点无法访问外网镜像仓库、私有仓库没配置凭据。排查kubectl -n redis describe pod redis-0看到Events里有Failed to pull image先用docker pull在节点上手动拉一次镜像能拉下来说明仓库和网络没问题重点查K8s侧配置拉不下来就看网络、仓库账号和镜像地址是否正确。内网环境可以用docker.io镜像加速器或者把镜像提前推送到集群内可访问的私有仓库。5.4 客户端连接超时或拒绝连接Service看起来正常Pod也Running但客户端就是连不上。这时要检查几个层面端口映射是否正常kubectl -n redis get svc确认Service的端口和目标端口一致。Pod内Redis监听的是6379Service的port和targetPort都要对应。Pod内部网络是否通畅在集群内随便起一个临时Pod用redis-cli -h redis-service.redis.svc.cluster.local -p 6379 -a 密码测试连通。连不上就说明Service的Selector没选中Pod。防火墙/网络安全策略有些集群启用了NetworkPolicy默认拒绝跨命名空间流量。检查是否有网络策略限制了Redis的访问来源。5.5 密码不生效这是一个特别的坑。如果你把requirepass直接写进了redis.conf然后又用命令行参数--requirepass再传一次密码那Redis会以最后一次指定的密码为准。如果两者不一致就会出现用配置文件密码连接失败、用命令行密码连接成功的情况。排查方式kubectl -n redis exec -it redis-0 -- redis-cli config get requirepass输出里的密码就是Redis当前实际使用的密码。如果和预期不一致统一把密码配置放到Secret里通过环境变量注入避免多源头管理。6. 生产环境部署的额外建议6.1 给Redis加监控和告警Redis部署上线只是开始保证稳定运行才是常态。生产环境建议加上监控至少覆盖几个指标内存使用率接近maxmemory设置值时需要告警。连接数连接数突然暴涨或打满时通常意味着业务方出现异常。持久化失败事件bgsave失败或AOF重写失败说明磁盘或权限出了问题。key过期情况和命中率命中率下降说明缓存策略需要调整。在K8s生态里比较快捷的方案是部署一个redis-exporter边车容器把Redis的metrics暴露成Prometheus格式再用Prometheus Grafana展示和告警。通过在StatefulSet里多加一个容器配合ServiceMonitor就能接入监控。边车容器的基本形态- name: redis-exporter image: oliver006/redis_exporter:v1.45.0 env: - name: REDIS_ADDR value: redis://localhost:6379 - name: REDIS_PASSWORD valueFrom: secretKeyRef: name: redis-secret key: redis-password ports: - containerPort: 9121注意REDIS_PASSWORD这个环境变量名要和exporter实际读取的变量名对应不同的exporter版本通常都兼容我写的这个变量名。接入之后按Prometheus的规则拉取redis_exporter容器的/metrics端点即可。6.2 数据备份与恢复策略日常使用中我习惯做两层备份一层是Redis内部持久化开启AOFappendonly yes设置appendfsync everysec。这是Redis自己的数据恢复机制Pod重启后能恢复到最近一秒的状态。一层是外部定期备份通过定时任务执行redis-cli --rdb或redis-cli bgrewriteaof把数据文件导出到对象存储或者定期对PVC做快照。持久化文件是数据安全的最后一道防线尤其当POD被误删除、PVC被误清理时外部备份能救命。K8s里定时执行命令可以用CronJobapiVersion: batch/v1 kind: CronJob metadata: name: redis-backup namespace: redis spec: schedule: 0 2 * * * jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: redis-cli image: redis:7.0-alpine command: [sh, -c] args: - | redis-cli -h redis-service.redis.svc.cluster.local -p 6379 -a 你的密码 --rdb /tmp/redis-backup.rdb \ cp /tmp/redis-backup.rdb /backup/redis-backup-$(date %Y%m%d).rdb volumeMounts: - name: backup-volume mountPath: /backup volumes: - name: backup-volume persistentVolumeClaim: claimName: redis-backup-pvc这个CronJob每天凌晨两点执行一次RDB备份把持久化文件存到专门的备份PV里。实际使用中再配合对象存储上传双保险。6.3 从单实例到集群的演进单实例Redis始终有单点故障风险尤其是缓存数据量增长到几十GB、并发访问量上涨时单机再大也扛不住。在K8s上做Redis Cluster我建议分两步走第一步把单个Redis实例的完整性保证好监控到位数据备份稳定。第二步数据量或访问量确实上来后再考虑主从复制或官方Redis Cluster。主从方案可以通过在StatefulSet里把replicas设为2以上配合Pod内启动时自动执行replicaof实现。true集群方案要引入多个StatefulSet和相应的哨兵/代理机制复杂度会明显上升。这个时候可以先评估一下是否需要引入外部的高可用方案还是直接升级到托管云Redis根据团队运维能力权衡再决定。我在生产环境中的习惯是如果只是缓存需求并且对数据丢失容忍度较高单实例日备方案就够如果Redis承担了业务强依赖的数据存储角色那无论如何都要考虑复制和高可用不要让单实例变成“定时炸弹”。7. 最后再分享几个我的个人习惯部署Redis到K8s我个人的建议是不要照抄任何一个配置文件模板。每个集群环境不同存储类不同、网络插件不同、安全基线也不同。我的做法是先跑通最小的可用配置验证存储和网络再逐步加上密码、监控、容灾这些生产要素。一次别贪多否则出错了都不知道问题是哪一步引入的。还有一个小技巧StatefulSet部署完后赶紧把PVC的名字记下来。以后排查数据持久化问题这个PVC就是最重要的依据。>