EKS上gRPC服务网格上下文传播触发PROTOCOL_ERROR问题求助

环境配置 #

• Kubernetes 1.27（EKS集群）
• Istio 1.18
• Knative 1.11（通过Knative Serving部署Golang gRPC微服务，所有Pod包含Knative queue-proxy容器）
• 流量路由路径：Route53 → AWS ALB → istio-ingressgateway → Knative服务
• 自定义上下文传播实现：
  服务间调用时的上下文传递代码：

  outgoingCtx, err := common.PropagateContext(ctx)
  if err != nil {
      return nil, err
  }
  
  result, err := client.PerformAction(outgoingCtx)
  if err != nil {
      return nil, err
  }
  

  上下文传播核心逻辑：

  func PropagateContext(ctx context.Context, newFields ...*Field) (context.Context, error) {
      md, ok := metadata.FromIncomingContext(ctx)
      if !ok {
          return nil, fmt.Errorf("unable to propagate context")
      }
      for _, field := range newFields {
          md.Set(field.Key, field.Value)
      }
      return metadata.NewOutgoingContext(ctx, md), nil
  }
  

问题现象 #

3天前服务突发故障，无代码变更，排查后定位到微服务间上下文传递环节：

• 自定义元数据（如authorization令牌）传递无异常
• Istio和ALB插入的系统元数据会触发错误：stream terminated by RST_STREAM with error code: PROTOCOL_ERROR
• 问题非必现，重建连接后请求可能成功
• 涉及的异常元数据列表：

  k-proxy-request [activator]
  x-envoy-attempt-count [1]
  x-envoy-external-address [IP3]
  X-envoy-peer-metadata-id [router~IP4~istio-ingressgateway-REMOVED.istio-system~istio-system.svc.cluster.local] x-b3-sampled [0] 
  x-envoy-decorator-operation [SERVICE-REVISION.default.svc.cluster.local:81/*] 
  x-b3-spanid [SPAN-ID] 
  x-forwarded-for [IP1, IP2, IP3, IP4, IP5] 
  x-request-id [REQUEST-ID] 
  :authority [SERVICE.domain.com] 
  x-forwarded-port [443] 
  content-type [application/grpc] 
  x-forwarded-proto [http] 
  x-amzn-trace-id [Root=1-TRACE-ID] 
  content-length [15]
  x-b3-parentspanid [PARENT-SPAN-ID] 
  authorization [AUTH-TOKEN] 
  forwarded [for=IP1;proto=http, for=IP@, for=IP3, for=IP4]
  x-envoy-peer-metadata [REMOVED] 
  x-b3-traceid [TRACE-ID] 
  user-agent [grpc-go/1.56.2]
  authorization [<JWT>] 
  

临时解决方案 #

移除除authorization外的所有元数据后，问题暂时缓解。

根因分析 #

1. 元数据格式错误
   观察到forwarded字段中存在for=IP@的非法格式（IP地址不合法），Envoy在解析这类不符合规范的元数据时，会触发协议错误并发送RST_STREAM终止连接。由于请求路径中IP的生成存在偶发异常，导致问题非必现。

2. 重复元数据字段冲突
   元数据中出现了两次authorization字段，虽然gRPC规范允许重复键，但Istio Envoy对重复字段的处理在高负载场景下存在兼容性问题，可能引发协议层面的异常。

3. 元数据大小超限
   Istio和ALB插入的系统元数据较多，加上自定义字段后，总大小可能超出Envoy或gRPC对元数据的默认大小限制。当元数据累积到阈值时触发错误，负载波动导致问题非必现。

4. 版本兼容性问题
   当前使用的grpc-go 1.56.2与Istio 1.18对应的Envoy版本在元数据解析逻辑上存在差异，尤其是对:authority、x-envoy-peer-metadata这类特殊字段的处理，偶发触发协议错误。

验证与修复建议 #

• 优先修复forwarded字段的格式错误：检查ALB或Istio的配置，确认IP地址生成逻辑，避免非法格式的元数据进入服务网格。
• 清理重复的authorization字段：在上下文传播时对重复键去重，确保每个元数据键唯一。
• 调整元数据传递策略：通过Istio的metadata_exchange过滤器配置，只保留必要的追踪字段（如b3、x-request-id），减少元数据总大小。
• 升级grpc-go版本：将grpc-go升级到1.60+的稳定版，验证与Istio Envoy的兼容性是否改善。

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