Managed instance groups in GCP - Step-by-Step Execution

Process Flow - Managed instance groups

Create Instance Template

↓

Create Managed Instance Group

↓

Group uses Template to launch VMs

↓

Autoscaling & Autohealing Monitor

↓

Add or Remove Instances Automatically

↓

Update Group with New Template

↓

Rolling Update of Instances

↓

Group Stable

This flow shows how a managed instance group is created from a template, then automatically manages VM instances by scaling, healing, and updating them.

Execution Sample

GCP

gcloud compute instance-templates create web-template \
  --machine-type=e2-medium --image-family=debian-11 \
  --image-project=debian-cloud

gcloud compute instance-groups managed create web-group \
  --base-instance-name=web --size=2 \
  --template=web-template --zone=us-central1-a

gcloud compute instance-groups managed set-autoscaling web-group \
  --max-num-replicas=5 --min-num-replicas=1 --target-cpu-utilization=0.6 \
  --zone=us-central1-a

This code creates an instance template, then a managed instance group with 2 VMs, and sets autoscaling based on CPU usage.

Process Table

Step	Action	State Change	Result
1	Create instance template 'web-template'	Template created with Debian 11 image and e2-medium machine type	Template ready for use
2	Create managed instance group 'web-group' with size 2	2 VM instances launched using 'web-template'	Group has 2 running instances
3	Set autoscaling: min 1, max 5, target CPU 60%	Autoscaler monitors CPU usage	Group can scale between 1 and 5 instances
4	CPU usage rises above 60%	Autoscaler adds 1 instance	Group scales up to 3 instances
5	CPU usage drops below 60%	Autoscaler removes 1 instance	Group scales down to 2 instances
6	Update instance template with new software	New template version created	Ready for rolling update
7	Perform rolling update on 'web-group'	Instances replaced one by one with new template	All instances updated and stable
8	Instance fails health check	Autohealing deletes and recreates instance	Group maintains desired size and health
9	Manual resize to 4 instances	Group adds 2 instances	Group now has 4 running instances
10	Autoscaler disables	No automatic scaling	Group size fixed until autoscaler re-enabled
11	Exit	No further actions	Group stable with current instances

💡 Execution stops as group is stable and no further scaling or updates occur

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 7	After Step 9	Final
Instance Template	None	web-template created	web-template created	web-template created	Updated template created	Updated template created	Updated template created
Managed Instance Group Size	0	2	3	2	2 (rolling update ongoing)	4	4
Autoscaler Status	Disabled	Enabled	Enabled	Enabled	Enabled	Enabled	Disabled
Instance Health	N/A	Healthy	Healthy	Healthy	Healthy (rolling update)	Healthy	Healthy

Key Moments - 3 Insights

Why does the managed instance group add or remove instances automatically?

Because the autoscaler monitors CPU usage and adjusts the number of instances to keep CPU near the target, as shown in steps 3, 4, and 5 in the execution table.

What happens during a rolling update of the managed instance group?

Instances are replaced one by one with new versions from the updated template to avoid downtime, as shown in step 7.

How does autohealing keep the group healthy?

If an instance fails health checks, the group deletes and recreates it automatically, maintaining the desired size and health, as shown in step 8.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the group scale up due to high CPU usage?

A Step 4

B Step 5

C Step 7

D Step 9

💡 Hint

Check the 'Action' and 'Result' columns for scaling events related to CPU usage.

According to the variable tracker, what is the group size after step 9?

A 2

B 4

C 3

D 5

💡 Hint

Look at the 'Managed Instance Group Size' row and the 'After Step 9' column.

If autoscaling is disabled at step 10, what happens to the group size afterward?

A It continues to scale automatically

B It immediately scales down to minimum size

C It remains fixed until autoscaler is re-enabled

D It deletes all instances

💡 Hint

Refer to step 10 in the execution table under 'Result' for autoscaler status effects.

Concept Snapshot

Managed instance groups use an instance template to launch identical VMs.
They automatically scale instances based on load and heal unhealthy ones.
Rolling updates replace instances gradually to avoid downtime.
Autoscaling can be configured with min/max sizes and CPU targets.
Autohealing ensures group health by recreating failed instances.

Full Transcript

Managed instance groups start by creating an instance template that defines VM settings. Then, a managed instance group is created using this template, launching a set number of VM instances. Autoscaling monitors CPU usage and adjusts the number of instances automatically to keep performance steady. When CPU usage rises, the group adds instances; when it falls, it removes them. Updates to the group are done by creating a new template version and performing a rolling update, replacing instances one at a time to avoid downtime. Autohealing monitors instance health and replaces any failing instances to keep the group stable. Manual resizing and disabling autoscaling are also possible, giving control over the group size. This process ensures a reliable, scalable, and maintainable VM environment.

Practice

