企业官网建设流程全解析

将现有的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-gateway
topologyKey: 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"