Preparing for Internal HTTP(S) Load Balancing setup

Setting up Internal HTTP(S) Load Balancing has two phases:

• Performing prerequisite tasks, such as ensuring that required accounts have the correct permissions and preparing the VPC network
• Setting up the load balancer resources

This guide describes how to set up the prerequisites. Additional guides describe how to set up the load balancing resources.

Before following this guide, familiarize yourself with the following:

• Internal HTTP(S) Load Balancing Concepts
• Firewall Rules Overview

Permissions

To follow this guide, you must be able to create instances and modify a network in a project. You must be either a project owner or editor, or you must have all of the following Compute Engine IAM roles:

Task	Required Role
Create networks, subnets, and load balancer components	Network Admin
Add and remove firewall rules	Security Admin
Create instances	Instance Admin

Setup overview

You can configure Internal HTTP(S) Load Balancing as described in the following high-level configuration flow. The numbered steps refer to the numbers in the diagram.

Internal HTTP(S) Load Balancing numbered components (click to enlarge)

As shown in the diagram, this example creates an internal HTTP(S) load balancer in a VPC network in region us-west1, with one backend service and two backend groups.

The diagram shows:

1. A VPC network with two subnets:

   1. One subnet is used for backends (instance groups and NEGs) and the forwarding rule. Its primary IP address range is 10.1.2.0/24.

   2. One subnet is a proxy-only subnet in the us-west1 region. You must create one proxy-only subnet in each region of a VPC network where you use internal HTTP(S) load balancers. The region's proxy-only subnet is shared among all internal HTTP(S) load balancers in the region. Source addresses of packets sent from the internal HTTP(S) load balancer to your service's backends are allocated from the proxy-only subnet. In this example, the proxy-only subnet for the region has a primary IP address range of 10.129.0.0/26. For more information, refer to Proxy-only subnets for internal HTTP(S) load balancers.

2. Firewall rules that permit desired traffic flows in your network. This includes adding one rule that allows TCP port 80, 443, and 8000 traffic from 10.129.0.0/26 (the range of the proxy-only subnet in this example) and another rule for the health check probes.

3. Backend instances. This example demonstrates the following backend deployments:

   1. Google Compute Engine VMs
   2. Google Kubernetes Engine (GKE) backends added to network endoint groups (NEGs)

4. Instance groups and NEGs:

   1. Managed or unmanaged instance groups for Compute Engine VM deployments
   2. NEGs for GKE deployments

   In each zone, you can have combination of backend group types based on the requirements of your deployment.

5. A regional health check that reports the readiness of your backends.

6. A regional backend service that monitors the usage and health of backends.

7. A regional URL map that parses the URL of a request and forwards requests to specific backend services based on the host and path of the request URL.

8. A regional target HTTP or HTTPS proxy, which receives a request from the user and forwards it to the URL map. For HTTPS, configure a regional SSL certificate resource. The target proxy decrypts SSL traffic using the SSL certificate if you configure HTTPS load balancing. The target proxy can forward traffic to your instances via HTTP or HTTPS.

9. A forwarding rule, which has the internal IP address of your load balancer, to forward each incoming request to the target proxy.

Configuring the network and subnets

You need a VPC network with two subnets: one for the load balancer's backends and the other for load balancer's proxies. An internal HTTP(S) load balancer is regional. Traffic within the VPC network is routed to the load balancer if the traffic's source is in a subnet in the same region as the load balancer.

This example uses the following VPC network, region, and subnets:

• Network: The network is a custom-mode VPC network named lb-network.

• Subnet for backends: A subnet named backend-subnet in the us-west1 region uses 10.1.2.0/24 for its primary IP range.

• Subnet for proxies: A subnet named proxy-only-subnet in the us-west1 region uses 10.129.0.0/26 for its primary IP range.

Note: You can change the name of the network, the region, and the parameters for the subnets; however, subsequent steps in this guide use the network, region, and subnet parameters as outlined above.

Configuring the network and subnet for backends

Console

1. Go to the VPC networks page in the Google Cloud Console.
   Go to the VPC network page
