HTTP(S) Load Balancer (Layer 7) in GCP - Commands & Configuration

Introduction

When many users visit your website, their requests can slow down or crash your server. An HTTP(S) Load Balancer helps by spreading these requests across multiple servers, making your site faster and more reliable.

When your website gets more visitors than one server can handle smoothly.

When you want to keep your website running even if one server stops working.

When you want to direct users to the closest server to reduce loading time.

When you want to secure your website with HTTPS and manage certificates easily.

When you want to balance traffic based on URL paths or hostnames.

Config File - load-balancer.yaml

load-balancer.yaml

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeBackendService
metadata:
  name: example-backend-service
spec:
  protocol: HTTP
  backends:
  - group: projects/my-project/zones/us-central1-a/instanceGroups/example-instance-group
  healthChecks:
  - projects/my-project/global/healthChecks/example-health-check
---
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeUrlMap
metadata:
  name: example-url-map
spec:
  defaultService: example-backend-service
---
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeTargetHttpProxy
metadata:
  name: example-http-proxy
spec:
  urlMap: example-url-map
---
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeGlobalForwardingRule
metadata:
  name: example-forwarding-rule
spec:
  ipAddress: example-lb-ip
  ipProtocol: TCP
  portRange: "80"
  target: example-http-proxy

This file creates the main parts of an HTTP Load Balancer on GCP:

• ComputeBackendService: Defines the group of servers that will handle the traffic.
• ComputeUrlMap: Routes incoming requests to the backend service.
• ComputeTargetHttpProxy: Connects the URL map to the forwarding rule.
• ComputeGlobalForwardingRule: Listens for traffic on port 80 and sends it to the proxy.

The IP address is a static external IP assigned to the load balancer.

Commands

Reserve a global static IP address for the load balancer to use. This IP will be the public address users connect to.

Terminal

gcloud compute addresses create example-lb-ip --global

Expected Output

