Latchu@DevOps

Posted on Sep 2

Part-36: Mastering GCP Managed Instance Groups (Stateless): Load Balancing, Autoscaling & Canary Deployments

#googlecloud #gcp #cloud #tutorial

Google Compute Engine – Managed Instance Groups (Stateless)

Google Cloud’s Managed Instance Groups (MIGs) are one of the most powerful ways to run scalable, reliable applications in the cloud. They let you manage identical VMs as a single logical unit, with support for autoscaling, load balancing, auto-healing, and rolling updates.

🔹 What are Managed Instance Groups (MIGs)?

A Managed Instance Group (MIG) is a collection of identical VM instances created from the same instance template.

With MIGs, you don’t manage VMs individually. Instead, you manage the entire group. If one VM goes down, Google automatically replaces it. If demand increases, MIGs automatically scale your app.

🔹 Why Stateless MIGs?

A stateless MIG is the most common configuration, where all VM instances are identical and do not persist unique state data.

Key points:

All VMs are created using the same instance template.
Instance Template is mandatory.
Recommended for 99% of use cases.

🔹 Features of Stateless MIGs

✅ Load Balancing – Distribute traffic evenly across all VMs.

✅ Multi-zone Deployments – Increase availability by spreading instances across zones.

✅ Autoscaling – Scale in/out based on CPU, load, or custom metrics.

✅ Auto-healing (Health Checks) – Automatically replaces unhealthy instances.

✅ Auto-updating – Rolling updates with minimal downtime.

🔹 Global vs Regional MIGs

📌 Global MIG

Instances are deployed across multiple regions.
Works with Global HTTP(S) Load Balancer.
Best for global-scale applications.

📌 Regional MIG

Instances are deployed across multiple zones within the same region.
Works with Regional Load Balancer.
Best for high availability within one region.

🔹 Step-01: Introduction

An Instance Group is a collection of VM instances that you can manage as a single entity.

👉 A Managed Instance Group (MIG) provides:

✅ Autoscaling – Scale VMs up or down automatically
✅ Auto-healing – Replace unhealthy VMs automatically
✅ Auto-updating – Perform rolling updates with zero downtime
✅ Multi-zone Deployment – Increase availability by spreading instances across zones
✅ Load Balancing – Distribute traffic across VMs

In this demo, we’ll focus on Managed Instance Groups – Stateless, the most commonly used option in production.

🔹 Step-02: Create Instance Template

A Managed Instance Group requires an Instance Template. This defines the machine type, boot disk, startup script, and other configuration details for VMs in the group.

🖥️ Console Steps

Go to Compute Engine → Instance Templates → Create Instance Template
Fill in the following details:

Name: mig-it-stateless-v1
Location: Regional (us-central1)
Machine Type: e2-micro (Series: E2)
Firewall: Allow HTTP traffic
Service Account: Default (with default access)
Startup Script: Add your v1-webserver-install.sh script

Here’s the startup script (v1-webserver-install.sh) we’ll use:

#!/bin/bash
sudo apt install -y telnet
sudo apt install -y nginx
sudo systemctl enable nginx
sudo chmod -R 755 /var/www/html
HOSTNAME=$(hostname)
sudo echo "<!DOCTYPE html> <html> <body style='background-color:rgb(250, 210, 210);'> <h1>Welcome to Latchu@DevOps - WebVM App1 </h1> <p><strong>VM Hostname:</strong> $HOSTNAME</p> <p><strong>VM IP Address:</strong> $(hostname -I)</p> <p><strong>Application Version:</strong> V1</p> <p>Google Cloud Platform - Demos</p> </body></html>" | sudo tee /var/www/html/index.html

Click Create to save the template.

⚡ CLI Equivalent

Prefer the command line? You can create the same instance template with:

# Set Project
gcloud config set project PROJECT_ID
gcloud config set project gcpdemos

