Setup Http(s) Load balancing with Managed Instance Groups on GCP Using the Windows Powershell or Command Prompt
Note: You can use the “google cloud sdk shell” that has been provided for Windows.
Prerequisites:
- Google cloud sdk installed and activated, and
- Windows admin access rights
- For powershell (non-gcp installed version) and command prompt run both as “admin user”.
In continuation of my desire to show users how easy it is to use the powershell or command prompt on Window to get work done I will be sharing with the steps involved in setting up an http(s) load balancer on GCP using these tools. We will be using the image bellow, borrowed from google cloud:
to build this load balancer but before we do that let us make some useful deductions from this image with respect to our task:
- The global forwarding rule, along with target proxy are the “frontend” in this setup,
- The “url map” is the load balancer itself and maps a given “url” to a backend service (and this can be many),
- The global backend service is the backend service that receives traffic from the “url-map” service and sends it to the backend vm instances. It uses the health check to determine the current state of the vm instances and from this determines who gets traffic,
- Global health check send probes to the vm instances and reports their state to both the instance groups and the backend service,
- Instance groups are used to manage a group of vm instances and autoscale using the autoscaling policies and perform autohealing using the health check information provided by the health check service, and
- Internet is just the internet :-).
Now start by setting up the templates and instance groups:
a. Create the instance templates with these commands:
- We create the instance that will be used for creating the template
gcloud compute instances create instance-template-base --machine-type=f1-micro --zone=us-central1-a --tags=”http-server,https-server” --no-boot-disk-auto-delete
- Then delete the instance, but the boot disk is left as we required this with the command option “ — no-boot-disk-auto-delete”
gcloud compute instances delete instance-template-base --zone=us-central1-a
- We now create an image from the disk for use with instance template creation
gcloud compute images create instance-template-image --source-disk=instance-template-base
- Finally we add the “http-tag” for use by the firewall rule that we will be creating. This allows the health check probe access to the vm instances, and the “http-server” and “https-server” tags will enable “http” traffic on the created vms.
gcloud compute instance-templates create instance-template --machine-type=f1-micro --image=instance-template-image --image-project=egusi-new-soup --boot-disk-size=10GB --boot-disk-type=pd-standard --tags=”http-server,https-server,http-tag”
b. Create the health check:
gcloud compute health-checks create http instance-health-check --check-interval=10s --port=80 --timeout=5s --unhealthy-threshold=3 --project egusi-new-soup
c. Create the instance groups and set up autoscaling, it’s a two part command:
gcloud compute instance-groups managed create us-webserver-instancegroup --size=1 --template=instance-template--initial-delay=60 --health-check=instance-health-check --region=us-central1
- contd…
gcloud compute instance-groups managed set-autoscaling us-webserver-instancegroup --max-num-replicas=6 --min-num-replicas=3 --scale-based-on-cpu --target-cpu-utilization=0.6 --cool-down-period=60 --region=us-central1
Create the same for region “us-west1”, use the name “west-webserver-instancegroup”.
d. Set up the backend service and add the above created instance groups:
gcloud compute backend-services create webserver-backend --protocol=http --port-name=http --timeout=30s --health-checks=instance-health-check --global
- Contd…
gcloud compute backend-services add-backend webserver-backend --instance-group=us-webserver-instancegroup --instance-group-region=us-central1 --balancing-mode=utilization --capacity-scaler=1 --max-utilization=0.8 --global
- Contd…
gcloud compute backend-services add-backend webserver-backend --instance-group=west-webserver-instancegroup --instance-group-region=us-west1 --balancing-mode=utilization --capacity-scaler=1 --max-utilization=0.8 --global
e. Create the “url map” service:
gcloud compute url-maps create egusi-url-map --default-service webserver-backend
f. Create the static ip but we could also use an ephemeral ip:
gcloud compute addresses create instance-global-static-ip --ip-version=ipv4 --global
g. Create the target proxy:
gcloud compute target-http-proxies create webserver-proxy --url-map egusi-url-map
h. Now let us create the forwarding rule:
gcloud compute forwarding-rules create instance-webserver-frontend --ip-protocol=tcp --ports=80 --global --target-http-proxy webserver-proxy --address=instance-global-static-ip
i. Create the firewall rule that the “health check” will use:
gcloud compute firewall-rules create health-check-rule --action=ALLOW --rules=tcp:80 --source-ranges="35.191.0.0/16,130.211.0.0/22" --destination=INGRESS --target-tags=http-tag
And we are set to use the load balancer, but give it a few minutes to get the health checks to kick in. Other forms of load balancing can be implemented using the powershell or the command prompt and this is one of the first lessons I learnt using Linux as in some cases we may not have a visual display to work with and using this method gives you a good understanding of the inner workings of the gcp and helps in trouble shooting issues when they arise. Please leave clap if you found this useful.