Created [https://www.googleapis.com/compute/v1/projects/my-project/global/addresses/example-lb-ip].

→

--global - Reserve the IP address globally for global load balancers.

Check the reserved IP address details to use it in the load balancer configuration.

Terminal

gcloud compute addresses describe example-lb-ip --global

Expected Output

address: 34.68.194.64

addressType: EXTERNAL

creationTimestamp: '2024-06-01T12:00:00.000-07:00'

description: ''

id: '1234567890123456789'

name: example-lb-ip

networkTier: PREMIUM

selfLink: https://www.googleapis.com/compute/v1/projects/my-project/global/addresses/example-lb-ip

status: RESERVING

→

--global - Show details for the global IP address.

Create the load balancer resources in GCP using the configuration file.

Terminal

kubectl apply -f load-balancer.yaml

Expected Output

computebackendservice.compute.cnrm.cloud.google.com/example-backend-service created

computeurlmap.compute.cnrm.cloud.google.com/example-url-map created

computetargethttpproxy.compute.cnrm.cloud.google.com/example-http-proxy created

computeglobalforwardingrule.compute.cnrm.cloud.google.com/example-forwarding-rule created

Verify that the forwarding rule for the load balancer is active and listening on the correct IP and port.

Terminal

gcloud compute forwarding-rules list --global

Expected Output

NAME                   REGION  IP_ADDRESS    IP_PROTOCOL  PORT_RANGE  TARGET

example-forwarding-rule        global  34.68.194.64  TCP          80          example-http-proxy

→

--global - List global forwarding rules.

Key Concept

If you remember nothing else from this pattern, remember: a Layer 7 load balancer directs web traffic by inspecting URLs and spreads requests across multiple servers to keep your site fast and reliable.

Common Mistakes

Not reserving a global static IP before creating the forwarding rule.

The forwarding rule needs a fixed IP to receive traffic; without it, the load balancer won't have a reachable address.

Always create and note the global static IP address first, then use it in your load balancer configuration.

Applying the configuration without the backend instance group ready.

The backend service will fail to connect to servers, causing the load balancer to not route traffic properly.

Ensure your instance group with running servers exists before applying the load balancer config.

Using regional forwarding rules instead of global for HTTP(S) load balancers.

HTTP(S) load balancers in GCP require global forwarding rules to work across regions.

Use --global flag and global forwarding rules for HTTP(S) load balancers.

Summary

Reserve a global static IP address for your load balancer to have a fixed public address.

Create backend services and URL maps to define how traffic is routed to your servers.

Set up target HTTP proxy and global forwarding rule to listen for web traffic and send it to your backend.

Verify the forwarding rule is active and using the correct IP and port.

Practice

1. What is the primary function of an HTTP(S) Load Balancer in Google Cloud Platform?

easy

A. Distribute incoming web traffic across multiple backend services

B. Store user data securely in the cloud

C. Create virtual machines automatically

D. Monitor network latency between regions

Solution

1. Step 1: Understand the role of HTTP(S) Load Balancer

   It is designed to spread incoming web traffic to multiple backend services to improve performance and reliability.

2. Step 2: Eliminate unrelated functions

   Storing data, creating VMs, and monitoring latency are not functions of the load balancer.

3. Final Answer:

   Distribute incoming web traffic across multiple backend services -> Option A

4. Quick Check:

   Load balancer = traffic distribution [OK]

Hint: Load balancer = spreading traffic to backends [OK]

Common Mistakes:

• Confusing load balancer with storage or VM services
• Thinking it monitors network latency
• Assuming it creates resources automatically

2. Which component is NOT part of the HTTP(S) Load Balancer setup in GCP?

easy

A. Cloud Storage bucket

B. Forwarding rule

C. Target proxy

D. URL map

Solution

1. Step 1: Identify components of HTTP(S) Load Balancer

   It includes URL maps, forwarding rules, and target proxies to route traffic.

2. Step 2: Recognize unrelated components

   Cloud Storage bucket is for storing files, not part of load balancing setup.

3. Final Answer:

   Cloud Storage bucket -> Option A

4. Quick Check:

   Storage bucket ≠ load balancer component [OK]

Hint: Storage buckets store files, not route traffic [OK]

Common Mistakes:

• Confusing storage services with load balancer parts
• Mixing forwarding rules with storage buckets
• Assuming all GCP services are load balancer components

3. Given this URL map configuration snippet, which backend service will handle requests to /images/*?

{
  "hostRules": [{"hosts": ["*"], "pathMatcher": "allpaths"}],
  "pathMatchers": [{
    "name": "allpaths",
    "defaultService": "backend-service-default",
    "pathRules": [{"paths": ["/images/*"], "service": "backend-service-images"}]
  }]
}

medium

A. backend-service-default

B. backend-service-images

C. backend-service-static

D. backend-service-api

Solution

1. Step 1: Analyze path rules in URL map

   The path rule for /images/* points to backend-service-images.

2. Step 2: Understand default service role

   Requests not matching specific paths use backend-service-default, but /images/* matches a specific path rule.

3. Final Answer:

   backend-service-images -> Option B

4. Quick Check:

   Specific path rule overrides default service [OK]

Hint: Specific path rules override default backend [OK]

Common Mistakes:

• Choosing default service instead of specific path service
• Ignoring path pattern matching
• Confusing backend service names

4. A user configures an HTTP(S) Load Balancer but finds that requests to /api/* are not routed to the intended backend service. Which is the most likely cause?

medium

A. The backend service is not in the same region

B. The forwarding rule is missing

C. The target proxy is not HTTPS

D. The URL map lacks a path rule for /api/*

Solution

1. Step 1: Check URL map path rules

   If /api/* is missing in path rules, requests won't route correctly.

2. Step 2: Verify other components

   Forwarding rule and target proxy affect traffic flow but missing path rule directly causes routing failure. Backend region mismatch usually causes latency, not routing failure.

3. Final Answer:

   The URL map lacks a path rule for /api/* -> Option D

4. Quick Check:

   Missing path rule = routing failure [OK]

Hint: Check URL map paths if routing fails [OK]

Common Mistakes:

• Assuming forwarding rule absence causes routing error
• Confusing HTTPS proxy with routing logic
• Ignoring URL map path rules

5. You want to design a scalable web application using GCP's HTTP(S) Load Balancer that routes traffic based on URL paths to different backend services. Which design approach ensures high availability and efficient routing?

hard

A. Use a single backend service for all traffic and scale it vertically

B. Deploy multiple forwarding rules each pointing to different backend services without URL maps

C. Configure URL map with path matchers directing to multiple regional backend services behind managed instance groups

D. Use TCP Load Balancer instead of HTTP(S) Load Balancer for path-based routing

Solution

1. Step 1: Understand path-based routing needs

   HTTP(S) Load Balancer uses URL maps with path matchers to route requests to different backends efficiently.

2. Step 2: Ensure scalability and availability

   Using multiple regional backend services behind managed instance groups provides scalability and high availability.

3. Step 3: Evaluate other options

   Single backend limits scalability; multiple forwarding rules without URL maps cannot do path-based routing; TCP Load Balancer does not support Layer 7 routing.

4. Final Answer:

   Configure URL map with path matchers directing to multiple regional backend services behind managed instance groups -> Option C

5. Quick Check:

   URL map + regional backends = scalable routing [OK]

Hint: Use URL maps with regional backends for scalable routing [OK]

Common Mistakes:

• Using single backend limits scalability
• Misusing forwarding rules for path routing
• Choosing TCP Load Balancer for HTTP path routing