# Create Instance Template - V1
gcloud compute instance-templates create mig-it-stateless-v1 \
  --machine-type=e2-micro \
  --network-interface=network=default,network-tier=PREMIUM \
  --instance-template-region=us-central1 \
  --tags=http-server \
  --metadata-from-file=startup-script=v1-webserver-install.sh

🔹 Step-03: Create Health Check

💡 What is a Health Check?

A health check determines whether a VM instance is healthy by periodically sending requests to it.

If an instance consistently responds with the expected result, it’s marked as healthy.
If it fails, it’s marked as unhealthy and the MIG can automatically replace or restart it.

👉 Health checks are essential for:

Load balancing – Only send traffic to healthy VMs
Autoscaling – Scale based on application responsiveness
Auto-healing – Replace failed VMs automatically

🖥️ Console Steps

Go to Compute Engine → Instance Groups → Health Checks → Create Health Check
Fill in the details:

Name: app1-health-check
Scope: Regional
Region: us-central1 (Iowa)
Protocol: HTTP
Port: 80
Request Path: /app1/status.html
Response: App1
Proxy Protocol: None (default)
Logs: Off (recommended to avoid high Cloud Logging costs)
Health Criteria: Leave defaults

Click Create.

⚡ CLI Equivalent

You can also create the health check using gcloud:

# Create Health Check
gcloud compute health-checks create http app1-health-check \
   --project=gcpdemos \
   --port=80 \
   --request-path=/index.html \
   --proxy-header=NONE \
   --response=Welcome \
   --region=us-central1 \
   --no-enable-logging \
   --check-interval=10 \
   --timeout=5 \
   --unhealthy-threshold=3 \
   --healthy-threshold=2

🔹 Step-04: Create a Firewall Rule for Health Checks

Google Cloud’s health check service uses specific IP address ranges to send probes.
If your firewall blocks them, the health check will always fail—even if your app is healthy.

📌 IP Ranges for Health Check Probes

130.211.0.0/22
35.191.0.0/16

📌 Why is this needed?

Our VMs listen on port 80 (HTTP)
Without this rule, the MIG won’t detect VM health correctly
Required for load balancing, auto-healing, and autoscaling

🖥️ Console Steps

Go to VPC Network → Firewall → Create Firewall Rule
Fill in the details:

Name: allow-health-check
Network: default
Targets: All instances in the network (or filter by tags if you prefer)
Source filter: IP ranges
Source ranges:

130.211.0.0/22
35.191.0.0/16

Protocols and ports: tcp:80

Click Create.

⚡ CLI Equivalent

# Create Firewall rule for Health Checks
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

🔹 Step-05: Create a Managed Instance Group (Stateless, Single Zone)

🖥️ Console Steps

Go to Compute Engine → Instance Groups → Create a new Managed Instance Group (stateless)
Fill in the details:

Name: mig-stateless
Description: mig-stateless
Instance Template: mig-it-stateless-v1
Location: Single Zone → us-central1-a

⚙️ Autoscaling Configuration

Autoscaling Mode: On (add/remove instances)
Minimum Instances: 2
Maximum Instances: 6
Autoscaling Signal: CPU Utilization = 60%

🔹 Other Autoscaling Signals:

HTTP Load Balancer Utilization (scale based on request traffic)
Cloud Pub/Sub Queue (scale workers based on message backlog)
Cloud Monitoring Metric (custom scaling using monitoring metrics)

Predictive Autoscaling: ✅ On

Initialization Period: 60 seconds
Scale-in Controls: Enabled - Don’t scale in by more than 1 VM within 10 minutes

⚕️ Autohealing Configuration

Health Check: app1-health-check
Initial Delay: 180 seconds (time given before health checks start evaluating new instances)
Update Policy: Keep existing instance configuration

🌐 Port Mapping

Port Name: webserver-port
Port Number: 80

Click Create. 🚀

⚡ CLI Equivalent

