我对我们环境中的一些用例感到困惑。首先，我们将拥有自己的 API 网关来处理南北流量，我们的 API 网关将监听来自外部世界的请求。所以我们计划使用 Istio 来管理服务之间的东西流量。现在我的主要困惑是，如果我们排除 Istio 的入口网关，它是否能够管理金丝雀发布、断路、分析标头时的跟踪以及其他很酷的功能？
谢谢
答案1
据我所知，这应该不会有任何问题。
下面举几个例子。
看一下 ambassador api 网关文档和一个邮政在 itnext.io 上了解如何将其与 istio 连接。
Ambassador 是适用于微服务的 Kubernetes 原生 API 网关。Ambassador 部署在您的网络边缘，并将传入流量路由到您的内部服务（又称“南北”流量）。Istio 是微服务的服务网格，旨在为服务到服务流量（又称“东西”流量）添加 L7 可观察性、路由和弹性。Istio 和 Ambassador 都是使用 Envoy 构建的。
Ambassador 和 Istio 可以一起部署在 Kubernetes 上。在此配置中，来自集群外部的传入流量首先通过 Ambassador 路由，然后由 Ambassador 路由到 Istio。Ambassador 负责处理身份验证、边缘路由、TLS 终止和其他传统边缘功能。
这使得运营商可以同时拥有两全其美的优势：高性能、现代边缘服务 (Ambassador) 与最先进的服务网格 (Istio) 相结合。Istio 的基本入口控制器，入口控制器非常有限，并且不支持身份验证或 Ambassador 的许多其他功能。
看一眼文档关于使用 Gloo API 网关扩展 Istio 1.5
Gloo 是一个基于 Envoy Proxy 构建的开源 API 网关，它高度补充了 Istio 等服务网格，具有请求/响应转换、直接响应操作以及 Open API Spec/Swagger 和 gRPC 发现等边缘功能。Gloo Enterprise 支持更复杂的安全边缘要求，如 OIDC 身份验证、OPA 授权、Web 应用程序防火墙 (WAF)、速率限制等。许多 Gloo 用户将 Gloo 放在边缘，与 Istio 集成，实现东西向流量管理。