Envoy控制平面多实例故障转移机制及耗时确定性问题咨询

你当前配置的控制平面对应集群为STRICT_DNS类型，Envoy与控制平面之间基于xDS协议的双向流gRPC长连接通信，故障转移逻辑如下：

• 基础端点发现：Envoy按照固定周期解析配置的control-plane-fqdn，将解析返回的所有IP作为该集群的可用端点，默认采用轮询策略在端点间做负载均衡。
• 连接状态监测：Envoy与选中的控制平面实例建立gRPC长连接后，会持续监测连接状态：如果收到实例主动发送的TCP FIN/RST断连包、传输层报错、保活探测连续失败，会立刻将该端点标记为不健康，从可用连接池中剔除。
• 故障触发重连：现有活跃连接被判定失效后，Envoy会立即从当前已解析到的健康端点列表中选择下一个实例发起新的gRPC连接，连接超时取配置的connect_timeout值；如果单次连接失败，会按退避规则重试，直到成功连接到可用实例。
• 补充说明：单控制平面集群场景下，Envoy同一时间只会和一个控制平面实例保持活跃xDS流，不会同时维持多连接。

耗时跨度大本质是多个未显式配置的默认参数、故障场景差异、时间相位差共同导致的，不同场景下触发耗时的逻辑完全不同：

• 5s左右的低耗时场景：当控制平面实例优雅关停时，会主动向Envoy发送TCP断连信号，Envoy内核层可立刻感知连接失效，直接触发重连，重连超时为你配置的5s，新连接建立完成总耗时就落在5s左右，这是最优场景。
• 中等耗时场景：如果控制平面实例是崩溃退出、网络隔离等异常下线，不会主动发送断连信号，Envoy无法立刻感知故障。此时如果故障发生时间刚好临近DNS刷新节点，Envoy会在定期解析DNS时发现故障IP已被从记录中摘除，主动剔除故障端点后触发重连；如果故障刚发生在上一次DNS刷新刚结束的时间点，就要等完整一个DNS刷新周期（默认5s）才会更新端点列表，加上连接耗时总时长会落在10s-20s区间。
• 50s左右的高耗时场景：默认配置下Envoy不会主动为上游HTTP/2（gRPC基于HTTP/2运行）连接开启高频保活探测，异常断连后最长需要等待默认的gRPC保活超时（约45s）才能判定连接失效，加上5s的连接超时，总耗时就接近50s。如果此时故障实例的IP还没从DNS记录中摘除，Envoy重连时可能先尝试连接故障IP，等满5s超时后再切下一个地址，重试次数的随机性也会进一步拉长耗时。

可以通过显式配置把所有不确定的时间参数固定，将故障转移耗时收敛到可预期的区间：

• 固定DNS刷新逻辑：在cplane集群配置中显式指定DNS刷新周期，替换默认的随机退避逻辑，示例配置如下：

dns_refresh_rate: 2s
dns_failure_refresh_rate:
  base_interval: 1s
  max_interval: 2s

配置后DNS解析的最大等待时间固定为2s，不会出现解析失败时随机退避拉长耗时的问题。

• 显式开启HTTP/2连接保活：不要依赖默认的内核TCP保活（默认时长2小时，完全不适用长连接场景），主动配置固定间隔的HTTP/2 PING探测，最快感知连接故障：

typed_extension_protocol_options:
  envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
    "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
    explicit_http_config:
      http2_protocol_options:
        connection_keepalive:
          interval: 3s
          timeout: 1s

配置后每3秒发送一次保活探测，1s未收到响应就判定连接失效，最长4s就能感知到异常断连。

• 开启异常点检测避免重复重试故障IP：配置异常点检测规则，单次连接失败就临时驱逐故障端点，不要反复重试无效地址：

outlier_detection:
  consecutive_gateway_failure: 1
  interval: 1s
  base_ejection_time: 30s
  max_ejection_percent: 100

• 固定重连退避参数：在xDS对应的config_source配置中，固定gRPC流断开后的重连间隔，关闭默认的随机指数退避：

grpc_services:
  envoy_grpc:
    cluster_name: cplane
initial_stream_reconnect_delay: 1s
max_stream_reconnect_delay: 2s

• 调整连接超时：由于Envoy和控制平面通常部署在同机房或同可用区，TCP连接建立耗时通常在百毫秒以内，可以把connect_timeout从5s调整为2s，减少无意义的连接等待。

按以上配置调整后，故障转移总耗时可以稳定在3s-6s区间，不会出现几十秒的极端波动。

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