用於 kubernetes 集群中東西向流量管理的 istio 服務網格
我對我們環境中的一些案例感到困惑。第一個是我們將擁有自己的 api 網關，用於北/南流量，我們的 api 網關將監聽來自外部世界的請求。因此，我們計劃在服務之間使用 istio 進行東/西流量管理。現在我的主要困惑是，如果我們排除它的入口網關，istio 是否能夠在分析標頭時管理金絲雀版本、斷路、跟踪以及其他很酷的功能？
謝謝你
據我所知，這不應該有任何問題。
下面舉幾個例子。
查看ambassador api gateway文件和itnext.io上關於將其與 istio 連接的文章。
Ambassador 是用於微服務的 Kubernetes 原生 API 網關。Ambassador 部署在您的網路邊緣，並將傳入流量路由到您的內部服務（也稱為“南北”流量）。Istio 是用於微服務的服務網格，旨在為服務到服務的流量（也稱為“東西向”流量）添加 L7 可觀察性、路由和彈性。Istio 和 Ambassador 都是使用 Envoy 建構的。
Ambassador 和 Istio 可以一起部署在 Kubernetes 上。在此配置中，來自集群外部的傳入流量首先通過 Ambassador，然後將流量路由到 Istio。Ambassador 處理身份驗證、邊緣路由、TLS 終止和其他傳統邊緣功能。
這使運營商可以兩全其美：高性能的現代邊緣服務 (Ambassador) 與最先進的服務網格 (Istio) 相結合。Istio 的基本入口控制器，入口控制器非常有限，並且不支持身份驗證或大使的許多其他功能。
查看有關使用 Gloo API Gateway 擴展 Istio 1.5 的文件
Gloo 是一個基於 Envoy Proxy 建構的開源 API 網關，它高度補充了像 Istio 這樣的服務網格，具有請求/響應轉換、直接響應操作以及 Open API Spec/Swagger 和 gRPC 發現等邊緣功能。Gloo Enterprise 支持更複雜的安全邊緣要求，如 OIDC 身份驗證、OPA 授權、Web 應用程序防火牆 (WAF)、速率限制等。許多 Gloo 使用者將 Gloo 放在邊緣，並與 Istio 集成以進行東西向流量管理。