Kubernetes环境下基于Consul+Envoy配置gRPC粘性通信时负载均衡策略不生效问题

现有配置存在的核心问题 #

• 流量路径绕过 Consul 网格代理
  所有 ServiceResolver 定义的负载均衡规则，仅对经过 Consul 纳管的 Envoy 代理的流量生效。你当前的 LoadBalancer 类型 K8s Service 如果直接将流量转发到后端 grpc-test Pod 的 18788 端口，未经过 Consul Ingress 网关、也未走 Pod 内置的 Envoy 边车，网格层规则会被完全绕过，流量直接走 K8s Service 默认的随机转发逻辑。
• ServiceResolver 绑定的目标服务不匹配
  Consul ServiceResolver CRD 会通过 metadata 名称，绑定同命名空间下 Consul Catalog 中注册的后端业务服务，而非外部访问用的 LoadBalancer 类型 K8s Service。你当前将 ServiceResolver 命名为 grpc-test-load-balancer，规则完全匹配不到实际处理 gRPC 流量的后端服务，不会触发任何生效逻辑。
• 未向 Consul 声明 gRPC 服务协议
  你的 K8s Service 仅标注了 TCP 转发协议，未携带 Consul 识别服务协议的注解。Consul 默认会将未声明协议的服务归类为 L4 纯 TCP 转发流量，对应 Envoy 实例只会加载 TCP 转发过滤器，不会启用 L7 层的负载均衡 hash 处理逻辑，所有自定义策略都会被忽略，回退到默认随机策略。
• hashPolicies 字段不适配 gRPC 场景
  你配置的 hash 提取字段为 cookie，该字段是专门针对 HTTP1 浏览器请求的 Cookie 头设计的提取规则。gRPC 流量基于 HTTP2 协议，调用方默认不会携带 Cookie 头，且 Consul 的 gRPC 流量处理逻辑不会从 Cookie 字段提取粘性标识，即便规则绑定正确，也无法获取有效 hash 值。

修复调整步骤 #

• 梳理流量转发路径：确保从 LoadBalancer 入口进入的全部 gRPC 流量，经过 Consul 治理的 Envoy 网关/边车代理，不绕过网格直接转发到后端 Pod。
• 调整 ServiceResolver 的 metadata 名称，使其与后端被 Consul 注册的实际业务服务名完全一致，即后端 app: grpc-test 对应的 K8s Service 名称，不再用外部访问的 LoadBalancer Service 名做规则绑定。
• 给后端业务 K8s Service 添加 Consul 协议注解，触发 Envoy 加载 gRPC 对应的 L7 协议解析过滤器：

  metadata:
    annotations:
      consul.hashicorp.com/service-protocol: "grpc"
  

• 调整 hashPolicies 的提取逻辑，适配 gRPC 场景的粘性标识。若通过 gRPC 元数据（即 HTTP2 请求头）传递粘性标识，将 field 修改为 header，fieldValue 填写实际传递的 gRPC 元数据 key，示例配置：

  apiVersion: consul.hashicorp.com/v1alpha1
  kind: ServiceResolver
  metadata:
    name: grpc-test
  spec:
    loadBalancer:
      policy: maglev
      hashPolicies:
        - field: "header"
          fieldValue: "x-sticky-user-id"
  

• 配置调整完成后，等待 Consul 自动将规则同步到对应 Envoy 实例，一般 10 秒内即可生效，无需手动重启 Pod。

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