将现有的redis statefulSet迁移到 redisFailover
因为sentinel并不会自动及时监听到masterip的变化 redis默认的运行机制认为ip是不会频繁变动的
之前再sentinel command内
echo "sentinel monitor mymaster $MASTER_IP 6379 2" >> /etc/redis/sentinel.conf
echo "sentinel auth-pass mymaster R3d1s@2026Sec!" >> /etc/redis/sentinel.conf
sentinel master slave关系
master 主 slave 从节点
sentinel是健康监管 并负责监听master fail时 推举新的主节点
排查sentinel访问问题
echo -e "INFO sentinel\r\n" | nc redis-sentinel-service.backend-space.svc.cluster.local 26379
master0 开头的信息 从后端pod内部执行查看 redis sentinel状态
data解析错乱 解析成null报错 helm模板解析
secret
stringData：
redis-password 使用stringData代替 data防止 解析错乱
添加 Helm repo
helm repo add spotahome https://spotahome.github.io/redis-operator
helm repo update
安装到 kube-system
helm install redis-operator spotahome/redis-operator \
-n kube-system \
--set image.repository=quay.io/spotahome/redis-operator \
--set image.tag=v1.4.0
apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
name: redis-ha
namespace: backend-space
spec:
sentinel:
replicas: 3
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
-
matchExpressions:
-
key: type
operator: In
values:
- virtual-kubelet
tolerations:
- key: "virtual-kubelet.io/provider"
operator: "Exists"
effect: "NoSchedule"
redis:
replicas: 3 # 1 master + 2 slave，Operator 自动管理角色
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: "1"
memory: 1Gi
password: "R3d1s@2026Sec!"
storage:
keepAfterDeletion: true
emptyDir: {} # 或改为 persistentVolumeClaim 持久化
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
-
matchExpressions:
-
key: type
operator: In
values:
- virtual-kubelet
tolerations:
- key: "virtual-kubelet.io/provider"
operator: "Exists"
effect: "NoSchedule"
auth:
secretPath: redis-secret # 引用你现有的 Secret
跨节点请求的优化方案
因为nlb和 gateway pod所在的可用区不一定相同 经常出现需要跨可用区请求访问 这个无法避免 但是流量从gateway到后端业务pod时 可以针对可用区节点的调度进行优化
节点亲和性配置
优先将后端业务pod调度到 gateway所在的节点，因为gateway nlb默认要有两个可用区
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: higress-gatewaytopologyKey: topology.kubernetes.io/zone
拓步感知 优先转发
annotations:
service.kubernetes.io/topology-mode: Auto
从gateway转发请求时优先转发给同可用区的pod 需要搭配 topologySpreadConstraints 节点分散可用区部署同时使用
topologySpreadConstraints:
配置节点分散可用区部署
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: xxxx
注意：这种 只有当后端pod 副本再每个可用区上面超过3个时候才会生效
对于会话保持即 长连接的调度优化
业务场景：对于在pod内部存储了连接状态，因为我的SSE 在多进程业务中是使用的map内部存储的 如果map里已经存在则使用命中缓存 这种情况下 如果连接失败了重新连接的时候调度到别的pod内则会造成内存没有正确释放 有僵尸进程
sessionAnifity:clientIp 同一的客户端ip请求调度到同一个pod 缺点 对于特殊网络 比如热点网络等由于客户端IP会变化 导致连接失败
或者cookie亲和性 （推荐）
annotations:
# 开启 Cookie 亲和
nginx.ingress.kubernetes.io/affinity: "cookie"
# 持久模式：Cookie 有效期内始终路由到同一 Pod
nginx.ingress.kubernetes.io/affinity-mode: "persistent"
# 自定义 Cookie 名称（可选）
nginx.ingress.kubernetes.io/session-cookie-name: "HIGRESSCOOKIE"
# Cookie 有效期（秒），可选
nginx.ingress.kubernetes.io/session-cookie-max-age: "3600"