我遇到一种情况，我不确定我是否做错了什么，或者 Istio 根本不支持该用例。这是我的设置：
我有一个连接到Gateway的VirtualService，以使一些 API 在外部可用，例如作为api1.example.com。VirtualService连接到执行某些请求预处理(某些条件 URL 重写(的某些Service。现在是棘手的部分：服务应该将请求转发到某个 API 管理解决方案，该解决方案在同一集群上运行，在不同的命名空间中，并且没有启用 Istio。这通常有效，但我有一些额外的要求困扰我。API 管理需要知道请求最初发送到哪个终结点(以应用正确的规则(，因此当我将请求从我的服务转发到 API 管理 Pod 时，HTTPHost标头仍应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
为了能够在 istio 注入的服务和外部服务(到 istio service-mesh(之间进行通信，您需要使用 ServiceEntry 对象。
根据 istio 文档：
ServiceEntry允许在 Istio 的内部服务注册表中添加其他条目，以便网格中自动发现的服务可以访问/路由到这些手动指定的服务。服务条目描述服务的属性(DNS 名称、VIP、端口、协议、终结点(。这些服务可以是网格外部的(例如，Web API(，也可以是不属于平台服务注册表的网格内部服务(例如，一组与 Kubernetes 中的服务通信的虚拟机(。此外，还可以使用workloadSelector字段动态选择服务条目的端点。这些端点可以是使用WorkloadEntry对象或 Kubernetes Pod 声明的虚拟机工作负载。在单个服务下同时选择 Pod 和 VM 的功能允许将服务从 VM 迁移到 Kubernetes，而无需更改与服务关联的现有 DNS 名称。
就像你提到的：
在启用了 Istio 的命名空间 1 中运行的pod1
在命名空间 2 中运行且禁用 Istio 并公开为service2的pod2
在这种情况下，service2需要一个ServiceEntry对象，该对象将添加到 Istio 服务网格注册表中。这将允许service2像在 Istio 中一样使用。请注意，需要 envoy 代理的 istio 功能不适用于此服务，因为它实际上并没有注入 istio。
我建议遵循此 istio 访问外部服务指南。