1. What is the main purpose of a Managed Instance Group (MIG) in Google Cloud?

easy

A. To create a single virtual machine with custom settings

B. To run multiple copies of the same virtual machine for reliability

C. To store large amounts of data in the cloud

D. To manage user access and permissions

Solution

1. Step 1: Understand the role of Managed Instance Groups

   Managed Instance Groups run many copies of the same VM to keep applications reliable and available.

2. Step 2: Compare options with this role

   Options describing storage, single VM creation, and permissions are other cloud services, not MIGs.

3. Final Answer:

   To run multiple copies of the same virtual machine for reliability -> Option B

4. Quick Check:

   MIGs = multiple VM copies for reliability [OK]

Hint: MIGs run many identical VMs to keep apps running [OK]

Common Mistakes:

• Confusing MIGs with storage services
• Thinking MIGs manage single VMs only
• Mixing up MIGs with user permission management

2. Which command correctly creates a managed instance group named web-group with 3 instances using the instance template web-template?

easy

A. gcloud compute instance-groups managed create web-group --template=web-template --size=3

B. gcloud compute instance-groups create web-group --template web-template --count 3

C. gcloud compute managed-instances create web-group --template=web-template --size=3

D. gcloud compute instance-groups managed create web-group --template web-template --count=3

Solution

1. Step 1: Identify correct gcloud syntax for managed instance group creation

   The correct command uses 'gcloud compute instance-groups managed create' with '--template' and '--size' flags.

2. Step 2: Check each option for syntax correctness

   gcloud compute instance-groups managed create web-group --template=web-template --size=3 matches the correct syntax exactly. The other options have incorrect flags or command structure.

3. Final Answer:

   gcloud compute instance-groups managed create web-group --template=web-template --size=3 -> Option A

4. Quick Check:

   Correct command syntax = gcloud compute instance-groups managed create web-group --template=web-template --size=3 [OK]

Hint: Use '--template' and '--size' with 'instance-groups managed create' [OK]

Common Mistakes:

• Using 'count' instead of 'size'
• Omitting 'managed' keyword
• Wrong command order or flags

3. Given this autoscaling policy for a managed instance group:

autoscaling:
  minNumReplicas: 2
  maxNumReplicas: 5
  cpuUtilization:
    targetUtilization: 0.6

What happens when CPU usage rises to 80%?

medium

A. The group stays at the current number of instances

B. The group scales down to 2 instances

C. The group scales up by adding more instances, up to 5

D. The group deletes all instances

Solution

1. Step 1: Understand autoscaling triggers

   The target CPU utilization is 60%. When actual CPU usage is 80%, it is above the target.

2. Step 2: Determine autoscaling behavior

   Since CPU usage is higher than target, autoscaler adds instances up to maxNumReplicas (5) to reduce load.

3. Final Answer:

   The group scales up by adding more instances, up to 5 -> Option C

4. Quick Check:

   CPU > target -> scale up [OK]

Hint: CPU above target means add instances [OK]

Common Mistakes:

• Thinking it scales down when CPU is high
• Assuming no change happens
• Confusing min and max replica counts

4. You try to update a managed instance group with a new instance template but get an error. Which is the most likely cause?

medium

A. Autoscaling is disabled

B. You did not specify the rolling update policy

C. The managed instance group has zero instances

D. The instance template name is missing or incorrect

Solution

1. Step 1: Identify common update errors

   Updating a MIG requires a valid instance template name; missing or wrong name causes errors.

2. Step 2: Evaluate other options

   Rolling update policy is optional, zero instances or autoscaling off do not cause update errors.

3. Final Answer:

   The instance template name is missing or incorrect -> Option D

4. Quick Check:

   Invalid template name -> update error [OK]

Hint: Check instance template name carefully when updating MIG [OK]

Common Mistakes:

• Assuming rolling update policy is mandatory
• Ignoring template name correctness
• Confusing autoscaling with update errors

5. You want to ensure zero downtime when updating a managed instance group with a new version of your app. Which strategy should you use?

hard

A. Perform a rolling update with a minimal number of instances unavailable at once

B. Delete all instances and recreate them with the new template immediately

C. Turn off autoscaling before updating and turn it back on after

D. Manually stop each instance, update it, then start it again

Solution

1. Step 1: Understand zero downtime update methods

   Rolling updates replace instances gradually, keeping most instances running to avoid downtime.

2. Step 2: Evaluate other options for downtime risk

   Deleting all instances or manual stop/start causes downtime; turning off autoscaling is unrelated.

3. Final Answer:

   Perform a rolling update with a minimal number of instances unavailable at once -> Option A

4. Quick Check:

   Rolling update = zero downtime [OK]

Hint: Use rolling updates to avoid downtime during MIG changes [OK]

Common Mistakes:

• Deleting all instances at once
• Manual updates causing downtime
• Misunderstanding autoscaling role in updates