Istio 和 HTTP 主机头答案

【问题标题】：Istio and the HTTP Host headerIstio 和 HTTP 主机头
【发布时间】：2020-08-12 19:38:52
【问题描述】：

我有一种情况，我不确定自己是否做错了，或者 Istio 是否完全不支持该用例。这是我的设置：

我有一个 VirtualService 连接到一个 Gateway 以使某些 API 在外部可用，例如作为api1.example.com。 VirtualService 连接到一些 Service，它执行一些请求预处理（一些条件 URL 重写）。现在到了棘手的部分：服务应该将请求转发到一些 API 管理解决方案，该解决方案在同一集群上运行，在不同的命名空间中，并且没有启用 Istio。这通常有效，但我有一些额外的要求让我感到困扰。 API 管理需要知道请求最初发送到哪个端点（以应用正确的规则），因此当我将请求从我的服务转发到 API 管理 pod 时，HTTP Host 标头仍应为 api1.example.com .这是它中断的地方，我只收到502 Bad Gateway 错误。

现在这是完整的设置，但我认为您可以将其归结为以下设置（不幸的是，我目前无法访问可以创建和测试一些最小工作示例的集群）：

pod1 在启用 Istio 的 namespace1 中运行
pod2 在禁用 Istio 的情况下在 namespace2 中运行，并暴露为 service2

现在来自pod1 以下作品：

wget -qO- http://service2.namespace2.svc.cluster.local

但以下不是：

wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local

非常感谢任何帮助或提示！

对提出的问题进行了一些更新：

Istio 版本为 1.4.6
当我做wget -qO- http://service2.namespace2.svc.cluster.local 比pod2 收到请求时，当我读取Host 标头时，它是service2.namespace2.svc.cluster.local
当我执行wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local 时，请求根本不会到达pod2
istioctl proxy-config listeners pod1 显示如下（pod1 中的服务运行在 1024 端口，pod2 中的服务运行在 80 端口）

ADDRESS            PORT      TYPE
100.96.4.131       1024      HTTP
100.96.4.131       15020     TCP
100.69.164.43      443       TCP
10.250.0.42        10250     TCP
10.250.0.47        10250     TCP
100.64.124.217     443       TCP
100.67.245.255     15011     TCP
10.250.0.46        10250     TCP
10.250.0.48        10250     TCP
10.250.0.9         10250     TCP
10.250.0.24        10250     TCP
10.250.0.50        10250     TCP
100.64.124.217     15032     TCP
100.64.0.1         443       TCP
10.250.0.108       10250     TCP
100.64.0.10        53        TCP
10.250.0.34        10250     TCP
10.250.0.8         10250     TCP
10.250.0.37        10250     TCP
100.64.124.217     15029     TCP
10.250.0.30        10250     TCP
10.250.0.36        10250     TCP
10.250.0.105       10250     TCP
100.64.124.217     15031     TCP
100.64.124.217     15030     TCP
10.250.0.92        10250     TCP
100.66.112.190     443       TCP
100.68.34.255      44134     TCP
100.64.124.217     15443     TCP
10.250.0.91        10250     TCP
10.250.0.97        10250     TCP
0.0.0.0            443       TCP
10.250.0.10        10250     TCP
10.250.0.45        10250     TCP
0.0.0.0            9943      TCP
100.64.132.219     9115      TCP
0.0.0.0            10249     TCP
100.70.99.95       443       TCP
100.65.54.197      26379     TCP
100.64.0.10        9153      TCP
0.0.0.0            9090      TCP
0.0.0.0            15014     TCP
100.71.44.89       6789      TCP
100.70.253.4       2020      TCP
0.0.0.0            9094      TCP
100.67.56.56       443       TCP
100.65.133.0       4314      TCP
0.0.0.0            4005      TCP
100.70.229.77      9411      TCP
0.0.0.0            9901      TCP
100.71.167.108     443       TCP
100.69.145.185     9093      TCP
100.70.32.142      443       TCP
100.66.233.175     42422     TCP
0.0.0.0            8080      TCP
100.69.114.203     6789      TCP
100.70.144.106     3300      TCP
0.0.0.0            20001     TCP
0.0.0.0            4004      TCP
0.0.0.0            9093      TCP
100.67.179.223     9000      TCP
100.70.18.125      3300      TCP
100.64.255.234     9090      TCP
100.66.197.157     9710      TCP
100.67.193.139     3300      TCP
100.69.114.203     3300      TCP
0.0.0.0            16909     TCP
0.0.0.0            3000      TCP
0.0.0.0            15004     TCP
100.68.54.218      9115      TCP
0.0.0.0            8060      TCP
0.0.0.0            8008      TCP
100.70.162.45      9115      TCP
0.0.0.0            15010     TCP
0.0.0.0            10054     TCP
100.65.13.208      5473      TCP
100.67.193.139     6789      TCP
100.71.44.89       3300      TCP
100.70.18.125      6789      TCP
100.67.56.56       8081      TCP
0.0.0.0            9411      TCP
0.0.0.0            2379      TCP
100.66.228.227     8081      TCP
0.0.0.0            9091      TCP
0.0.0.0            5556      TCP
100.64.124.217     15020     TCP
100.68.245.60      7000      TCP
0.0.0.0            9283      TCP
0.0.0.0            80        TCP
0.0.0.0            3100      TCP
100.66.228.227     8080      TCP
100.70.144.106     6789      TCP
0.0.0.0            1024      TCP
100.70.229.77      14268     TCP
0.0.0.0            15019     TCP
0.0.0.0            5558      TCP
100.70.229.77      14267     TCP
100.67.17.80       9100      TCP
0.0.0.0            15001     TCP
0.0.0.0            15006     TCP
100.96.1.142       443       TCP
0.0.0.0            15090     HTTP

