【问题标题】:x-b3-sampled header is always set to 0 when accessing service through ingress controller通过入口控制器访问服务时,x-b3-sampled 标头始终设置为 0
【发布时间】:2020-12-09 22:45:28
【问题描述】:

我安装了带有演示配置文件的 Kubernetes 1.17.5 和 Istio 1.6.8。

这是我的测试设置 [nginx-ingress-controller] -> [proxyServiceA] -> [proxyServiceB]

  • serviceA 和 serviceB 的代理由 Istio 自动注入 (istio-injection=enabled)
  • Nginx 入口控制器没有启用跟踪,也没有作为 sidecar 的 envoy 代理
  • ServiceA 将跟踪标头向下传递给 ServiceB
  • 我正在尝试跟踪从 ServiceA 到 ServiceB 的调用,目前不关心 Ingress->ServiceA 跨度

当我向入口控制器发送请求时,我可以看到 ServiceA 从代理接收所有必需的跟踪标头

x-b3-traceid: d9bab9b4cdc8d0a7772e27bb7d15332f
x-request-id: 60e82827a270070cfbda38c6f30f478a
x-envoy-internal: true
x-b3-spanid: 772e27bb7d15332f
x-b3-sampled: 0
x-forwarded-proto: http

问题是 x-b3-sampled 始终设置为 0,并且没有跨度/跟踪被推送到 Jaeger

我尝试过的几件事

  1. 我已将 Gateway 和 VirtualService 添加到 ServiceA 以通过 Istio ingressgateway 公开它。当我通过 ingressgateway 发送流量时,一切都按预期工作。我可以在 JaegerUI 中看到跟踪 [ingress-gateway]->[ServiceA]->[ServiceB]
  2. 我还尝试使用自定义配置安装 Istio 并尝试跟踪相关参数,但没有成功。

这是我尝试使用的配置

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  addonComponents:
    tracing:
      enabled: true
    grafana:
      enabled: false
    istiocoredns:
      enabled: false
    kiali:
      enabled: false
    prometheus:
      enabled: false
  values:
    tracing:
      enabled: true
    pilot:
      traceSampling: 100

【问题讨论】:

  • 是的,通过 ingressgateway 发送请求按预期工作。但是我们通过入口控制器为大量流量提供服务,它对我们有用。用 istio ingressgateway 替换它来解决跟踪问题目前的变化太大了。
  • 当我用任何其他服务替换入口控制器并从集群内部初始化对 serviceA 的请求时,它工作正常。所以我认为这与请求是从集群外部转发的事实有关。我正在尝试重新配置入口控制器,以从对上游服务的请求中删除所有 X-Forwarded-* 标头,以诱使特使“认为”该请求是本地的。看看能不能解决问题。

标签: kubernetes trace istio


【解决方案1】:

经过几天的挖掘,我已经弄清楚了。问题在于 nginx 入口控制器使用的 x-request-id 标头的格式。

Envoy 代理期望它是一个 UUID(例如 x-request-id: 3e21578f-cd04-9246-aa50-67188d790051),但 ingrex 控制器将它作为非格式化的随机字符串(x-request-id: 60e82827a270070cfbda38c6f30f478a)传递。当我在请求中将格式正确的 x-request-id 标头传递给入口控制器时,它会被传递给特使代理,并且请求会按预期进行采样。我也尝试删除 使用简单的 EnvoyFilter 从入口控制器到 ServiceA 的请求中的 x-request-id 标头。它也可以按预期工作。 Envoy 代理生成一个新的 x-request-id 并且请求被跟踪。

【讨论】:

  • 我有类似的问题,但在 ingress-nginx 上,我有一个 Envoy sidecar,以便在入口控制器 pod 和其他服务之间使用 mTLS。来自 ingress-nginx 的请求 x-request-id 标头采用以下格式:'4668081de0d9e63cae60680710a23cfd' 但不是由 Envoy 创建的,因为 ingress-nginx 不会自行创建该标头(和其他 b3-标头) ?所以我想知道为什么 Envoy 没有以正确的 UUID 格式格式化请求 ID。
  • 您能分享一下您是如何确保“x-request-id”格式正确的吗?我可以查看任何文档吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2019-04-03
  • 2016-12-09
  • 1970-01-01
  • 2019-03-13
  • 1970-01-01
  • 2012-05-18
  • 2014-08-19
相关资源
最近更新 更多