The GKE Ingress controller is Google Cloud's built-in controller that converts Kubernetes Ingress resources into Google Cloud Application Load Balancers (ALBs) to route HTTP(S) traffic into cluster workloads. When deploying an external Application Load Balancer, Google Front End (GFE) proxies terminate client Transport Layer Security (TLS) at the edge of Google's global network and route requests to backend Pods. The controller provisions the load balancer and creates firewall rules allowing traffic from Google health check IP ranges (35.191.0.0/16 and 130.211.0.0/22) and GFE proxies to reach the Pods. Reserving a static IP address and adding the kubernetes.io/ingress.global-static-ip-name annotation attaches that static external IP address to the load balancer frontend.
When deploying an internal Application Load Balancer, the Ingress controller provisions a regional, proxy-based load balancer inside a Virtual Private Cloud (VPC) network for private communication. This internal architecture requires a proxy-only subnet in the VPC and mandates the use of Network Endpoint Groups (NEGs) rather than instance groups. Google Cloud provisions Envoy proxies inside this proxy-only subnet to evaluate rules and forward requests directly to the Pods. While the controller automatically creates firewall rules for health checks, operators must manually create a firewall rule allowing traffic from the proxy-only subnet range to the container ports.
StudyCerts
StudyCertsExternal: Client ──► GFE Edge Proxy ──► Backend Pods (via NEG)
Internal: Client ──► VPC Proxy-Only Subnet (Envoy) ──► Container Ports (via NEG)
BackendConfig and FrontendConfig are custom resource definitions (CRDs) that apply Google Cloud load balancing features to Kubernetes workloads without modifying the core Ingress specification. A BackendConfig attaches directly to a Kubernetes Service through the beta.cloud.google.com/backend-config annotation. This configuration defines Google Cloud Armor security policies to prevent denial-of-service (DDoS) and web attacks, sets custom health check parameters, adjusts session affinity and connection timeouts, and activates Identity-Aware Proxy (IAP) or Cloud CDN.
A FrontendConfig custom resource applies policies directly to the load balancer frontend through the networking.gke.io/v1beta1.FrontendConfig annotation on the Ingress resource. Operators use the FrontendConfig resource to attach customized SSL policies and define TLS protocol versions. By decoupling backend and frontend policies from base manifests, teams can manage security and operational controls across different infrastructure lifecycles.
TLS configuration for GKE Ingress establishes encrypted communication across public client connections and backend network paths. External Application Load Balancers manage certificates through Google-managed certificates, pre-shared certificates uploaded to Google Cloud, or self-managed certificates stored in Kubernetes Secrets. A single Ingress manifest can reference up to 15 certificates, using Server Name Indication (SNI) to present the correct certificate matching the client domain name. To encrypt traffic moving from the load balancer proxy to the backend Pods, the Service manifest must set the service.spec.ports[].appProtocol field to HTTPS.
Container-native load balancing is a networking architecture that uses Network Endpoint Groups (NEGs) of type GCE_VM_IP_PORT to route load-balanced traffic directly to individual Pod IP addresses. In traditional node-level load balancing, traffic travels to a Compute Engine virtual machine (VM) node port and traverses iptables rules configured by kube-proxy, introducing two hops and uneven distribution. Container-native routing bypasses the node IP and kube-proxy layer entirely, sending requests from the load balancer directly to target containers.
Traditional: Load Balancer ──► Node VM (NodePort) ──► iptables / kube-proxy ──► Pod IP
NEG-Native: Load Balancer ───────────────────────────────────────────────────► Pod IP
Direct routing to Pods improves network throughput, lowers latency, and provides accurate observability by measuring health and response times at the NEG level rather than aggregating metrics across VM nodes. Google Kubernetes Engine incorporates Pod readiness gates so the load balancer evaluates container health before routing traffic to newly created Pods. A Pod enters the ready state and begins receiving user traffic only after passing its Google Cloud health checks, preventing dropped connections during workload scaling.
Container-native load balancing requires a VPC-native GKE cluster with the HttpLoadBalancing add-on enabled. GKE enables container-native load balancing automatically for Ingress resources on VPC-native clusters that do not use Shared VPC or GKE Network Policy, applying the annotation cloud.google.com/neg: '{"ingress": true}' to target Services. Internal Application Load Balancers strictly require NEGs and do not support instance group backends.
Standalone NEGs are decoupled endpoint groups managed by the GKE NEG controller while an administrator manually manages the forwarding rules, health checks, and backend services. Choose standalone NEGs for advanced use cases such as external proxy Network Load Balancers, Cloud Service Mesh integrations, or hybrid backend pools mixing VM and container IP addresses. When using GKE-managed load balancers, operators must never manually alter the generated Cloud Load Balancing configurations, because the GKE controller reconciliation loop overwrites external changes.
The GKE Gateway controller is Google Cloud's implementation of the open-source Kubernetes Gateway API, serving as the modern replacement for GKE Ingress by provisioning Layer 7 Application Load Balancers. The Gateway API uses three role-oriented resource layers to support multi-tenant operational boundaries:
Cross-namespace routing allows a single Gateway in a shared infrastructure namespace to accept routing rules from HTTPRoutes across different application namespaces. A Gateway controls access through the allowedRoutes parameter in its listener configuration, granting routing access to the same namespace, a list of allowed namespaces, or all namespaces. If a platform operator needs to alter the underlying infrastructure type of a Gateway, they must delete and recreate the Gateway manifest with the new gatewayClassName, as in-place class updates are unsupported.
[ GatewayClass ] (Infrastructure Admin)
│
▼
[ Gateway ] (Platform Operator / Shared Namespace)
│
├───────────────────────────────┐
▼ ▼
[ HTTPRoute A ] (App Team A) [ HTTPRoute B ] (App Team B)
The HTTPRoute resource evaluates incoming request hostnames, headers, and URL paths to route traffic without relying on non-standard annotations. Operators apply request modifications, response header additions, or URL path rewrites directly through native HTTPRoute filter definitions. Traffic splitting directs client traffic across multiple backend Services based on numeric weight ratios defined inside the backendRefs field. Traffic shifting enables canary deployments and blue-green rollouts without altering the underlying application Pod configurations.
Multi-Cluster Gateway (MCG) extends the GKE Gateway controller to route traffic across multiple GKE clusters organized within a fleet. Clusters within a fleet rely on the principle of namespace sameness, which assumes identical namespaces across clusters represent the same operational tenant. Workload teams deploy identical Services in target clusters and export them using a ServiceExport resource, which creates a ServiceImport resource in the configuration cluster. The multi-cluster GatewayClass (designated by the -mc suffix) routes client requests across the multi-cluster ServiceImport backends, while Google Cloud Armor security policies attach directly to the imported services at the edge.
Client Request ──► Multi-Cluster Gateway (-mc)
│
┌─────────────┴─────────────┐
▼ ▼
[ ServiceImport / Cluster A ] [ ServiceImport / Cluster B ]
│ │
▼ ▼
Cluster A Pods Cluster B Pods
An edge-to-mesh ingress architecture pairs a cloud-managed Application Load Balancer at the edge with an in-cluster Cloud Service Mesh to deliver defense-in-depth traffic management. The outer layer, called cloud ingress, runs on Google Front End edge infrastructure to terminate public TLS using certificates managed by Certificate Manager and apply Google Cloud Armor Web Application Firewall (WAF) policies. The inner layer, called mesh ingress, runs Envoy proxies inside dedicated cluster namespaces to enforce mutual TLS (mTLS) and microservice routing policies across application workloads.
Client ──► [ Cloud Ingress: Global External ALB ] ──► [ Mesh Ingress: Envoy Proxies ] ──► Workload Pods
Health checking in this two-layer design operates hierarchically across trust boundaries. The external Application Load Balancer checks the exposed health check endpoints on the mesh ingress Envoy proxies. Concurrently, the Envoy mesh proxies independently monitor internal Pod health to steer traffic locally within the cluster.
GCE_VM_IP_PORT to route traffic directly to Pod IP addresses, bypassing Compute Engine node ports and kube-proxy.-mc suffix and routes traffic across fleet clusters through ServiceExport and ServiceImport resources.Node-level load balancing routes incoming traffic to a Compute Engine VM node port before kube-proxy forwards the request across internal iptables rules to a destination Pod, adding an extra network hop. Container-native load balancing uses Network Endpoint Groups to connect the load balancer directly to individual Pod IP addresses, eliminating the intermediate node hop and improving latency.
Use a standalone NEG when you require custom load balancing architectures that standard Ingress does not automate, such as external proxy Network Load Balancers, Cloud Service Mesh deployments, or backend pools that mix virtual machine and container endpoints.
The Gateway API supports canary deployments by allowing application teams to define multiple backend destinations with relative numeric weights inside the backendRefs field of an HTTPRoute resource, splitting traffic across Services without custom annotations.
Multi-Cluster Gateway relies on ServiceExport to expose a local Kubernetes Service across a multi-cluster fleet, which generates a corresponding ServiceImport in the configuration cluster that the Gateway HTTPRoute targets as a multi-cluster backend.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills