Cloud CDN leverages Google Cloud global external HTTP(S) load balancers to provide routing, health checking, and Anycast IP support. Global external HTTP(S) load balancers can have multiple backend instance types, and you can choose which backends (or origins) to enable Cloud CDN for.
This setup guide shows you how to create a simple external HTTPS load balancer with Cloud CDN enabled. The load balancer has the following resources:- The default Virtual Private Cloud (VPC) network
- A Compute Engine managed instance group
- A named port that specifies port 80 for backend traffic
- A default URL map
- A simple backend health check
- A simple frontend forwarding rule
- A reserved external IP address
- An SSL certificate
For a content-based, multi-region example that includes IPv6 and SSL certificate setup, see Setting up a multi-region, content-based external HTTPS load balancer.
For general concepts, see the External HTTP(S) Load Balancing overview.
If you're using GKE, the load balancer is typically configured by the Kubernetes Ingress controller. For more information, see Configuring Ingress for external load balancing.
HTTPS load balancer topology
In this guide, you create the configuration that is illustrated in the following diagram.
The sequence of events in the diagram is as follows:
- A client sends a content request to the external IPv4 address defined in the forwarding rule.
- The load balancer checks whether the request can be served from cache. If so, the load balancer serves the requested content out of cache. If not, processing continues.
- The forwarding rule directs the request to the target HTTPS proxy.
- The target proxy uses the rule in the URL map to determine that the single backend service receives all requests.
- The load balancer determines that the backend service has only one instance group and directs the request to a virtual machine (VM) instance in that group.
- The VM serves the content requested by the user.
Before you begin
Make sure that your setup meets the prerequisites.
Set up an SSL certificate resource
Create an SSL certificate resource as described in the following:
We recommend using a Google-managed certificate.
This example assumes that you already have an SSL certificate resource named
www-ssl-cert
.
Set up permissions
To complete the steps in this guide, you must have permission to create Compute Engine instances, firewall rules, and reserved IP addresses in a project. You must have either a project owner or editor role, or you must have the following Compute Engine IAM roles.
Task | Required role |
---|---|
Create instances | Instance Admin |
Add and remove firewall rules | Security Admin |
Create load balancer components | Network Admin |
Create a project (optional) | Project Creator |
For more information, see the following guides:
Creating a managed instance group
To set up a load balancer with a Compute Engine backend, your VMs need to be in an instance group. This guide describes how to create a managed instance group with Linux VMs that have Apache running, and then set up load balancing.
The managed instance group provides VMs running the backend servers of an external HTTPS load balancer. For demonstration purposes, backends serve their own hostnames.Console
- In the Google Cloud Console, go to the Instance groups page.
- Click Create instance group.
- On the left, choose New managed instance group.
- For Name, enter
lb-backend-example
. - Under Location, select Single zone.
- For Region, select your preferred region. This example uses
us-east1
. - For Zone, select us-east1-b.
- Under Instance template, select Create a new instance template.
- For Name, enter
lb-backend-template
. - Ensure that the Boot disk is set to a Debian image, such as
Debian GNU/Linux 9 (stretch). These instructions use commands that
are only available on Debian, such as
apt-get
. Under Management, security, disks, networking, sole tenancy, on the Management tab, insert the following script into the Startup script field.
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html
On the Networking tab, add the network tags:
allow-health-check
Click Save and continue.
Under Autoscaling mode, select Don't autoscale.
Under Number of instances, enter
2
.To create the new instance group, click Create.
gcloud
Create the template.
gcloud compute instance-templates create lb-backend-template \ --region=us-east1 \ --network=default \ --subnet=default \ --tags=allow-health-check \ --image-family=debian-9 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
Create the managed instance group based on the template.
gcloud compute instance-groups managed create lb-backend-example \ --template=lb-backend-template --size=2 --zone=us-east1-b
Adding a named port to the instance group
For your instance group, define an HTTP service and map a port name to the relevant port. Once configured, the load balancing service forwards traffic to the named port.
Console
- In the Google Cloud Console, go to the Instance groups page.
- Click the name of your instance group (in this example
lb-backend-example
) and click Edit Group. - Click Specify port name mapping.
- Click Add item.
- For the port name, enter
http
. For the port number, enter and80
. - Click Save.
gcloud
gcloud compute instance-groups unmanaged set-named-ports lb-backend-example \ --named-ports http:80 \ --zone us-east1-b
Configuring a firewall rule
In this example, you create the fw-allow-health-check
firewall rule.
This is an ingress rule that allows traffic from the Google Cloud health
checking systems (130.211.0.0/22
and 35.191.0.0/16
). This example uses the
target tag allow-health-check
to identify the VMs.
Console
- In the Google Cloud Console, go to the Firewall page.
- Click Create firewall rule to create the second firewall rule.
- For Name, enter
fw-allow-health-check
. - Under Network, select Default.
- Under Targets, select Specified target tags.
- Populate the Target tags field with
allow-health-check
. - Set Source filter to IP ranges.
- Set Source IP ranges to
130.211.0.0/22
and35.191.0.0/16
. - Under Protocols and ports, select Specified protocols and ports.
- Select the tcp checkbox, and then type
80
for the port numbers. - Click Create.
gcloud
gcloud compute firewall-rules create fw-allow-health-check \ --network=default \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Reserving an external IP address
Now that your instances are up and running, set up a global static external IP address that your customers use to reach your load balancer.
Console
- In the Google Cloud Console, go to the External IP addresses page.
- To reserve an IPv4 address, click Reserve static address.
- For Name, enter
lb-ipv4-1
. - Set Network Service Tier to Premium.
- Set IP version to IPv4.
- Set Type to Global.
- Click Reserve.
gcloud
gcloud compute addresses create lb-ipv4-1 \ --ip-version=IPV4 \ --global
Note the IPv4 address that was reserved:
gcloud compute addresses describe lb-ipv4-1 \ --format="get(address)" \ --global
Setting up the load balancer
In this example, you are using HTTPS between the client and the load balancer, so you need one or more SSL certificate resources to configure the proxy. We recommend using a Google-managed certificate.Console
-
In the Google Cloud Console, go to the Load balancing page.
- Click Create load balancer.
- Under HTTP(S) Load Balancing, click Start configuration.
- Select From Internet to my VMs, and then click Continue.
- For the load balancer Name, enter
web-map-https
. -
Click Backend configuration.
- Under Create or select backend services & backend buckets, select Backend services > Create a backend service.
- Add a name for your backend service, such as
web-backend-service
. - Under Protocol, select HTTP.
- For the Named Port, enter
http
. - In Backends > New backend >
Instance group, select your instance group,
lb-backend-example
. - For the Port numbers, enter
80
. - Retain the other default settings.
- Under Health check, select Create a health
check, and then add a name for your health check, such as
http-basic-check
. - Set the protocol to HTTP, and then click Save and continue.
- Select Enable Cloud CDN.
- Retain the other default settings.
- Click Create.
- In Host and path rules, retain the default settings.
- In Frontend configuration, use the following values:
- Set Protocol to HTTPS.
- Set IP address to
lb-ipv4-1
, which you created earlier. - Ensure that Port is set to 443 to allow HTTPS traffic.
- Click the Certificate drop-down list and select your primary SSL certificate.
- Click Done.
- Click Review and finalize.
- When you finish configuring the load balancer, click Create.
- Wait for the load balancer to be created.
- Click the name of the load balancer.
- On the Load balancer details screen, note the IP:Port for your load balancer.
gcloud
- Create a health check.
gcloud compute health-checks create http http-basic-check \ --port 80
- Create a backend service.
gcloud compute backend-services create web-backend-service \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check \ --global
- Add your instance group as the backend to the backend service.
gcloud compute backend-services add-backend web-backend-service \ --instance-group=lb-backend-example \ --instance-group-zone=us-east1-b \ --global
- Create a URL map to route the incoming requests to the default backend
service.
gcloud compute url-maps create web-map-https \ --default-service web-backend-service
- If you haven't aleady done so, create the global SSL certificate
resource, as shown in:
The following example assumes that you already have a certificate file called
certificate-file
and a private key file calledprivate-key-file
. The example creates an SSL certificate resource calledwww-ssl-cert
.gcloud compute ssl-certificates create www-ssl-cert \ --certificate=certificate-file \ --private-key=private-key-file \ --global
- Create a target HTTPS proxy to route requests to your URL map. The
proxy is the portion of the load balancer that holds the SSL certificate
for HTTPS Load Balancing, so you also load your certificate in this step.
gcloud compute target-https-proxies create https-lb-proxy \ --url-map web-map-https --ssl-certificates www-ssl-cert
- Create a global forwarding rule to route incoming requests to the proxy.
gcloud compute forwarding-rules create https-content-rule \ --address=lb-ipv4-1\ --global \ --target-https-proxy=https-lb-proxy \ --ports=443
Enabling Cloud CDN
If you didn't already enable Cloud CDN when you created your backend service, you can do this now by updating the backend service:
gcloud compute backend-services update web-backend-service \ --enable-cdn \ --cache-mode=CACHE_MODE
Replace CACHE_MODE with one of the following:
CACHE_All_STATIC
: Automatically caches static content. Responses that are marked as uncacheable (private
,no-store
, orno-cache
directives inCache-Control
response headers) aren't cached. To cache dynamic content, the content must have valid caching headers. This is the default behavior for all new Cloud CDN-enabled backends.USE_ORIGIN_HEADERS
(default): Requires the origin to set valid caching headers to cache content. Responses without these headers aren't cached at Google's edge and require a full trip to the origin on every request, potentially impacting performance and increasing load on the origin server. This is the default behavior for all existing Cloud CDN-enabled backends.FORCE_CACHE_ALL
: Caches all content, ignoring anyprivate
,no-store
, orno-cache
directives inCache-Control
response headers. This might result in caching of private, per-user (user identifiable) content. You should only enable this on backends that are not serving private or dynamic content, such as Cloud Storage buckets.
To automatically cache static responses from your origin, you can use the
CACHE_ALL_STATIC
cache mode setting.
To control cacheability for each response by using HTTP cache
directives, set the cache mode to use origin headers (USE_ORIGIN_HEADERS
). For
information about the cache directives that Cloud CDN understands and
what's not cached by Cloud CDN, see Cacheable
content and Non-cacheable
content.
If your origin isn't serving any per-user dynamic content, you might want to
cache all responses from the origin. To do this, use the FORCE_CACHE_ALL
mode. This mode caches all responses, regardless of content type or cache
directives.
If you don't explicitly select a cache mode when you enable Cloud CDN
on a backend, the API and the gcloud
command-line tool default to USE_ORIGIN_HEADERS
,
and the Cloud Console defaults to CACHE_ALL_STATIC
.
Testing traffic sent to your instances
Now that the load balancing service is running, you can send traffic to the forwarding rule and watch the traffic be dispersed to different instances.
Console
In the Google Cloud Console, go to the Load balancing page.
- Click the load balancer that you just created.
- In the Backend section, confirm that the VMs are healthy. The
Healthy column should be populated, indicating that both VMs
are healthy (
2/2
). If you see otherwise, first try reloading the page. It can take a few moments for the Cloud Console to indicate that the VMs are healthy. If the backends do not appear healthy after a few minutes, review the firewall configuration and the network tag assigned to your backend VMs. - If you are using a Google-managed certificate, confirm that your certificate resource's status is ACTIVE. For more information, see Google-managed SSL certificate resource status.
- After the Cloud Console shows that the backend instances are
healthy, you can test your load balancer using a web browser by going to
https://IP_ADDRESS
. ReplaceIP_ADDRESS
with the load balancer's IP address. - If you used a self-signed certificate for testing, your browser displays a warning. You must explicitly instruct your browser to accept a self-signed certificate.
- Your browser should render a page with content showing the name of the
instance that served the page, along with its zone (for example,
Page served from: lb-backend-example-xxxx
). If your browser doesn't render this page, review the configuration settings in this guide.
Disabling Cloud CDN
Console
Disable Cloud CDN for a single backend service
- In the Google Cloud Console, go to the Cloud CDN page.
- On the right side of the origin row, click Menu and then select Edit.
- Clear the checkboxes of any backend services that you want to stop from using Cloud CDN.
- Click Update.
Remove Cloud CDN for all backend services for an origin
- In the Cloud Console, go to the Cloud CDN page.
- On the right side of the origin row, click Menu and then select Remove.
- To confirm, click Remove.
gcloud
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --no-enable-cdn
Disabling Cloud CDN does not invalidate or purge caches. If you disable and then re-enable Cloud CDN, most or all of your cached content might still be cached. To prevent content from being served from cache, you must invalidate that content.
What's next
- To learn about what content is cached, see the Caching overview.
- To use Cloud CDN in GKE, see Ingress features.
- To check whether Cloud CDN is serving responses from cache, see Viewing logs.
- To find information about common problems and solutions, see Troubleshooting.
- To learn how Cloud CDN works, see the Cloud CDN overview.