# Create MIG with health check
gcloud compute instance-groups managed create mig-stateless \
   --size=2 \
   --template=projects/gcpdemos/regions/us-central1/instanceTemplates/mig-it-stateless-v1 \
   --zone=us-central1-c \
   --health-check=projects/gcplearn9/regions/us-central1/healthChecks/app1-health-check

# Set Named Ports
gcloud compute instance-groups set-named-ports mig-stateless \
   --zone=us-central1-c \
   --named-ports=webserver-port:80

# Configure Autoscaling
gcloud compute instance-groups managed set-autoscaling mig-stateless \
   --project=gcpdemos \
   --zone=us-central1-c \
   --cool-down-period=60 \
   --max-num-replicas=6 \
   --min-num-replicas=2 \
   --mode=on \
   --target-cpu-utilization=0.6 \
   --scale-in-control=max-scaled-in-replicas=1,time-window=600

🔹 Step-06: Review MIG Properties

Go to Compute Engine → Instance Groups → mig-stateless

Overview Tab: Group size, template, autoscaling details
Details Tab: Health check, port mapping, zone
Monitoring Tab: CPU usage, scaling events, health status
Errors Tab: Any VM creation or health-check-related issues

Go to Compute Engine → VM Instances

Verify that 2 instances have been automatically created using the Instance Template

🔹 Step-07: Create a Load Balancer

Navigate to Network Services → Load Balancing → Create Load Balancer
Choose HTTP(S) Load Balancing → Start Configuration
Global or Regional deployment -> Regional workloads
Select: From Internet to my VMs

🌍 General Settings

Name: lb-for-mig-stateless

🌐 Frontend Configuration

New Frontend IP and port
Name: fip-lb-mig-stateless
Protocol: HTTP
Network Service Tier: Premium
IP Version: IPv4
IP Address: Create new → sip-lb-mig-stateless
Port: 80

Click Done ✅

🔙 Backend Service

Create Backend Service

Name: lb-backend-for-mig-stateless
Description: lb-backend-for-mig-stateless
Backend Type: Instance Group
Protocol: HTTP
Named Port: webserver-port
Timeout: 30s
Backend Group: mig-stateless
Port Number: 80
Balancing Mode: Utilization
Max Backend Utilization: 80%
Capacity: 100

Logging: Off (default)

Security: Not enabled (default)

Click Create.

📑 Host & Path Rules

Mode: Simple host and path rule

Forward all traffic to the backend

✅ Finalize

Review Frontend and Backend configuration

Click Create

Wait 3–5 minutes for provisioning

🔹 Step-08: Verify Load Balancer Properties

Go to Network Services → Load Balancing → lb-for-mig-stateless

Ensure:

Backends show Healthy (health check passing)
Frontend IP is assigned

🔹 Step-09: Access the Sample Application

# Access Sample App in Browser
http://<LB-IP-ADDRESS>
# Example
http://34.149.43.103

# Observe:
# 1. Refresh the browser → You’ll see responses alternating between MIG VMs
# 2. Each VM shows hostname, IP, and version (from startup script)

🔄 To continuously test load balancing in CLI:

while true; do curl http://34.149.43.103/; sleep 1; done

You’ll notice the output switches between instances as the LB distributes traffic across the MIG.

Compute Engine - Instance Groups Autoscaling

What is the core feature of Managed Instance Group(MIG) ?

MIG maintains configured number of instances at any point of time
If a VM Instance crashes, MIG automatically launches a new VM Instance in the instance Group.

What is autoscaling ?

MIGs support autoscaling that dynamically adds or removes VM instances from the group in response to increases or decreases in load
You can configure an autoscaling policy to specify how you want to scale the group.
In your autoscaling policy, you can set one or more signals to scale the group based on CPU utilization, load balancing capacity, Cloud Monitoring metrics and Schedules

🔹 Step-10: Manage Schedules

Sometimes traffic patterns are predictable (e.g., sales, weekly reports, live events). Instead of relying only on reactive scaling, we can schedule MIG capacity ahead of time.

