两者似乎都做同样的事情。根据我的收集，Istio在Inngress级别进行路由，在ESP级别进行容器级。我仍在了解Istio。
答案 0 :(得分：0)
根据Google云documentation：
可扩展服务代理
可扩展服务代理（ESP）是基于Nginx的高性能，可扩展代理，可在OpenAPI或gRPC API后端之前运行，并提供API管理功能，例如身份验证，监视和日志记录。有关更多信息，请参见About Endpoints和Endpoints: Architectural overview。
可扩展服务代理V2 Beta
可扩展服务代理V2 Beta（ESPv2 Beta）是基于Envoy的高性能，可扩展代理，它在OpenAPI API后端之前运行，并提供API管理功能，例如身份验证，监视和日志记录。有关更多信息，请参见About Endpoints和Endpoints: Architectural overview。
ESPv2 Beta支持OpenAPI Specification的版本2。 ESPv2 Beta当前不支持gRPC。
ESPv2 Beta仅支持用于Cloud Functions和Cloud Run的Beta版端点。 App Engine，GKE，Compute Engine或Kubernetes的端点不支持ESPv2 Beta。
根据istio github documentation：
简介
Istio是一个开放平台，用于提供统一的方式来集成微服务，管理跨微服务的流量，执行策略和汇总遥测数据。 Istio的控制平面在基础集群管理平台（例如Kubernetes）上提供了一个抽象层。
Istio由以下组件组成：
Envoy -每个微服务的Sidecar代理，以处理集群中服务之间以及从服务到外部服务的入口/出口流量。代理形成一个安全的微服务网格，提供了丰富的功能集，如发现，丰富的7层路由，断路器，策略执行和遥测记录/报告功能。
注意：服务网格不是覆盖网络。它简化并增强了应用程序中的微服务如何通过底层平台提供的网络相互通信。
混合器-代理和微服务利用中央组件来执行诸如授权，速率限制，配额，身份验证，请求跟踪和遥测收集之类的策略。
< / li>飞行员-一个负责在运行时配置代理的组件。
城堡-负责证书颁发和轮换的集中组件。
城堡代理-每个节点的组件，负责证书的颁发和轮换。
Galley -用于验证，提取，汇总，转换和分发Istio中的配置的中央组件。
操作员-该组件提供了用户友好的选项来操作Istio服务网格。
Istio当前支持Kubernetes和基于Consul的环境。我们计划在不久的将来支持其他平台，例如Cloud Foundry和Mesos。
与Istio一样，ESP v2 Beta也基于Envoy代理。但是，Istio具有ESP v2尚不具备的一些高级功能，因为它仍处于beta中。对于ESP v1，它更像是nginx入口。所有这些工具都能够执行路由任务，但是每种工具在后台都有不同的机制，并提供不同数量的配置灵活性和复杂性。
希望有帮助。