【问题讨论】：

执行以下命令并提供输出：istioctl proxy-config listeners [.namespace]
bot 案例中 pod2 的日志是什么？如果 pod 需要标头，第一种情况如何工作？在第二个请求中，请求将到达带有此标头的 pod2，您能检查一下它到达那里的标头吗
您使用的是哪个 istio 版本？

标签： http-headers istio

【解决方案1】：

为了能够在 istio 注入服务和外部服务（到 istio 服务网格）之间进行通信，您需要使用 ServiceEntry 对象。

根据 istio documentation:

ServiceEntry 允许在 Istio 的内部服务注册表中添加额外的条目，以便网格中自动发现的服务可以访问/路由到这些手动指定的服务。服务条目描述了服务的属性（DNS 名称、VIP、端口、协议、端点）。这些服务可能在网格外部（例如，Web API）或网格内部服务，它们不属于平台的服务注册表（例如，一组与 Kubernetes 中的服务通信的 VM）。此外，还可以使用workloadSelector 字段动态选择服务条目的端点。这些端点可以是使用 WorkloadEntry 对象或 Kubernetes pod 声明的 VM 工作负载。在单个服务下同时选择 pod 和 VM 的能力允许将服务从 VM 迁移到 Kubernetes，而无需更改与服务关联的现有 DNS 名称。

就像你提到的：

pod1 在启用 Istio 的 namespace1 中运行

pod2 在 namespace2 中运行并禁用 Istio，并公开为 service2

在这种情况下，service2 将需要一个 ServiceEntry 对象，该对象会将其添加到 Istio 服务网格注册表中。这将允许 service2 像在 Istio 中一样使用。请注意，需要 envoy 代理的 istio 功能不适用于此服务，因为它实际上不是 istio 注入的。

我建议遵循这个 istio Accessing External Services 指南。

【讨论】：

有点晚了，但我想确认ServiceEntry 解决了这个问题。我添加了一个将host 设置为“*.example.com”的条目，然后请求有效：“wget -qO- --header 'Host: api1.example.com' service2.namespace2.svc.cluster.local”