DEV Community

Cover image for Part-37: 🚀 Google Compute Engine – Managed Instance Groups (Stateful) in Google Cloud Platform (GCP)
Latchu@DevOps
Latchu@DevOps

Posted on

Part-37: 🚀 Google Compute Engine – Managed Instance Groups (Stateful) in Google Cloud Platform (GCP)

#googlecloud #gcp #cloud #tutorial

When deploying workloads on Google Cloud Platform (GCP), Managed Instance Groups (MIGs) are one of the most powerful ways to run scalable and resilient applications. While Stateless MIGs are ideal for most scenarios, some applications require persistent state — this is where Stateful MIGs come into play.

🔹 What is a Stateful MIG?

A Stateful Managed Instance Group is a special type of MIG that can preserve unique state for each VM instance in the group.
This means that when MIG auto-heals, updates, or replaces VMs, it can retain disks, metadata, and IP addresses, ensuring continuity for workloads that depend on instance-specific data.

Key preserved components:

  • Persistent Disks (Boot & Data Disks)
  • Instance Metadata
  • Customizable Instance Names
  • Internal & External IP addresses

ss1

🔹 Key Features of Stateful MIGs

⚡ Load Balancing – Distribute traffic across instances.

🌍 Multi-zone Deployments – High availability across zones.

🩺 Auto-healing (with Health Checks) – Replace unhealthy instances without losing state.

🔄 Auto-updating – Apply updates while keeping stateful resources intact.

💾 Disk & Metadata Preservation – Keep data and configurations tied to each VM.

⚠️ Note: Unlike Stateless MIGs, Autoscaling is NOT supported for Stateful MIGs, since scaling in/out could result in loss of preserved state.

🔹 When to Use Stateful MIGs?

Stateful MIGs are recommended for applications that cannot function without maintaining unique state per instance, such as:

  • 🗄 Databases (MySQL, PostgreSQL, MongoDB, etc.)
  • 🏛 Legacy monolithic applications that depend on local storage or custom configurations
  • 🕒 Long-running batch computations requiring persistent local data

Instance Groups - Unmanaged vs Stateless MIG vs Stateful MIG

When working with Google Compute Engine, you’ll often need to manage multiple VMs together. This is where Instance Groups come into play.
But not all instance groups are the same — you can choose between Unmanaged, Stateless Managed (MIGs), and Stateful Managed (MIGs) depending on your use case.

Here’s a breakdown 👇

ss2

🟦 1. Unmanaged Instance Groups

  • VMs are non-identical (different configurations allowed, e.g., e2-small + e2-medium).
  • Supports Load Balancing only.
  • ❌ No autoscaling, auto-healing, auto-updating, or multi-zone deployments.
  • Instance Template is not required.
  • ⚠️ Not recommended unless you want to manage VMs manually or run non-identical VMs in one group.

🟧 2. Managed Instance Groups – Stateless (MIGs)

VMs are identical (created from Instance Templates).

Example: All instances are e2-small.

✅ Supports:

  • Load Balancing
  • Multi-zone deployments
  • Autoscaling
  • Auto-healing
  • Auto-updating

Instance Template is mandatory.

Recommended in 99% of use cases where workloads are stateless and scale horizontally (e.g., web servers, app servers).

🟩 3. Managed Instance Groups – Stateful (MIGs)

VMs are identical, but state can be preserved.

Can retain:

  • Persistent Disks (Boot + Data)
  • Instance Metadata
  • Internal & External IPs

✅ Supports:

  • Load Balancing
  • Multi-zone deployments
  • Auto-healing
  • Auto-updating

❌ Autoscaling is not supported (to avoid losing preserved state).

Instance Template is mandatory.

Recommended for stateful applications, such as:

  • Databases
  • Legacy monolithic apps
  • Long-running computations with persistent data

Create a MIG Stateful

Step-01: Introduction

Instance Group: An instance group is a collection of virtual machine (VM) instances that you can manage as a single entity.

Instance Groups Types

  • Unmanaged Instance Group

Load Balancing

  • Managed Instance Group (Stateless)

Autoscaling
Autohealing
Auto-updating
Multi-Zone Deployment
Load Balancing

  • Managed Instance Group (Stateful)

Autohealing and updating
Disk and Metadata Preservation
Multi-Zone Deployment
Load Balancing

In this demo, we are going to focus on Managed Instance Groups - Stateful

Step-02: Create Health Check

What is Health Check?

  • A health check determines whether a VM instance is healthy by sending requests to the instance.
  • An instance is considered healthy if it returns consecutive responses within a specified time.

  • Health checks are used for load balancing and autoscaling managed instance groups

  • Go to Compute Engine -> Instance Groups -> Health Checks -> CREATE HEALTH CHECK

  • Name: app1-health-check

  • Description:

  • Scope: Regional

  • Region: us-central-1 (IOWA)

  • Protocol: HTTP

  • Port: 80

  • Proxy Protocol: None

  • Request Path: /index.html

  • Response: App1

  • Host HTTP Header: leave empty (leave to defaults)

  • Logs: Off (leave to defaults) If enabled Cloud Logging cost is going to be high

  • Health Criteria: Leave to defaults

  • Click on CREATE

CLI Equivalent

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

Step-03: Create a firewall rule to allow health check probes to connect to your app

