Design, implement, and secure Google Cloud networks, from VPCs and hybrid connectivity to load balancing and Cloud Armor, and track your readiness for the Professional Cloud Network Engineer exam.
Prepare and test your skills
Prepare and test your skills
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.
External: 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.Deploying an internal Application Load Balancer via GKE Ingress requires a dedicated proxy-only subnet in the Virtual Private Cloud (VPC) and mandates the use of Network Endpoint Groups (NEGs) instead of instance groups. Google Cloud provisions Envoy proxies within this proxy-only subnet, and operators must manually configure a firewall rule allowing traffic from the proxy-only subnet range to reach the backend container ports.
A BackendConfig custom resource attaches to a Kubernetes Service to manage backend features such as Google Cloud Armor security policies, custom health checks, Identity-Aware Proxy (IAP), and Cloud CDN. In contrast, a FrontendConfig custom resource attaches to an Ingress resource to control frontend settings, including customized SSL policies and TLS protocol versions.
The Gateway API enforces role-oriented boundaries by dividing load balancing controls across GatewayClass, Gateway, and HTTPRoute resources. Infrastructure administrators define cluster-scoped load balancer templates using GatewayClass, platform operators deploy the load balancer and configure listeners using Gateway, and application developers independently manage routing rules and backend destinations using HTTPRoute.
An edge-to-mesh ingress architecture pairs an external Application Load Balancer at the edge for public TLS termination and security with in-cluster Cloud Service Mesh Envoy proxies for mutual TLS (mTLS) enforcement and internal routing. Health checking operates hierarchically, meaning the external load balancer monitors the exposed health endpoints of the mesh ingress Envoy proxies, while those Envoy proxies independently evaluate the health of the workload Pods.
Last updated