内部服务调用时 http 请求标头中的客户端 Pod 标识

Question

我已经在 Kubernetes 上部署了一个应用程序并使用 Istio 服务网格公开。应用程序中有 2 个组件，UI 和 API。我正在尝试设置基于 Canary 的设置以启用 AB 测试。因此，对于这 2 个组件，部署了 2 个版本（v1 和 v2），因此（最少）4 个 pod 正在运行。

假设 v1 是稳定的，v2 是发布版本。v1 版将服务于真实的互联网流量，v2 版将服务于来自特定 ip 地址的请求，以确保 v2 版的升级不会影响实际生产环境。有关应用程序中交通流量的清晰度，请参阅附图。

通过使用 virtualService 过滤用户的真实客户端 IP 地址，UI V2（发布版本）的测试非常容易-

    - headers:
        x-forwarded-for:
          regex: .*1.2.3.4.*

API v2（发布版本）的测试很复杂，因为它没有暴露在互联网上，并且只能在内部提供来自 UI v2（发布版本）的流量，但我无法做到。

    url = "http://service-api"
    hdr = { 'CALLER_POD' : 'ui_v2_pod_hostname_with_release' }
    req = urllib.request.Request(url, headers=hdr)
    response = urllib.request.urlopen(req)

我在应用程序中应用的一个技巧，在从 UI v2 pod 调用 API 时添加了自定义 http 请求标头"CALLER_POD"，以便 API virtualService 可以根据"CALLER_POD"过滤掉请求。但它看起来更复杂，因为它需要在更广泛的层面上进行代码重构，并且如果发生任何变化，将来更易于人为管理。

在 Kubernetes 或 Istio 级别内部调用 API 服务时，有什么方法可以在 http 请求标头中添加 UI v2 pod 标识（首选主机名）。

Answer 1

您是否尝试过使用sourceLabels基于路由？例如：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: socks-com
spec:
  hosts:
  - sock.com
  http:
  - match:
    - sourceLabels:
        UI: v2
    - route:
      - destination:
          host: API
          label: v2
  - route:
    - destination:
        host: API
        subset: v1

它还需要DestinationRule更新两个subsets.