Skip to content

Load Balancers

  • Global: HTTP(S), SSL Proxy, TCP Proxy
  • single any-cast IP address
  • All global LB are proxied and external
  • Routing based on URL for HTTP(S), or specific port numbers for SSL/TCP
  • Regional: Internal HTTP(S), Internal TCP/UDP, External Network TCP/UDP
  • HTTP(S) is proxied, others are non-proxied
  • All are internal except External network TCP/UDP
  • comparison
  • BP choosing LB
  • External -> Yes
    • HTTP(S) -> HTTP LB
    • TCP -> Yes
    • SSL Offload -> SSL Proxy
    • Global LB or IPV6 -> TCP Proxy
    • Preserve client IPs -> Network TCP/UDP
    • UDP -> Network TCP/UDP (only regional and no IPV6)
  • Internal -> Yes
    • HTTP(S) -> Internal HTTP(S)
    • Network TCP/UDP
  • use Google Front Ends GFE
  • automatic DoS Denial of Service protection
  • optional: Cloud Armor for HTTP(S) LB
  • Data Model:
  • HTTP(S): Internet (global IP) -> Global Forwarding Rule (IP, Protocol, Port) -> Target Proxy (terminates client session, SSL certificates deployed here, consists of URL Map) -> backend-service -> Managed Instance Groups or Network Endpoint Groups (service capacity zone, healthcheck)
  • Internal Load Balancing: Internet (global IP) -> Global Forwarding Rule -> Backend Service

Global

  • 3 types: HTTP, TCP Proxy and SSL Proxy
  • Requires premium network tier
  • HTTP LB uses anycast routing (single Virtual IP) with cross region failover, overflow
  • unlike DNS load balancer, global has single virtual IP that doesn't require updating DNS records in case of an regional outage
  • Components
  • routes traffic to local first in order of priority
  • HTTP traffic is proxied, i.e. incoming traffic terminates at LB, and LB opens a new connection to proxied server
  • BP: Firewall only sees traffic from LB. Set up Cloud Armor to limit access to public LB
  • preferentially routes traffic from local PoP to regional
  • if there is an outage or congestion, it can route anywhere in the world
  • Network Endpoint Group NEG is container level load balancing v/s VM level in instance group
  • e.g. a kubernetes application can ne load balanced at container (pod) level with NEG
  • enabled in k8s by an annotation load-balance-neg: true in Service manifest
  • Components of HTTP(S) load balancer
  • Backend Configuration: Multiple Backend Service or Backend Bucket
  • Multiple Host and Path rules: each host+path maps to one backend service
  • Front-end configuration: accessed by clients. Multiple protocol+port eg HTTP:80
  • can be mapped to multiple host+path rules
  • can provide multi-cluster ingress that targets k8s which is closest to the user
  • External Multi-Region TCP LB components
  • Backend: 1+ either all Instance Groups or Network Endpoint Groups, Named Port, Time Out and Health Check
  • Frontend: IP+port
  • Q: Does HTTPS load balancer support WebSocket, A: Yes
  • BP when proxying TCP or SSL, prefer SSL for connecting from LB to backend

Network LB

  • External but Regional and non-proxied
  • TCP/SSL or UDP
  • Backend can be Instance Group or Target Pool
  • Target pool:
  • LB picks an instance based on hash of Source IP+Port and Target IP+Port
  • each target pool can have only one health-check
  • Components:
  • Backend configuration:
  • front-end configuration:

Internal LB

  • Regional, only with internal IPs
  • TCP/UDP
  • Reduced latency
  • Unlike traditional proxied internal load balancing, this is software-defined LB (Andromeda)

Regional

  • regional LB, Layer 4, non-proxied (client IP addresses are preserved)
  • can use firewall rules to check against source
  • Types; Internal (TCP/UDP), Network (TCP/UDP) or Internal (HTTP)
  • backend can be instance group or Target Pool resource
  • uses target pools for session affinity
  • load balances using 2, 3 or 5 tuples
  • ip based session affinity
  • http healthchecks
  • Network LB employs, proprietary google technology that
  • unlike traditional active-passive LB, has multiple LB in active-active LBs
  • backend servers use Direct Server Return to return results directly without going through LBs again.
  • Load balancers IP ranges 130.211.0.0/22 and 35.191.0.0/16
  • Internal LB components (must be single region)
  • Backend: 1 or more Instance Groups, Health Check, Session affinity
  • Frontend: Consists of IP and port

Backend service

  • one of
  • Instance Group,
  • Zonal Network Endpoint Groups (Zonal NEG)
  • Serverless NEG (App Engine/Cloud Run/Cloud Function)
  • Internet NEGs (outside google)
  • Buckets in Cloud Storage
  • Protocol and named port, eg HTTP
  • Consists of one or more backends. Each instance group specifies
  • port number that maps to named port, eg 80
  • balancing mode: CPU Utilization or RPS
  • maximum utilization: eg 80
  • capacity in %: eg 100%
  • Health check
  • remember to create a firewall rule to allows access from 130.211.0.0/22 and 35.191.0.0/16
  • session affinity, based on either client IP or cookie
  • CDN and Cloud Armor enablement.
  • Cloud Armor not supported for buckets
  • when both CDN and Cloud Armor are enabled, CDN is served first, ie a cache hit is not checked by Armor
  • draining timeout: time allowed to terminate existing connections, but no new connections are allowed

Internal LB

  • doesn't use public IP, works with internal IP
  • Unlike traditional LB, GCP doesn't have real (physical) LB because it is Software Defined Networking SDN (code name Andromeda)
  • SDN is control-plane only with no data-plane. i.e. no data flows through LB
  • control-plane define routes and push down to VMs directly

gcloud

  • load balancer config: create target pool, create instance template, create managed instance group
# load balancer config
gcloud compute target-pools create nginx-pool
gcloud compute instance-templates create nginx-template --metadata-from-file startup-script=startup.sh
gcloud compute instance-groups managed create nginx-group \
        --base-instance-name nginx \
        --size 2 \
        --template nginx-template \
        --target-pool nginx-pool
  • L3: create forwarding rule to tie target pool and port
gcloud compute forwarding-rules create nginx-lb --region us-central1 --ports=80 --target-pool nginx-pool
gcloud compute forwarding-rules list  # list forwarded IP addresses
  • L7: create health-check, tie managed group with port, create backend service
gcloud compute http-health-checks create http-basic-check # health-checks
gcloud compute instance-groups managed set-named-ports nginx-group --named-ports http:80 # create a http-service with port mapping
gcloud compute backend-services create nginx-backend \ # create back-end service
      --protocol HTTP --http-health-checks http-basic-check --global
gcloud compute backend-services add-backend nginx-backend \  # add back-end to instance group
    --instance-group nginx-group \
    --instance-group-zone us-central1-a \
    --global
gcloud compute url-maps create web-map --default-service nginx-backend
gcloud compute target-http-proxies create http-lb-proxy --url-map web-map
gcloud compute forwarding-rules create http-content-rule \
        --global \
        --target-http-proxy http-lb-proxy \
        --ports 80