Example: High Traffic Tuesdays

Go to Compute Engine → Instance Groups → mig-stateless

Click on Details tab → Manage Schedules → Create Schedule

Fill in:

Name: high-traffic-tuesday
Description: high-traffic-tuesday
Minimum Required Instances: 3
Start Time: 7:00 AM
Duration: 10 hours
Time Zone: IST (Asia/Calcutta)
Recurrence: Weekly → Tuesday

Click Save → Refresh → Done

This ensures that every Tuesday from 7 AM to 5 PM IST, at least 3 VMs will always be running, even if normal autoscaling would have kept it at 2.

🖥️ CLI Equivalent

gcloud compute instance-groups managed update-autoscaling mig-stateless \
   --project=gcpdemos \
   --zone=us-central1-c \
   --set-schedule=high-traffic-tuesday \
   --schedule-cron='0 7 * * Tue' \
   --schedule-duration-sec=36000 \
   --schedule-time-zone='Asia/Calcutta' \
   --schedule-min-required-replicas=3 \
   --schedule-description='high-traffic-tuesday'

🔹 Step-11: Predictive Autoscaling & Auto-Healing

🔸 Step-11-01: Predictive Autoscaling

Reactive autoscaling works after CPU/traffic load increases. Predictive autoscaling uses machine learning to forecast traffic trends and scale before demand spikes.

To enable:

Go to Compute Engine → Instance Groups → mig-stateless
Click Edit
Under Predictive Autoscaling → click “See if predictive autoscaling can optimize your availability”
Turn Predictive Autoscaling = ON

This helps avoid latency during traffic spikes since MIG VMs are already running when demand arrives.

Compute Engine - Instance Group Auto-Healing

What is auto-healing ?

We already know MIG automatically recreates a new VM Instance when any of the instance in MIG is not in RUNNING state.

Ideally that is not sufficient for maintaining effective high availability of our application.

What happens if application running inside VM Instance freezes, crashes or overloads ?

VM will be in RUNNING state but application is having an issue
At this point, we will have drop in our High Availability due to application unavailability and load on other VM Instances increases.

Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading.

If a health check determines that an application has failed on a VM, the group automatically recreates that VM instance

🔹 Step-11-02: Auto-Healing in Action

One of the most powerful features of Managed Instance Groups (MIGs) is auto-healing.

When a VM becomes unhealthy (failing health checks or app files missing), MIG automatically repairs or recreates the instance to restore service continuity.

🛠️ Demo: Breaking the App & Letting MIG Heal

Connect to one of the MIG-created VM instances:

gcloud compute ssh --zone "us-central1-c" "mig-stateless-2ztq" --project "gcpdemos"

Delete the app files (simulate failure):

cd /var/www/html
sudo rm index.html
sudo rm index.nginx-debian.html

Access the app from browser using VM public IP:

http://<EXTERNAL-IP>

📌 Observation 1:
You’ll see 403 Forbidden error from Nginx because the index.html file is missing.

🔄 Auto-Healing Behavior

MIG will notice that the health check fails for this VM.
It will automatically delete and recreate a new VM with the same name.
The new VM runs the startup script again, reinstalling Nginx and recreating the app’s index.html.
Within a couple of minutes, the service is back online without manual intervention.

✅ Result: The application is automatically restored, ensuring high availability and resilience.

Compute Engine - Instance Group Auto-Updating

What is auto-updating ?

Helps us to easily and safely deploy new version of software to VM Instances in a MIG

What are Rolling Updates ?

Create new Instance Template and update MIG to new instance template
MIG will slowly or gradually do the rolling update of VM Instances to the new Instance Template based on update type selected

When should the VM Instances get updated ?

PROACTIVE (Automatic): Start updates to VMs immediately in the MIG
OPPORTUNISTIC (Selective): Update VMs in MIG when they are replaced, refreshed or restarted except during auto-healing use case.

When Update Type: Automatic - How should the update happen ?