Health check probes come from addresses in the ranges 130.211.0.0/22 and 35.191.0.0/16, so make sure your firewall rules allow the health check to connect. For this example, the MIG uses the default network, and its VMs listen on port 80. If port 80 isn't already open on the default network, create a firewall rule.

# Create Firewall rule
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
Enter fullscreen mode Exit fullscreen mode

Step-04: Create Instance Template with additional persistent disk

  • Go to Compute Enginer -> Virtual Machines -> Instance Templates -> Create Instance Template
  • Name: mig-it-stateful-v1
  • Location: Regional
  • Region: us-central1

ss3

  • Machine Configuration:

Series: E2
Machine Type: e2-micro

  • Availability Policies:

VM Provisioning Model: Standard

  • Display Device: unchecked (leave to default)
  • Confidential VM Service: unchecked (leave to default)
  • Container: unchecked (leave to default)
  • Boot Disk: Leave to defaults
  • Identity and API Access:

Service Account: Compute Engine default Service Account
Access Scopes: Allow default Access

  • Firewall

Allow HTTP Traffic

  • Advanced Options - Management:

Description: demo4-vm-startupscript
eservations: Automatically use created reservation (leave to default)
Automation: > Startup Script: Copy paste content from webserver-install.sh file

webserver-install.sh

#!/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
Enter fullscreen mode Exit fullscreen mode
  • CLick on disks
  • Additional disks: Click on Add new disk

Name: autogenerated
Description: persistent-disk-1
Type: Balanced persistent disk
Source type: Blank disk
Mode: Read/Write
Deletion rule: Keep disk / Delete disk (Even if we put delete disk also when we create stateful MIG, this setting will be override)
Size(GB): 12
Device name: Custom
name: persistent-disk-1
Click on Done

ss4

ss5

  • Click on CREATE

ss6

Step-05: Create Managed Instance Group Stateful Single Zone

Persistent Disks

Disk will be preserved during VM lifetime. It will be reattached on instance recreation, autohealing, and update events, and deleted on permanent instance deletion.

Persistent Internal and External IPs

IP will be preserved during VM lifetime. It will be reattached on instance recreation, autohealing, and update events, and deleted on permanent instance deletion.

Create Managed Instance Group - Stateful

  • Name: mig-stateful
  • Description: mig-stateful
  • Location: Single Zone
  • Region: us-central1
  • Zone: us-central1-a
  • Instance Template: mig-it-stateful
  • Number of Instances: 2

ss7

ss8

  • Stateful configuration:
  • Persistent-disk-1:

DEVICE NAME: persistent-disk-1
Stateful: YES
On permanent instance deletion: Detach disk
Yes: Disk will be preserved during VM lifetime. It will be reattached on instance recreation, autohealing, and update events, and deleted on permanent instance deletion.
No: Disk will be detached on instance deletion.
Note: The disk disk_persistent-disk-1 will be preserved beyond the VM’s lifetime. It will be reattached on instance recreation, autohealing, and update events, and detached on instance deletion.

  • External IP address:

Stateful: YES
NOTE: IP will be preserved during VM lifetime. It will be reattached on instance recreation, autohealing, and update events, and deleted on permanent instance deletion.
On permanent instance deletion: DETACH IP
Note: IP from default network will be preserved beyond the VM’s lifetime. It will be reattached on instance recreation, autohealing, and update events, and detached on instance deletion.

  • Internal IP address:

Stateful: YES
NOTE: IP will be preserved during VM lifetime. It will be reattached on instance recreation, autohealing, and update events, and deleted on permanent instance deletion.
On permanent instance deletion: DETACH IP
Note: IP from default network will be preserved beyond the VM’s lifetime. It will be reattached on instance recreation, autohealing, and update events, and detached on instance deletion.

ss9

  • VM Instance lifecycle: leave to defaults

Action on failure: Repair instance

ss10

  • Autohealing:
  • Health check: app1-health-check
  • Initial Delay: 300 seconds
  • Updates during VM instance repair: Keep the same instance configuration
  • Specify Port Name Mapping:

Port Name: webserver-port
Port Numbers: 80

ss11

  • Advanced creation options: leave to defaults and discuss
  • Click on CREATE

Step-06: Review Managed Instance Group Properties

  • Go to Compute Engine -> Instance Groups -> Verify Group Type Stateful

ss12

  • Go to Compute Engine -> Instance Groups -> Click on mig-stateful
  • Review the following Tabs

Overview
Details
Monitoring
Errors (Not applicable for Unmanaged Instance Groups)

  • Go to Compute Engine -> VM Instances -> Verify VM created by Instance Group

ss13

  • Go to Compute Engine -> Disks -> Verify Disks created for Stateful Instance Group.

ss14

Step-07: Delete Stateful Managed Instance Group Stateful

  • Go to Compute Engine -> Instance Groups -> Click on mig-stateful
  • Click on DELETE GROUP
  • Go to Compute Engine -> Disks -> Verify Disks created for Stateful Instance Group.

# Sample disk name format
mig-stateful-wgh6-1

Even after deleting the Stateful Instance Group, we can see disks are still present because they got detached and persisted

Step-08: Clean-Up - Delete Disk

  • Delete the disk whatever created as per this demo.
  • Go to Compute Engine -> Disks -> mig-stateful-wgh6-1 -> Actions -> Delete

ss15

# Sample disk name format
managed-instance-group-stateful-wgh6-1

Step-09: Delete External and Internal IP

Go to VPC Network -> IP Addresses
Release External and Internal IP addresses

Top comments (0)