在GCP Kubernetes环境下：Google Cloud Load Balancer是否为Envoy托管版？

Great question—this is a super common point of confusion when picking a layer 7 load balancer for GCP Kubernetes, so let’s unpack this step by step.

Is Google Cloud Load Balancer (GCLB) a managed version of Envoy? #

Short answer: No. While Google engineers are major contributors to the Envoy project, GCLB is built on Google’s own proprietary, global-scale load balancing infrastructure. It doesn’t run Envoy under the hood—this is a critical distinction.

Is GCLB just Envoy plus GCP CDN integration? #

Absolutely not. CDN integration is just one of many GCP-native features baked into GCLB. It also tightly integrates with:

• Cloud Armor (for WAF and DDoS protection)
• Identity-Aware Proxy (IAP) for secure access control
• Cloud Monitoring/Logging for out-of-the-box observability
• GCP VPC networks and Cloud DNS for seamless network integration
• Backend services that support GCE VMs, Kubernetes pods, and serverless functions

Core Differences Beyond Managed vs. Self-Deployed #

Even if you were to compare a managed Envoy solution (like Istio on GKE) to GCLB, there are fundamental differences in their design and use cases:

• Architecture & Scope:

  • GCLB is a global edge load balancer—it routes traffic from end-users across Google’s global network directly to your backends, reducing latency and handling massive scale out of the box.
  • Envoy is a service proxy designed for cluster-internal traffic (as a sidecar in service meshes) or as a cluster ingress controller. It’s focused on fine-grained traffic control within your Kubernetes environment, not global edge routing.

• Configuration Model:

  • GCLB uses GCP’s native resource model (e.g., BackendService, UrlMap, TargetHttpProxy) configured via the GCP Console, gcloud CLI, or infrastructure-as-code tools like Terraform. It’s optimized for GCP ecosystem integration, not low-level proxy customization.
  • Envoy uses its own YAML configuration or the xDS protocol for dynamic updates. It offers extreme flexibility for customizing routing rules, retries, timeouts, circuit breaking, and more—but requires more hands-on expertise to manage.

• Performance & Scale:

  • GCLB is built to handle petabytes of traffic daily, with built-in DDoS mitigation and global traffic steering. Google manages the underlying infrastructure’s scaling and reliability.
  • Envoy’s performance and scale depend entirely on your Kubernetes cluster’s resources. You’re responsible for scaling proxy instances, handling failovers, and ensuring high availability.

• Feature Focus:

  • GCLB prioritizes edge-level features: global traffic management, SSL termination at the edge, CDN caching, and integration with GCP’s security services.
  • Envoy excels at service mesh use cases: mTLS between services, traffic splitting for canary releases, rate limiting per service, and detailed observability into inter-service communication.

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