GKE环境下Google Cloud Endpoints与Istio协同部署可行性问询

Great question! Let’s walk through how these two tools interact, and whether combining them is a smart move for your microservices setup:

1. Quick Recap: Endpoints Without Istio #

First, a baseline: without Istio, you’d deploy the gcr.io/endpoints-release/endpoints-runtime:1 sidecar alongside each microservice. This sidecar takes care of all API management heavy lifting—think API key validation, rate limiting, authentication checks, and metrics collection—before passing traffic to your actual service.

2. Two Ways to Integrate Envoy with Endpoints #

When you add Istio’s Envoy proxy into the mix, you have two official, supported approaches:

Option 1: Dual Sidecars (Envoy + Endpoints Runtime) #

In this setup:

• Istio’s Envoy runs as your primary service mesh sidecar, handling traffic routing, load balancing, mTLS encryption, and cluster-wide observability.
• The Endpoints runtime sidecar runs alongside Envoy and your microservice.
• You configure Istio to route incoming API traffic to the Endpoints sidecar first. The Endpoints proxy processes all API management rules, then forwards validated traffic to your microservice (either directly or back through Envoy, depending on your setup).

This approach lets you keep using the familiar Endpoints sidecar while leveraging Istio’s service mesh capabilities. The key thing to note: Envoy doesn’t "proxy the Endpoints container" in a wrapping sense—it simply routes traffic to it so Endpoints can do its API-specific work.

Option 2: Endpoints Istio Adapter (Single Sidecar) #

Google provides an official Istio adapter that integrates Endpoints’ API management features directly into Istio’s Envoy proxy. This eliminates the need for the separate endpoints-runtime sidecar entirely.

With this adapter:

• Envoy handles both service mesh tasks (traffic management, mTLS) and Endpoints features (API key checks, quota enforcement, metrics synced to Cloud Monitoring).
• You define your Endpoints OpenAPI spec as usual, and the adapter syncs those rules to Envoy automatically.

This is generally the more efficient choice—fewer sidecars mean less resource overhead and simpler pod management.

3. Is This a Bad Strategy? #

Not at all! Google explicitly supports both integration patterns, and combining Endpoints with Istio gives you the best of both worlds:

• Istio manages cross-cluster service traffic, security, and observability for your internal microservices.
• Endpoints adds robust, Google-managed API governance for external (or internal) APIs, with easy integration into Cloud Identity, Cloud Monitoring, and other GCP tools.

That said, the dual-sidecar approach (Option 1) does have tradeoffs:

• Resource usage: Two sidecars per pod consume more CPU and memory than a single Envoy proxy.
• Configuration complexity: You’ll need to set up Istio VirtualServices/DestinationRules to route traffic through the Endpoints sidecar, adding an extra layer of config to maintain.

For most teams, the Endpoints Istio Adapter (Option 2) is the better bet—it’s simpler, more efficient, and combines both tools’ strengths into a single proxy layer.

内容的提问来源于stack exchange，提问作者Govinda Attal