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

Question

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

假设，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)

我在应用程序中应用了一个 hacky 技巧，添加了自定义 http 请求 headers "CALLER_POD" 从 UI v2 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。

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

Client Pod identity in http request header while internal service call

kubernetes

google-kubernetes-engine

kubernetes-helm

istio

amazon-eks