2. Click Create VPC network.
3. For the Name, enter lb-network.
4. In the Subnets section:
   • Set the Subnet creation mode to Custom.
   • In the New subnet section, enter the following information:
     • Name: backend-subnet
     • Region: us-west1
     • IP address range: 10.1.2.0/24
     • Click Done.
5. Click Create.

gcloud

1. Create the custom VPC network with the gcloud compute networks create command:

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. Create a subnet in the lb-network network in the us-west1 region with the gcloud compute networks subnets create command:

   gcloud compute networks subnets create backend-subnet \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-west1
   

api

Make a POST request to the networks.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/networks
{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Make a POST request to the subnetworks.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-west1/subnetworks
{
  "name": "backend-subnet",
  "network": "projects/[project-id]/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/[project-id]/regions/us-west1",
}

Configuring the proxy-only subnet

The proxy-only subnet is for all internal HTTP(S) load balancers in the us-west1 region.

Important: Don't try to assign addresses from the proxy-only subnet to your load balancer's forwarding rule or backends. You assign the forwarding rule's IP address and the backend instance IP addresses from a different subnet range (or ranges), not this one. Google Cloud reserves this subnet range for Google Cloud-managed proxies.

console

If you're using the GCP Console, you can wait and create the proxy-only subnet later in the Load Balancing UI. See Continuing the setup process.

gcloud

Create the proxy-only subnet with the gcloud compute networks subnets create command.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/26

api

Create the proxy-only subnet with the subnetworks.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/projects/[project-id]/regions/us-west1/subnetworks
{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/26",
  "network": "projects/[project-id]/global/networks/lb-network",
  "region": "projects/[project-id]/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Configuring firewall rules

This example uses the following firewall rules:

• fw-allow-backend-subnet: An ingress rule, applicable to all targets in the VPC network, allowing all TCP, UDP, and ICMP traffic from sources in the 10.1.2.0/24 range. This rules allows incoming traffic from any source within the backend-subnet to the instances (VMs) being load balanced. The example shows the firewall rule applied to all instances in the network. Alternatively, you can apply the rule only to the actual backends of the load balancer.

• fw-allow-ssh: An ingress rule, applicable to the instances being load balanced, that allows incoming SSH connectivity on TCP port 22 from any address. You can choose a more restrictive source IP range for this rule; for example, you can specify just the IP ranges of the system from which you initiate SSH sessions. This example uses the target tag allow-ssh to identify the VMs to which the firewall rule applies.

• fw-allow-health-check: An ingress rule, applicable to the instances being load balanced, that allows all TCP traffic from the Google Cloud health checking systems (in 130.211.0.0/22 and 35.191.0.0/16). This example uses the target tag load-balanced-backend to identify the instances to which it should apply.

• fw-allow-proxies: An ingress rule, applicable to the instances being load balanced, that allows TCP traffic on ports 80, 443, and 8000 from the internal HTTP(S) load balancer's managed proxies. This example uses the target tag load-balanced-backend to identify the instances to which it should apply.

Without these firewall rules, the default deny ingress rule blocks incoming traffic to the backend instances.

Console

1. Go to the Firewall rules page in the Google Cloud Console.
   Go to the Firewall rules page
2. Click Create firewall rule and enter the following information to create the rule to allow subnet traffic:
   • Name: fw-allow-backend-subnet
   • Network: lb-network
   • Direction of traffic: ingress
   • Action on match: allow
   • Targets: All instances in the network
   • Source filter: IP ranges
   • Source IP ranges: 10.1.2.0/24
   • Protocols and ports:
     • Choose Specified protocols and ports.
     • Check tcp and udp.
     • Under Other protocols, enter icmp.
3. Click Create.
4. Click Create firewall rule again to create the rule to allow incoming SSH connections:
   • Name: fw-allow-ssh
   • Network: lb-network
   • Direction of traffic: ingress
   • Action on match: allow
   • Targets: Specified target tags
   • Target tags: allow-ssh
   • Source filter: IP ranges
   • Source IP ranges: 0.0.0.0/0
   • Protocols and ports:
     • Choose Specified protocols and ports.
     • Check tcp and type 22 for the port number.
5. Click Create.
6. Click Create firewall rule a third time to create the rule to allow Google Cloud health checks:
   • Name: fw-allow-health-check
   • Network: lb-network
   • Direction of traffic: ingress
   • Action on match: allow
   • Targets: Specified target tags
   • Target tags: load-balanced-backend
   • Source filter: IP ranges
   • Source IP ranges: 130.211.0.0/22 and 35.191.0.0/16
   • Protocols and ports:
     • Choose Specified protocols and ports
     • Check tcp and enter 80.
       As a best practice, limit this rule to just the protocols and ports that match those used by your health check. If you use tcp:80 for the protocol and port, Google Cloud can contact your VMs using HTTP on port 80, but it cannot contact them using HTTPS on port 443.
7. Click Create.
8. Click Create firewall rule a fourth time to create the rule to allow the load balancer's proxy servers to connect the backends:
   • Name: fw-allow-proxies
   • Network: lb-network
   • Direction of traffic: ingress
   • Action on match: allow
   • Targets: Specified target tags
   • Target tags: load-balanced-backend
   • Source filter: IP ranges
   • Source IP ranges: 10.129.0.0/26
   • Protocols and ports:
     • Choose Specified protocols and ports.
     • Check tcp and type 80, 443, 8000 for the port numbers.
9. Click Create.

gcloud

1. Create the fw-allow-backend-subnet firewall rule to allow communication from within the subnet with the gcloud compute firewall-rules create command.

   gcloud compute firewall-rules create fw-allow-backend-subnet \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.1.2.0/24 \
       --rules=tcp,udp,icmp
   

2. Create the fw-allow-ssh firewall rule to allow SSH connectivity to VMs with the network tag allow-ssh. When you omit source-ranges, Google Cloud interprets the rule to mean any source.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

3. Create the fw-allow-health-check rule to allow Google Cloud health checks. This example allows all TCP traffic from health check probers; however, you can configure a narrower set of ports to meet your needs.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

4. Create the fw-allow-proxies rule to allow the internal HTTP(S) load balancer's proxies to connect to your backends.

   gcloud compute firewall-rules create fw-allow-proxies \
     --network=lb-network \
     --action=allow \
     --direction=ingress \
     --source-ranges=10.129.0.0/26 \
     --target-tags=load-balanced-backend \
     --rules=tcp:80,tcp:443,tcp:8000
   

api

Create the fw-allow-backend-subnet firewall rule by making a POST request to the firewalls.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
  "name": "fw-allow-backend-subnet",
  "network": "projects/[project-id]/global/networks/lb-network",
  "sourceRanges": [
    "10.1.2.0/24"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS"
}

Create the fw-allow-ssh firewall rule by making a POST request to the firewalls.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
  "name": "fw-allow-ssh",
  "network": "projects/[project-id]/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Create the fw-allow-health-check firewall rule by making a POST request to the firewalls.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/[project-id]/global/firewalls
{
  "name": "fw-allow-health-check",
  "network": "projects/[project-id]/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Create the fw-allow-proxies firewall rule to allow TCP traffic within the proxy subnet the firewalls.insert method, replacing [project-id] with your project ID.

POST https://www.googleapis.com/compute/v1/projects/{project}/global/firewalls
{
  "name": "fw-allow-proxies",
  "network": "projects/[project-id]/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/26"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8000"
      ]
    }
  ],
  "direction": "INGRESS"
}

Continuing the setup process

To set up Internal HTTP(S) Load Balancing, use one of the following procedures, depending on whether your backend services run on Compute Engine VMs or GKE pods:

• Setting Up Internal HTTP(S) Load Balancing for Compute Engine VMs
• Setting Up Internal HTTP(S) Load Balancing for GKE pods

What's next

• See Internal HTTP(S) Load Balancing Concepts for information on how Internal HTTP(S) Load Balancing works.
• See Proxy-only subnet for internal HTTP(S) load balancers for information on managing the proxy-only subnet resource required by Internal HTTP(S) Load Balancing.