OpenShift如何配置多服务Pod副本实现故障时流量自动切换

你设计的同组Pod绑定流量的架构属于强故障域隔离部署模式，OpenShift原生支持两种落地路径，分别匹配你的初始架构预期、以及更符合云原生设计的低运维成本高可用方案。

方案1：匹配预期的分组副本集实现 #

该方案完全对齐你设计的Set1/Set2独立调用链架构，故障时整组流量切走，配置步骤如下：

• 第一步：给两组副本打统一故障域标签。直接在各应用的application.template的Pod元数据段添加标签，Set1下所有FE、BE1、BE2 Pod统一打set-id=set-1标签，Set2下所有Pod统一打set-id=set-2标签。
• 第二步：为每组创建独立的内部服务。不要用跨组的全局Service，分别为Set1创建fe-set1、be1-set1、be2-set1三个Headless Service，选择器匹配对应应用名+set-id=set-1标签；同理为Set2创建fe-set2、be1-set2、be2-set2三个Headless Service。
• 第三步：配置同组流量亲和规则，避免跨组调用。通过OpenShift Downward API把当前Pod所属的set-id标签注入为容器环境变量，不需要硬编码分组标识，Deployment中环境变量配置片段如下：

  env:
  - name: SET_ID
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['set-id']
  

  之后把FE配置中BE1的访问地址改为http://be1-${SET_ID}:<服务端口>，BE1配置中BE2的访问地址改为http://be2-${SET_ID}:<服务端口>，就能保证Pod永远只调用同组内的下游服务。
• 第四步：配置入口层故障自动切换。在最外层的OpenShift Route上同时绑定fe-set1、fe-set2两个后端Service，开启Route的主动健康检查，当某一组FE的所有后端副本都异常时，Route会自动把所有用户流量切到另一组健康的FE，连带实现整条调用链的故障转移。
• 第五步：调整pipeline配置，把两组副本的部署拆为独立阶段，支持单组独立发版、单组故障隔离，不会因为单组发布或故障影响全量服务。

方案2：推荐的云原生原生高可用方案 #

强分组方案存在明显的资源浪费问题：只要组内任意一个服务的副本故障，整组容量就完全不可用，常态下资源利用率仅50%，且运维需要维护多套服务配置。直接用OpenShift原生的服务发现、健康检查、调度能力可以实现更灵活的高可用，不需要强制绑定同组Pod：

• 第一步：为三类应用分别创建全局ClusterIP Service：fe-svc、be1-svc、be2-svc，选择器只匹配对应应用的标签，不做分组区分。
• 第二步：每类应用至少配置2副本（和你原设计的总容量一致），同时配置Pod反亲和规则，保证同一应用的不同副本调度到不同节点、不同可用区，避免单机/单可用区故障导致服务完全不可用。
• 第三步：为所有Pod配置存活探针和就绪探针：存活探针检测应用进程状态，异常时自动重启Pod；就绪探针调用应用本身的业务健康检查接口（比如Java应用的Spring Boot Actuator健康端点、React前端的静态页探活），检测到业务异常时自动把该Pod从Service的后端端点列表中剔除，OpenShift的kube-proxy会自动把流量转发到同服务其他健康副本，流量切换完全不需要人工干预。
• 第四步：在服务间REST调用的客户端配置合理的超时时间和1-2次失败重试，当单次请求刚好打到异常副本时，客户端会自动重试到其他健康副本，用户完全无感知。
• 方案收益：该模式下常态资源利用率可达100%，单副本故障只会影响对应服务的部分容量，不会出现整组不可用的情况，故障影响面更小；同时不需要维护多组服务、环境变量拼接逻辑，滚动发布时可以实现零停机，运维成本远低于强分组方案。

通用配置注意事项 #

• 所有服务间访问一律使用OpenShift内部Service DNS名称，不要写固定Pod IP，避免Pod重启IP漂移导致通信失败。
• 如果业务需要会话保持，优先在Route层配置cookie维度的会话亲和，不要配置IP维度亲和，避免Pod漂移导致会话失效。
• 就绪探针不要只用TCP端口探活，一定要调用真实的业务健康检查接口，避免出现进程存活但业务逻辑已经卡死的假健康状态。

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