第三方负载均衡器

 阅读时间 3 分钟  

Istio 提供了入口和服务网格实现，可以一起使用或单独使用。虽然这些设计为无缝协同工作，但在某些情况下需要与第三方入口集成。这可能是出于迁移目的、功能需求或个人喜好。

集成模式

在“独立”模式下，第三方入口直接发送到后端。在这种情况下，后端可能已注入 Istio sidecar。

graph LR cc((客户端)) tpi(第三方入口) a(后端) cc-->tpi-->a

在这种模式下，事情大多都能正常工作。服务网格中的客户端无需知道他们连接到的后端是否有 sidecar。但是，入口将不使用 mTLS，这可能导致不良行为。因此，此设置的大部分配置都围绕启用 mTLS。

在“链式”模式下，我们按顺序使用第三方入口和 Istio 自身的网关。当您需要两层的功能时，这很有用。特别是，这对于托管云负载均衡器很有用，这些负载均衡器具有全局地址和托管证书等功能。

graph LR cc((客户端)) tpi(第三方入口) ii(Istio 网关) a(后端) cc-->tpi tpi-->ii ii-->a

云负载均衡器

通常，云负载均衡器在独立模式下无需 mTLS 即可开箱即用。需要特定于供应商的配置才能支持链式模式或具有 mTLS 的独立模式。

Google HTTP(S) 负载均衡器

如果不需要 mTLS，则与 Google HTTP(S) 负载均衡器的集成仅在独立模式下开箱即用，因为不支持 mTLS。

链式模式是可能的。有关设置说明，请参阅Google 文档。

集群内负载均衡器

通常，在独立模式下，集群内负载均衡器无需 mTLS 即可开箱即用。

可以通过将 sidecar 插入集群内负载均衡器的 Pod 中来实现带有 mTLS 的独立模式。这通常需要比标准 sidecar 注射多两个步骤。

  1. 禁用入站流量重定向。虽然不是必需的，但通常我们只想将 sidecar 用于出站流量 - 来自客户端的入站连接已由负载均衡器本身处理。这还可以保留原始客户端 IP 地址，否则这些地址将被 sidecar 丢失。可以通过在负载均衡器Pod上插入traffic.sidecar.istio.io/includeInboundPorts: ""注释来启用此模式。

  2. 启用服务路由。Istio sidecar 只有在请求发送到服务而不是特定 Pod IP 时才能正常工作。大多数负载均衡器默认会发送到特定的 Pod IP，从而破坏 mTLS。执行此操作的步骤是特定于供应商的；下面列出了一些示例，但建议查阅特定供应商的文档。

    或者，将Host头设置为服务名称也可以。但是，这可能会导致意外行为；负载均衡器将选择一个特定的 Pod，但 Istio 将忽略它。有关此工作原理的更多信息，请参阅此处。

ingress-nginx

可以通过在Ingress资源上插入注释来配置ingress-nginx执行服务路由。

nginx.ingress.kubernetes.io/service-upstream: "true"

Emissary-Ingress

Emissary-ingress 默认使用服务路由，因此无需执行其他步骤。

这些信息是否有用？
您是否有任何改进建议？

感谢您的反馈！