第三方負載平衡器

 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) 負載平衡器

與 Google HTTP(S) 負載平衡器的整合，只有在不需要 mTLS 時，才能在獨立模式下開箱即用，因為不支援 mTLS。

鏈式模式是可行的。有關設定說明，請參閱Google 文件。

叢集內負載平衡器

一般來說，叢集內負載平衡器在獨立模式下，無需 mTLS 即可開箱即用。

具有 mTLS 的獨立模式可以透過將 Sidecar 插入叢集內負載平衡器的 Pod 中來實現。這通常涉及標準 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 預設使用服務路由，因此不需要額外的步驟。

這項資訊是否有用？
您是否有任何改進建議？

感謝您的回饋！