Temporary additional Instances or Maximum Surge: How many temporary instances should be created during deletion of old instances for instance replacement ?

Maximum Unavailable: How many instances can be offline at the same
time while replacing VM instances ?

🔹 Step-12: Updating VMs in Managed Instance Groups

When running production workloads, we often need to:

Update VM machine types for better performance.
Roll out new application versions (via startup scripts).

In MIGs, this is done by creating a new instance template and applying it to the group.

🛠️ Step-12-01: Create a New Instance Template

Here, we’ll clone the existing template mig-it-stateless-v1 and make changes:

Change-1: Machine type → e2-small
Change-2: Startup script → v2-webserver-install.sh

Console Method

Go to Compute Engine → Instance Templates.
Select mig-it-stateless-v1 → Create Similar.
Name → mig-it-stateless-v2.
Machine Type → e2-small.
Update startup script with v2-webserver-install.sh.
Click Create.

CLI Method

# Create Instance Template - V2
gcloud compute instance-templates create mig-it-stateless-v2 \
  --machine-type=e2-small \
  --network-interface=network=default,network-tier=PREMIUM \
  --instance-template-region=us-central1 \
  --tags=http-server \
  --metadata-from-file=startup-script=v2-webserver-install.sh

📜 v2-webserver-install.sh

This script sets up Nginx and deploys App Version V2 with a new background color.

#!/bin/bash
sudo apt install -y telnet
sudo apt install -y nginx
sudo systemctl enable nginx
sudo chmod -R 755 /var/www/html
HOSTNAME=$(hostname)
sudo echo "<!DOCTYPE html> <html> <body style='background-color:rgb(200, 210, 210);'> \
<h1>Welcome to Latchu@DevOps - WebVM App1 </h1> \
<p><strong>VM Hostname:</strong> $HOSTNAME</p> \
<p><strong>VM IP Address:</strong> $(hostname -I)</p> \
<p><strong>Application Version:</strong> V2</p> \
<p>Google Cloud Platform - Demos</p> </body></html>" | sudo tee /var/www/html/index.html

👉 At this stage, we now have two templates:

mig-it-stateless-v1 → App Version V1
mig-it-stateless-v2 → App Version V2

Step-12-02: How to UPDATE VMs setting in Instance Groups ? - UPDATE VMs

Go to Compute Engine -> Instance Groups -> Click on mig-stateless

Instance template & overrides

Instance Template: mig-it-stateless-v2

Update Type: Automatic

When instance configuration changes, updates to existing VMs will be applied automatically by MIG. (API name: PROACTIVE)

1. You are deploying template "mig-it-stateless-v1" to 50% of instances and template "mig-it-stateless-v2" to 50% of instances in instance group "mig-stateless".
2. 1 instance will be taken offline at a time and 1 instance will be temporarily added to support the update.

Actions allowed to update VMs: only replace (Discuss all options)
When replacing keep VM names same: leave empty (leave to defaults - NOT CHECKED)
Temporary additional instances: 1
Maximum unavailable instances: 1
Minimum wait time: 0 seconds
Click on SAVE

Step-12-03: Verify the VM Instances

Go to Compute Engine -> VM Instances
We should observe one VM created with e2-small
We should see finally we end up with 2 VMs

 2VMs with e2-small

We should see V2 version of application deployed
Observation: It will take few minutes (approximately 10 minutes) to complete the overall process and reach desired state

# Access Application using Load balancer
curl http://35.209.128.93/
http://35.209.128.93/

# In a while loop
while true; do curl http://35.209.128.93/; sleep 1; done

🔹 Step-13: Explore DELETE INSTANCE Setting

In a Managed Instance Group, if you delete a VM manually, the MIG controller automatically notices the missing instance and re-creates a new one to maintain the desired group size.

Demo:

Go to Compute Engine → Instance Groups → mig-stateless.
Select one instance → Click Delete.
Wait for a couple of minutes.
A new instance with a different name is created to replace the deleted VM.

