kubernetes - 内部服务调用时，http请求 header 中的客户端Pod身份

Question

我已经在Kubernetes上部署了一个应用程序，并暴露于Istio服务网格。应用程序中有2个组件，UI和API。我正在尝试设置基于canary的设置以启用AB测试。因此，对于这两个组件，已经部署了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(发行版)的测试很复杂，因为它不暴露于Internet，并且只能在内部从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请求 header “CALLER_POD” ，以便API virtualService可以基于“CALLER_POD” 过滤请求。但是它看起来更加复杂，因为它需要更广泛的代码重构，并且如果将来有任何更改的话，将来需要更多的人为管理。
在Kubernetes或Istio级别上内部调用API服务时，是否有任何方法可以在http请求 header 中添加UI v2 pod身份(首选主机名)。

Answer 1

您是否尝试过使用基于sourceLabels的routing？例如:

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。