将现有的redis statefulSet迁移到 redisFailover因为sentinel并不会自动及时监听到masterip的变化 redis默认的运行机制认为ip是不会频繁变动的之前再sentinel command内echo sentinel monitor mymaster $MASTER_IP 6379 2 /etc/redis/sentinel.confecho sentinel auth-pass mymaster R3d1s2026Sec! /etc/redis/sentinel.confsentinel master slave关系master 主 slave 从节点sentinel是健康监管 并负责监听master fail时 推举新的主节点排查sentinel访问问题echo -e INFO sentinel\r\n | nc redis-sentinel-service.backend-space.svc.cluster.local 26379master0 开头的信息 从后端pod内部执行查看 redis sentinel状态data解析错乱 解析成null报错 helm模板解析secretstringDataredis-password 使用stringData代替 data防止 解析错乱# 添加 Helm repohelm repo add spotahome https://spotahome.github.io/redis-operatorhelm repo update# 安装到 kube-systemhelm install redis-operator spotahome/redis-operator \-n kube-system \--set image.repositoryquay.io/spotahome/redis-operator \--set image.tagv1.4.0apiVersion: databases.spotahome.com/v1kind: RedisFailovermetadata:name: redis-hanamespace: backend-spacespec:sentinel:replicas: 3resources:requests:cpu: 100mmemory: 128Milimits:cpu: 500mmemory: 512Miaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: typeoperator: Invalues:- virtual-kubelettolerations:- key: virtual-kubelet.io/provideroperator: Existseffect: NoScheduleredis:replicas: 3 # 1 master 2 slaveOperator 自动管理角色resources:requests:cpu: 100mmemory: 256Milimits:cpu: 1memory: 1Gipassword: R3d1s2026Sec!storage:keepAfterDeletion: trueemptyDir: {} # 或改为 persistentVolumeClaim 持久化affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: typeoperator: Invalues:- virtual-kubelettolerations:- key: virtual-kubelet.io/provideroperator: Existseffect: NoScheduleauth:secretPath: redis-secret # 引用你现有的 Secret跨节点请求的优化方案因为nlb和 gateway pod所在的可用区不一定相同 经常出现需要跨可用区请求访问 这个无法避免 但是流量从gateway到后端业务pod时 可以针对可用区节点的调度进行优化节点亲和性配置优先将后端业务pod调度到 gateway所在的节点因为gateway nlb默认要有两个可用区affinity:podAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchLabels:app: higress-gatewaytopologyKey: topology.kubernetes.io/zone拓步感知 优先转发annotations:service.kubernetes.io/topology-mode: Auto从gateway转发请求时优先转发给同可用区的pod需要搭配 topologySpreadConstraints 节点分散可用区部署同时使用topologySpreadConstraints:# 配置节点分散可用区部署- maxSkew: 1topologyKey: topology.kubernetes.io/zonewhenUnsatisfiable: ScheduleAnywaylabelSelector: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