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
  1. Backend Configuration: Multiple Backend Service or Backend Bucket
  2. Multiple Host and Path rules: each host+path maps to one backend service
  3. 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