我正在使用 istio 1.9.0。
只有在出现问题时，我才发现服务条目是在集群级别应用的，即使在清单中指定了命名空间也是如此。如果您在不同的命名空间中有多个服务条目用于相同的主机名，这将变得特别棘手。
我后来找到了提到以下内容的文档：
exportTo:
此服务导出到的命名空间列表。导出一个 服务允许它被边车、网关和虚拟机使用 其他命名空间中定义的服务。此功能提供了一个 服务所有者和网格管理员控制 跨命名空间边界的服务可见性。
如果没有指定命名空间，则服务将导出到所有 默认命名空间。
值“。”保留并定义到相同命名空间的导出 声明服务。类似地，保留值“*” 并定义对所有命名空间的导出。
来自here。
第一季度。 但是，文档没有明确说明添加 exportTo='.' 是否确保我的命名空间中的服务条目始终具有优先权。这是暗示吗？特别有兴趣找到一些说明预期行为的文档。
第二季度。 另外，如果存在多个，您如何检查已为同一主机名应用了哪个服务条目？ Istio 是如何处理这个问题的？
【问题讨论】：
标签： istio
问题与ServiceEntry概念设计有关，比较复杂。
我对当前情况的理解是，应该在某个命名空间中明确定义 ServiceEntry，以防止 Istio 在另一个命名空间中搜索其他 ServiceEntry 以获得相同的主机端点。
您可以在 issue #13008 中找到有关该问题的更多信息：
在 PR #13631 中进行了更改：
有关详细信息，请参阅design doc。我建议阅读整个文档以查看完整图片。
改变的要点是实现以下几点：
建议的行为
- Pilot 将通过主机名和命名空间对在内部修改为关键服务，而不仅仅是主机名。在确定将哪些服务用于主机名时，我们将遵循以下解决方案：
- 如果主机名存在于客户端的命名空间中，请仅使用该命名空间的服务。
- 如果主机名仅存在于 Sidecar 导入的一个命名空间中，请使用该命名空间的服务。 否则，如果有多个带有服务的命名空间，则可以选择任意一个（基于创建时间戳，就像其他配置一样）。
这样做的最终结果是，虽然主机名在全局级别上是不同的，但任何给定的代理都将有一个唯一的主机名 -> 服务映射。
此外，如果在不同的命名空间中创建内部服务的 ServiceEntry，它将被拒绝。例如，如果 foo.ns1.svc.cluster.local 在命名空间 ns2 中定义，它将被拒绝。这可以防止用户导入 [ns1/, ns2/] 并劫持他们对 foo.ns1.svc.cluster.local 的请求。
很遗憾，我无法找到最新 Istio 版本实施更改的最终状态。
如果没有您提供的最小可重复示例，我无法检查您是否面临实施缺陷，或者您的配置是否是更改无法解决的极端情况。
很遗憾，当前的 Istio 文档对这方面的解释不够好。
【讨论】：