Understanding GCP Load Balancers
In this post, we will try to give you the big picture about GCP Load Balancing and answer the following questions: how Load Balancing works in GCP, what are the types of GCP Load Balancers and their purposes, which components make a GCP Load Balancer... with examples and links to go deeper.
GCP Load Balancers overview
GCP Load Balancer overview
GCP Load Balancers types
Have a look at GCP Load Balancers types for details.
There are two main types of Load Balancers in GCP (Google Cloud Platform):
-
Application Load Balancers: for Layer 7 HTTP(S) traffic
-
Network Load Balancers: for layer 4 traffic (TCP, UDP...) and also SSL/TLS traffic.
Network Load Balancers are divided into two categories:
Proxy Network Load Balancers
Terminate clients requests connections and create new connections to the backends, originating from the Load Balancer. Backends responses are sent back to the Load Balancer, then to clients by the Load Balancer. By default, backends see the IP address of the Load Balancer instead of clients IPs. It is also possible to forward clients IP addresses to the backends by enabling the PROXY protocol.
Session affinity and connection draining can also be configured for the Load Balancers backends.
That Load Balancer is also called SSL Proxy Network Load Balancer when it terminates SSL/TLS connections and TCP Proxy Network Load Balancer when it terminates TCP, UDP or other layer 4 protocols connections.
Passthrough Network Load Balancers
Clients requests connections are directly forwarded to the backends. Backends responses are directly sent to the clients (direct server return).
GCP Load Balancers scopes
- External: accessible from the internet via a public IP address
- Internal: accessible only from inside a GCP internal network (VPC) or from networks connected to it, through a private (RFC 1918) IP address
- Global: optimized (low latency) for traffic coming from anywhere in the world. The Load Balancer will be accessible via a global anycast IP address. Backend applications could be deployed in any GCP region.
- Regional: optimized (low latency) for traffic coming from a specific region in the world. The Load Balancer will be accesible via a regional IP address. Backend applications should be deployed in the same region as the Loab Balancer. All the network traffic will stay inside the choosen region.
- Cross-regional: optimized (low latency) for traffic coming from multiple regions (2 or more). The Load Balancer will be accessible via a dedicated Virtual IP (VIP) inside each region. Backend applications should be deployed in the choosen regions. All the network traffic will stay inside the choosen regions.
The combination of one item from global, regional or cross-regional and another one from external or internal represents the Load Balancer deployment mode or operation mode. Ex: cross-region internal, global external, regional external...
Sometimes you will also see the classic operation mode available for some of the external Load Balancers. It can be used to deploy the Load Balancer in either global external (when using Premium Tier) or regional external (when using Standard Tier) operation modes.
Application Load Balancer
Application Load Balancer (ALB)
Proxy Network Load Balancer
Proxy Network Load Balancer (Proxy-NL)
Passthrough Network Load Balancer
Passthrough Network Load Balancer (Passthrough-NL)
-
External Passthrough-NL overview (backend via a backend service)
-
External Passthrough-NL overview (backend via a target pool)
GCP Load Balancers components
Backend services and Forwarding rules
Passthrough Network Load Balancer components
We are going to explain what the Forwarding rule and Backend service are, and also show the usage of Health check and Firewall rules in relation to the backend service.
Backend service
The backend service component can be used to represent the Load Balancers backends. Backends are the final destination of the Load Balancer traffic. They can be seen as endpoints (IP + Port) that receive traffic from the Load Balancer. Ex: Virtual Machines (classic or instance groups) and NEG (Network Endpoint Groups).
The backend service supports the following backends:
- virtual machines instance groups (managed or unmanaged)
- Network Endpoint Groups (NEG)
Some interesting features of the Load Balancer are also defined by the backend service:
- sessions affinity
- client connections timeouts
- requests logging
- type of health checks for the backends (http, tcp...)
- IAP (Identity Aware Proxy)
- Cloud Armor (Web Application Firewall)
- Etc... the following command should give an overview of those features:
gcloud compute backend-services create --help
gcloud compute backend-services add-backend --help
Here is an example for creating a backend service using gcloud:
# Backend service needs health checks for the backends
# Here is an example for creating a http health check
gcloud compute health-checks create http http-basic-check --port 80
# We also need to create a firewall rule to allow
# health checks probes sources IP ranges on the backends.
# Depending on the type of the Load Balancer, the list of
# the IP ranges can be found here:
# https://cloud.google.com/load-balancing/docs/health-check-concepts?hl=en#ip-ranges
gcloud compute firewall-rules create fw-allow-health-check \
--network=$network \
--action=allow \
--direction=ingress \
--source-ranges=$ranges \
--target-tags=allow-health-check \
--rules=tcp:80
# Create the backend service
gcloud compute backend-services create myapp-backend-service --protocol=HTTP --port-name=http --health-checks=http-basic-check --global
# Add an instance group as backend to the backend service
gcloud compute backend-services add-backend myapp-backend-service \
--instance-group=web-instance-group \
--instance-group-zone=us-east4-c \
--global
In addition to backend services, the following components can also be used for some Load Balancers:
- backend bucket: for using Cloud Storage buckets as backends (to servce static websites for instance)... supported by Application Load Balancers only.
- target pools: for using virtual machines as backends.
Forwarding rule
The forwarding rule is the frontend of GCP Loab Balancers and defines the IP address of the Load Balancer, a protocol + one or more ports to listen on, and depending on the Load Balancer type, specify either a backend service, a target proxy or a target pool.
The exposition (external or internal) and the scope of the Load Balancer (regional or global) is also determined by the Forwarding rule. A forwarding rule can either be:
- external or internal:
# gcloud flag for: gcloud compute forwarding-rules create...
--load-balancing-scheme=[EXTERNAL|EXTERNAL_MANAGED|INTERNAL|INTERNAL_MANAGED|INTERNAL_SELF_MANAGED]` (gcloud flag)
- global or regional:
# gcloud flags for: gcloud compute forwarding-rules create ...
--global
--region=REGION
Here are examples for creating Forwarding rules for Passthrough Network Load Balancers using gcloud:
# (Regional, external) Passthrough Network Load Balancer
# Backends are virtual machines inside a target pool
$ gcloud compute forwarding-rules create my-forwarding-rule-1 \
--region $region \
--ports 80 \
--address my-regional-static-ip-name \
--target-pool my-target-pool
# (Regional, internal) Passthrough Network Load Balancer
# Backends are virtual machines inside instance groups
$ gcloud compute forwarding-rules create my-forwarding-rule-2 \
--ports=80 \
--address=my-regional-static-ip-name \
--backend-service=my-backend-service \
--address-region=$region \
--load-balancing-scheme=INTERNAL \
--network=my-vpc \
--subnet=my-vpc-subnet # subnet of the associated IP address (--address)
Target proxies and SSL/TLS certificates
Proxy Network Load Balancer components
Clients connections received by the Proxy Network Load Balancer are forwarded to the following target proxies:
- target TCP proxy: for TCP/UDP and other layer 4 traffic
- target SSL proxy: for SSL traffic. The use of this target proxy requires an associated SSL/TLS certificates for encrypting communications between the clients and the Load Balancer.
Connections reveived by the Application Load Balancer are forwarded to the:
- target HTTP(S) proxy: for HTTP(S) (Layer 7) traffic. The use of the HTTPS target proxy requires an associated SSL/TLS certificates for encrypting communications between the clients and the Load Balancer.
All connections arriving at the target proxies are terminated and new ones, originating from the Load Balancer, are created to the backends. This is the main purpose of the target proxies.
The following commands should give an overview of the possibilities when creating a target proxy:
gcloud compute target-tcp-proxies create --help
gcloud compute target-ssl-proxies create --help
gcloud compute target-https-proxies create --help
gcloud compute target-http-proxies create --help
Here is an example for creating a HTTP target proxy using gcloud:
gcloud compute target-http-proxies create myapp-target-http-proxy --url-map myapp-url-map
# for target-https-proxies an additional flag should be specified
# (--certificate-map or --certificate-manager-certificates...)
# to indicate where to find the SSL/TLS certificate
URL map
Application Load Balancer components
Only used by Application Load Balancers target HTTP(s) proxy, to determine where to forward a specific HTTP request (to a backend service or a backend bucket). The forwarding / routing decisions are made depending on the HTTP requests Host and/or URI.
The following command should give an overview of the possibilites when creating a URL map:
gcloud compute url-maps create --help
Here is an example for creating a URL map using gcloud:
gcloud compute url-maps create myapp-url-map --default-service myapp-backend-service