GCP Load Balancer - ghdrako/doc_snipets GitHub Wiki

Load balancer types

  • Regional External HTTP(S) Load Balancer

  • Global External HTTP(S) Load Balancer

  • SSL proxy load balancing(Global)

  • TCP proxy load balancing(Global)

  • External TCP/UDP Network load balancing(Regional) pass-through - preserve client ip

  • Internal TCP/UDP load balancing (Regional)

  • Internal HTTP(S) load balancing (Regional)

  • Network load balancing (Regional)

In the case of a proxy, the source IP is swapped to the proxy's IP as the connection is terminated at the proxy. In the case of a load balancer,the source IP is preserved. Keep this in mind when you configure your firewall rules using the source IP.

It allows you to distribute a workload between your scaling resources. It works with GCE, GAE, and GKE.

HTTP(S) load balancing

When your web application requires high availability of responses to web requests coming from global users, then you can choose HTTP(S) Global Load Balancing from GCP.

HTTP(S) Load Balancing is implemented on Google Front End (GFE). GFEs are distributed globally and operate together using Google's global network and control plane. You can configure URL rules to route some URLs to one set of instances and route other URLs to other instances. Requests are always routed to the instance group that is closest to the user, if that group has enough capacity and is appropriate for the request. If the closest group does not have enough capacity, the request is sent to the closest group that does have capacity.

To set up a load balancer with a Compute Engine backend, your VMs need to be in an instance group. The managed instance group provides VMs running the backend servers of an external HTTP load balancer.

When you need to load balance traffic across multiple Compute Engine instances in one GCP region, Google Cloud offers two internal load balancing services: Internal TCP/UDP Load Balancer and Internal HTTP(S) Load Balancer. This service allows you to load balance internal traffic to a group of Virtual machines running inside a region.

  • External HTTP(S) load balancers are global and allow external connectivity. It supports both IPv4 and IPv6. It can be only used for HTTP and HTTPS traffic but offers a couple of additional features, such as the following:
    • CDN caching
    • Integrates with Cloud Armor
    • Supports URL maps
    • Hosts SSL certificates
    • Supports Cloud Storage
    • Supports session affinity
    • Supports the Quick UDP Internet Connections (QUIC) protocol
  • Internal HTTP(S) load balancers are regional and accessible only in the selected region of the VPC. They do not support the following:
    • Cloud CDN
    • Cloud Armor
    • Storage buckets
    • Google-managed SSL certificates
    • SSL policies

SSL proxy load balancing

The SSL proxy terminates the user's SSL (TLS connections) and is intended for non-HTTP(S) traffic. It is global and allows external connectivity that supports both IPv4 and IPv6. The traffic from the proxy to the machines can use either the TCP or SSL protocols.

TCP proxy load balancing

The TCP proxy terminates non-HTTP traffic that does not require SSL. It is global and allows external connectivity that supports both IPv4 and IPv6.

Network TCP/UDP load balancing

Network load balancing uses a non-proxied load balancer that distributes traffic-based inbound IP protocol data such as addresses, ports, and protocol types. It is regional and external with support for IPv4 only. The network load balancer collects VMs to be load balanced into a logical group called a target pool.

Setting Up Network Load Balancing.

# create vm www1 - reapet to www2 and www3
gcloud compute instances create www1 \
  --image-family debian-9 \
  --image-project debian-cloud \
  --zone us-central1-a \
  --tags network-lb-tag \
  --metadata startup-script="#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"
# Create a firewall rule to allow external traffic to the VM instances
gcloud compute firewall-rules create www-firewall-network-lb \
    --target-tags network-lb-tag --allow tcp:80


# 1. Create a static external IP address for your load balancer
gcloud compute addresses create network-lb-ip-1 --region us-central1 
# 2. Add a legacy HTTP health check resource:
gcloud compute http-health-checks create basic-check     
# 3. Add a target pool in the same region as your instances            
gcloud compute target-pools create www-pool \
    --region us-central1 --http-health-check basic-check  
# 4. Add the instances to the pool
gcloud compute target-pools add-instances www-pool \
    --instances www1,www2,www3 
# 5. Add a forwarding rule
gcloud compute forwarding-rules create www-rule \
    --region us-central1 \
    --ports 80 \
    --address network-lb-ip-1 \
    --target-pool www-pool       
# 6.  view the external IP address of the www-rule forwarding rule used by the load balancer
gcloud compute forwarding-rules describe www-rule --region us-central1   
# 7 while true; do curl -m1 IP_ADDRESS; done

Internal TCP/UDP load balancing:

Internal load balancing is a non-proxied form of load balancing. It is regional and internal with support for IPv4 only. As an example, it can be used for three-tier applications where web services need to load balance an internal connection to the application tier.

Comparision

Load balancer type trafic type Preserve Client IP Global/Regional Lb scheme lb dest port Proxy or pass-through
External HTTP(S) HTTP/HTTPS No Globa* EXTERNAL 80,8080,443 Proxy
Internal HTTP(s) HTTP/HTTPS No Regional INTERNAL_MANAGED 80,8080,443 Proxy
SSL Proxy TCP with SSL No Global* EXTERNAL Proxy
TCP PROXY TCP witout SSL No Global* EXTERNAL Proxy
External TCP/UDP TCP,UDP,ESP,ICMP Yes Regional EXTERNAL Any Pass-trough
Internal TCP/UDP TCP,UDP Yes Regional INTERNAL Any Pass-trough

Choosing the right load balancer

  1. choose whether we want the load balancer to be accessible externally or internally. For external exposure, we choose what traffic we want to balance.
  2. For HTTP and HTTPS traffic, we use an HTTP(S) load balancer.
  3. For TCP traffic with an SSL offload, we would go for the SSL proxy. If we don't need the offload SSL but need IPv6 or global scope support, we would choose the TCP proxy.
  4. Then, we need to check whether we need to preserve client IPs. If yes, we go for the network load balancer; if not, we stay with the TCP proxy. The network load balancer can be also used for UDP traffic that does not need IPv6 or global scope.
  5. For internal load balancing, use an internal TCP/UDP load balancer.
⚠️ **GitHub.com Fallback** ⚠️