Kubernetes/Openshift中保持客户端与服务端流量同区域的最佳方案

推荐实现方案 #

以下方案均适配OKD 3.11（对应Kubernetes 1.11版本）的原生特性，无需额外引入复杂组件，可彻底避免跨区域轮询访问Redis的问题：

方案1：同区域调度+分区域Service绑定（兼容性最好，推荐优先使用） #

• 第一步：按区域部署独立的Redis副本集
  为每个区域单独部署一套Redis实例，通过nodeSelector绑定对应区域的节点，示例配置：

  nodeSelector:
    failure-domain.beta.kubernetes.io/region: zone-a # 替换为你的区域标签值
  

  每个区域的Redis对应一个独立的Service，仅选择本区域的Redis Pod作为后端，命名格式建议为redis-<区域名>，例如redis-zone-a、redis-zone-b。
• 第二步：应用注入区域信息自动绑定同区域Redis
  通过Kubernetes Downward API将当前Pod所在节点的区域标签注入为应用的环境变量，应用启动时自动拼接对应区域的Redis Service域名即可，Downward API配置示例：

  env:
  # 直接读取节点的区域标签注入环境变量
  - name: NODE_REGION
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['failure-domain.beta.kubernetes.io/region']
  

• 优势：完全从路由侧隔离跨区域访问，Service仅包含本区域Redis后端，不存在轮询到跨区域节点的可能，无需修改Redis客户端配置，兼容性最高。

方案2：Pod亲和性+拓扑感知服务路由（适合单一Redis集群场景） #

如果不想拆分多套Redis Service，采用统一Redis集群部署时可以使用该方案：

• 第一步：给所有Redis Pod打上区域标签，例如redis-region: zone-a
• 第二步：给后端应用配置Pod亲和性，优先调度到和Redis Pod同区域的节点，同时配置服务的拓扑路由规则（注：该特性为Kubernetes 1.17后引入的alpha特性，如果你的OKD 3.11集群未开启对应FeatureGate，优先使用方案1即可），指定服务优先将流量转发到同区域的后端Pod，配置示例：

  apiVersion: v1
  kind: Service
  metadata:
    name: redis
  spec:
    selector:
      app: redis
    ports:
    - port: 6379
    topologyKeys:
    - "failure-domain.beta.kubernetes.io/region"
    - "*"
  

• 优势：无需拆分多个Redis Service，维护成本更低，流量会优先转发到同区域的Redis副本，仅当本区域副本不可用时才会跨区访问。

方案3：Redis客户端侧就近访问（适合Redis哨兵/集群模式） #

如果已经部署了跨区域的Redis哨兵或者Redis Cluster集群，可以直接在客户端配置优先访问同区域的节点：

• 先通过Downward API将应用所在区域注入到Pod环境变量
• 客户端初始化时优先选择和自身区域一致的Redis节点作为访问入口，读请求直接走同区域副本，写请求可根据一致性要求选择转发到主节点或者本地同步副本。

内容的提问来源于stack exchange，提问作者mirekphd