👉 This demonstrates the self-healing nature of MIGs.

🔹 Step-14: Explore REMOVE FROM GROUP Setting

Unlike deletion, Remove from Group detaches the instance from the MIG but doesn’t delete it immediately.

Demo:

Go to Compute Engine → Instance Groups → mig-stateless.
Select one VM → Click Remove from Group.
Wait a few minutes. A new instance will be created to maintain the group size.
Go to VM Instances → Manually delete the detached instance (option becomes available after removal).

👉 This is useful when you want to keep a VM for debugging without MIG trying to replace it instantly.

🔹 Step-15: Explore RESTART / REPLACE VMs Setting

Sometimes you need to restart or replace all VMs in a MIG (for upgrades or maintenance). MIG provides two options:

🌀 Step-15-01: Restart Option

Restarts existing VMs without recreating them.
Settings:
Maximum unavailable: 1 instance
Minimum wait time: 0 seconds
Action: Click Restart → Instances reboot one by one.

👉 Useful for applying in-place OS updates or maintenance tasks.

🔄 Step-15-02: Replace Option

Fully recreates VMs (deletes old ones, provisions new ones).
Settings:
Maximum surge: 1 instance (temporary extra VMs allowed during replacement).
Maximum unavailable: 1 instance.
Minimum wait time: 0 seconds.
Action: Click Replace → MIG creates new VMs, removes old ones.

👉 Useful when applying a new instance template or upgrading VM specs.

🔹 Step-16: Review Monitoring Tab

MIG provides a built-in Monitoring tab with useful insights:

Instances graph → shows VM counts scaling in/out.
Autoscaling history → highlights when MIG added or removed VMs.
Health check status → shows how auto-healing kept your app healthy.

👉 Monitoring is crucial for validating whether autoscaling, healing, and updates behave as expected in real workloads.

Compute Engine - Instance Group Canary Updates

What is Canary Deployment ?

Test new application version with group of instances before releasing it across all instances.
In rolling update type, we will completely switch the instance template from old to new and gradually update VMs based on update type
In canary deployment model, we will add second instance template by specifying Target Size (50% or 1 VM) where new application version should
be deployed.

Goto > Instance groups > Select your group > Edit > Instance templates and overrides > Add > v1 group with 50 percent serving traffic > Save

Cleanup

Delete the Loadbalancer
Release External IP Address used for LB
Delete Instance group
Delete Instance templates

DEV Community

Part-36: Mastering GCP Managed Instance Groups (Stateless): Load Balancing, Autoscaling & Canary Deployments

Google Compute Engine – Managed Instance Groups (Stateless)

🔹 What are Managed Instance Groups (MIGs)?

🔹 Why Stateless MIGs?

🔹 Features of Stateless MIGs

🔹 Global vs Regional MIGs

🔹 Step-01: Introduction

🔹 Step-02: Create Instance Template

🔹 Step-03: Create Health Check

🔹 Step-04: Create a Firewall Rule for Health Checks

🔹 Step-05: Create a Managed Instance Group (Stateless, Single Zone)

🔹 Step-06: Review MIG Properties

🔹 Step-07: Create a Load Balancer

🔹 Step-08: Verify Load Balancer Properties

🔹 Step-09: Access the Sample Application

Compute Engine - Instance Groups Autoscaling

🔹 Step-10: Manage Schedules

🔹 Step-11: Predictive Autoscaling & Auto-Healing

Compute Engine - Instance Group Auto-Healing

Compute Engine - Instance Group Auto-Updating

🔹 Step-12: Updating VMs in Managed Instance Groups

🔹 Step-13: Explore DELETE INSTANCE Setting

🔹 Step-14: Explore REMOVE FROM GROUP Setting

🔹 Step-15: Explore RESTART / REPLACE VMs Setting

🔹 Step-16: Review Monitoring Tab

Compute Engine - Instance Group Canary Updates

Cleanup

Top comments (0)